Page History

ServiceMix is an Emterprise Service Bus (ESB) that is based on the Java Business Integration (JBI) standard JSR 208. The JBI-based design specifies a standards-based pluggable architecture with a JVM-based runtime component called the Normalized Message Router (NMR). The Basic example demonstrates how applications communicate via the ServiceMix ESB, and the role that the NMR can play in that communication. Similar techniques could be used to plug any external ¹ application or service into ServiceMix (e.g. SAP, Peoplesoft, spreadsheets, POJOs, Webservices and EJBs) and allow it to communicate with other external applications or components using ServiceMix itself.

A hypothetical business scenario, which extends the Basic Example, is that of a department store distributor. This distributor sells products from multiple wholesalers (suppliers) to various retailers (customers). The distributor presents a common interface for product ordering to each of its department store customers. However, the distributor must work with a different ordering interface for each wholesale suppliers for the products they are buying.

Using an ESB, the distributor has developed a number of components to receive department store orders and then dynamically route and transform these orders to the appropriate wholesaler. The order processing flow is described as follows:

1. Using the distributor's web interface, a department store customer submits an order for multiple products. An HTTP request is sent to the OrderReceiver, an HTTP binding component (BC). ³
2. The OrderReceiver sends the message to an OrderRouter service engine (SE) ⁴ component. This SE is responsible for parsing the order and deciding, based on the message content, which OrderTransformer should receive which part of the message (i.e., an order for a product).
3. The OrderRouter publishes the orders to the appropriate message topics based on the message content. Specifically, the OrderRouter publishes the messages based on which wholesaler sells the item.
4. The OrderTransformer is a service engine component, which modifies the message and puts it in a format which is readable by the wholesaler interface that will fulfill the order.
5. Each OrderTransformer sends the modified message to the OrderProcessor.
6. The OrderProcessor is a binding component that has two functions:
   a. It places an order to the appropriate wholesaler through the wholesaler's Webservice or proprietary interface.
   b. It also publishes a message about the order on a topic.
7. The message on the topic is subsequently picked up by the BusinessMonitor component via the jmsTrace component.
8. The BusinessMonitor component monitors the orders for quality assurance and business analytics, such as data mining.

The following diagram illustrates this:

1. External means the application is outside of the ESB.
2. Resource Adapter: a resource adapter provides connectivity between a specific external application and the ESB. In the Basic example the jencks container provides a JMS resource adapater.
3. Binding Component (BC): a BC provides connectivity to applications that are external to the ESB.
4. Service Engine (SE): a service engine provides business logic and transformation services to other components within the enterprise service bus

The Basic example shows how to integrate an external application with the JBI bus (ServiceMix).
The same scenario applies to integrating legacy applications with the JBI bus as well.
The technique used in the Basic example could be used to integrate
SAP, Peoplesoft or other external applications, such as POJOs and EJBs that need to
communicate with each other or a legacy application, onto an enterprise service bus.

The purpose of this is to provide a way for different applications
to communicate in a common or "protocol neutral" way through the enterprise
service bus. In our example, the external applications are the same (JMS),
so obviously they could communicate directly; this is a simplification to
enable us to concentrate on the logical flow of the messages
rather than the details of transforming one type of message into another.

Recall from the JSR 208 specification the components for one legacy/external application
to talk to one another:

legacy/external app --> resource adapter --> |binding component (inside ESB) --> NMR -->
binding component |--> resource adapter --> legacy app.

(I will make a Dave Chappell like diagram of above for this use case, then map in
the Basic example components where they belong in the diagram.)

Etcetera, etc....

...

1. .