Page History

The purpose of an Enterprise ServiceMix is an Emterprise Service Bus (ESB) , also known as a that is based on the Java Business Integration (JBI) bus, is to provide a mechanism for different applications to communicate in a common or protocol neutral manner. ServiceMix is an implemenation of JSR 208, the JBI specification, and it facilitates the communications between applications.The Basic example shows how two external ¹ applications communicate to each other via the ServiceMix ESB. The techniques used in the Basic example could be used to integrate any external application with ServiceMix and allow it to communicate with another external application or a component within ServiceMix itself. Examples of applications that may need to be accessible to other applications are 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, etc.POJOs, or POJOs Webservices and EJBs that need ) and allow it to communicate with each other or with a legacy application.

In the Basic example, the external applications communicate using the same protocol, JMS. Therefore, they could communicate directly with each other. The Basic example 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.

A common scenario in which an enterprise service bus may be used is for a Web-based form to request data from a legacy application. The Web-based form communicates via HTTP which the legacy application does not understand. Using the ESB, the communication between the applications would flow like this:

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
2. Using a web-based form, a user asks for data from a legacy application.
3. An HTTP request is formulated and sent to the HTTP binding component (BC). ^{2 3}
4. The HTTP binding component transforms the HTTP message into a neutral form. This is called a normalized message.
5. The normalized message is routed through the Normalized Message Router (NMR) to a Service Engine (SE) ³ or BC that knows how to communicate to the legacy application.
6. The SE/BC transforms the message into a form that the legacy application understands.
7. The SE/BC passes the message to the resource adapter ⁴ for the legacy application.
8. The resource adapter communicates with the legacy application and obtains the requested data.
9. 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).
10. 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.
11. 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.
12. Each OrderTransformer sends the modified message to the OrderProcessor.
13. 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.
14. The message on the topic is subsequently picked up by the BusinessMonitor component via the jmsTrace component.
15. The BusinessMonitor component monitors the orders for quality assurance and business analytics, such as data miningThe requested data is transferred back to the web-based form, reversing the route.

The following diagram illustrates this:

In comparison, the Basic example, looks like the following diagram. This is a simplified diagram of the basic example. For a complete diagram, please see: xxxx.

!usecase_forbasic_basicex.ppt|align=center!

Please note: The Basic example uses inbound messages via the resource adapter, and most legacy applications won't support inbound messaging via the resource adapter.

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 adapaterExternal means the application is outside of the enterprise service bus.
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.Resource Adapter: a resource adapter provides connectivity between a specific external application and the ESB.