Meet JBI

The EBI 3 team is pretty excited about using ServiceMix as a core piece of our server. This allows EXTOL to provide you with many different configuration options and a stable platform to deploy your projects into. This series of articles will acclimate you to the architecture and describe some of the tools we’ll be using. First, I’d like to you meet JBI.

ServiceMix is an Enterprise Service Bus that has been developed according to the Java Business Integration (JBI) standard. JBI can seem a bit tricky at first but isn’t much more than a high-level specification for controlling data exchanges between dissimilar systems and services.

The JBI specification provides a pluggable component architecture based around message exchanges. Messages between components are orchestrated via the Normalized Message Router (NMR). Also known as — the bus. Because components do not speak to each other directly, we are left with a loosely coupled system and the ability for services to exist on separate machines.

The components that are used inside of a JBI container are either service engines or binding components. Service engines are used to provide a bit of logic that executes within the JBI environment and only speak to the NMR. One example of these that we’ll run into further along on our series is Camel. When a service engine wants to interact outside the JBI container, it uses a binding component. Binding components are responsible for dealing with protocol and transport level formats. They are capable of encoding and decoding messages according to the format the NMR dictates. Some common binding component protocols are HTTP, JMS, FTP, and file.

You may be wondering, “But how do I connect these engines and bindings?” In the JBI container, endpoints can be located in two ways. You are able to specify the exact endpoint you’d like a message sent to or you can let the container determine the message destination for you. There are three details used to identify endpoints – service, interface, and endpoint names. Any combination of these can be used to help steer the message to the correct endpoint.

Now that we know more about messages we can discuss Message Exchange Patterns (MEP). Each message is sent and received according to a pattern; in-only, robust in-only, in-out, in optional-out. The details of each pattern are defined in the JBI specification. There are certain semantics to each pattern regarding status messages and return replies.

Finally we can take a look at how messages flow through the JBI container:

  1. Your service consumer will contact the exposed binding component.
  2. The binding component transforms your message into a normalized message and sends it to the NMR.
  3. The NMR uses routing logic to deliver the normalized message to a service provider (service engine or binding component).
  4. Any responses or status messages are delivered back up the chain.

Since you’ve become acquainted with our good friend JBI, you may be tempted to begin creating your own components. Not so fast! Many of the bindings and service engines are supplied by third party organizations, including EXTOL. You can even write your own if you need to. Be sure to stop back for our next article, Moving Data With Camels.

More info:

Leave a Reply

Your email address will not be published. Required fields are marked *