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.