Procedure 3.1. Task

1. Study the quickstart's readme.txt file.
2. Run the ant help command in the quickstart's directory.

Procedure 5.1. Task

1. In order to publish contract information, you must give an action the following org.jboss.internal.soa.esb.publish.Publish annotation. (This example uses the SOAPProcessor for demonstrative purposes):

   @Publish(JBossWSWebserviceContractPublisher.class)
   public class SOAPProcessor extends AbstractActionPipelineProcessor {
   //TODO: implement
   }
   

2. Implement the org.jboss.soa.esb.actions.soap.ContractPublisher interface (You only need to implement one method):

   public ContractInfo getContractInfo(EPR epr);
   

Procedure 6.1. Task

• Use jBPM's Process Designer functionality.

  Note

  A side benefit of using this tool is that it can help foster good working relationships between your business analysts and your technical developers.

1. You have many deployment options: choose from using the GPD deployment (Graphical Design Process) tab, the JSF console upload form and the Ant DeployProcessTask.

   Warning

   Do not include the jBPM libraries in your deployed ESB applications. The jbpm.esb module already provides the libraries and configuration files required to run jBPM applications. Always use the provided versions and default settings as these have been refined by Red Hat's extensive Quality Engineering tests in order to prevent issues such as class loading conflicts and configuration mismatches.

   Note

   Process definitions should be deployed separately from the web application. Red Hat recommends that you deploy the process before the web application so that the latter can operate under the assumption the process is available at all times.
2. The jBPM Graphical Design Process editor includes four modes: Diagram, Deployment, Design and Source, which are available as switchable tabs at the bottom of the editor. To adjust the deployment settings of the project you should select the tab that opens the Deployment mode. You can easily modify them or, if the settings do not match your needs, reset them to their defaults.
3. In multi-tenancy use cases, a single server hosts many applications, each of which requires a different configuration. Red Hat recommends that you give each configuration file a unique name (something other than jbpm.cfg.xml), to avoid overriding the default configuration file that comes provided with the platform.

1. To create a JBPM database, start the DatabaseInitializerMBean. (You will find the configuration settings for this MBean in the first configuration element of the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbpm.esb/jbpm-service.xml file.)

   Warning

   The JbpmDS data source is defined in the jbpm-ds.xml file, located in SOA_ROOT/jboss-as/server/PROFILE/deploy/jbpm.esb. By default, it uses a Hypersonic database. Always change this to a production-quality database in a live environment.

   Warning

   The JBoss Enterprise SOA Platform also comes equipped with Hypersonic, an in-memory reference database. Use this in testing environments only.
2. Follow the example shown below:

   <classpath codebase="deploy" archives="jbpm.esb"/>
   <classpath codebase="deploy/jbossesb.sar/lib" 
      archives="jbossesb-rosetta.jar"/>
   
   <mbean code="org.jboss.internal.soa.esb.dependencies.DatabaseInitializer"
          name="jboss.esb:service=JBPMDatabaseInitializer">
         <attribute name="Datasource">java:/JbpmDS</attribute>
         <attribute name="ExistsSql">select count(*) from JBPM_ID_USER</attribute>
         <attribute name="SqlFiles">
         jbpm-sql/jbpm.jpdl.hsqldb.sql
         </attribute>
         <depends>jboss.jca:service=DataSourceBinding,name=JbpmDS</depends>
         <attribute name="UseEOL">true</attribute>
   </mbean>
   
   <mbean code="org.jboss.soa.esb.services.jbpm.configuration.JbpmService"
      name="jboss.esb:service=JbpmService">
   </mbean>
   

1. The jbpm.cfg.xml file is set to tell the JBPM to use the JTA Transaction Manager:

   <service name="persistence">
         <factory>
           <bean class="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory">
             <property name="isTransactionEnabled"><false/></property>
             <property name="isCurrentSessionEnabled"><true/></property>
             <!--property name="sessionFactoryJndiName">
               <string value="java:/myHibSessFactJndiName" />
             </property-->
           </bean>
        </factory>
        </service>
   

2. The hibernate.cfg.xml file also tells the JBPM use the JTA Transaction Manager:

       <!-- JTA transaction properties (begin) -->
       <property name="jta.UserTransaction">UserTransaction</property>
       <property name="hibernate.current_session_context_class">jta</property>
       <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
       <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
       <!-- JTA transaction properties (end) -->
   
   

   Note

   Do not use Hibernate to create the database schema. Use the DatabaseInitializer MBean instead.
