|Oracle® Fusion Middleware Third-Party Application Server Guide
11g Release 1 (11.1.1)
Part Number E17852-01
This chapter contains information about managing Oracle SOA Suite applications and components on IBM WebSphere.
This chapter contains the following sections:
When you install Oracle SOA Suite with IBM WebSphere, an internal LDAP server is not automatically configured with SOA users and groups. You must manually perform these configuration tasks in an external LDAP server, such as Oracle Internet Directory, after installation.
For information on the LDAP servers that are supported by Oracle Fusion Middleware, refer to the certification information on the Oracle Technology Network:
The following provides an overview of the tasks to perform when configuring your supported LDAP server for use with Oracle SOA Suite:
Use your LDAP management tool to create two groups (Operator user and Monitor user) and two users (Operator user and Monitor user).
Note that the management tool you use to create the users and groups will vary, depending up on the LDAP server you are using. For example, if you are using Oracle Internet Directory, refer to information about using the Oracle Directory Services Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
In the IBM WebSphere Administration Console, create the following mappings:
User roles for operator and monitor
Group roles for operator and monitor
For example, the following page shows the Administrative user roles section with the monitor user ashish (second checkox) and the operator user opuser (fourth check box) available for selection. You perform similar mappings for group roles on a separate page.
Log in to Oracle Enterprise Manager Fusion Middleware Control Console with administrator access.
In the navigator, right-click soa-infra, and select Security > Application Roles.
Map the SOA roles to the Operator and Monitor roles.
For SOAOperator role, add the Operator group as a member.
For SOAMonitor role, add the Monitor group as a member.
For additional information about switching LDAP authentication providers, see the following documentation:
To switch LDAP authentication providers if the corresponding LDAP server contains the user or users who start the domain, see Section "Requirements for Using an LDAP Authentication Provider" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
To add an Oracle Internet Directory, Oracle Virtual Directory, or other authentication provider using WLST commands, see Section "Configuring Additional Authentication Providers" in Oracle Fusion Middleware Oracle WebLogic Scripting Tool.
The following sections describe differences and restrictions when developing and deploying Oracle SOA Suite applications on IBM WebSphere:
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.
Table 4-1 Differences Between wsadmin and WLST
WLST commands are prefixed with
sca_deployComposite('http:// adc10:9080','/tmp/sca_HelloWorld_ rev1.0.jar')
soa.sca_deployComposite('http:// adc10:9080', '/tmp/sca_ HelloWorld_rev1.0.jar')
You use true/false or 1/0.
You must use 1/0.
Composite management commands
You run WLST commands in offline mode.
To start a composite:
soa.sca_startCompositeMb(compositeName, revision, label, partition)
To stop a composite:
soa.sca_stopCompositeMb(compositeName, revision, label, partition)
To activate a composite:
soa.sca_activateCompositeMb(compositeName, revision, label, partition)
To retire a composite:
soa.sca_retireCompositeMb(compositeName, revision, label, partition)
To assign a default composite:
soa.sca_assignDefaultCompositeMb(compositeName, revision, partition)
To get a default composite revision:
soa.sca_getDefaultCompositeRevisionMb(composite Name, partition)
To list deployed composites:
To list all composites in the given partition:
wsadminonline commands using MBeans may not provide specific error details. Instead, you may see just an
Execute Oracle SOA Suite
wsadmin commands from the
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.
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
Follow the WebSphere Application Client installation steps provided in the IBM documentation.
When selecting WebSphere Application Client features for installation, ensure that you select the following components when prompted:
IBM Developer Kit
Standalone thin clients and resource adapters
Apply the latest fix packs through the IBM Update Installer (for 11g Release 1 (18.104.22.168), apply fix pack 11).
Make a copy of the example file provided in the instructions at the WebSphere Application Server Information Center that describe how to run the
wsadmin tool remotely in a Java 2 Platform, Standard Edition environment.
wsadmin.sh file (for Linux) or the
wsadmin.bat file (for Windows) as follows:
WAS_HOME variable to your WebSphere Application Client home directory:
USER_INSTALL_ROOT variable to
wsadminHost variable to your remote IBM WebSphere Application Server hostname:
wsadminPort variable to your remote IBM WebSphere Server SOAP connector port:
C_PATH variable to use the WebSphere Application Client JAR files:
If installing on Windows, perform the following modifications to the
@setlocal to the beginning of the file.
Replace the following code:
if exist "%JAVA_HOME%\bin\java.exe" ( set JAVA_EXE="%JAVA_HOME%\bin\java" ) else ( set JAVA_EXE="%JAVA_HOME%\jre\bin\java" )
with the following code:
Remove all quotations from the following Java system properties:.
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%USER_INSTALL_ ROOT%\properties\soap.client.props set CLIENTSAS=-Dcom.ibm.CORBA.ConfigURL=file:%USER_INSTALL_ ROOT%\properties\sas.client.props set CLIENTSSL=-Dcom.ibm.SSL.ConfigURL=file:%USER_INSTALL_ ROOT%\properties\ssl.client.props set CLIENTIPC=-Dcom.ibm.IPC.ConfigURL=file:%USER_INSTALL_ ROOT%\properties\ipc.client.props
Remove all trailing white space characters from the entire file.
Ensure that the script works by running
wsadmin.bat from the command line. Note the following:
You may need to enter the username and password at the login prompt.
You may need to accept the server certificate by clicking Y at the signer exchange prompt.
See Step 20 of Section 4.2.4, "Creating an Application Server Connection" for instructions.
Follow the instructions in Section 4.2.4, "Creating an Application Server Connection" to create an application server connection, and enter the following information when prompted:
wsadmin.bat file you created in this section (for example,
Use the runtimes directory of the WebSphere Application Client (for example,
Use the properties directory that contains
sas.client.props (for example,
Log in to the IBM WebSphere Administrative Console:
Go to Application servers > JrfServer > Process definition > Java Virtual Machine > Custom properties.
Define the following properties and values.
Restart the server.
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.
Table 4-2 Location of Application Server Connection Configuration Details
|Connection Wizard Fields||For IBM WebSphere Application Server - Network Deployment (ND), Select...||For IBM WebSphere Application Server 7.0, Select...|
System administration > Deployment manager > Configuration > Ports > SOAP_CONNECTOR_ADDRESS
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Ports > SOAP_CONNECTOR_ADDRESS
System administration > Deployment manager > Configuration > Name
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Name
System administration > Deployment manager > Runtime > Node name
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Node name
System administration > Deployment manager > Runtime > Cell name
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Runtime > Cell name
System administration > Deployment manager -> Configuration > Ports > BOOTSTRAP_ADDRESS
Servers > Server Types > WebSphere Application Servers > Your_Server_Name > Configuration > Ports > BOOTSTRAP_ADDRESS
To create an application server connection:
From the File main menu, select New.
In the General list, select Connections.
Select Application Server Connection, and click OK.
The Name and Type page appears.
In the Connection Name field, enter a name for the connection.
In the Connection Type list, select WebSphere Server 7.x to create a connection to IBM WebSphere Server.
The Authentication page appears.
In the Username field, enter the user authorized for access to the application server.
In the Password field, enter the password for this user.
The Configuration page appears. If you are not sure about the information to enter on this page, see Table 4-2.
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
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
In the Server Name field, enter the name assigned to the target application server for this application.
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,
host is the name of the host on which the node resides).
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,
host is the name of the host on which the node resides).
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,
\bin\wsadmin.bat for Windows or
/bin/wsadmin.sh for Unix).
Note:Do not enter spaces in the path to the
wsadmin.batfile. For example, if on Windows, use the DOS equivalent path of
The JMX page appears.
If you want to browse the SOA Infrastructure and deploy over JMX, select Enable JMX for this connection.
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.
In the WebSphere Runtime Jars Location field, enter or browse for the IBM WebSphere Server's runtime JAR files (for example,
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,
/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:
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
To encode the password in the sas.client.props file, save this file with a clear text password and then run the following utility:
WebSphere_Home\bin\PropFilePasswordEncoder.bat ..\properties\sas.client.props com.ibm.CORBA.loginPassword
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
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
#-------------------------------------------------------------- # 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,
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
AddVMOption -Djavax.net.ssl.trustStore=c:/path/to/truststore AddVMOption -Djavax.net.ssl.trustStorePassword=DemoTrust KeyStorePassPhrase
Multiple WAS connections
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.
Click Test Connection to test your server connection.
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.
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.
Table 4-3 Deployment to HTTPS and HTTP Servers
|If This Checkbox Is...||Then...|
An HTTPS server URL must exist to deploy the composite with SSL. Otherwise, deployment fails.
If the server has only an HTTP URL, deployment also fails. This enables you to ensure that SSL deployment must not go through a non-SSL HTTP URL, and must only go through an HTTPS URL
An HTTP server URL must exist to deploy to a non-SSL environment. Otherwise, deployment fails.
If the server has both HTTPS and HTTP URLs, deployment occurs through a non-SSL connection. This enables you to force a non-SSL deployment from Oracle JDeveloper, even though the server is SSL-enabled.
If a SOA composite application includes an EJB service, you must perform the following configuration procedures for the EJB service binding to work properly.
You must set up credentials for EJB JNDI binding before deploying a composite that contains an EJB service binding.
Create an entry for Oracle Platform Security Services (OPSS) (for example, with
SOA as the name and
Deployer as the key.
Go to the
MW_HOME is the directory in which Oracle SOA Suite is installed.
wsadmin.sh file executable (if it is not already):
chmod +x wsadmin.sh
Execute the following command, and enter the password when prompted:
./wsadmin.sh -host localhost -port 8880 -conntype SOAP -user wasadmin -lang jython
Enter the following command to create the credentials:
Assign the JNDI reading, writing, and binding roles to the administrator user.
Note:The JNDI binding role does not need to be granted to the Administrator. However, it must match the user you specified with the
Opsscommand in Step d.
Log in to the WebSphere Administration Console.
Click and expand Environment > Naming.
Click CORBA naming service groups.
Click the Add button.
Select all the roles in the selection box at the top.
Search for groups using the wildcard ("
Select the Administrators group (to which the
wasadmin user belongs).
Click the Save link.
Restart the server.
Generate stubs for the EJB interfaces using the
createEJBStubs.sh utility and ensure that the stubs are in the client classpath.
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.
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.
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.
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.
The following sections describe differences and restrictions when managing Oracle SOA Suite components on IBM WebSphere:
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.
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.