Procedure 3.1. Install Open JDK on Red Hat Enterprise Linux

1. Subscribe to the Base Channel

   Obtain the OpenJDK from the RHN base channel. (Your installation of Red Hat Enterprise Linux is subscribed to this channel by default.)

2. Install the Package

   Use the yum utility to install OpenJDK: yum install java-1.7.0-openjdk-devel

3. Verify that OpenJDK is Now Your System Default

   To ensure that the correct JDK is set as the system default, login as root and run the alternatives command: /usr/sbin/alternatives --config java
   Select /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
   Set javac /usr/sbin/alternatives --config javac
   Select /usr/lib/jvm/java-1.6.0-openjdk/bin/java

Procedure 3.2. Installing Apache Ant on Red Hat Enterprise Linux

1. Download Apache Ant

   Open a terminal and input this command: sudo yum install ant-trax

2. Install Apache Ant

   Enter Y when prompted to do so by the installer.

3. Add the ANT_HOME Environment Variable

   1. vi ~/.bash_profile.
   2. Add the following line:

   export ANT_HOME=/FILEPATH/ant

   where filepath is the directory in which Apache Ant was installed. Save and exit vi.

   Example 3.1. 

   export ANT_HOME=/opt/apache-ant-1.8.2

4. Append the Ant installation's bin directory to the Path environmental variable.

   1. vi ~/.bash_profile.
   2. Add the following line and then save and exit vi:

   export PATH=$PATH:$ANT_HOME/bin

5. Test the installation

   Go back to your terminal and run ant -version. The output should resemble the following:

   [localhost]$ ant -version
   Apache Ant(TM) version 1.8.2 compiled on July 6 2011
   

Procedure 3.3. Installing Apache Ant on Microsoft Windows

1. Download Apache Ant

   Download the latest Apache Ant binary release from http://ant.apache.org/.

2. Extract Apache Ant

   Extract the files to a preferred installation location such as:

   • c:\Program Files\Apache\Ant\

3. Add the ANT_HOME Environment Variable

   1. Click on the Start Menu.
   2. Open the Control Panel.
   3. Select System → Advanced → Environment Variables
   4. Create a new variable called ANT_HOME.
   5. Configure the ANT_HOME variable so that it points to the Apache Ant directory.

4. Append the bin directory of the Ant installation to the Path environmental variable.

   1. Click on the Start Menu.
   2. Open the Control Panel.
   3. Select System → Advanced → Environment Variables → System Variables
   4. Edit the PATH variable and append the text:

   ;%ANT_HOME%\bin

5. Test the installation

   Run ant -version in a command line terminal. The version number should appear.

Procedure 4.1. Task:

1. Browse to https://access.redhat.com and click the Log in link in the top right corner. Enter your credentials and click Log In.
   Result:

   You are logged into RHN and you are returned to the main web page at https://access.redhat.com.

2. Navigate to the Downloads page.

   Use one of the following options to navigate to the Downloads page.
   • Click the Downloads link in the top navigation bar.
   • Navigate directly to https://access.redhat.com/downloads/.

3. Select the product and version to download.

   Use one of the following ways to choose the correct product and version to download.
   • Step through the navigation one level at a time.
   • Search for your product using the search area at the top right-hand side of the screen.

4. Download the appropriate file for your operating system and installation method of choice.

   Depending on the product you choose, you may have the choice of a Zip archive, RPM, or native installer for a specific operating system and architecture. Click either the file name or the Download link to the right of the file you want to download.

Procedure 4.2. Verify the Downloaded File

1. To verify that a file downloaded from the Red Hat Customer Portal is error-free, whilst still on the portal site, go to that package's Software Details page. Here you will find MD5 and SHA256"checksum" values that you will use to check the integrity of the file.
2. Open a terminal window and run either either the md5sum or sha256sum command, supplying the filename of the downloaded ZIP as an argument. The program will output the checksum value for the file.
3. Compare the checksum value returned by the command to the corresponding value displayed on the Software Details page for the file.

   Note

   Microsoft Windows does not come equipped with a checksum tool. Users of that operating system will have to download a third-party product instead.

Procedure 5.1. Installation

1. Extract the installation directory by running unzip soa-p-VERSION.zip.
2. Open the user account settings file in your text editor: vi SOA_ROOT/jboss-as/server/default/conf/props/soa-users.properties.
   The contents of this file using the following syntax: username=password.

   #admin=admin
   

   Confirm that the security roles for your admin account are enabled by removing a leading hash character, if it is present.

   Warning

   Because this account is not secure and the password can be easily guessed, use admin=admin for test purposes only. Do not use admin as a password on production systems as this may compromise security.
3. Save the file and exit vi.
4. Open the security permissions file in your text editor: vi SOA_ROOT/jboss-as/server/default/conf/props/soa-roles.properties.

   #admin=JBossAdmin,HttpInvoker,user,admin
   

   Confirm that the security roles for your admin account are enabled by removing a leading hash character, if it is present.
5. Save the changes to the file and exit vi.

Procedure 5.2. Installation

1. Extract the soa-p-VERSION.zip using the ZIP tool of your choice.
2. Confirm that the security roles for your admin account are enabled by removing a leading hash character, if it is present.

   Warning

   Because this account is not secure and the password can be easily guessed, use admin=admin for test purposes only. Do not use admin as a password on production systems as this may compromise security.
3. Save the file and exit Notepad.
4. Open SOA_ROOT\jboss-as\server\default\conf\props\soa-roles.properties in Notepad.

   #admin=JBossAdmin,HttpInvoker,user,admin
   

   Remove the hash to enable the security permissions for your admin account.
5. Save the file and exit Notepad.

Procedure 6.1. Start the JBoss Enterprise SOA Platform

• Start the SOA server in a server window

  • Red Hat Enterprise Linux

    1. Open a terminal and navigate to the bin directory by entering the command cd SOA_ROOT/jboss-as/bin.
    2. Enter ./run.sh to start the SOA server. (Because you are not specifying a server profile, "default" will be used.)

  • Microsoft Windows

    1. Open a terminal and navigate to the bin directory by entering the command chdir SOA_ROOT\jboss-as\bin.
    2. Enter run.bat to start the SOA server. (Because you are not specifying a server profile, "default" will be used.)

Procedure 6.4. Stop the JBoss Enterprise SOA Platform Server

• Stop the SOA server

  Press ctrl-c in the server window (the terminal window where the SOA server was started).

Procedure 7.1. Add a New User

