In previous chapters we introduced you to the important aspects of JBoss ESB Services, such as:
- The structure of ESB messages
- How the configuration mechanism works
- An explanation of the service pipeline
- Service composition
- Writing actions
In this chapter we will introduce the final part of the service puzzle, how services connect into the ESB and consume messages. We will cover the following topics:
- InVM transport and its interactions with transactional contexts
- The difference between pass-by-value and pass-by-reference semantics and its pitfalls
- Lock-step delivery with InVM transports
- JMS transports
- SQL transports
- Remote file system transports
- Local file system transport
So let's get on with it...
At the core of JBoss ESB is the concept of a bus, an abstract representation of the transports through which request messages will be delivered to the target services and their response messages, if appropriate, returned to the service invoker. Each service 'plugs into the bus' by defining the configuration for its associated transports within the jboss-esb.xml file, the details of which will then be used to create and register Endpoint References (EPRs) within the Service Registry.
The ServiceInvoker, used by clients to invoke ESB services, will query the service registry to locate the EPRs associated with the service, choose one based on the current policy in force, and send the message through the transport associated with the chosen EPR.
Note
The Endpoint References are opaque structures which contain the information necessary for the transport to identify a service endpoint and, potentially, a specific conversation handled by that endpoint. No assumptions should be made about these contents as they relate to the specific transport and may change with different releases of JBoss ESB.
A graphical representation of the bus is as follows:
In the diagram we can see three services deployed into the bus, each of which is registering two distinct endpoints. Each service endpoint represents a specific transport configuration through which the services can be contacted.
The diagram also highlights three service invocations from two distinct clients. Each client is isolated from the specifics of the transport configuration, through the registry and endpoint references, allowing the invocations to be made using various transports and targeted at multiple service destinations.
In keeping the client isolated from the details of the service and its invocation, the ESB is encouraging a loosely coupled architecture through which the service and client can evolve without having a direct impact on the other end of the invocation. Clients and services may be located on disparate systems with these invocations occurring over multiple transport types in a synchronous or asynchronous manner.
With all this in mind, let's now take a look at how this appears in practice. We will walk you through the configuration of JBoss Developer Studio and follow up with some examples covering the service invocations.