3. The jbpm.mail.templates.xml file contains the following:

           jboss-as ]$ cat server/default/deploy/jbpm.esb/jbpm.mail.templates.xml 
   
   <?xml version="1.0" encoding="UTF-8"?>
   <mail-templates>
     <variable name="taskListBaseURL" value="http://localhost:8080/jbpm-console/app/task.jsf?id=" />
   
     <mail-template name='task-assign'>
       <actors>${taskInstance.actorId}</actors>
       <subject>Task notification: ${taskInstance.name}</subject>
       <text><![CDATA[Hi ${taskInstance.actorId},
   Task '${taskInstance.name}' has been assigned to you.
   Go for it: ${taskListBaseURL}${taskInstance.id}
   
   Sent by jBPM]]></text>
     </mail-template>
   
     <mail-template name='task-reminder'>
       <actors>${taskInstance.actorId}</actors>
       <subject>Task reminder: ${taskInstance.name}</subject>
       <text><![CDATA[Hey ${taskInstance.actorId},
   Do not forget about task '${taskInstance.name}'.
   Get going: ${taskListBaseURL}${taskInstance.id}
   
   Sent by jBPM]]></text>
     </mail-template>
   </mail-templates>
   

   Note

   To learn more about each of these configuration files, refer to the JBPM Reference Guide.

1. Use a Creation wizard to create an empty process definition. Select File → New → Other. The wizard opens on the Select Wizard page.
2. Select the JBoss jBPM category, then the jBPM Process Definition item. Clicking on the Next button brings us to the Create Process Definition page.
3. Type in a name for the process archive file. Click on the Finish button to end the wizard and open the process definition editor.
4. By viewing the Package Explorer, you can see that creating a process definition involves creating an XML file called [process name].jpdl.xml, which contains the process definition information. A JPG file called [process name].jpg will also be automatically generated when changes are saved to the process.

1. Check that the server is running.
2. Activate a process archive by going to the JBPM Graphical Editor's Deployment tab.

   Note

   Sometimes you will only need to deploy the processdefinition.xml file but, most often, you will be deploying other types of artifacts as well, such as task forms.
3. Deploy the definition using one of these methods:
   1. Using JBoss Developer Studio , configure the upload servlet used by the deployer. Next, click the Deploy Process Archive button. This is visible in the Deployment view.
   2. Using the DeployProcessToServer JBPM ant task.
   3. Save the deployment to a local .par file from the Deployment view. Next, activate the archive using the JBPM console. (This requires that you have administration privileges.)

1. The configuration for this action in the jboss-exb.xml looks like this:

   <action name="create_new_process_instance" class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
   	<property name="command" value="StartProcessInstanceCommand" />
   	<property name="process-definition-name" value="processDefinition2"/>
   	<property name="actor" value="FrankSinatra"/>	
   	<property name="esbToBpmVars">
   		<!-- esb-name maps to getBody().get("eVar1") -->
   		<mapping esb="eVar1" bpm="counter" default="45" />
   		<mapping esb="BODY_CONTENT" bpm="theBody" />
   	</property>
   </action>
   

2. You are required to input these two attributes:
   1. name
      Use any value for this name attribute, as long as it is unique in the action pipeline .
   2. class
      Always set this attribute to org.jboss.soa.esb.services.jbpm.actions.BpmProcessor .

1. Attach the EsbNotifier to the JBPMprocessdefinition.xml file's outgoing transition as shown below:

   <node name="ShipIt">
     <transition name="ProcessingComplete" to="end">
       <action name="ShipItAction" 
         class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier">
         <esbCategoryName>BPM_Orchestration4</esbCategoryName>
         <esbServiceName>ShippingService</esbServiceName>                           
         <bpmToEsbVars>
           <mapping bpm="entireCustomerAsObject" esb="customer" />
           <mapping bpm="entireOrderAsObject" esb="orderHeader" />
           <mapping bpm="entireOrderAsXML" esb="entireOrderAsXML" />
         </bpmToEsbVars>
       </action>
     </transition>
   </node>
   

2. You can specify the following attributes:
   • name
     This is required. It is the user-specified name of the action
   • class
     This is required. You must set it to org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier

1. Attach the EsbActionHandler to a node to call an action when that node is entered. When the EsbActionHandler is executed, the node waits for a transition signal (normally sent by the JBossESB callback service).
2. Configure as follows:

   <action name="create_new_process_instance" 
     class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
   
     <property name="command" value="StartProcessInstanceCommand" />
     <property name="process-definition-name" value="processDefinition2"/>
     <property name="actor" value="FrankSinatra"/>                                                 
     
     <property name="esbToBpmVars">
     <!-- esb-name maps to getBody().get("eVar1") -->
       <mapping esb="eVar1" bpm="counter" default="45" />
       <mapping esb="BODY_CONTENT" bpm="theBody" />
     </property>             
   
   </action>
   

