Note - where action names are specified without spaces (e.g., SmooksAction), they are the names of out-of-the-box actions provided in the JBoss SOA Platform. Where the names have spaces (e.g., JPA action) they describe an action that could be provided to perform this functionality.

Each service in the Service Model that is being implemented in the JBossESB should be mapped to a JBoss ESB service. This entails the creation of a separate JBoss ESB project. The general notion of a service allows for multiple tasks. This is typically the case with entity services, which would provide CRUD type operations. The contract for the task however, should not be inherent in the inteface, rather it should be contained within the message.

For example, the Service Model might have a service called AccountEntityService with four tasks:

• createAccount
• updateAccount
• getAccount
• deleteAccount

The Service Model also provides request and response XSDs that should use polymorphism to include a separate complex type for each operation, along with an task-name element that specifies the task. These XSDs will be specified in the JBoss ESB configuration if the ESB services should be exposed as a Web service.

ESB Services are mapped to service endpoints. With the JBoss ESB, these endpoints may be JMS queues (or topics), or virtual, InVM endpoints. The use of JMS provides a degree of service decoupling, whereas InVM provides for better throughput.

The following is a general overview of the steps required. The examples assume the use of JMS queues as service endpoints. For further details see the Task associated with each particular type of service, along with the JBoss SOA-P product documentation. For a discussion about security implementation, see Configure ESB Security.

Steps:

• Use the Eclipse File -> New JBoss ESB Project. Name the project the name of the service. E.g. AccountEntityService.
• Use the JBoss ESB Config Editor to edit the jboss-esb.xml file. First add the providers - one for the gateway and one for the actual service. With ESB services deployed as Web services there are no gateway providers required, instead only a single JMS provider is required for the ESB Service endpoint. 

<jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
  <jms-bus busid="accountEntityChannel">
    <jms-message-filter dest-type="QUEUE"
                        dest-name="queue/account_Request_ESB"transacted="true"  />
  </jms-bus>
</jms-provider>
<service category="EntityServices"
         name="AccountEntityService"
         description="Persists Account information">
  <listeners>
    <jms-listener name="account"
                  busidref="accountEntityChannel"
                  maxThreads="1"  />
  </listeners>
  <actions inXsd="/accountRequest.xsd"
           outXsd="/accountResponse.xsd"
           faultXsd="/accountFault.xsd">

... list of action elements
  </actions>
</service>

This configuration will automatically expose the ESB service through an associated WS endpoint. As part of the deployment, a wsdl will be generated that can be consumed by clients. This configuration will also allow validation of request/response bodies in the pipeline.

• There will be no automatic translation of the request/response into objects however, the ESB service will need to add actions to process XML input/output in the default body location of the messages and / or provide transformations as required to support the business logic.
• Add additional actions as required, depending on the type of services and its implementation requirements.