1. Open the soa-users.properties file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/props/soa-users.properties. Add the user's name and password on a new line, using this syntax: username=password.
   Here is an example for a user with the login name "Harold":

   harold=@dm1nU53r
   

   Note

   Any line in this file that begins with a hash (#) is ignored. (You can use this convention to temporarily disable a user account.)
2. Save the changes to the file and exit the text editor.
3. Open the soa-roles.properties file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/props/soa-roles.properties. Add the user and the roles you wish to assign to them on a new line, using this syntax: username=role1,role2,role3.

   harold=JBossAdmin,HttpInvoker,user,admin
   

   Note

   You can assign any number of roles. Note that a user must be assigned the JBossAdmin, HttpInvoker, user and admin roles in order to be able to log into the server consoles.

   Any line in this file that begins with a hash (#) is ignored. You can use this convention to temporarily disable user roles.
4. Save the changes to the file and exit the text editor.

Procedure 7.2. Disable a User's Account

1. Open the soa-users.properties file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/props/soa-users.properties. Either delete the entire line containing the user's name and password or simply put a hash (#) in front of it to "comment it out."
   Here is an example for a user with the login name "Harold":

   #harold=@dm1nU53r
   

2. Save the changes to the file and exit the text editor.

1. Back Up Your Server Profile

   Make a copy of the server profile for which you plan to configure your database as the Database Configuration Tool modifies the configuration settings. cp -R SOA_ROOT/jboss-as/server/Profile /path/to/backup/folder.

2. Running the Database Configuration Tool

   Change to the directory containing the Database Configuration script: cd SOA_ROOT/jboss-as/tools/schema

3. Run Ant

   Run the ant command to launch the script.

4. Enter Data

   Following the prompts, enter the following information as it is requested:
   • the type of database being used,
   • the name of the database,
   • the host name or IP Address of the database,
   • the TCP port being used for the database,
   • the user name needed to access the database, and
   • the password for this user account.

   Note

   You could also add these values directly to the build.properties file (found in the same directory) before running the script. The Database Schema Tool will not prompt you for these properties if it finds you have already added them to the file.

Procedure 9.1. Task

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Scroll down to the "registry" section and alter the settings as you wish.

   <properties name="registry">
     <property name="org.jboss.soa.esb.registry.implementationClass"
       value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
     
     <property name="org.jboss.soa.esb.registry.factoryClass"
       value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
     
     <property name="org.jboss.soa.esb.registry.queryManagerURI"
       value="org.apache.juddi.v3.client.transport.wrapper.UDDIInquiryService#inquire"/>
     
     <property name="org.jboss.soa.esb.registry.lifeCycleManagerURI"
       value="org.apache.juddi.v3.client.transport.wrapper.UDDIPublicationService#publish"/>
     <property name="org.jboss.soa.esb.registry.securityManagerURI"
       value="org.apache.juddi.v3.client.transport.wrapper.UDDISecurityService#secure"/>
     
     <property name="org.jboss.soa.esb.registry.user" value="root"/>
     <property name="org.jboss.soa.esb.registry.password"	value="root"/>
     
     <property name="org.jboss.soa.esb.scout.proxy.uddiVersion" value="3.0"/>
     <property name="org.jboss.soa.esb.scout.proxy.uddiNameSpace" value="urn:uddi-org:api_v3"/>
     
     <property name="org.jboss.soa.esb.scout.proxy.transportClass"
       value="org.apache.ws.scout.transport.LocalTransport"/>
     <!-- specify the interceptors, in order -->
     <property name="org.jboss.soa.esb.registry.interceptors"
     value="org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor, org.jboss.internal.soa.esb.services.registry.CachingRegistryInterceptor"/>
     <!-- The following properties modify the cache interceptor behaviour -->
     <property name="org.jboss.soa.esb.registry.cache.maxSize" value="100"/>
     <property name="org.jboss.soa.esb.registry.cache.validityPeriod" value="600000"/>
     
     <!-- Organization Category to be used by this deployment. -->
     <property name="org.jboss.soa.esb.registry.orgCategory"         
     value="org.jboss.soa.esb.:category"/>
   </properties>
   

3. Save the file and exit.

Procedure 9.2. Task

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Scroll down to the "registry" section and alter the settings like this:

   <properties name="registry">
   
   	    <property name="org.jboss.soa.esb.registry.implementationClass" 				    
   	    value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
   
   	    <property name="org.jboss.soa.esb.registry.factoryClass" 					
   	    value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
   
       	<property name="org.jboss.soa.esb.registry.queryManagerURI" 				
       	value="org.apache.juddi.registry.local.InquiryService#inquire"/>
   
       	<property name="org.jboss.soa.esb.registry.lifeCycleManagerURI" 
       	value="org.apache.juddi.registry.local.PublishService#publish"/>
   
       	<property name="org.jboss.soa.esb.registry.securityManagerURI" 
       	value="org.apache.juddi.registry.local.SecurityService#secure"/>
   
       	<property name="org.jboss.soa.esb.registry.user" value="jbossesb"/>
       	<property name="org.jboss.soa.esb.registry.password" value="password"/>
       	
       	<property name="org.jboss.soa.esb.scout.proxy.transportClass" 				                                    
       	value="org.apache.ws.scout.transport.LocalTransport"/>
   
   </properties>
   

3. Save the file and exit.

Procedure 9.3. Task

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Scroll down to the "registry" section and alter the settings like this:

   <properties name="registry">
     <property name="org.jboss.soa.esb.registry.implementationClass"
       value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
   
     <property name="org.jboss.soa.esb.registry.factoryClass"
       value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
   
     <property name="org.jboss.soa.esb.registry.queryManagerURI"
       value="jnp://localhost:1099/InquiryService?org.apache.juddi.registry.rmi.Inquiry#inquire"/>
   
     <property name="org.jboss.soa.esb.registry.lifeCycleManagerURI"
       value="jnp://localhost:1099/PublishService?org.apache.juddi.registry.rmi.Publish#publish"/>      
     <property name="org.jboss.soa.esb.registry.securityManagerURI"
       value="jnp://localhost:1099/PublishService?org.apache.juddi.registry.rmi.Publish#publish"/>
     
     <property name="org.jboss.soa.esb.registry.user" value="jbossesb"/>
     <property name="org.jboss.soa.esb.registry.password" value="password"/>
         
     <property name="org.jboss.soa.esb.scout.proxy.transportClass"
       value="org.apache.ws.scout.transport.RMITransport"/>
   </properties>
   

3. Save the file and exit.
4. Open the web.xml file in your text editor.
5. Configure it like this:

   <!--  uncomment if you want to enable making calls in juddi with rmi  -->
     <servlet>
     	<servlet-name>RegisterServicesWithJNDI</servlet-name>
     	<servlet-class>org.apache.juddi.registry.rmi.RegistrationService</servlet-class>
     	<load-on-startup>1</load-on-startup>
     </servlet>
   

6. Save the file and exit.
7. Open the jUDDI configuration file in a text editor: vi SOA_ROOT/jboss-as/server/standard/deploy/juddi-service.sar/juddi.war/WEB-INF/juddi.properties.
8. Configure it like this:

   # JNDI settings (used by RMITransport)
   java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
   java.naming.provider.url=jnp://localhost:1099
   java.naming.factory.url.pkgs=org.jboss.naming
   

9. Save the file and exit.
10. Add scout-client.jar to the RMI client's class-path.

1. For a local application, open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Scroll down to the "registry" section and alter the local settings like this:

   <properties name="registry">
   	<property name="org.jboss.soa.esb.registry.implementationClass" 
   value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
   
   	<property name="org.jboss.soa.esb.registry.factoryClass"
   value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
   
       	<property name="org.jboss.soa.esb.registry.queryManagerURI"
   value="org.apache.juddi.registry.local.InquiryService#inquire"/>
   
       	<property name="org.jboss.soa.esb.registry.lifeCycleManagerURI"
   value="org.apache.juddi.registry.local.PublishService#publish"/>
   
       	<property name="org.jboss.soa.esb.registry.securityManagerURI"
   value="org.apache.juddi.registry.local.SecurityService#secure"/>
   
       	<property name="org.jboss.soa.esb.registry.user" value="jbossesb"/>
       	<property name="org.jboss.soa.esb.registry.password" value="password"/>
       	
       	<property name="org.jboss.soa.esb.scout.proxy.transportClass" 
   value="org.apache.ws.scout.transport.LocalTransport"/>
   </properties>
   

3. Save the file and exit.
4. For a remote application, open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
5. Scroll down to the "registry" section and alter the remote method invocation settings like this:

   <properties name="registry">
   	<property name="org.jboss.soa.esb.registry.implementationClass"
   value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
   
   	<property name="org.jboss.soa.esb.registry.factoryClass"
   value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
   
       	<property name="org.jboss.soa.esb.registry.queryManagerURI"
   value="jnp://localhost:1099/InquiryService?org.apache.juddi.registry.rmi.Inquiry#inquire"/>
   
       	<property name="org.jboss.soa.esb.registry.lifeCycleManagerURI"
   value="jnp://localhost:1099/PublishService?org.apache.juddi.registry.rmi.Publish#publish"/>
   	
       	<property name="org.jboss.soa.esb.registry.user" value="jbossesb"/>
       	<property name="org.jboss.soa.esb.registry.password" value="password"/>
       	
       	<property name="org.jboss.soa.esb.scout.proxy.transportClass"
   value="org.apache.ws.scout.transport.RMITransport"/>
   </properties>
   

6. Save the file and exit.
7. Point the host names of the queryManagerURI and lifeCycleManagerURI classes to the host on which the jUDDI Registry is running (this is also where the local is running). Note that the local application needs to have access to a naming service.
8. Use these settings to register the application:

   //Getting the JNDI setting from the config
   Properties env = new Properties();
   env.setProperty(RegistryEngine.PROPNAME_JAVA_NAMING_FACTORY_INITIAL,factoryInitial);
   env.setProperty(RegistryEngine.PROPNAME_JAVA_NAMING_PROVIDER_URL, providerURL);
   env.setProperty(RegistryEngine.PROPNAME_JAVA_NAMING_FACTORY_URL_PKGS,
     factoryURLPkgs); 
   
   InitialContext context = new InitialContext(env);
   Inquiry inquiry = new InquiryService();
   log.info("Setting " + INQUIRY_SERVICE + ", " + inquiry.getClass().getName());
   mInquery = inquiry;
   context.bind(INQUIRY_SERVICE, inquiry);
   Publish publish = new PublishService();
   log.info("Setting " + PUBLISH_SERVICE + ", " + publish.getClass().getName());
   mPublish = publish;
   context.bind(PUBLISH_SERVICE, publish);
   

9. Include the scout-client.jar file on the RMI client's class-path.

Procedure 9.4. Task

1. Shut down the RMI service by "commenting out" the web.xml file's RegisterServicesWithJNDI servlet.
2. Deploy the juddi.war archive.
3. Configure the data-source.
   Here are some sample properties:

   <properties name="registry">
   	<property name="org.jboss.soa.esb.registry.implementationClass" 				
   	value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
   
   	<property name="org.jboss.soa.esb.registry.factoryClass" 					
   	value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
   
      	<property name="org.jboss.soa.esb.registry.queryManagerURI" 				
      	value="http://localhost:8080/juddi/inquiry"/>
   
      	<property name="org.jboss.soa.esb.registry.lifeCycleManagerURI" 				
      	value="http://localhost:8080/juddi/publish"/>	
   
      	<property name="org.jboss.soa.esb.registry.user" value="jbossesb"/>
      	<property name="org.jboss.soa.esb.registry.password" value="password"/>
      	
      	<property name="org.jboss.soa.esb.scout.proxy.transportClass" 				
      	value="org.apache.ws.scout.transport.AxisTransport"/>
   </properties>
   

Procedure 9.5. Task

1. Open a web browser session and go to the jUDDI Console at http://localhost:8080/uddi-console/. Log in as root.
2. Click "Publisher".
3. From the Publisher ID list, click on the username.
4. Select the "Is Admin" checkbox.

Procedure 9.6. Task

1. Launch JBoss Developer Studio
2. Go to JBoss Central screen
3. Download the plug-ins you require to do your SOA development work.

Procedure 10.1. Task

1. Choose a specific JAXR implementation.
2. Set the property to configure the class. (Because the JBoss Enterprise SOA Platform uses Apache Scout by default, this property is set to the Scout factory class, namely org.apache.ws.scout.registry.ConnectionFactoryImpl.)
3. Configure the JAXR implementation by providing it with the Registry's location. Do so by editing org.jboss.soa.esb.registry.queryManagerURI, org.jboss.soa.esb.registry.lifeCycleManagerURI and org.jboss.soa.esb.registry.securityManagerURI.

Procedure 10.2. Task

• Write a new SystinetRegistryImplemtation class and provide a reference to it from within this property.

Procedure 10.3. Task

1. Edit the node definition file: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml
2. Use the node settings to select which transport to use:

   <node>
   	    <!-- required 'default' node -->
   	    <name>default</name> 
   	    <description>Main jUDDI node</description>
   	    <properties>
   	<property name="serverName" value="localhost" />
   		<property name="serverPort" value="8880" />
   	    </properties>
   	    <!-- JAX-WS Transport
        <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport>
   	    <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer?wsdl</custodyTransferUrl>
       <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry?wsdl</inquiryUrl>
       <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish?wsdl</publishUrl>
       <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security?wsdl</securityUrl>
       <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription?wsdl</subscriptionUrl>
       <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener?wsdl</subscriptionListenerUrl>
   	   <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</juddiApiUrl>
   	    -->
   	   <!-- In VM Transport Settings 
       <proxyTransport>org.jboss.internal.soa.esb.registry.client.JuddiInVMTransport</proxyTransport>
       <custodyTransferUrl>org.apache.juddi.api.impl.UDDICustodyTransferImpl</custodyTransferUrl>
   	    <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl>
   	    <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl>
       <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl>
       <subscriptionUrl>org.apache.juddi.api.impl.UDDISubscriptionImpl</subscriptionUrl>
       <subscriptionListenerUrl>org.apache.juddi.api.impl.UDDISubscriptionListenerImpl</subscriptionListenerUrl>
   	   <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl>
    	-->
   	<!-- RMI Transport Settings -->
   <proxyTransport>org.apache.juddi.v3.client.transport.RMITransport</proxyTransport>
   	<custodyTransferUrl>/juddiv3/UDDICustodyTransferService</custodyTransferUrl>
   	<inquiryUrl>/juddiv3/UDDIInquiryService</inquiryUrl>
   	<publishUrl>/juddiv3/UDDIPublicationService</publishUrl>
   <securityUrl>/juddiv3/UDDISecurityService</securityUrl>
   <subscriptionUrl>/juddiv3/UDDISubscriptionService</subscriptionUrl>
   <subscriptionListenerUrl>/juddiv3/UDDISubscriptionListenerService</subscriptionListenerUrl>
   <juddiApiUrl>/juddiv3/JUDDIApiService</juddiApiUrl>
   <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial>
   	<javaNamingFactoryUrlPkgs>org.jboss.naming</javaNamingFactoryUrlPkgs>
   	<javaNamingProviderUrl>jnp://localhost:1099</javaNamingProviderUrl>
   	</node>
   

3. By default, the Remote Method Invocation (RMI) settings are enabled. To switch transports, comment those ones out and enable the ones you want to use.
4. Save the file and exit.

Procedure 10.4. Task

1. Check that the transportClass is set to LocalTransport in the uddi.xml file.
2. Configure the uddi.xml file to utilize the Registry's transports (these being InVM, RMI and WS, respectively). The file is located in SOA_ROOT/jboss-as/server/all/deploy/jbossesb.sar/esb.juddi.client.xml
3. Create a schema in the jUDDI registry by adding the jbossesb publisher to it.

   Note

   The product/install/jUDDI-registry directory contains database-create scripts for most common databases. These files are located in SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi-sql.

   Note

   The system can generate the database automatically if the user has been granted permission to create tables. (The Registry can create a database of any type for which there exists an associated Hibernate dialect.)
4. Check that the SOA_ROOT/jboss-as/server/default/deploy/jbossesb-registry.sar/esb.juddi.xml and SOA_ROOT/jboss-as/server/all/deploy/jbossesb.sar/esb.juddi.client.xml exist. These files contain the Registry's configuration settings.

   Note

   If you want the software to communicate with another UDDI registry, use Apache Scout's JAXR transports. There are four implementations of this class and they are also based on SOAP, SAAJ, RMI and Embedded Java.
5. If you decide to change the transport, always change the query and life-cycle uniform resource indicators as well. Here is sample code that demonstrates how to do so:

   SOAP
   queryManagerURI	http://localhost:8080/juddi/inquiry
   lifeCycleManagerURI	http://localhost:8080/juddi/publish
   transportClass		org.apache.ws.scout.transport.AxisTransport
   
   RMI
   queryManagerURI 	jnp://localhost:1099/InquiryService?org.apache.juddi.registry.rmi.Inquiry#inquire
   lifeCycleManagerURI 	jnp://localhost:1099/PublishService?org.apache.juddi.registry.rmi.Publish#publish
   transportClass		org.apache.ws.scout.transport.RMITransport
   
   Local
   queryManagerURI	org.apache.juddi.registry.local.InquiryService#inquire
   lifeCycleManagerURI	org.apache.juddi.registry.local.PublishService#publish
   transportClass		org.apache.ws.scout.transport.LocalTransport
   

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Modify the org.jboss.soa.esb.registry.interceptors properties.
3. Save the file and exit.

Procedure 11.1. Task

• Integration is turned on by default. To confirm this, open vi SOA_ROOT/jboss-as/server/PROFILE/deploy/riftsaw.sar/bpel.properties.xml and ensure that is set as follows: bpel.uddi.registration=true.

Procedure 11.2. Task

1. Open the esb.juddi.client.xml file in your text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml
2. Configure the settings. For example:

   </nodes>
      <clerks registerOnStartup="false">
         <clerk name="SOAExample" node="default" publisher="root" password="root"/>
      </clerks>
      </manager>
   </uddi>
   

3. Save the file and exit.
4. Put another copy of the file in here (the files must always correspond: SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/
5. Save the file and exit.

Procedure 12.1. Task

1. Go to the HornetQ Directory: cd SOA_ROOT/jboss-as/extras/hornetq.

2. Deploy It

   Run ant.

Procedure 12.2. Task

1. Configure the JMS Provider

   To configure JBoss Messaging, open the configuration file in a text editor: vi jboss-esb.xml.
2. Modify these settings:

   jndi-URL="localhost”
   	jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
   	connection-factory="ConnectionFactory"
   	destination-type="queue"
   	destination-name="queue/myqueue"
   

   Important

   Always include the jboss-messaging-client.jar file on the class-path. (This file is found in the SOA_ROOT/jboss-as/client/jboss-messaging-client.jar archive.)

   Note

   If you want to use load balancing and fail-over capabilities, you must configure JBoss Messaging for clustering. This functionality is constantly evolving. To learn how to configure it, please consult the JBoss Messaging documentation.
3. Check that JBoss Messaging's Service Binding Manager configuration matches that found in the SOA_ROOT/seam/bootstrap/deploy/remoting-service.xml file.

Procedure 12.3. Task

1. Copy the IBM Websphere wmq.jmsra.rar file to the JBoss Enterprise SOA Platform: cp wmq.jmsra.rar SOA_ROOT/jboss-as/server/PROFILE/deploy/
2. Copy the IBM Websphere com.ibm.mqetclient.jar to the JBoss Enterprise SOA Platform: cp com.ibm.mqetclient.jar SOA_ROOT/jboss-as/lib/.
3. Open run.conf in your text editor: vi SOA_ROOT/jboss-as/bin/run.conf
4. Add this setting by modifying the JAVA_OPTS in run.conf:

   JAVA_OPTS="-DtraceEnabled=true -DtraceDestination=wmq_jca.trc 
       -DtraceLevel=10 -DlogWriterEnabled=false"
   

5. Save the file and exit.
6. Open the jboss-esb.xml file in your text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.esb/META-INF/jboss-esb.xml
7. Add these settings:

   <jms-jca-provider name="WMQ-JCA" connection-factory="MyAppXAConnectionFactory"
   adapter="wmq.jmsra.rar"
          jndi-URL="10.12.10.110:1414/CH1"
          jndi-context-factory="com.ibm.mq.jms.context.WMQInitialContextFactory">
       <property name="max-xa-sessions-per-connection" value="1" />
   <jms-bus busid="quickstartEsbChannel">
     <jms-message-filter dest-type="QUEUE" dest-name="Q1" transacted="true"/>
   </jms-bus>
   <activation-config>
        <property name="queueManager" value="QM1" />
        <property name="channel" value="CH1" />
        <property name="hostName" value="10.12.10.110" />
        <property name="port" value="1515" />
        <property name="transportType" value="CLIENT" />
        <property name="useJNDI" value="false" />
   </activation-config>
   </jms-jca-provider>
   

8. Save the file and exit.
9. Run crtmqm -q QM1
10. Run strmqm QM1

    define channel (CH.1) chltype (RCVR) trptype (TCP)
    start channel (CH.1)
    define qlocal (Q1)
    define listener(QM1.LISTENER) trptype(TCP) port(30001) ipaddr(10.12.58.110)
    start listener (QM1.LISTENER)
    

Procedure 12.4. Task

1. Run this command: /opt/mqm/java/bin/JMSAdmin -v

        
   java -Dcom.ibm.msg.client.commonservices.log.outputName=$MQ_JAVA_DATA_PATH/log -Dcom.ibm.msg.client.commonservices.trace.outputName=$MQ_JAVA_DATA_PATH/trace -DMQJMS_INSTALL_PATH=$MQ_JAVA_INSTALL_PATH com.ibm.mq.jms.admin.JMSAdmin $*
   

2. Open JMSAdmin.config in your text editor: vi JMSAdmin.config
3. Edit the file as per this sample code:

        
   INITIAL_CONTEXT_FACTORY=com.ibm.mq.jms.context.WMQInitialContextFactory
   
   PROVIDER_URL=localhost:30002/SYSTEM.DEF.SVRCONN
   
   SECURITY_AUTHENTICATION=none
   

   Note

   If you have a listener on a different port, use it instead. (The default is 1414).
4. Save the file and exit.
5. Define objects with these commands: InitCtx> def cf(ConnectionFactory) qmgr(QM1) tran(CLIENT) host(10.12.58.105) BROKERQMGR(QM1) and InitCtx> def qcf(QueueConnectionFactory) qmgr(QM1) tran(CLIENT) host(10.12.58.105)
6. If you are having problems with JMSAdmin, troubleshoot the logs: less /var/mqm/errors/AMQERR01.LOG and less /var/mqm/qmgrs/QUEUE MANAGER NAME/errors/AMQERR01.LOG

   Note

   For more information, refer to http://www.ibm.com/developerworks/websphere/techjournal/0502_woolf/0502_woolf.html.

Procedure 12.5. Task

1. Configure the Adapter

   The adapter name is wmq.jmsra.rar. Copy this file into the JBoss Enterprise SOA Platform's SOA_ROOT/jboss-as/server/PROFILE/deploy directory.

2. Check the Context Factory

   Ensure that the initial context factory is com.ibm.mq.jms.context.WMQInitialContextFactory.

3. Configure the QueueManager

   Ensure that the queueManager configuration is in the <activation-config>. You will need to configure a queue manager in your own Websphere MQ installation. (Note that all of your destination queues are configured in your queue manager.)

4. Configure the Channel

   Ensure that the channel configuration is in the <activation-config> property.

   Note

   You can configure a queue manager to use a number of different types of channel. Clients connect through server connection channels. A default server connection channel (SYSTEM.DEF.SVRCONN), is added as part of the Websphere MQ installation but it is a good idea to also create your own dedicated channels, especially if you are using extended (XA) transactions.

5. Configure the transportType

   Edit the transportType. The configuration for this is in the <activation-config> property. Websphere MQ supports two transport types ( Client and Binding).

6. Edit the Settings

   Open the configuration file in a text editor and edit it.
   Here is an example of a <jms-jca-provider> configuration. It shows how to set a gateway provider configuration:

   <jms-jca-provider adapter="wmq.jmsra.rar" connection-factory="MyAppXAConnectionFactory" jndi-context-factory="com.ibm.mq.jms.context.WMQInitialContextFactory" name="WMQ-JCA">
   	<property name="max-xa-sessions-per-connection" value="1"/>
   		<jms-bus busid="quickstartGwChannel">
   		<jms-message-filter dest-name="QUEUE1_JMS" dest-type="QUEUE" transacted="true"/>
   		</jms-bus>
   			<activation-config>
   				<property name="queueManager" value="TQM"/>
   				<property name="channel" value="Q1CONN"/>
   				<property name="hostName" value="localhost"/>
   				<property name="port" value="1414"/>
   				<property name="transportType" value="CLIENT"/>
   			</activation-config>
   </jms-jca-provider>
   

   Note

   It is actually the <jms-listener> configuration that determines the gateway/message-aware characteristics of a listener. However, as far as Websphere MQ is concerned, this is only of use as a gateway listener provider. In other words, this configuration would not work as a message-aware listener for Websphere MQ. This is because it does not specify an appropriate JNDI provider URL (as used by the ServiceInvoker) for routing ESB messages to the destinations (buses) defined on the provider.

7. Configure the JCA Adapter

   The <activation-config> configures the JCA adapter so that it obtains messages from the destinations. It does not determine how messages are to be delivered to the destinations. Here is an example of a configuration that could be used as a message-aware listener's provider:

   <jms-jca-provider adapter="wmq.jmsra.rar" connection-factory="MyAppXAConnectionFactory" jndi-URL="localhost:1414/CHANX" jndi-context-factory="com.ibm.mq.jms.context.WMQInitialContextFactory" name="WMQ-JCA">
   	<property name="max-xa-sessions-per-connection" value="1"/>
   		<jms-bus busid="quickstartEsbChannel">
   			<jms-message-filter dest-name="QUEUE2_JMS" dest-type="QUEUE" transacted="true"/>
   		</jms-bus>
   	<activation-config>
   		<property name="queueManager" value="TQM"/>
   		<property name="channel" value="Q2CONN"/>
   		<property name="hostName" value="localhost"/>
   		<property name="port" value="1414"/>
   		<property name="transportType" value="CLIENT"/>
   	</activation-config>
   </jms-jca-provider>
   

8. Creating a Standard JMS Provider

   The settings for creating a standard JMS provider configuration are similar:

   <jms-provider connection-factory="MyAppConnectionFactory" jndi-URL="localhost:1414/CHAN1" jndi-context-factory="com.ibm.mq.jms.context.WMQInitialContextFactory" name="JMS">
   	<jms-bus busid="quickstartGwChannel2">
   		<jms-message-filter dest-name="QUEUE3_JMS" dest-type="QUEUE"/>
   	</jms-bus>
   </jms-provider>
   

   Note

   With the standard provider, there is neither an adapter nor any <activation-config> configurations. Listeners receiving messages from the destinations defined in a standard provider do not use a JCA Adapter Inflow to obtain the messages. Instead, they need to use JNDI to find the destination and obtain the messages. This means that, for Websphere MQ, the jndi-URL must always be specified (remember that for JCA it is only required for destinations that service a Message-Aware listener).

9. Save

   Save the file and exit.

Procedure 12.6. Task

1. Edit the JMSRouter Configuration

   Open the JMSRouter's configuration file in a text editor and modify the settings in your jboss-esb.xml. Here is an example of a JMSRouter configuration for routing messages to Websphere MQ from inside an ESB action pipeline:

   <action class="org.jboss.soa.esb.actions.routing.JMSRouter" name="routeToORDERSQueue">
   	<property name="jndi-context-factory" value="com.ibm.mq.jms.context.WMQInitialContextFactory"/>
   	<property name="jndi-URL" value="wmqserver:1414/CHANX"/>
   	<property name="connection-factory" value="WMQConnectionFactory"/>
   	<property name="jndiName" value="ORDERS"/>
   </action>
   

2. Save

   Save the file and exit.

Procedure 12.7. Task

1. Edit the jms-jca-provider Configuration

   Edit the jboss-esb.xml file in a text editor. Here is how the jms-jca-provider configuration would look for an Extended Transaction Client configuration. (In this example, the XA Connection Factory that has been configured in the WMQ JNDI namespace is called WMQXAConnectionFactory.)

   Note

   Inflow related configurations (adapter, <activation-config> etc) were intentionally omitted as they are not relevant to the Extended Client configuration:

   <jms-jca-provider name="WMQ" connection-factory="WMQXAConnectionFactory"
   	jndi-URL="wmqserver:1414/CHANXA_SEND"
   	jndi-context-factory="com.ibm.mq.jms.context.WMQInitialContextFactory">
   		<property name="max-xa-sessions-per-connection" value="1" />
   			<jms-bus busid="ordersGwChannel">
   			<jms-message-filter dest-type="QUEUE" dest-name="ORDERS" transacted="true"/>
   			</jms-bus>
   				<activation-config>
   					<!--
   					Used by inflow... not relevant to client
   					See section on JMS and JCA.
   					-->
   		</activation-config>
   </jms-jca-provider>
   

2. Configuring for Use with the JMSRouter

   This example shows how to use the same XA Connection Factory on the JMSRouter:

   <action name="routeToORDERSQueue" class="org.jboss.soa.esb.actions.routing.JMSRouter">
   <property name="jndi-context-factory"
   value="com.ibm.mq.jms.context.WMQInitialContextFactory"/>
   <property name="jndi-URL" value="wmqserver:1414/CHANXA_SEND"/>
   <property name="connection-factory" value="WMQXAConnectionFactory"/>
   <property name="jndiName" value="ORDERS"/>
   <property name="max-xa-sessions-per-connection" value="1"/>
   <!-- etc... -->
   </action>
   

   Important

   An important point to note about Websphere MQ and XA is that it does not support both getting and putting messages concurrently on the same Queue Manager Channel. For this reason, it is a good idea to configure a dedicated channel for each component that gets or puts messages into a Websphere MQ destination in the context of XA transactions.
3. Set the max-xa-sessions-per-connection property in jboss-esb.xml to 1.

4. Save

   Save the file and exit.
5. Configure a dedicated queue manager channel for each component that obtains or sends messages to a Websphere MQ destination.
6. Make sure the GET and PUT properties on each of the Websphere MQ destinations are not set to Inhibit. (This can be happen when the destination is created and it results in the ESB being unable to obtain or send messages.)

Procedure 12.8. Task

1. Navigate to the bin directory: cd /opt/mqm/java/bin.
2. Launch JMSAdmin.
3. Use this program to administer your JNDI settings and obtain a ConnectionFactory for Plain JMS interactions.

   Note

   For more information about using JMSAdmin, refer to http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp.

Procedure 12.9. Task

1. Make a queue manager called QM1: crtmqm -q QM1
2. Start runmqsc: runmqsc QM1
3. Input the following settings when prompted:

   define channel (CH.1) chltype (RCVR) trptype (TCP)
   start channel (CH.1)
   define qlocal (Q1)
   define listener(QM1.LISTENER) trptype(TCP) port(30001) ipaddr(10.12.58.110)
   start listener (QM1.LISTENER) 
   (end)
   

4. Exit the program.
5. Copy com.ibm.mqetclient.jar from your Websphere MQ installation to your server: cp com.ibm.mqetclient.jar SOA_ROOT/jboss-as/PROFILE/lib/
6. Copy wmq.jmsra.ivt.ear from your Websphere MQ installation to your server: cp wmq.jmsra.ivt.ear SOA_ROOT/jboss-as/server/PROFILE/deploy
7. Copy wmq.jmsra.rar from your Websphere MQ installation to your server: cp wmq.jmsra.rar SOA_ROOT/jboss-as/server/PROFILE/deploy
8. Create a data source file in a text editor (be sure to change the IP address to that of your WSMQ server): vi SOA_ROOT/jboss-as/server/PROFILE/deploy/wsmq-ds.xml
   Here is a sample configuration:

   <?xml version="1.0" encoding="UTF-8"?>
   
    
   
   <connection-factories>
     <!-- connection factory definition -->
     <tx-connection-factory>
   
    
   
       <jndi-name>IVTCF</jndi-name>
       <xa-transaction />
       <rar-name>wmq.jmsra.rar</rar-name>
   
    
   
       <connection-definition>
         javax.jms.ConnectionFactory
       </connection-definition>
   
    
   
       <config-property name="channel" type="java.lang.String">SYSTEM.DEF.SVRCONN</config-property>
       <config-property name="hostName" type="java.lang.String">
         10.12.58.110
       </config-property>
       <config-property name="username" type="java.lang.String">mqm</config-property>
       <config-property name="password" type="java.lang.String">mqm</config-property>
       <config-property name="port" type="java.lang.String">30001</config-property>
       <config-property name="queueManager" type="java.lang.String">QM1</config-property>
       <config-property name="transportType" type="java.lang.String">CLIENT</config-property>
   
    
   
       <security-domain-and-application>JmsXARealm</security-domain-and-application>
     </tx-connection-factory>
   
    
   
     <!-- admin object definition -->
     <mbean code="org.jboss.resource.deployment.AdminObject"
         name="jca.wmq:name=ivtqueue">
   
    
   
       <attribute name="JNDIName">
         IVTQueue
       </attribute>
       <depends optional-attribute-name="RARName">
         jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'
       </depends>
       <attribute name="Type">javax.jms.Queue</attribute>
   
    
   
       <attribute name="Properties">
         baseQueueManagerName=QM1
         baseQueueName=Q1
       </attribute>
     </mbean>
   </connection-factories>
   

9. Save the file as and exit your text editor.
10. Launch a web browser and go to http://localhost:8080/WMQ_IVT/.
    This brings up the IVT ("Install Verification Test").
11. Run the normal test and the transactional test.

    Note

    For more information, refer to http://www.ibm.com/developerworks/websphere/library/techarticles/0710_ritchie/0710_ritchie.html.

Procedure 12.10. Task

1. Open the run.conf File

   Open the file in a text editor: vi SOA_ROOT/jboss-as/bin/run.conf.

2. Edit the run.conf File

   Appending the following lines onto the end of the file:

   # Settings to enable WebSphere MQ resource adapter trace
   JAVA_OPTS="$JAVA_OPTS -DtraceEnabled=true -DtraceDestination=wmq_jca.trc
   -DtraceLevel=10 -DlogWriterEnabled=false"
   

3. Enable Client Logging

   Still in the text editor, set the MQJMS_TRACE_LEVEL property:

   # Settings to enable WebSphere MQ resource adapter and client trace
   JAVA_OPTS="$JAVA_OPTS -DtraceEnabled=true -DtraceDestination=wmq_jca.trc
   -DtraceLevel=10 -DlogWriterEnabled=false -DMQJMS_TRACE_LEVEL=base"
   

4. Save

   Save the file and exit.

Procedure 12.11. Task

• Call the enableTrace Static Method

  Call the com.ibm.mq.MQEnvironment's enableTrace static method.

Procedure 12.12. Task

1. Edit the Configuration

   Open the configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.esb/META-INF/jboss-esb.xml.
2. Add these parameters:

   <property name="jndi-prefixes" value="connectionFactory. , destination"/>
   <property name="jndi-connection-factory" value="org.apache.qpid.jndi.PropertiesFileInitialContextFactory"/>
   <property name="connectionFactory.qpidConnectionFactory" value="amqp:// guest:guest@clientid/virtualHost?brokerlist='tcp://localhost:5672'"/>
   <property name="destination.[queueName]Queue" value="direct://amq.direct//[queueName]? routingkey=[routingkeyname]"/>
   

3. Save

   Save the file and exit.

4. Add the Requisite Files to the Class-Path

   Add these .JAR files to the classpath:
   • qpid-common-0.6.jar
   • qpid-client-0.6.jar

Procedure 12.13. Task

1. Edit the Configuration

   Open the configuration file in a text editor (vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.esb/META-INF/jboss-esb.xml) and set these parameters:

   jndi-URL="tcp://localhost:7222”
   jndi-context-factory=”com.tibco.tibjms.naming.TibjmsInitialContextFactory"
   connection-factory="QueueConnectionFactory"
   destination-type="queue"
   destination-name="myqueue"
   

2. Save

   Save the file and exit.

3. Add the Requisite Files to the Class-Path

   Add these .JAR files to the classpath (they are located in the tibco/ems/clients/java directory):
   • jaxp.jar
   • jndi.jar
   • tibcrypt.jar
   • tibjmsapps.jar
   • tibrvjms.jar
   • jms.jar
   • jta-spec1_0_1.jar
   • tibjmsadmin.jar
   • tibjms.jar

1. To configure the settings, open the properties file: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/jbossesb-properties.xml
2. Locate the following lines:

   <property name="org.jboss.soa.esb.registry.queryManagerURI" value="org.apache.juddi.registry.local.InquiryService#inquire"/>
   <property name="org.jboss.soa.esb.registry.lifeCycleManagerURI" value="org.apache.juddi.registry.local.PublishService#publish"/>
   

   Change them to this:

   <property name="org.jboss.soa.esb.registry.queryManagerURI" value="http://<server-name>:9901/uddi/inquiry_v2"/>
   <property name="org.jboss.soa.esb.registry.lifeCycleManagerURI" value="http://<server-name>:9901/uddi/publish_v2"/>
   <property name="org.jboss.soa.esb.registry.uddi.maxRows" value="100"/>
   

3. Edit the queryManagerURI and the lifeCycleManagerURI to match the URLs from your installation of SOA Workbench:

   <property name="org.jboss.soa.esb.registry.uddi.maxRows" value="100"/>
   <property name="org.jboss.soa.esb.registry.queryManagerURI" value="http://<server-name>:9901/uddi/inquiry_v2"/>
   <property name="org.jboss.soa.esb.registry.lifeCycleManagerURI" value="http://<server-name>:9901/uddi/publish_v2"/>
   

4. Locate this line:

   <property name="org.jboss.soa.esb.scout.proxy.transportClass" value="org.apache.ws.scout.transport.LocalTransport"/>
   

   Change it to this:

   <property name="org.jboss.soa.esb.scout.proxy.transportClass" value="org.apache.ws.scout.transport.AxisTransport"/>
   

5. Within jbossesb-properties.xml, change this to match the SOA Workbench username and password that you will be using:

   <property name="org.jboss.soa.esb.registry.user" value="administrator"/>
   <property name="org.jboss.soa.esb.registry.password" value="password"/>
   

6. Save the file and exit.

1. Download axis-bin-1_4.tar.gz from http://ws.apache.org/axis/ and extract axis-1.4.jar and commons-discovery-0.2.jar (or later).
2. Copy these two files into the lib directory: cp *jar SOA_ROOT/jboss-as/server/PROFILE/lib.

1. To apply the guest role to a guest user to grant anonymous access, go into the Organization Tree and click on the top-level registry node in the SOA Workbench hierarchy.

   Note

   SOA Workbench is a section of the SOA Service Manager Registry that acts as a third party UDDI registry provider.
2. Click on the second-level “Security” tab (within the Workbench hierarchy).
3. Click “Manage Role” for “Guest” under “Role Memberships.
4. Search for the user “guest”.
5. Select the checkbox next to “guest” and click “Apply".

1. To change the workflow so that services are published upon creation, click on the “Configure” tab and then select “Workflow”.
2. View the Workflow Definition, save it to your local disk, and then change the function type line under @create to <function type="publish" /> and the step attribute to “100”.
3. Save this.
4. Update the workflow to the local copy you have just saved.

• Use the "Search" option to find services. This feature also displays information about each service, including a description, its current state, its version number and the number of alerts it has generated. Services are registered in the SOA Service Workbench so manage them directly through its graphical user interface.

• If you encounter an error when configuring and updating the Workflow, you can verify it has been modified correctly by checking that its configuration has changed from the original configuration (which looked like this):

  <action id="1" name="@create">
  	<results>
  		<unconditional-result old-status="Created" status="Draft" step="100" owner="${caller}"/>
  	</results>
  	<post-functions>
  		<function type="setLifecycleStage">
  			<arg name="stage">Design</arg>
  			</function>
  	</post-functions>
  </action>
  

  Rather, it should now look like this:

  <action id="1" name="@create">
  	<results>
  		<unconditional-result old-status="Created" status="Draft" step="100" owner="${caller}"/>
  		</results>
  		<post-functions>
  			<function type="publish">
  		</function>
  	</post-functions>
  </action>
  

Procedure 13.1. Task

1. Open the Configuration File

   vi jboss-esb.xml

2. Edit the File

   Specify the following parameters:
   • jndi-URL
   • jndi-context-factory
   • jndi-pkg-prefix
   • connection-factory
   • destination-type
   • destination-name

   Important

   Make sure you include your JMS provider's client's JAR files in the class-path.

3. Save

   Save the file and exit the text editor.

Procedure 13.2. Task

1. Open the Relevant Configuration File

   Open the component in question's JNDI configuration file in a text editor.

2. Set the relevant Properties

   You can edit these two properties: max-sessions-per-connection and max-xa-sessions-per-connection
   You must set the parameters as generic properties in the JMS provider configuration files. This example code demonstrates how to do so:

   <jms-provider ...>
   	<property name="max-sessions-per-connection" value="5" />
   	<property name="max-xa-sessions-per-connection" value="1" />
   	<!-- And add providers.... -->
   </jms-provider>
   

   Note

   If you do not configure either of these parameters, then the JmsConnectionPool creates a single JMS connection and derives every session from it.

Procedure 13.3. Task

1. Edit the Configuration File

   Open the configuration file in a text editor and modify the settings. Here is a sample:

   <jms-jca-provider connection-factory="XAConnectionFactory" name="JBossMessaging">
   	<jms-bus busid="ordersGwChannel">
   		<jms-message-filter dest-name="queue/orders" dest-type="QUEUE" transacted="true"/>
   	</jms-bus>
   		<activation-config>
   			<property name="dLQMaxResent" value="5"/>
   		</activation-config>
   </jms-jca-provider>
   

2. Save

   Save the file and exit.

Procedure 13.4. Task

1. Add the jndi-prefixes for the Appropriate JMS Provider Element

   Open the configuration file in a text editor and add the jndi-prefixes for the appropriate JMS provider element with a comma-separated list of the additional prefixes you want to use:

   <jms-provider name="JMS" connection-factory="ConnectionFactory">
   <property name="jndi-prefixes” value="test.prefix." />
   <property name="test.prefix.extension1" value="extension1" />
   <property name="test.prefix.extension2" value="extension2" />
   </jms-provider>
   

   Note

   You can also configure the extensions property in this same location.

2. Save

   Save the file and exit.

Procedure 14.1. Task

1. Go into the jbpm.esb archive's config directory.
2. Locate the configuration file for the service you want to use.
3. To replace the active configuration, remove the one found in the jbpm.esb directory and replace it with the configuration file you wish to use (having first removed the .config suffix from its name).

Procedure 14.2. Task

1. To use the jBPM Job Executor in a web application, open the application's web.xml file in a text editor and add the following code:

             
   <!-- Job executor launcher -->
   	<listener>
   		<description>
   			Starts the job executor on initialization and stops it on destruction.
   		</description>
   			<listener-class>org.jbpm.web.JobExecutorLauncher</listener-class>
   	</listener>
   <!-- Job executor launcher -->
   

2. Save the file and exit.

Procedure 14.3. Task

1. Open a service.xml file in a text editor and add an MBean to it

   Note

   You can either make this specific to the jBPM (adding it to the jbpm-service.xml file) or it can be shared with other JCA inflow configurations.
   The following example code creates a provider adapter which refers to a remote JMS provider executing at this address: 192.168.1.1:1099.

         
   <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
   name="jboss.messaging:service=JMSProviderLoader,name=RemoteProviderLoader">
      <attribute name="ProviderName">RemoteProviderAdapter</attribute>
      <attribute
   name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
      <attribute name="QueueFactoryRef">XAQueueConnectionFactory</attribute>
      <attribute name="TopicFactoryRef">XATopicConnectionFactory</attribute>
      <attribute name="Properties">
         java.naming.provider.url=192.168.1.1:1099
      </attribute>
   </mbean>
   

   Note

   Use the value set for the Properties attribute to create the InitialContext for the JNDI.
2. Provide references to the provider adapter within the JMSMessageServiceFactory file. Open it in a text editor: vi JMSMessageServiceFactory
3. Add the location of the JNDI in the providerAdapterJNDI field:

         
   <service name="message">
     <factory>
       <bean
   class="org.jboss.soa.esb.services.jbpm.integration.msg.JmsMessageServiceFactory">
         <field name="providerAdapterJNDI"><string
   value="RemoteProviderAdapter"/></field>
       </bean>
     </factory>
   </service>
   

4. Save the file and exit.
5. Provide references to the provider adapter within the JMSSchedulerServiceFactory file in a text editor: vi JMSSchedulerServiceFactory
6. Add the location of the JNDI in the providerAdapterJNDI field.
7. Save the file and exit.

Procedure 15.1. Task

1. Add the Variable on a Red Hat Enterprise Linux System

   Open the file with the vi ~./bash_profile command and add the following line:

   export JBOSS_HOME=path

   (export JBOSS_HOME=/path/to/SOA_ROOT.)
2. Save and exit.

3. Add the Variable on a Microsoft Windows System

   Click on Control Panel → System → Advanced → Environment Variables and then New. Set the variable name to JBOSS_HOME and the variable value to the SOA_ROOT directory.

Procedure 15.2. Task

• Refer to the JBoss Enterprise Application Platform's Installation Guide for instructions.

  Note

  That Guide instructs you to install the files into the jboss-eap-5.1 directory. Substitute your SOA_ROOT every time you see mention of that directory.

Procedure 15.3. Task

1. Download the Package

   Download the MRG JCA Adapter from the Red Hat Customer Portal. Save it in the SOA_ROOT/jboss-as/server/PROFILE/deploy directory.

2. Create Queues

   To create queues, use the qpid-config add queue command.

3. Edit the Configuration File

   Open the configuration file: vi qpid-jca-ds.xml. In here, there are three JCA administration objects. You must set the destination addresses for the inbound (MRG-ESB_GW) and outbound ( MRG-ESB_RESP) queues and the routingKey for the outbound queue.

4. Save

   Save the file and exit.

Procedure 15.4. Task

1. Edit the Properties

   Open the global settings file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml. Search for org.jboss.soa.esb.ftp.renameretry and alter the value for this setting. It will look like this:

   <property name="org.jboss.soa.esb.ftp.renameretry" value="10"/>
   

2. Save

   Save the file and exit.

Procedure 16.1. Task

1. Obtain the Login Module (LM) located in org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
2. Open the LM's configuration file.
3. Enter the following code, inserting the names of the services you wish to use:

   <application-policy name="saml-issue-token">
        <authentication>
            <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule" flag="required">
                <module-option name="configFile">picketlink-sts-client.properties</module-option>
                <module-option name="endpointURI">http://security_saml/goodbyeworld</module-option>
            </login-module>
            <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
                <module-option name="configFile">picketlink-sts-client.properties</module-option>
            </login-module>
        </authentication>
    </application-policy>
   

   This configuration uses a stacked LM. The security token from the first LM is later used by the second LM which will validate the security token. Having two separate LMs for this can be useful as there can be situations where you only need to validate a security token.
4. Specify the picketlink-sts-client properties:

   serviceName=PicketLinkSTS
   portName=PicketLinkSTSPort
   endpointAddress=http://localhost:8080/picketlink-sts/PicketLinkSTS
   username=admin
   password=admin
   

   Note

   The username and password in this file are only used by the STSValidatingLoginModule. The username and password may also be stacked or provided by a callback.
5. To use this LM in JBossESB you need to update your server's login-config.xml with the above application-policy. You must also point the ESB service to where you want this LM to be used.
   For example, this is how you could configure it in jboss-esb.xml:

   <service category="SamlSecurityQuickstart" name="issueTokenService" invmScope="GLOBAL"
       description="This service demonstrates how a service can be configured to issue and validate a security token">
   
    
   
       <security moduleName="saml-issue-token" callbackHandler="org.jboss.soa.esb.services.security.auth.login.JBossSTSIssueCallbackHandler">
           <!-- disable the security context timeout so that our security context is re-evaluated -->
           <property name="org.jboss.soa.esb.services.security.contextTimeout" value="0"/>
       </security>
       ...
   </service>
   

   The callbackHandler that is is specified is specific to the ESB. This is because it requires access to the authentication request in the ESB for retreiving the username and password of the user for whom a security token should be issued.

Procedure 16.2. Task

1. Open the Login Module (LM) from org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule.
2. Configure the properties file as shown in the example below:

           <application-policy name="saml-validate-token">
       <authentication>
           <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
               <module-option name="configFile">picketlink-sts-client.properties</module-option>
           </login-module>
       </authentication>
   </application-policy>
   
    
   
   And in jboss-esb.xml:
   <service category="SamlSecurityQuickstart" name="securedSamlService" invmScope="GLOBAL"
       description="This service demonstrates that an ESB service can be configured to only validate a security token.">
   
       <security moduleName="saml-validate-token" callbackHandler="org.jboss.soa.esb.services.security.auth.login.JBossSTSTokenCallbackHandler">
           <!-- disable the security context timeout so that our security context is re-evaluated -->
           <property name="org.jboss.soa.esb.services.security.contextTimeout" value="0"/>
       </security>
       ...
   </service>
   

   Note

   The callbackHandler that is specified is specific to the ESB. This is because it requires access to the authentication request in the ESB for retreiving the SAML Token which is to be validated.

   Note

   An example of SAML support in JBossESB can be found in the security_saml quickstart. More information about the Login Modules provied by PicketLink can be found at http://www.jboss.org/community/wiki/STSLoginModules

Procedure 16.3. Task

1. Scroll down to the section that contains properties name="security" and edit the settings to suit your system:

   <properties name="security"> 
   <property name="org.jboss.soa.esb.services.security.implementationClass"
   value="org.jboss.internal.soa.esb.services.security.JaasSecurityService"/>
   
   <property name="org.jboss.soa.esb.services.security.callbackHandler" 
   value= 
   "org.jboss.internal.soa.esb.services.security.UserPassCallbackHandler"/>
           
   <property name="org.jboss.soa.esb.services.security.sealAlgorithm" 
   value="TripleDES"/> 
   
   <property name="org.jboss.soa.esb.services.security.sealKeySize" 
   value="168"/>
   
   <property name="org.jboss.soa.esb.services.security.contextTimeout" 
   value="30000"/>
   
   <property name= 
   "org.jboss.soa.esb.services.security.contextPropagatorImplemtationClass" 
   value= 
   "org.jboss.internal.soa.esb.services.security.JBossASContextPropagator"/>
           
   <property name="org.jboss.soa.esb.services.security.publicKeystore" 
   value="/publicKeyStore"/> 
   
   
   <property name="org.jboss.soa.esb.services.security.publicKeystorePassword" 
   value="testKeystorePassword"/> 
   
   <property name="org.jboss.soa.esb.services.security.publicKeyAlias" 
   value="testAlias"/> 
   
   <property name="org.jboss.soa.esb.services.security.publicKeyPassword" 
   value="testPassword"/> 
   
   <property name="org.jboss.soa.esb.services.security.publicKeyTransformation" 
   value="RSA/ECB/PKCS1Padding"/> 
   
   </properties>
   

2. Save the file and exit.
3. Open the log-in configuration file in your text editor: vi SOA_ROOT/server/PROFILE/conf/login-config.xml
4. Configure the JAAS log-in modules by editing the settings in this file. (You can use either a pre-configured option or create your own custom solution.)
5. Save the file and exit.

Procedure 16.4. Task

1. Go to the conf directory: cd SOA_ROOT/jboss-as/server/PROFILE/conf
2. Execute this command: java -cp ../../../lib/jbosssx.jar org.jboss.security.plugins.FilePassword welcometojboss 13 testpass esb.password

Procedure 16.5. Task

1. Generate a key pair using this command: keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore password.keystore and follow the prompts:

           keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore password.keystore
   Enter keystore password:  
   Re-enter new password: 
   What is your first and last name?
     [Unknown]:  Bob Bobson
   What is the name of your organizational unit?
     [Unknown]:  Corporate_IT
   What is the name of your organization?
     [Unknown]:  XYZ
   What is the name of your City or Locality?
     [Unknown]:  BRISBANE
   What is the name of your State or Province?
     [Unknown]:  QLD
   What is the two-letter country code for this unit?
     [Unknown]:  AU
   Is CN=Bob Bobson, OU=Corporate_IT, O=XYZ, L=BRISBANE, ST=QLD, C=AU correct?
     [no]:  yes
   
   Enter key password for jboss
   	(RETURN if same as keystore password):
   

   Note

   You must specify the same password for the key store and key pair.
2. Run chown to change ownership to the JBoss Application Server process owner, and chmod 600 password.keystore to make sure only the file's owner can read it.

   Note

   The process owner should not have console log-in access. In that case you will be performing these operations as another user. Creating masked passwords requires read access to the key store, so you may wish to complete configuration of masked passwords before restricting the key store file permissions.
3. Navigate to the jboss-as/bin directory: cd SOA_ROOT/jboss-as/bin
4. Run the password tool, using the command ./password_tool.sh on Red Hat Enterprise Linux systems, (or password_tool.bat on Microsoft Windows-based systems.)
5. Select 0: Encrypt Keystore Password by pressing 0, then Enter.
6. Enter the key store password you specified above.
7. Enter a random string of characters to aid with encryption strength. This is the salt.
8. Enter a whole number for the iterator count to aid with encryption strength.
9. Select 5: Exit to exit.

   Note

   The password tool will exit with the message: Keystore is null. Cannot store. This is normal.
10. Use the chown command to change ownership of the password/jboss_keystore_pass.dat file to the process owner, and chmod 600 jboss-keystore_pass.dat to ensure that only that owner can read the file.
11. Navigate to the jboss-as/bin directory: cd SOA_ROOT/jboss-as/bin
12. Run the password tool, using the command ./password_tool.sh on Red Hat Enterprise Linux systems (or password_tool.bat on Microsoft Windows systems).
13. Select 1: Specify KeyStore by pressing 1 then Enter.
14. Enter the path to the key store you created above. (You can specify an absolute path, or the path relative to SOA_ROOT/jboss-as/bin. This should be SOA_ROOT/jboss-as/bin/password.keystore, unless you have changed the defaults.)
15. Enter the key alias. This should be "jboss" (unless you have performed an advanced installation and changed the defaults).
16. Select 2: Create Password by pressing 2, then Enter. You will be prompted for the security domain. Follow the prompts on screen.

            /password_tool.sh 
    **********************************
    ****  JBoss Password Tool********
    **********************************
    Error while trying to load data:Encrypted password file not located
    Maybe it does not exist and need to be created.
    0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
    1
    Enter Keystore location including the file name
    password.keystore
    Enter Keystore alias
    jboss
    0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
    2
    Enter security domain:
    
    default
    Enter passwd:
    passwordmask
    Password created for domain:default
    0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
    

17. Enter a name for the password mask. This is an arbitrary unique name that you will use to identify the password mask in configuration files.
18. Enter the password that you wish to mask.
19. Repeat the password mask creation process to create masks for all passwords you wish to mask.
20. Exit the program by choosing 5: Exit
21. Navigate to the password directory: cd SOA_ROOT/jboss-as/bin/password

Procedure 16.6. Task

• Launch a text editor and replace each occurrence of a clear text password in the configuration files with an annotation referencing its mask.
  This is the general form of the annotation:

  <annotation>
  @org.jboss.security.integration.password.Password(securityDomain=MASK_NAME, methodName=setPROPERTY_NAME)
  </annotation>
  

  As a concrete example, the JBoss Messaging password is stored in the server profile's deploy/messaging/messaging-jboss-beans.xml file. If you create a password mask named "messaging", then the before and after snippet of the configuration file will looks like this:

  <property name="suckerPassword">
  CHANGE ME!!
  </property>
  

  <annotation>
  @org.jboss.security.integration.password.Password(securityDomain=messaging,
  methodName=setSuckerPassword)
  </annotation>
  

Procedure 16.7. Task

1. Open the security configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/security/security-jboss-beans.xml.
2. Edit the key store location and key alias. Here are some example settings:

   <!-- Password Mask Management Bean-->
      <bean name="JBossSecurityPasswordMaskManagement"
            class="org.jboss.security.integration.password.PasswordMaskManagement" >
            <property name="keyStoreLocation">password/password.keystore</property>
            <property name="keyStoreAlias">jboss</property>
            <property name="passwordEncryptedFileName">password/jboss_password_enc.dat</property>
            <property name="keyStorePasswordEncryptedFileName">password/jboss_keystore_pass.dat</property>
      </bean>
   

3. Save the file and exit.

Procedure 16.8. Task

1. Navigate to the SOA_ROOT directory: cd SOA_ROOT.
2. Run the keytool command and follow the prompts on screen:

   keytool -genkey -alias droolsKey -keyalg RSA -keystore MyDroolsPrivateKeyStore.keystore
   Enter keystore password:  
   Re-enter new password: 
   What is your first and last name?
     [Unknown]:  Test User
   What is the name of your organizational unit?
     [Unknown]:  HR
   What is the name of your organization?
     [Unknown]:  Test Org
   What is the name of your City or Locality?
     [Unknown]:  Brisbane
   What is the name of your State or Province?
     [Unknown]:  QLD
   What is the two-letter country code for this unit?
     [Unknown]:  AU
   Is CN=Test User, OU=HR, O=Test Org, L=Brisbane, ST=QLD, C=AU correct?
     [no]:  yes
   Enter key password for droolsKey
        (RETURN if same as keystore password):  
   Re-enter new password:
   

   After answering all of the questions, a password-protected file named MyDroolsPrivateKeyStore.keystore is created. This keystore file has a private key called droolsKey with the password "drools". Store this file in a safe location in your environment, which will hereafter be referred to as the keystoredir.

   Important

   The passwords above are examples only and should not be used in production.
3. Open the configuration file: vi jboss-as/server/default/deploy/properties-service.xml
4. Configure the JBoss Enterprise SOA Platform to use the JBoss Rules serialization feature by adding this snippet to properties-service.xml:

   <mbean code="org.jboss.varia.property.SystemPropertiesService"  name="jboss:type=Service,name=SystemProperties">
       <attribute name="Properties">
         # Drools Security Serialization specific properties
         drools.serialization.sign=true
         drools.serialization.private.keyStoreURL=file://$keystoredir/MyDroolsPrivateKeyStore.keystore
         drools.serialization.private.keyStorePwd=drools
         drools.serialization.private.keyAlias=droolsKey
         drools.serialization.private.keyPwd=drools
       </attribute>
   </mbean>
   

5. Set the drools.serialization.sign property to "true":

   drools.serialization.sign=true
   

   • drools.serialization.private.keyStoreURL=<RL> is the URL of the private keystore location.
   • In the example above, replace keystoredir and MyDroolsKeyStore.keystore with your keystore directory and the name of the keystore you created with the keytool
   • drools.serialization.private.keyStorePwd=<password> is the password to access the private keystore.
   • drools.serialization.private.keyAlias=<key> is the key alias (identifier) of the private key.
   • drools.serialization.private.keyPwd=<password> is the private key password.
6. Save the file and exit.
7. Restart the server instance.

   Warning

   If the system properties were not configured properly, you will see this error when you try to build a rules package:

   An error occurred building the package.
   
   Error
   signing object store: Key store with private key not configured. Please
   configure it properly before using signed serialization
   

Procedure 16.9. Task

1. Create a public key certificate from the private keystore. (You can access the keytool by running keytool -genkey -alias droolsKey -keyalg RSA -keystore.):

   keytool -export -alias droolsKey -file droolsKey.crt -keystore
   

       
   MyDroolsPrivateKeyStore.keystore 
   Enter keystore password:  
   Certificate stored in file <droolsKey.crtU>
   

2. Import the public key certificate into a public keystore. (This is where it will be used by your client applications):

   keytool -import -alias droolsKey -file droolsKey.crt -keystore
   

   MyPublicDroolsKeyStore.keystore
   Enter keystore password:  
   Re-enter new password: 
   Owner: CN=Test User, OU=Dev, O=XYZ Corporation, L=Brisbane, ST=QLD, C=AU
   Issuer: CN=Test User, OU=Dev, O=XYZ Corporation, L=Brisbane, ST=QLD, C=AU
   Serial number: 4ca0021b
   Valid from: Sun Sep 26 22:31:55 EDT 2010 until: Sat Dec 25 21:31:55 EST 2010
   Certificate fingerprints:
        MD5:  31:1D:1B:98:59:CC:0E:3C:3F:57:01:C2:FE:F2:6D:C9
        SHA1: 4C:26:52:CA:0A:92:CC:7A:86:04:50:53:80:94:2A:4F:82:6F:53:AD
        Signature algorithm name: SHA1withRSA
        Version: 3
   Trust this certificate? [no]:  yes
   Certificate was added to keystore
   

3. Open the server configuration file: vi grep drools jboss-as/server/default/deploy/properties-service.xml
4. Replace keystoredir and MyPublicDroolsKeyStore.keystore with your keystore directory, and the name of the public keystore you created previously:

   # Drools Client Properties for Security Serialization
   drools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore
   drools.serialization.public.keyStorePwd=drools
   

5. Save the file and exit.
6. Restart the JBoss Enterprise SOA Platform server.
7. For Java client applications, set the system properties in your code like this:

   // Set the client properties to deserialize the signed packages
   URL clientKeyStoreURL = getClass().getResource( "MyPublicDroolsKeyStore.keystore" );
   System.setProperty( KeyStoreHelper.PROP_SIGN,
                               "true" );
   System.setProperty( KeyStoreHelper.PROP_PUB_KS_URL,
                               clientKeyStoreURL.toExternalForm() );
   System.setProperty( KeyStoreHelper.PROP_PUB_KS_PWD,
                               "drools" );
   ...
   

   Alternatively, open the run.sh shell script (vi SOA_ROOT/jboss-as/bin/run.sh) script and edit the JAVA_OPTS section:

   # Serialization Security Settings
   JAVA_OPTS="-Ddrools.serialization.sign=true $JAVA_OPTS"
   JAVA_OPTS="-Ddrools.serialization.private.keyStoreURL=file://$keystoredir/MyDroolsKeyStore.keystore $JAVA_OPTS"
   JAVA_OPTS="-Ddrools.serialization.private.keyStorePwd=drools $JAVA_OPTS"
   JAVA_OPTS="-Ddrools.serialization.private.keyAlias=droolsKey $JAVA_OPTS"
   JAVA_OPTS="-Ddrools.serialization.private.keyPwd=drools $JAVA_OPTS"
   JAVA_OPTS="-Ddrools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore $JAVA_OPTS"
   JAVA_OPTS="-Ddrools.serialization.public.keyStorePwd=drools $JAVA_OPTS"
   

   Replace the values shown above with ones specific to your environment, and then restart the server instance.

1. Open the configuration file: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/properties-service.xml.
2. Remove the drools.serialization.sign property's value.
3. Save the file and exit.
   An alternative way to do this task is to open the run.sh shell script (vi SOA_ROOT/jboss-as/bin/run.sh) and edit it as follows:

   JAVA_OPTS="-Ddrools.serialization.sign=false $JAVA_OPTS"
   

4. Restart the server instance.
5. To turn signing off for Java client applications, remove the drools.serialization.sign property or add the following snippet to each application's code:

   System.setProperty( KeyStoreHelper.PROP_SIGN, "false" );
   

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jboss-esb.xml.
2. Scroll down to the service you want to configure.
3. Add a security element. This setting shows you how to do so:

   <service category="Security" name="SimpleListenerSecured"> 
      <security moduleName="messaging" runAs="adminRole"
       rolesAllowed="adminRole, normalUsers"
       callbackHandler="org.jboss.internal.soa.esb.services.security.UserPassCallbackHandler"> 
   	    <property name="property1" value="value1"/> 
   	    <property name="property2" value="value2"/> 
      </security>
      ...
   </service>
   

4. Save the file and exit.

Procedure 16.10. Task

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Configure the setting in question. Here is an example:

   <security moduleName="messaging" 
     runAs="adminRole" rolesAllowed="adminRole">
   
   <property 
       name="org.jboss.soa.esb.services.security.contextTimeout" 
       value="50000"/> 
     
   <property name=
   "org.jboss.soa.esb.services.security.contextPropagatorImplementationClass"
       value="org.xyz.CustomSecurityContextPropagator" /> 
   
   </security>
   

3. Save the file and exit.

Procedure 16.11. Task

• Execute this code:

  byte[] encrypted = PublicCryptoUtil.INSTANCE.encrypt((Serializable)
   authRequest);
  message.getContext.setContext(SecurityService.AUTH_REQUEST, encrypted);
  

Procedure 16.12. Task

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
2. Scroll down to the section that contains security.contextTimeout. Set the time-out value (in milliseconds).
3. Save the file and exit.

Procedure 16.13. Task

1. Open the service's configuration file in a text editor: vi jboss-esb.xml.
2. Scroll down to the section that contains Security Context. Set the time-out value (in milliseconds).
3. Save the file and exit.

Procedure 17.1. Task

1. Open the log-in configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
2. Add the details of your custom log-in module.
3. Save the file and exit.
4. Since different log-in modules require different information, you must specify the CallbackHandler attribute to be used. Open the specific security configuration for that service.
5. Make sure that the CallbackHandler specifies a fully-qualified classname for the class which implements the EsbCallbackHandler interface. This code shows you how to do so:

   public interface EsbCallbackHandler extends CallbackHandler
   {
     void setAuthenticationRequest(final AuthenticationRequest authRequest);
     void setSecurityConfig(final SecurityConfig config);
   }
   

6. Add both the "principle" and the credentials needed to authenticate a caller to the AuthenticationRequest class.

Procedure 17.2. Task

1. Open the log-in configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
2. Set the rolesPropertiesFile property. (This property can point to a file located on either the local file system or the class-path).
3. Map users to roles. This example code shows how to do so:

   # user=role1,role2,...
   guest=guest
   esbuser=esbrole
   # The current implementation will use the Common Name(CN) specified
   # for the certificate as the user name.
   # The unicode escape is needed only if your CN contains a space
   Andy\u0020Anderson=esbrole,worker
   

4. Save the file and exit.

Procedure 17.3. Task

1. Implement the SecurityService interface:

   public interface SecurityService
   {
       void configure() throws ConfigurationException;
   
       void authenticate(
           final SecurityConfig securityConfig, 
           final SecurityContext securityContext, 
           final AuthenticationRequest authRequest) 
           throws SecurityServiceException;
   
       boolean checkRolesAllowed(
           final List<String> rolesAllowed, 
           final SecurityContext securityContext);
   
       boolean isCallerInRole(
           final Subject subject, 
           final Principle role);
   
       void logout(final SecurityConfig securityConfig);
   
       void refreshSecurityConfig();
   }
   

2. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
3. Configure the file to use the customized SecurityService
4. Save the file and exit.

Procedure 17.4. Task

1. Edit the Settings in the jboss-service.xml File

   Open the file in a text editor: vi SOA_ROOT/server/PROFILE/conf/jboss-service.xml

2. Configure the Settings in the File

   Here is an example:

   <attribute name="DownloadServerClasses">false</attribute>
   

   Set this value to false to ensure that client applications can only download Enterprise Java Bean classes.

   Important

   By default, this value is set to false in the SOA Platform's 'production' profile. The value is set to true in all other cases, including the SOA Standalone version's default profile. Note that this is not a secure configuration and should only be used in development environments.

Procedure 18.1. Task

1. Make a GetAuthToken() request.
2. A GetAuthToken object is returned. Set a userid and credential (password) on this object:

   org.uddi.api_v3.GetAuthToken ga = new org.uddi.api_v3.GetAuthToken();
   ga.setUserID(pubId);
   ga.setCred("");
   
   org.uddi.api_v3.AuthToken token = securityService.getAuthToken(ga);
   

3. Locate the juddi.properties configuration file in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF. Open it in a text editor.
4. Configure the juddi.authenticator property to how the Service Registry will check the credentials passed to it by the GetAuthToken request. (By default it uses the jUDDIAuthenticator implementation.)
5. Save the file and exit.

Procedure 18.2. Task

1. Create a text file called juddi-users.xml and save it in jbossesb-registry.sar.

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <juddi-users>
       <user userid="sscholl" password="password" />
       <user userid="dsheppard" password="password" />
       <user userid="vbrittain" password="password" />
   </juddi-users>
   

2. Save the file and exit.
3. Add the file to the class-path.
4. Open the juddi.properties file in your text editor (located in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF).
5. Modify the file so that it looks like this:

   juddi.authenticator = org.apache.juddi.auth.XMLDocAuthentication
   juddi.usersfile = juddi-users.xml
   

6. Save the file and exit.

Procedure 18.3. Task

1. Locate the juddi.properties file in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF. Open it in your text editor.
2. Add the following configuration settings:

   juddi.authenticator=org.apache.juddi.auth.LdapSimpleAuthenticator
   juddi.authenticator.url=ldap://localhost:389
   

   The juddi.authenticator.url property tells the LdapSimpleAuthenticator class where the LDAP server resides.
3. Save the file and exit.

Procedure 18.4. Task

1. Locate the juddi.properties file in SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF. Open it in your text editor.
2. Add the following lines to the file:

   uddi.auth=org.apache.juddi.auth.JBossAuthenticator
   juddi.securityDomain=java:/jaas/other
   

   The juddi.authenticator property connects the JbossAuthenticator class to the jUDDI Registry's Authenticator framework. The juddi.security.domain tells JBossAuthenticator where it can find the Application Server's security domain. It uses this domain to perform the authentications.
   Note that JBoss creates one security domain for each application policy element in the SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml file. These domains are bound to the server JNDI tree with this name: java:/jaas/<application-policy-name>. (If a look-up refers to a non-existent application policy, a policy named other will be used by default.)
3. Save the file and exit.

Procedure 19.1. Start the JBoss Enterprise SOA Platform in a Production Environment

1. Navigate to the bin Directory

   Open a terminal and input this command: cd SOA_ROOT/jboss-as/bin (or chdir SOA_Root\jboss-as\bin in Microsoft Windows).

   Note

   It is required that you have set up an administration username and password before proceeding.

2. Launch the JBoss Enterprise SOA Server on Red Hat Enterprise Linux

   To start the product, run this command: ./run.sh -c production

3. Launch the JBoss Enterprise SOA Server on Microsoft Windows

   To start the product, run this command: run.bat -c production

Procedure 19.2. Task

• To make the JBoss Enterprise SOA Platform run as a background daemon (service), you will have to create your own shell script. Red Hat does not supply any scripts to do this.

Procedure 19.3. Task

• To start the JBoss Enterprise SOA Platform as a service, issue this command: service jboss_soa start

  Note

  If the JBoss user was created as a system account (using the -R switch) then a warning message is displayed. You can safely ignore this.

Procedure 19.4. Task

• To stop the JBoss Enterprise SOA Platform when it is running as a service, issue this command: service jboss_soa stop

Procedure 20.1. Remove the JBoss Enterprise SOA Platform from Your System

1. Remove the JBoss Enterprise SOA Platform from a Red Hat Enterprise Linux System

   Having made sure the server is shut down, navigate to the level above the SOA_ROOT directory and issue this command: rm -Rf SOA_ROOT.

2. Remove the JBoss Enterprise SOA Platform from a Microsoft Windows System

   Having made sure the server is shut down, open Windows Explorer, go to the directory in which the SOA_ROOT is located, select the SOA_ROOT and delete it.
3. Delete the database.