• Add a JBPM-native timer to the appropriate node. In this example, the timer has been configured so a transition called time-out is triggered if there is no signal received in ten seconds:

  <timer name='timeout' duedate='10 seconds' transition='time-out'/>
  

1. Once the server has stopped, access the JBPM Console from this address: http://localhost:8080/jbpm-console/app/processes.jsf.
2. You can now use the JBPM Console to deploy and monitor processes and tasks. The bpm_orchestration4 quick start demonstrates this feature.

   Warning

   The JbpmDS data source is defined in the jbpm-ds.xml file. By default, it uses a Hypersonic database. Always change this to a production-quality database in a live environment.

   Note

   Make sure that every jbpm.esb deployment shares the same database instance. (This is so that the various Enterprise Service Bus nodes have access to the same processes definitions.)

1. Select File → New → Other.
2. Choose JBoss jBPM Process Definition from the Selection wizard.
3. Save the process definition. Use a separate directory for each process definition to avoid confusion.
4. Start to "drag-and-drop" items from the jBPM Integrated Development Environment 's menu palette into the Process Design view. You can switch between the design and source modes to check XML elements as you add them.
5. Add the XML fragments that are needed for the integration.
6. Before building the order process diagram, create and test the three services. These are ordinary ESB services and they are defined in the jboss-esb.xml file. An example configuration with service names and categories is shown below:

   <services>
     <service category="BPM_orchestration4_Starter_Service" 
     name="Starter_Service"
     description="BPM Orchestration Sample 4: Use this service to start a 
   process instance">
   			<!-- .... -->						
     </service>
     <service category="BPM_Orchestration4" name="IntakeService"
     description="IntakeService: transforms, massages, calculates priority">
   			<!-- .... -->
     </service>		
     <service category="BPM_Orchestration4" name="DiscountService"
       description="DiscountService">					
     </service>		
     <service category="BPM_Orchestration4" name="ShippingService"
       description="ShippingService">			
   			<!-- .... -->
     </service>		 	
   </services>
   

7. Refer to these services by using either the EsbActionHandler or EsbNotifier action handler. (Choose the EsbActionHandler in cases where the JBoss Business Process Manager expects a response, and the EsbNotifier when none is required.)
8. Now that the ESB services are known, drag the Start state node into the design view. A new process instance will begin at this node.
9. Drag in a node and name it Intake Order.
10. Connect the Start and the Intake Order nodes by selecting Transition from the menu and then clicking on each of them. An arrow connecting them will appear. It will be pointing towards the first Intake Order.
11. Add the Service and Category names to the Intake Node. Select the Source view. You will be able to see the source code for the Intake Order node. It should look like this:

    <node name="Intake Order">
    	<transition name="" to="Review Order"></transition>
    </node>
    

12. Add the EsbActionHandler class reference, followed by the sub-element configuration settings for the service category and name, BPM_Orchestration4 and the IntakeService. It should look like this:

    <node name="Intake Order">
    	<action name="esbAction" class=
    		"org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
    			<esbCategoryName>BPM_Orchestration4</esbCategoryName>
    			<esbServiceName>IntakeService</esbServiceName>
    			<!-- async call of IntakeService -->
    	</action>
    <transition name="" to="Review Order"></transition>
    </node>
    

13. Send some JBoss Business Process Manager context variables along with the service call using the following code. (In the example below, there is a variable named entireOrderAsXML which is to be set in the default position in the message body.)

    			
    <bpmToEsbVars>
    	<mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" />
    </bpmToEsbVars>
    

    This will cause the XML-based contents of the entireOrderAsXML variable to end up in the body of the message. Now the IntakeService can access the message and process it by letting it flow through each action in the pipeline. When the last action is reached, the replyTo property is checked and the message is sent to the JBpmCallBack service.
    This makes a call back into the JBoss Business Process Manager, signaling the transition from the Intake Order node to the next one (in this case, Review Order).
