Important note: JBoss ESB is an archived project and its latest release dates back to Mar 2013. The replacement technology for it is JBoss Fuse which is an open source enterprise integration platform and service bus. You can find here a quickstart tutorial about JBoss Fuse.
This tutorial is a rewritten version of JBoss ESB tutorial: a new stable version of JBoss Tools has been released with the ESB plugin so we'll use it to set up a JBoss ESB project.
Introducing JBoss ESB
As you certainly know, the word SOA has become recentely one of the most hyped in the IT. Almost everyone wants to offer a SOA as a solution to all your problems, but is it true ? well for SOA to be embraced and deliver on its promises, businesses must be able to develop and launch their services in ways that match their organizational and financial realities.
If SOA is too expensive, complex or politically challenging, the technology won’t take off. How, then, is it possible to build an SOA that overcomes political and cost constraints? Driving an SOA strategy to success in a large organization requires a corporate-level CIO with the power to drive a vision, enforce a set of architectural goals and blueprints, and mediate financial allocations.
To get a manageable SOA, you’ll need to start with SOA platforms that represent a relatively low investment. That’ll likely mean tools and platforms that are open source, with support and ecosystem benefits available at a low cost.
Introducing JBoss ESBJBoss team have designed their own Service Bus: JBoss Enterprise Service Bus is a robust SOA solution designed since the release 4.2 with build-in fail-over, load balancing and delayed message redelivery. JBossESB allows you to distribute service instances across many nodes. Each node can be a virtual or physical machine running one or more instances of JBossESB.
How the physical implementation of the architecture is achieved -however- is not fundamental: in fact many different implementations and sub-architectures could be used. So what is the fundamental concept or idea in which to work when considering SOA?
JBossESB does not impose restrictions on what constitutes a service: this allows for the implementations to change without requiring clients/users to change. Only changes to the message definitions necessitate updates to the clients.
The fundamental of SOA is a unitary event bus which is triggered by receipt of a Message: a service registers with this bus to be informed when messages arrive. Next up the chain is a handler (dispatcher), that allows for sub-services (sub-components) to register for sub-documents (sub-messages) that may be logically or physically embedded in the initially received message. This is an entirely recursive architecture.
As such, JBossESB uses a message driven pattern for service definitions and structures: clients send Messages to services and the basic service interface is essentially a single doSomething method that operates on the Message received. Internally a service is structured from one or more Actions, that can be chained together to process incoming the incoming Message. What an Action does is implementation dependent, e.g., update a database table entry, or call an EJB.
So when developing your services, you first need to determine the conceptual interface/contract that it exposes to users/consumers. This contract should be defined in terms of Messages, e.g., what the payload looks like, what type of response Message will be generated (if any) etc.
How is made up a Service in JBoss ESB?
A service in JBossESB is defined a list of Action classes that process an ESB Message in a sequential manner. This list of Action classes is referred to as an Action Pipeline. A Service can define a list of Listeners, which act as inbound routers for the Service, routing messages to the Action Pipeline.
Picture 1: Action pipeline
JBossESB supports two forms of listener configuration:
1. Gateway Listeners: These listener configurations configure a Gateway Endpoint.
These Endpoint types can be used to get messages onto an ESB bus. It is responsible for adapting the message payload by wrapping it into an ESB Message before shipping it to the Service's Action Pipeline.
2. ESB Aware Listeners: These listener configurations configure an ESB Aware Endpoint. These Endpoint types are used to exchange ESB Messages between ESB Aware components i.e. exchanging messages on the bus.
- Next >>