Deployment descriptor options for service clients

The options you must set to create a service client binding in the EGL deployment descriptor file differ depending on the type of service your application is using.

Web (SOAP) services

When you create a SOAP Web binding in the deployment descriptor editor, fill in the following fields:
WSDL File
The name of the WSDL file representing the service.
WSDL File
The name of the WSDL file representing the service.
Web Binding Name
A mnemonic for the binding.
Interface
The fully qualified name of a Service part or Interface part in the client application. This part represents the service in logic parts within the client.
WSDL Port
The name of the port used by the binding. Services can have multiple ports, in order to provide different services to different clients, but a service client binding can reference only one port in the service.
WSDL Service
The name of the service as listed in the WSDL file.
WSDL URI
If specified, the value of this option overrides the URL in the WSDL file. If you know that the service is available at a location other than the location specified in the WSDL file, such as a different version of the service used for production or testing, you can enter that location here and use that version of the service instead. By default, this value is null.
Enable Generate
For clients being generated to COBOL, this option specifies whether to generate the Web service access layer when you generate the deployment descriptor. You must generate the Web service access layer at least once so EGL will create the code necessary to access the service, but once you have generated it, you do not need to generate it again unless you change the information in the service client binding. Generating the Web service access layer can be time-consuming, so you may want to clear this check box to save time.
For clients being generated to Java™, this option specifies whether to add binding information to the binding file in the generated output. This information is required, so you must select this option for clients being generated to Java.

Web (REST) services

When you create a service client binding in the deployment descriptor editor for a REST service, EGL fills in default values for the following options:
REST Binding Name
A mnemonic for the binding.
Interface
The fully qualified name of a Service part or Interface part in the client application. This part represents the service in logic parts within the client.
WSDL File
The name of the WSDL file representing the service.
WSDL Port
The name of the port used by the binding. Services can have multiple ports, in order to provide different services to different clients, but a service client binding can reference only one port in the service.
WSDL Service
The name of the service as listed in the WSDL file.
WSDL URI
If specified, the value of this option overrides the URL in the WSDL file. If you know that the service is available at a location other than the location specified in the WSDL file, such as a different version of the service used for production or testing, you can enter that location here and use that version of the service instead. By default, this value is null.
Enable Generate
For clients being generated to COBOL, this option specifies whether to generate the Web service access layer when you generate the deployment descriptor. You must generate the Web service access layer at least once so EGL will create the code necessary to access the service, but once you have generated it, you do not need to generate it again unless you change the information in the service client binding. Generating the Web service access layer can be time-consuming, so you may want to clear this check box to save time.
For clients being generated to Java, this option specifies whether to add binding information to the binding file in the generated output. This information is required, so you must select this option for clients being generated to Java.

EGL and native services

EGL and native services are not associated with WSDL files, as Web services are. Therefore, when you create a service client binding to an EGL or native service, you must enter information about how to access the service. The information necessary depends on the type of connection you are using to access the service.

EGL supports the following types of connections from a client to an EGL service:
SYSTEM-I LOCAL
For a client accessing a service in the same run unit. This type of connection is appropriate for services and clients generated to Java or COBOL.
CICSECI
For a Java client accessing a COBOL service through the CICS® Transaction Gateway (CTG) ECI interface.
CICSSSL
For a Java client accessing a COBOL service through the Secure Socket Layer (SSL) features of CICS Transaction Gateway (CTG).
CICSJ2C
For a Java client accessing a COBOL service through a J2C connector for the CICS Transaction Gateway.
JAVA400
For a Java client accessing a COBOL service that is on iSeries®. In this case, the connection details are managed by the Java client.
JAVA400J2C
For a Java client accessing a COBOL service that is on iSeries. This option is available only if the Java client is running under a fully JEE-compliant application server: for example, WebSphere® Application Server rather than Apache Tomcat. When JAVA400J2C is in use, the connection details such as security credentials are managed by the application server. EGL-generated applications should not share J2C connectors with non-EGL-generated applications.

JAVA400J2C does not support a stateful invocation but lets the user control the current library and library list used on the host.

TCPIP
For a Java client accessing a Java service through the TCP/IP protocol.
EGL supports the following types of connections from a client to a native service:
SYSTEM-I.LOCAL
For a COBOL client accessing a COBOL service that is on the same iSeries machine.
JAVA400
For a Java client accessing a COBOL service that is on iSeries. In this case, the connection details are managed by the Java client.
JAVA400J2C
For a Java client accessing a COBOL service that is on iSeries. This option is available only if the Java client is running under a fully JEE-compliant application server: for example, WebSphere Application Server rather than Apache Tomcat. When JAVA400J2C is in use, the connection details such as security credentials are managed by the application server. EGL-generated applications should not share J2C connectors with non-EGL-generated applications.

JAVA400J2C does not support a stateful invocation, but lets the user control the current library and library list used on the host.

The following options apply to all types of connections:
Name
The name used to access the binding; essentially, a key.
Service name
The name of the service.
Alias
A substitute name for the service if the service name is not legal in the target environment.

Depending on the type of connection, the deployment descriptor editor will prompt you for some of the following options:

bindDir
For a SYSTEM-I.LOCAL connection, a fully qualified binding directory such as LIBNAME/BIND_DIR_NAME, as used to access the service program
conversionTable
The name of the conversion table that is used to convert data on a call to the service. Conversion is necessary when the code page that is used for encoding text on the service is different from the encoding that is used on the client. See Data conversion for information on conversion tables.
ctgKeyStore
The name of the key store generated with the CICS Transaction Gateway tool IKEYMAN.
ctgKeyStorePassword
The password used when generating the key store.
ctgLocation
The URL for accessing the service through a CICS Transaction Gateway (CTG) server. Specify the related port with the ctgPort option.
ctgPort
The port through which to access a service through a CICS Transaction Gateway (CTG) server.
library
For a JAVA400 or SYSTEM-I.LOCAL connection, the name of the library in which the service is located on the iSeries system. For a JAVA400J2C connection, specify a value in the following form:
currentLibrary:libraryList
currentLibrary
The current library; as used to set the library on the host job. For example, *USRPRF.or *CRTDFT.
libraryList
A list of libraries, such that each entry is a library name followed by a position value that defaults to * LAST (ensuring that the entry is placed after any entries that have the alternative position value, which is *FIRST).
Here is an example value for library:
*USRPRF:MYMQLIB,MYFILLIB,MYDBLIB *FIRST
location
For a TCPIP connection, the TCPIP host name or address. For a JAVA400 connection, the server and path on which the service is located, such as myServer.myCompany.com/myService. For a JAVA400J2C, the JNDI name specified in the application server. For a CICSECI or CICSSSL connection, the CICS system identifier. For a CICSJ2C connection, the JNDI name of the ConnectionFactory object that you establish for the CICS transaction started by the call.
password
The password for the iSeries system. Specify the user ID with the userID option. The user ID for the iSeries system. If the connection type is JAVA400J2C, the security credentials are usually handled by the application server; but if you specify userID and password in the connection, the values you specify are used in place of any others.
serverID
For a TCPIP connection, the port number of the service's listener. For a CICSJ2C, CICSSSL, or CICSECI connection, the ID of a CICS transaction being called. The default is the CICS server system mirror transaction (CPMI).
userID
The user ID for the iSeries system. If the connection type is JAVA400J2C, the security credentials are usually handled by the application server; but if you specify userID and password in the connection, the values you specify are used in place of any others.

Feedback