14. Next, send some variables from the message to the node. Note that entire objects can be sent, as long both contexts can load the object's class. To retain the ability to "map back" to the JBoss Business Process Manager, add an esbToEsbVars element:

    <node name="Intake Order">
    <action name="esbAction" class=
    "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
    <esbCategoryName>BPM_Orchestration4</esbCategoryName>
    <esbServiceName>IntakeService</esbServiceName>
    <bpmToEsbVars>
    <mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" />
    </bpmToEsbVars>
    <esbToBpmVars>
    <mapping esb="body.entireOrderAsXML" bpm="entireOrderAsXML"/>
    <mapping esb="body.orderHeader" bpm="entireOrderAsObject" />
    <mapping esb="body.customer" bpm="entireCustomerAsObject" />
    <mapping esb="body.order_orderId" bpm="order_orderid" />
    <mapping esb="body.order_totalAmount" bpm="order_totalamount" />
    <mapping esb="body.order_orderPriority" bpm="order_priority" />
    <mapping esb="body.customer_firstName" bpm="customer_firstName" />
    <mapping esb="body.customer_lastName" bpm="customer_lastName" />
    <mapping esb="body.customer_status" bpm="customer_status" />
    </esbToBpmVars>
    </action>
    <transition name="" to="Review Order"></transition>
    </node>
    

    When this service returns, the following variables are then stored in the JBoss Business Process Manager's context:
    • entireOrderAsXML
    • entireOrderAsObject
    • entireCustomerAsObject
    In addition, for demonstration purposes, there are also some flattened variables:
    • order_orderid
    • order_totalAmount
    • order_priority
    • customer_firstName
    • customer_lastName
    • customer_status
15. You must now review the order process manually. Add a task node with the task called Order Review. These jobs need to be performed by someone with the actor_iduser.
    Make sure the XML fragment looks like this:

    <task-node name="Review Order">
    <task name="Order Review">
    <assignment actor-id="user"></assignment>
    <controller>
    <variable name="customer_firstName"
    access="read,write,required"></variable>
    <variable name="customer_lastName" access="read,write,required">
    <variable name="customer_status" access="read"></variable>
    <variable name="order_totalamount" access="read"></variable>
    <variable name="order_priority" access="read"></variable>
    <variable name="order_orderid" access="read"></variable>
    <variable name="order_discount" access="read"></variable>
    <variable name="entireOrderAsXML" access="read"></variable>
    </controller>
    </task>
    <transition name="" to="Calculate Discount"></transition>
    </task-node>
    

16. Create an XHTML data form to display these variables in a form in the jbpm-console.

    Note

    See the bpm_orchestration4 quick start's Review_Order.xhtml file for more information about this.
17. Link this data form to the task node by adding these settings to the forms.xml file:

    <forms>
    <form task="Order Review" form="Review_Order.xhtml"/>
    <form task="Discount Review" form="Review_Order.xhtml"/>
    </forms>
    

