InfoCenter Home >
3: Migration overview >
3.6: Interoperability with WebSphere Application Server for z/OS

3.6: Interoperability with WebSphere Application Server for z/OS

Interoperability between the Advanced Edition (AE) product and WebSphere Application Server for z/OS can be achieved by using RMI over IIOP to propagate transaction and security contexts.

Transactions

WebSphere provides this function by supporting distributed transactions involving enterprise beans running in both the AE and z/OS application servers. To enable the interoperability, set the following flags in the JVM settings (system properties) of the AE server:

"-Dcom.ibm.ejs.jts.jts.ControlSet.nativeOnly=false"
"-Dcom.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true"

To set the arguments with the administrative console:

  1. Select the application server node in the administrative domain tree.
  2. Click the JVM Settings tab.
  3. Add the arguments to the System Properties list.

Important: The default installation of the AE product provides a datasource that does not support the two-phase commit protocol. If your application involves a resource manager on a workstation and a resource manager on z/OS, you need to set up two-phase commit support. For this, you must use a JTA-enabled JDBC driver on the AE product by selecting the DB2 implementation class to be COM.ibm.db2.jdbc.DB2XADataSource. For details about defining a datasource and configuring it to use the JTA-enabled JDBC driver, see the related information.

Security authentication

In the Advanced Edition (AE) product, the security authentication service supports interoperability with WebSphere application servers for z/OS. If configured, this support allows only secure AE application servers to connect with secure z/OS targets that authenticate user IDs and passwords defined in a key file.

Important: This support requires the application of corrective service to the z/OS product. For details, see the AE product release notes.

To configure a secure application server to log on and access protected resources on a secure z/OS target, perform the following steps:

  1. Create a key file and add log-in information
  2. Enable security with the AE application server
  3. Enable security with the z/OS application server
  4. Prepare a valid Java Key Store for the AE application server
  5. Configure the AE application server
  6. Configure the z/OS application server
Create a key file and add log-in information
First, a key file must be created. Log-in information (target realm, user ID, and password) for each different z/OS target must be stored in the key file, which is simply a text file. When the security authentication service processes the key file, the passwords in the file will be encoded.

Add information to the key file in the following format:

RealmName   UserID   Password

Make sure that the data conforms to the following rules:

  • One realm name, one user ID, and one password defined in each entry
  • One entry per line
  • No blank lines between entries
  • Comments on separate lines only
  • Begin any comment with a pound sign (#)

Example:

# Sample key file
#
# First target realm
#
TargetRealm serverID serverPassword
#
# Second target realm
#
TargetRealm2 serverID2 serverPassword2
#
# End of key file

The realm name of a z/OS target is the IP name of the daemon as specified in the configuration of the z/OS product. The user ID and password are as defined for SSL-secured z/OS servers.

A sample file named wsserver.key contains these instructions and is shipped with the AE product. After installation, the sample file can be found in AE_installation_root\properties. You may use or modify the sample file as needed for testing.

Note: The key file can be placed anywhere on a host machine running the application server. However, it is recommended that you place the key file under a securable file system (for example, NTFS for Windows NT).

Enable security with the AE application server

Global security must be enabled. For details, see the related information.

Enable security with the z/OS application server

For details, see WebSphere Application Server for z/OS and OS/390: Installation and Customization (GA22-7834).

Prepare a valid Java Key Store for the AE application server

Secure Socket Layer (SSL) protocol is used to protect communication between AE and z/OS application servers. In order to complete the SSL connection at both ends, a valid Java key store for the AE server must be established as follows. You can use the Java key store file that is already used by the AE application server. If you do not have the key store file created already, see the related information to create one.

  1. Extract the public key of the z/OS server by using the key management tool of z/OS.

    For details, see WebSphere Application Server for z/OS and OS/390: Installation and Customization (GA22-7834).

  2. From the AE product, start the iKeyman tool to open the key store file of the AE application server. Using the iKeyman tool, add the extracted public key from the z/OS server as a signer certificate into the AE server's Java store file. For efficient key management, it is recommended that you store the public key in the trust file.

    For details, see the related information.

The AE server's Java key store file is now ready to interoperate with z/OS targets.

Configure the AE application server

After the Java key store file is ready and global security is enabled, resources like enterprise beans that will access z/OS also need to be configured. Before deploying the enterprise beans, RunAs Identity must be configured for each enterprise bean accessing z/OS resources. Because the security authentication service currently supports only AE application servers with z/OS targets, set RunAs Identity to System Identity.

Next, the server configuration must be updated. First, apply the Java key store file change as follows:

  1. From the Administrator Console, select the application server.
  2. From the right panel, click the Services tab.
  3. Select Object Request Broker from the list.
  4. Click Edit Properties.
  5. From the Object Request Broker panel, click Configure SSL.
  6. From the ORB SSL Configuration Properties panel, click the Enable SSL check box.
  7. In the Trust file name field, type the absolute path for the previously created Java key store file. Provide the appropriate password and format for the trust file.
  8. Click OK twice to go back to the administrative console.
  9. Click Apply.
  10. If the server is already running, restart it.

Next, set some Java properties as follows:

  1. From the Administrator Console, select the application server.
  2. From the right panel, click the Services tab.
  3. Select Object Request Broker from the list.
  4. Click Edit Properties.
  5. Set the Request timeout and Locate request timeout properties to 0.

    When the z/OS application server is first started, no server region is available for processing work. It is therefore recommended that you set these two properties to 0 in order to prevent potential timeouts.

  6. Click OK twice to go back to the administrative console.
  7. Click Apply.
  8. If the server is already running, restart it.

Finally, add a property to the property file used by the application server (that is, sas.server.props). The com.ibm.CORBA.keyFileName property must be set to the absolute path of the login key file created earlier, as follows:

com.ibm.CORBA.keyFileName=c\:/WebSphere/AppServer/properties/wsserver.key
Configure the z/OS application server

For details, see WebSphere Application Server for z/OS and OS/390: Installation and Customization (GA22-7834).

Go to previous article: Switching server databases to DB2/390: Switching administrative databases Go to next article: Interoperability with Version 3.5.x

 

 
Go to previous article: Switching server databases to DB2/390: Switching administrative databases Go to next article: Interoperability with Version 3.5.x