4 Managing Oracle SOA Suite on IBM WebSphere

4.2.1 Oracle SOA Suite wsadmin and WLST Command Differences

All Oracle SOA Suite wsadmin commands supported by IBM WebSphere have equivalent WebLogic Scripting Tool (WLST) commands. Table 4-1 describes differences between wsadmin and WLST.

sca_deployComposite('http://
 adc10:9080','/tmp/sca_HelloWorld_
rev1.0.jar')

soa.sca_deployComposite('http://
adc10:9080', '/tmp/sca_
HelloWorld_rev1.0.jar')

soa.sca_startCompositeMb(compositeName,
revision, label, partition)

soa.sca_stopCompositeMb(compositeName,
revision, label, partition)

soa.sca_activateCompositeMb(compositeName,
revision, label, partition)

soa.sca_retireCompositeMb(compositeName,
revision, label, partition)

soa.sca_assignDefaultCompositeMb(compositeName,
revision, partition)

soa.sca_getDefaultCompositeRevisionMb(composite
Name, partition)

soa.sca_listDeployedCompositesMb()

soa.sca_listCompositesInPartitionMb(partition)

Execute Oracle SOA Suite wsadmin commands from the ORACLE_HOME_for_SOA/common/bin directory:

cd ORACLE_HOME_for_SOA/common/bin
./wsadmin.sh 

To invoke online help for Oracle SOA Suite commands, enter the following:

wsadmin> print OracleHelp.help('soa')

To invoke online help for a specific command, enter the following:

wsadmin> print OracleHelp.help('soa.sca_deployComposite')

For more information about wsadmin commands, see Section 3.1.3, "Using the Oracle Fusion Middleware wsadmin Commands".

For information about the equivalent Oracle SOA Suite WLST commands, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

4.2.2 Configuring the WebSphere Application Client for Use with Oracle JDeveloper

This section describes how to configure the WebSphere Application Client for use with Oracle JDeveloper. Once the WebSphere Application Client is properly configured, Oracle JDeveloper can remotely connect to an IBM WebSphere Server. This enables you to perform actions such as the following in Oracle JDeveloper:

• Remote deployment of SOA composite applications and J2EE applications

• Browsing of SOA composite applications on a remote server

4.2.3 Configuring the Proxy on IBM WebSphere Server

1. Log in to the IBM WebSphere Administrative Console:

   host:port/ibm/console
   

2. Go to Application servers > JrfServer > Process definition > Java Virtual Machine > Custom properties.

3. Define the following properties and values.

   Property	Value
   http.proxyHost	www-proxy.us.oracle.com
   http.proxyPort	80
   http.proxySet	true

   
   

4. Restart the server.

4.2.4 Creating an Application Server Connection

You must create a connection to the IBM WebSphere Server to which to deploy a SOA composite application. During application server connection creation, you are prompted for configuration information on several wizard pages. Table 4-2 describes where to find this information on IBM WebSphere Administration Console for which you are prompted. The location differs based on the type of IBM WebSphere Server you are using.

To create an application server connection:

1. From the File main menu, select New.

2. In the General list, select Connections.

3. Select Application Server Connection, and click OK.

   The Name and Type page appears.

4. In the Connection Name field, enter a name for the connection.

5. In the Connection Type list, select WebSphere Server 7.x to create a connection to IBM WebSphere Server.

6. Click Next.

   The Authentication page appears.

7. In the Username field, enter the user authorized for access to the application server.

8. In the Password field, enter the password for this user.

9. Click Next.

   The Configuration page appears. If you are not sure about the information to enter on this page, see Table 4-2.

10. In the Host Name field, enter the host on which the IBM WebSphere Server is installed. If no name is entered, the name defaults to localhost.

11. In the SOAP Connector Port field, enter the port number of the server on which IBM WebSphere Server is installed. The default SOAP connector port is 8879.

12. In the Server Name field, enter the name assigned to the target application server for this application.

13. In the Target Node field, enter the name of the target node for this connection. A node is a grouping of managed servers (for example, hostNode01, where host is the name of the host on which the node resides).

14. In the Target Cell field, enter the name of the target cell for this connection. A cell is a group of processes that host runtime components (for example, hostNode01Cell, where host is the name of the host on which the node resides).

15. In the Wsadmin script location field, enter or browse for the location of the wsadmin script file to use for defining the system login configuration for this application server connection (for example, WebSphere_Home\bin\wsadmin.bat for Windows or WebSphere_Home/bin/wsadmin.sh for Unix).

    Note:

    Do not enter spaces in the path to the wsadmin.sh or wsadmin.bat file. For example, if on Windows, use the DOS equivalent path of C:\Progra~1\ instead of C:\Program Files\.

16. Click Next.

    The JMX page appears.

17. If you want to browse the SOA Infrastructure and deploy over JMX, select Enable JMX for this connection.

18. In the RMI Port field, enter the port number for the IBM WebSphere Server's RMI connector port. If you are not sure about the information to enter on this page, see Table 4-2.

19. In the WebSphere Runtime Jars Location field, enter or browse for the IBM WebSphere Server's runtime JAR files (for example, WebSphere_Home/runtimes).

20. In the WebSphere Properties Location (for secure MBean access) field, enter or browse for the location of the file that contains the properties for the security configuration and MBeans that are enabled (for example, WebSphere_Home/profiles/profile_name/properties). This field is optional (for some Oracle JDeveloper use cases), but is required for SOA browsing and deployment. The location you specify must contain the sas.client.props file. Details about the contents of the sas.client.props file are as follows:

    • Authentication:

      The sas.client.props file is required for authentication, and must be edited as follows:

      com.ibm.CORBA.securityServerHost=Server_Host_Name
      com.ibm.CORBA.securityServerPort=RMI/BOOTSTRAP_Port
      
      com.ibm.CORBA.loginSource=properties
      com.ibm.CORBA.loginUserid=User_Name
      com.ibm.CORBA.loginPassword=Plain_Text_or_Encoded_Password
      

    • Encode password:

      To encode the password in the sas.client.props file, save this file with a clear text password and then run the following utility:

      On Windows:

      WebSphere_Home\bin\PropFilePasswordEncoder.bat
      ..\properties\sas.client.props com.ibm.CORBA.loginPassword 
      

      On UNIX:

      WebSphere_Home/bin/PropFilePasswordEncoder.sh
      ../properties/sas.client.props com.ibm.CORBA.loginPassword
      

    • SSL (If not required):

      In most cases, SSL is not required for JMX. You must explicitly disable SSL as follows:

      # Does this client support/require SSL connections?
      com.ibm.CSI.performTransportAssocSSLTLSRequired=false
      com.ibm.CSI.performTransportAssocSSLTLSSupported=false
      

    • SSL (If required):

      If you require SSL for JMX, do not configure ssl.client.props. Instead, you must append the necessary SSL configuration details to sas.client.props for Sun JRE clients, since Oracle JDeveloper runs in the Sun JRE.

      Edit the following two sections in sas.client.props:

      • Edit the section on SSL connection requirements.

        # Does this client support/require SSL connections?
        com.ibm.CSI.performTransportAssocSSLTLSRequired=false
        com.ibm.CSI.performTransportAssocSSLTLSSupported=true
        

      • Append the following syntax to the end of sas.client.props. For the com.ibm.ssl.trustStore property, you can use the path to any *.jks truststore.

        #--------------------------------------------------------------
        
        # SSL configuration alias referenced in ssl.client.props
        #--------------------------------------------------------------
        
        com.ibm.ssl.alias=JDeveloperSSLSettings
        com.ibm.ssl.protocol=SSL
        com.ibm.ssl.securityLevel=HIGH
        com.ibm.ssl.trustManager=SunX509
        com.ibm.ssl.keyManager=SunX509
        com.ibm.ssl.contextProvider=SunJSSE
        com.ibm.ssl.enableSignerExchangePrompt=gui
        
        com.ibm.ssl.trustStoreName=WeblogicDemoTrustStore
        com.ibm.ssl.trustStore=c:/YOUR_JDEVHOME/wlserver_
        10.3/server/lib/DemoTrust.jks
        
        com.ibm.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase
        com.ibm.ssl.trustStoreType=JKS
        com.ibm.ssl.trustStoreProvider=SUN
        com.ibm.ssl.trustStoreFileBased=true
        com.ibm.ssl.trustStoreReadOnly=false 
        

      • Upon the first invocation of JMX (typically when you click Test Connection on the Test page of this wizard), the SSL Signer Exchange dialog can appear. Click y to accept the server certificate. Note that a ThreadDeath error is displayed that can safely be ignored.

      • Provide the keystore location through the system properties in either of the following ways:

        Note:

        When configuring the truststore location through the system properties on Windows operating systems, you must enter a forward slash (/) in the path. For example, c:/to/path/truststore.

        From the command prompt:

        $JDEV_INSTALL_DIR/jdev/bin/jdev
        -J-Djavax.net.ssl.trustStore=c:/path/to/truststore
        -J-Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase 
        

        In the jdev.conf file:

        AddVMOption   -Djavax.net.ssl.trustStore=c:/path/to/truststore
        AddVMOption   -Djavax.net.ssl.trustStorePassword=DemoTrust 
         KeyStorePassPhrase 
        

    • Multiple WAS connections

      Since one sas.client.props file is required for each application server connection, Oracle recommends that you create a directory for each application server, copy sas.client.props to that directory, and edit the file as necessary.

21. Click Next.

22. Click Test Connection to test your server connection.

23. If the connection is successful, click Finish. Otherwise, click Back to make corrections in the previous dialogs. Even if the connection test is unsuccessful, a connection is created.

4.2.5 Deploying SOA Composite Applications

Deployment of SOA Composite Applications from Oracle JDeveloper to IBM WebSphere Server is largely the same as described in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

The only exception is the appearance of the Deploy using SSL check box on the SOA Servers page of the deployment wizard. This differs from Oracle WebLogic Server, where the Deploy using SSL check box instead appears on the Configuration page of the Create Application Server Connection wizard page.

Table 4-3 describes what occurs when you select this check box during IBM WebSphere Server deployment.

4.2.6 Using EJB Bindings

If a SOA composite application includes an EJB service, you must perform the following configuration procedures for the EJB service binding to work properly.

4.2.7 AQ Technology Adapter and WebSphere 7.0

For the AQ Adapter to work correctly on the WebSphere 7.0 platform, you need to use the WebSphere Application Server Console to provide specific connection factory and data source properties.

For the connection factory, you need to set the following custom property for the connection pool: defaultConnectionTypeOverride = unshared

For the AQ adapter dataSource, ensure that validate existing pooled connections is checked. The associated interval can be set to 0. See the following screen shot.

Description of the illustration aqds4.gif

Also for the AQ adapter dataSource, you must define the same property as a custom property for the connection pool by setting the following: defaultConnectionTypeOverride = unshared

See the following screen shot.

You also need to set the maximum connections value of AQadapter J2C connection factories to a higher value than the default of 10. You can find this entry in the WebSphere Application Server J2C connection factories -> <Name of AQAdapter> -> Connection pools panel.

4.2.8 JMS Technology Adapter on WebSphere 7.0

If you are developing composite applications to run on WebSphere 7.0, you need to use the Third Party option when modelling the JMS adapter with the Default Messaging JMS provider. You can specify that the adapter uses a third-party JMS Provider, by supplying a value to the FactoryProperties parameter in the weblogic-ra.xml file. Specifically, you can provide the ThirdPartyJMSProvider value to the FactoryProperties parameter.

When deployed on WebSphere 7.0, the JMS Adapter will not work with an AQJMS provider, unless you use the Adapter Configuration Wizard to set defaultConnectionTypeOverride as unshared for both the adapter connection factory pool and for the queue/topic connection factory pool. See the following screen shot.
Description of the illustration j2c3_1.gif

You also need to set the maximum connections value of JMS Adapter J2C factories to a higher value than the default of 10. You can find this entry in the WebSphere Application Server J2C connection factories -> <Name of JMS Adapter> -> Connection pools panel.

4.2.9 Oracle Database Adapter on WebSphere 7.0

For the Oracle Database Adapter to work properly, you need to the set the maximum connections value of the DB adapter J2C connection factories, using the WebSphere Admin Server. This value needs to be set to a higher value than the default of 10. You can find this entry under J2C connection factories -> <Name of DB-Adapter> -> Connection pools. The preferred value is 100.

4.3.1 Publishing Services to a UDDI Registry

You cannot publish service binding components to the Universal Description, Discovery, and Integration (UDDI) registry from Oracle Enterprise Manager Fusion Middleware Control Console on IBM WebSphere.

4.3.2 Oracle Enterprise Manager Fusion Middleware Control Console Shortcut Links

Oracle Enterprise Manager Fusion Middleware Control Console does not include shortcut links to the WebSphere Administration Console from the following locations:

• The Server Data Source JNDI and Server Transaction Data Source JNDI fields of the Data Sources section of the SOA Infrastructure Common Properties page

• The Related Links menu available on service engine pages.

To log in to IBM WebSphere, you must go directly to the WebSphere Administration Console.