18. In this case, the same form is applied to two task nodes. There is a reference to the variables in the Review Order form as shown in the following sample code. (This, in turn, refers to the variables that are set in the JBoss Business Process Manager's context.)

    <jbpm:datacell>
    <f:facet name="header">
    <h:outputText value="customer_firstName"/>
    </f:facet>
    <h:inputText value="#{var['customer_firstName']}" />
    </jbpm:datacell>
    

19. When the process reaches the Review Node, you can log into the jBPM Console and click on Tasks to see a list of items.
20. Click on a task to examine it in detail. A form will appear. You can then update some of the values.
21. Conclude by clicking Save and Close, at which point the process will move to the next node.
22. This one is the Calculate Discount node. It is, once again, an ESB service node, the configuration file for which looks like this:

    <node name="Calculate Discount">
    <action name="esbAction" class="
    org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
    <esbCategoryName>BPM_Orchestration4</esbCategoryName>
    <esbServiceName>DiscountService</esbServiceName>
    <bpmToEsbVars>
    <mapping bpm="entireCustomerAsObject" esb="customer" />
    <mapping bpm="entireOrderAsObject" esb="orderHeader" />
    <mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" />
    </bpmToEsbVars>
    <esbToBpmVars>
    <mapping esb="order"
    bpm="entireOrderAsObject" />
    <mapping esb="body.order_orderDiscount" bpm="order_discount" />
    </esbToBpmVars>
    </action>
    <transition name="" to="Review Discount"></transition>
    </node>
    

    The service receives the customer, orderHeader and the entireOrderAsXML data. It then computes a discount. The response maps the body.order_orderDiscount value onto a JBoss Business Process Manager context variable called order_-discount. The process is signaled, which tells it to move to the Review Discount node.
23. Review the discount, which is set to a value of 8.5. Click on Save and Close. The process will move to the Ship It node, which is also an ESB service.
    To circumvent the order process before the Ship It service completes, use the EsbNotifier action handler by attaching it to the outgoing transition as shown below:

    <node name="ShipIt">
    <transition name="ProcessingComplete" to="end">
    <action name="ShipItAction" class=
    "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier">
    <esbCategoryName>BPM_Orchestration4</esbCategoryName>
    <esbServiceName>ShippingService</esbServiceName>
    <bpmToEsbVars>
    <mapping bpm="entireCustomerAsObject" esb="customer" />
    <mapping bpm="entireOrderAsObject" esb="orderHeader" />
    <mapping bpm="entireOrderAsXML" esb="entireOrderAsXML" />
    </bpmToEsbVars>
    </action>
    </transition>
    </node>
    

    After notifying the ShippingService, the order process moves to the end state and terminates. (The ShippingService itself may still be finishing.)
    In the bpm_orchestration4 quick start, the JBoss Rules engine is used to determine whether this order is to be shipped via the normal or the express method.

1. Create a new process instance once the process definition is deployed. (Note that you can use the StartProcessInstanceCommand. This command allows you to create a process instance with some pre-set initial values.)

   <service category="BPM_orchestration4_Starter_Service"
   name="Starter_Service"
   description="BPM Orchestration Sample 4: Use this service to start a
   process instance">
   	<listeners>
   	</listeners>
   		<actions>
   			<action name="setup_key" class=
   				"org.jboss.soa.esb.actions.scripting.GroovyActionProcessor">
   					<property name="script"
   						value="/scripts/setup_key.groovy" />
   		</action>
   		<action name="start_a_new_order_process" class=
   			"org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
   				<property name="command"
   					value="StartProcessInstanceCommand" />
   				<property name="process-definition-name"
   					value="bpm4_ESBOrderProcess" />
   				<property name="key" value="body.businessKey" />
   				<property name="esbToBpmVars">
   					<mapping esb="BODY_CONTENT" bpm="entireOrderAsXML" />
   			</property>
   		</action>
   	</actions>
   </service>
   

2. The new process instance is now invoked and using a script. The jBPM key is set to the value of the OrderId by an incoming order XML file.
   This same XML is subsequently put into a jBPM context, through use of the esbToBpmVars mapping.
   In the bpm_orchestration4 quick start, the XML came from the Seam DVD Store and the SampleOrder.xml looks like this:

   <Order orderId="2" orderDate="Wed Nov 15 13:45:28 EST 2006" statusCode="0"
   	netAmount="59.97" totalAmount="64.92" tax="4.95">
   		<Customer userName="user1" firstName="Rex" lastName="Myers" state="SD"/>
   			<OrderLines>
   				<OrderLine position="1" quantity="1">
   					<Product productId="364" title="Gandhi"
   						price="29.98"/>
   				</OrderLine>
   				<OrderLine position="2" quantity="1">
   						<Product productId="299" title="Lost Horizon" price="29.99"/>
   				</OrderLine>
   			</OrderLines>
   </Order>
   

   Note

   Enterprise Service Bus and JBoss Business Process Manager deployments are what is known as "hot."

   The jBPM has a special feature that results in process deployments being "versioned". Newly created process instances will use the latest version, while existing ones will run to their conclusion using the process deployment they were started on.

Procedure 10.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 10.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 11.1. Task

1. Open jboss-esb.xml and set the cbrAlias property to XPath.
2. Define the routing rules in the route-to configurations (found in the container destinations property) as shown:

   <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
   	<property name="cbrAlias" value="XPath"/>
   	<property name="destinations">
   		<route-to service-category="BlueTeam"  service-name="GoBlue"  expression="/Order[@statusCode='0']" />
   		<route-to service-category="RedTeam"   service-name="GoRed"   expression="/Order[@statusCode='1']" />
   		<route-to service-category="GreenTeam" service-name="GoGreen" expression="/Order[@statusCode='2']" />
   	</property>
   </action>
   

Procedure 11.2. Task

1. Open the jboss-esb.xml file and set the cbrAlias property to XPath.
2. Define the routing expressions in a .properties file. Make sure the property keys correlate with the destination names and that the property values are the XPath expressions for routing to this destination.
3. Define the routing rules in the route-to configurations via the container destinations property. The destination-name attribute will refer to the XPath rule key as defined in the external .properties file as shown:

   <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
      <property name="cbrAlias" value="XPath"/>
      <property name="ruleSet" value="/rules/xpath-rules.properties"/>
      <property name="ruleReload" value="true"/>
      <property name="destinations">
          <route-to destination-name="blue"  service-category="BlueTeam"  service-name="GoBlue" />
          <route-to destination-name="red"   service-category="RedTeam"   service-name="GoRed" />
          <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" />
      </property>
   </action>
   

• Define XML namespace prefix-to-URI mappings as shown below. (This applies to both external and in-line rule definitions.)

  <action class="org.jboss.soa.esb.actions.ContentBasedRouter" 
  name="ContentBasedRouter">
      <property name="cbrAlias" value="XPath"/>
      <property name="namespaces">
          <route-to prefix="ord" uri="http://www.acne.com/order" />
      </property>
      <property name="destinations">
          <route-to service-category="BlueTeam"  
          service-name="GoBlue"  expression="/ord:Order[@statusCode='0']" />
          <route-to service-category="RedTeam"   
          service-name="GoRed"   expression="/ord:Order[@statusCode='1']" />
          <route-to service-category="GreenTeam" 
          service-name="GoGreen" expression="/ord:Order[@statusCode='2']" />
      </property>
  </action>
  

1. Open the file jboss-esb.xml and set the cbrAlias property to Regex.
2. Define the routing rules in the route-to configurations. (These are found in the container destinations property.)

   <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
      <property name="cbrAlias" value="Regex"/>
      <property name="destinations">
          <route-to service-category="BlueTeam"  service-name="GoBlue"  expression="#*111#*" />
          <route-to service-category="RedTeam"   service-name="GoRed"   expression="#*222#*" />
          <route-to service-category="GreenTeam" service-name="GoGreen" expression="#*333#*" />
      </property>
   </action>
   

1. Open the file jboss-esb.xml and set the cbrAlias property to Regex.
2. Define the routing expressions in a .properties file. The property keys should be the destination names and the property values are the Regex expressions for routing to the destination.
3. Define the routing rules in the route-to configurations (found in the container destination property) with the destination-name attribute set to the Regex rule key as defined in the .properties file.

   <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
      <property name="cbrAlias" value="XPath"/>
      <property name="ruleSet" value="/rules/regex-rules.properties"/>
      <property name="ruleReload" value="true"/>
      <property name="destinations">
          <route-to destination-name="blue"  service-category="BlueTeam"  service-name="GoBlue" />
          <route-to destination-name="red"   service-category="RedTeam"   service-name="GoRed" />
          <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" />
      </property>
   </action>
   

   The XPath rules are in a .properties file and are represented in this format:

   blue=#*111#*
   red=#*222#*
   green=#*333#*
   

1. First, define the expressions in the XPathLanguage.dsl file and use the following code to reference it in the rule set:

   expander XPathLanguage.dsl
   

2. The XPath Language makes sure the message is in JBOSS_XML and that the following items have been defined:
   1. xpathMatch<element> : this yields true if an element by this name is matched.
   2. xpathEquals<element> , <value> : this yields true if the element is found and its value equals the value.
   3. xpathGreaterThan<element> , <value> : this yields true if the element is found and its value is greater than the value.
   4. xpathLessThan<element> , <value> : this yields true if the element is found and its value is lower then the value.

   Note

   The fun_cbr quick-start demonstrates this use of XPath.

   Note

   It is possible to define a completely different domain-specific language.

• XPath statements are connected through configuration settings stored in the jboss-esb.xml file. The service configuration below shows an example service configuration fragment. (In this example, the service is listening to a Java Message Service queue.)

  <service> 
          	category="MessageRouting" 
          	name="YourServiceName" 
          	description="CBR Service">
          	<listeners>        
                    <jms-listener name="CBR-Listener"                  
                              busidref="QueueA" maxThreads="1">             
  	           </jms-listener>
                 </listeners>
  		<actions> 
  		     <action class="org.jboss.soa.esb.actions.ContentBasedRouter" 
  		     				     name="YourActionName">
                      	<property name="ruleSet" value="JBossESBRules.drl"/>
                      	<property name="ruleReload" value="true"/>
                      	<property name="destinations">
                             <route-to destination-name="xml-destination" 
  				    service-category="category01" 
  			           service-name="jbossesbtest1" /> 
                             <route-to destination-name="serialized-destination"
                              				           service-category="category02" 
  				    service-name="jbossesbtest2" /> 
                      	</property> 
                      	<property name="object-paths">
  				<object-path esb="body.test1" /> 
  				<object-path esb="body.test2" /> 
  		     	</property>
                      </action>
  		</actions>
              </service>
  

  Each message is passed to the ContentBasedRouter action class, which is loaded with a certain rule-set. It then sends the message to the JBoss Rules engine's working memory, runs the rules, obtains the list of destinations and sends copies of the message to the services.
  In this case, it uses the JBossESBRules.drl rule-set which matches two destinations- xml-destination and serialized-destination . These names are mapped to those of real services in the route-to section.

• Use the SmooksAction component to "plug" Smooks into an ESB action pipeline.

  Note

  You will find a number of quick-starts that demonstrate transformations in the samples/quick starts directory. (The name of each transformation of these quick starts is prefixed with the word transform_.)

Procedure 13.1. Task

1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml.
2. Scroll down to the section and edit it to suit your configuration:

   <properties name="dbstore">
     <!--  connection manager type -->
     <property name="org.jboss.soa.esb.persistence.db.conn.manager" value=
   "org.jboss.internal.soa.esb.persistence.manager.StandaloneConnectionManager"/>
       <!-- this property is only used for the j2ee connection manager -->
       <property name="org.jboss.soa.esb.persistence.db.datasource.name" 	
         value="java:/JBossesbDS"/>
       <!-- standalone connection pooling settings -->
       <!--  mysql
       <property name="org.jboss.soa.esb.persistence.db.connection.url" 	
         value="jdbc:mysql://localhost/jbossesb"/>
       <property name="org.jboss.soa.esb.persistence.db.jdbc.driver" 		
         value="com.mysql.jdbc.Driver"/>
       <property name="org.jboss.soa.esb.persistence.db.user" 				
         value="kstam"/> -->
       <!--  postgres 
       <property name="org.jboss.soa.esb.persistence.db.connection.url" 	
         value="jdbc:postgresql://localhost/jbossesb"/>
       <property name="org.jboss.soa.esb.persistence.db.jdbc.driver" 		
         value="org.postgresql.Driver"/>
       <property name="org.jboss.soa.esb.persistence.db.user" 				
         value="postgres"/>
       <property name="org.jboss.soa.esb.persistence.db.pwd" 				
         value="postgres"/> -->
       <!-- hsqldb -->
       <property name="org.jboss.soa.esb.persistence.db.connection.url" 	
         value="jdbc:hsqldb:hsql://localhost:9001/jbossesb"/>
       <property name="org.jboss.soa.esb.persistence.db.jdbc.driver" 		
         value="org.hsqldb.jdbcDriver"/>
       <property name="org.jboss.soa.esb.persistence.db.user" value="sa"/>
       <property name="org.jboss.soa.esb.persistence.db.pwd" value=""/>	
       <property name="org.jboss.soa.esb.persistence.db.pool.initial.size"	
         value="2"/>
       <property name="org.jboss.soa.esb.persistence.db.pool.min.size"		
         value="2"/>
       <property name="org.jboss.soa.esb.persistence.db.pool.max.size"		
         value="5"/>
       <!--table managed by pool to test for valid connections
           created by pool automatically -->
       <property name="org.jboss.soa.esb.persistence.db.pool.test.table"	
         value="pooltest"/>		
       <property name="org.jboss.soa.esb.persistence.db.pool.timeout.millis"
         value="5000"/> 
   </properties>
   

   Note

   You will find the scripts for the "required database" schema in the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.esb/message-store-sql/DB_TYPE/create_database.sql file.
3. Sill in the global configuration file, configure the database connection manager:

   <!--  connection manager type -->
   <property name="org.jboss.soa.esb.persistence.db.conn.manager" 
     value="org.jboss.internal.soa.esb.persistence.format.db.Standalone
   ConnectionManager"/>
   <!--  property name="org.jboss.soa.esb.persistence.db.conn.manager" 
   value="org.jboss.soa.esb.persistence.manager.J2eeConnectionManager"/ -->
   <!-- this property is only used for the j2ee connection manager -->
   <property name="org.jboss.soa.esb.persistence.db.datasource.name" 
     value="java:/JBossesbDS"/>
   

   Note

   The Stand-Alone Manager uses C3PO to manage the connection pooling logic whilst the J2eeConnectionManager, by contrast, employs a data-source. Use the latter when deploying Enterprise Service Bus end-points inside a container such as a JBoss Application Server.
4. Save the file and exit.
5. Alternatively, you could plug in a custom connection manager by implementing the org.jboss.internal.soa.esb.persistence.manager.ConnectionManager interface and then updating the Properties file by providing it with the name of the new class.

Procedure 15.1. Task

1. To redeploy a .DRL or .DSL file, redeploy the jbrules.esb directory by copying it back into SOA_ROOT/jboss-as/server/PROFILE/deploy.
2. Alternatively, you can activate the Action Configuration's ruleReload feature. After activating this functionality, if a rule file changes, it is re-loaded automatically.

Procedure 15.2. Task

1. Redeploy the .ESB archive in which it resides by copying it back into the SOA_ROOT/jboss-as/server/PROFILE/deploy directory.
2. Alternatively, launch a web browser and log into the Monitoring and Management Console at http://localhost:8080/admin-console.
3. Send out a notification message over the Java Message Service. Smooks will process this event causing it to reload automatically.

Procedure 15.3. Task

• Use the jBPM Eclipse plug-in to deploy a new version of a business process definition to the jBPM database.

  Note

  Please be aware that only a fresh process instance will use this new version. Existing process life-cycles will still use the previous definition.

  Note

  Note that this procedure works in standalone mode, too.

Procedure 15.4. Task

• Run ruleReload.

1. To continue the existing stateful session, set these two message properties:

   message.getProperties().setProperty(“dispose”, false);
   message.getProperties().setProperty(“continue”, true);
   

2. When you run the rules for the last time, set dispose to true to clear the JBoss Rules' engine's working memory:

   message.getProperties().setProperty(“dispose”, true);
   message.getProperties().setProperty(“continue”, true);
   

   Note

   To learn more about using stateful rules sessions, please refer to the business_ruleservice_stateful quick-start.

• There are three requirements when creating rule sets on the JBoss Enterprise SOA Platform.
  The name and action class as shown:

  <action class="org.jboss.soa.esb.actions.BusinessRulesProcessor"
    name="OrderDiscountRuleService">
  

  One of the following is also required:
  • a DRL file:

    <property name="ruleSet" value="drl/OrderDiscount.drl" />
    

  • a DSL or DSLR ( Domain Specific Language ) file:

    <property name="ruleSet" value="dsl/approval.dslr" />
    <property name="ruleLanguage" value="dsl/acme.dsl" />
    

  • a decisionTable on the class-path:

    <property name="decisionTable" value="PolicyPricing.xls" />
    

  • a properties file on the class-path. This tells the rule agent how to find the rules package. You enable it by specifying either an URL or the path to a local file:

    <property name="ruleAgentProperties"
               value="brmsdeployedrules.properties" />
    

1. Ensure the rule-set imports the ESB message. To test, use this code:

   import org.jboss.soa.esb.message.Message
   

2. Next, ensure the rule set defines the following global variable which creates the list of destinations:

   global java.util.List destinations;
   

   The message is now sent to the JBoss Rules engine's working memory.
   Now you can turn a regular rule set into one that can be used for content-based routing. Do this by evaluating the ESB message's matching rule and ensuring it outputs a list of service destination names.

1. Set the object-paths property to extract those objects with an ESB Message Object Path.

   Note

   You can use the object-paths property to drill down further into object trees. Do so by setting this property to extract those objects with an ESB Message Object Path.
2. The JBoss Rules engine uses the MVFLEX Expression Language (MVEL) to extract the object. Your path must abide by this syntax:

   location.objectname.[beanname].[beanname]...
   

   Important

   Remember to add the java import statements to any objects that you import into your rule set.

   Note

   The Object Mapper cannot "flatten out" entire collections. If you need to do that, run a "transformation" process on the message first, as this "unrolls" the collection.

1. To send an object to a JBoss Rules engine channel, use this DRL syntax. (It goes on the right-hand side of the rule definition.)

   channels["mychannel"].send(myobject);
   

2. For the above code to work, register mychannel as your channel. To do this you add a channels property section to the jboss-esb.xml configuration file.
   Define as many channels as you want. For each particular channel name, the channels will be executed in the same order as they appear in the configuration file.
3. The following channels are supported:
   • The ServiceChannel (default). Specify the channel-name, service-category and service-name as attributes of the send-to element.
     There are also optional attributes, including async, timeout and set-payload-location (where the object sent to that channel will be placed in a new ESB message).
     This code shows you how to set an attribute:

     <property name="channels">
         <send-to channel-name="mychannel"
             service-category="cat1" service-name="svc1" />
     </property>
     

     Important

     Make sure you have invmScope="GLOBAL" defined on the target service.
   • Specify the custom channels by using your own org.drools.runtime.Channel implementation class. The send-to attribute for this is channel-class. Your implementation requires a public no-arg constructor.
     If you want your implementation to be configurable, implement the org.jboss.soa.esb.Configurable interface so your setConfiguration(ConfigTree() method will be called. This allows it to pass the attributes and sub- property elements to your custom channel.
     This code sample shows how to configure a custom channel:

     <property name="channels">
         <send-to channel-name="mychannel"
             channel-class="com.example.MyChannel" />
     </property>
     

1. Package your rule code into functional units by putting them in .esb packages. (The aim is to package routing rules alongside the rule services that use the rule sets .)
2. Once you have created the jbrules.esb archive deploy and reference it via the deployment.xml file. Use this code to do so:

   <jbossesb-deployment>
    <depends>jboss.esb:deployment=jbrules.esb</depends>
   </jbossesb-deployment>
   

Procedure 18.1. 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 18.2. 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 18.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. 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 18.4. Task

• Execute this code:

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

Procedure 18.5. 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 18.6. 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 18.7. 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 18.8. 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 18.9. 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 18.10. 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 19.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 19.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 19.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 19.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.