8.6. How Services Work
Introduction
Read this section to learn in more detail how services, end-point references, listeners and actions actually work.
The following code fragment is loosely based on the configuration settings for the JBossESBHelloworld example:
...
<service category="FirstServiceESB" name="SimpleListener" description="Hello World">
<listeners>
<jms-listener name="helloWorld" busidref="quickstartEsbChannel" maxThreads="1"/>
</listeners>
<actions>
<action name="action1" class="org.jboss.soa.esb.actions.SystemPrintln"/>
</actions>
</service>
...
When the service initializes it registers the category, name and description to the UDDI registry. Also, for each listener element, it will register a ServiceBinding to UDDI, in which it stores an end-point reference. (In this case it will register a JMSEPR for this service, as it is a jms-listener.)
The specific details for JMS like the queue name are not shown, but appeared at the top of the jboss-esb.xml file where you can find the 'provider' section.
In the jms-listener you can simply reference the "quickstartEsbChannel" in the busidref attribute.
If it is given the category and service name, another service can look up your service in the registry. It will then receive the JMSEPR which it can use to send a message to your service. (All of this work is done by the ServiceInvoker class.)
When your HelloWorld Service receives a message over the quickstartEsbChannel, it will hand this message to the process method of the first action in the ActionPipeline which, in this case, is the SystemPrintln action.
Note
Because ServiceInvoker hides much of the fail-over complexity from users, by necessity, it can only work with native ESB Messages. Furthermore, not all gateways have been modified to use the ServiceInvoker, so ESB-unaware messages coming to those kinds of gateways may not always be able to take advantage of service fail-over.
