Tech Ads
Back to Article List
Originally published October 2005 [ Publisher Link ]
JBI and ServiceMix : Remaking the Java ESB
The Java world evolves around formal specifications in the form of JSRs. One of the most recent additions to this group of requests is JBI (Java Business Integration): an ESB (Enterprise Service Bus) which is set to form one of the key infrastructure pieces for enabling service-oriented architecture in the Java world. In the following article we will explore the concepts behind JBI and an open source implementation named ServiceMix.
The main purpose behind JBI is to provide a service-based platform as an extension to the current offerings supported by the Java/J2EE platform. Since Web services are already a reality in J2EE today, and the terms ESB and SOA seem to have more marketing than technical momentum, let's dig a little deeper into what it actually means to have a "service-based platform" in Java/J2EE.
Current J2EE deployments operate with one foundation, an application server, which in itself is composed by two separate pieces -- a Servlet and an EJB container, used for deploying JSP/Servlets and EJB components, respectively. In either one, you can make use of Web services; however, coordinating the use of services in anything but a piecemeal fashion can be a daunting task, and it is JBI which aims to provide a specific environment to undertake these tasks.
JBI at its most basic level is another container and just like its J2EE counterparts defines its own deployable components. Yet before we dive into specifics, let's elaborate more on the primary intention of having JBI.
First off, focus on the core part of a Web service: the SOAP message/envelope which is transferred between endpoints. This data fragment or token can contain information that may be serviced to various applications. Not only that, depending on the originating or receiving party, it might be beneficial to apply certain business logic to the data.
Now take a step back from Web services as you know them today. In many enterprise applications -- prior to the appearance of Web services -- the use of message-oriented middleware systems, or MOMs, was ample when trying to achieve heterogeneous system communication. It's the same intent behind Web services, MOM deficiencies aside. The message-based architecture used by MOMs is similar to that of Web services; data is serviced to operate seamlessly across applications.
Applying the previous scenarios to a typical J2EE environment and servicing them through technologies like JMS or JAX-RPC might be viable for simple deployments, but, as mentioned previously, the existing containers can prove cumbersome to work with when doing overly complex designs based on these approaches. It's this area that JBI tries to address.
JBI provides a Normalized Message Router (NMR), in layman's terms, a place where all message-based data fragments -- SOAP fragments, MOM messages , HTTP data snippets or other information bits -- can be funneled into, interpreted, have business logic applied to them, transformed, flattened into another format if necessary and later dispatched to their final destination(s).
The previous description is indicative of why JBI is called an ESB. It's fitted for Enterprise type applications -- message-based -- which are Serviced through a Bus type architecture in order to accommodate a wide range of consumers and providers. Now let's address what makes up JBI besides its NMR (a.k.a its JBI environment).
Directly interacting with the JBI environment are two more pieces, JBI machines and JBI bindings. JBI machines define the manner in which components are deployed and managed throughout the environment. In essence, they are the black boxes designed by vendors to support their proprietary models in the JBI. JBI bindings, on the other hand, are used by the environment to communicate with the outside via specific business protocols.
Now let's ground these concepts with a real world JBI implementation: ServiceMix. ServiceMix is an open source project built from the ground up on the semantics of JBI, which has support for various bindings -- including HTTP, JMS, flat files and RSS among others -- and a series of service components like BPEL , Schema Validation, JCA and caching.
Also incorporated into Service Mix are a JMX-based management interface as well as support for a native client API used for communicating with JBI components. Although further describing the functionalities of ServiceMix would go beyond the scope of this document -- and something you can easily do downloading the software -- let's illustrate an actual JBI component deployable in ServiceMix to give you a feel for it.
Listing for JBI Components - File Sender & File Receiver.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:my="http://servicemix.org/demo/">
<!-- the JBI container -->
<container id="jbi">
<property name="useMBeanServer" value="true"/>
<property name="createMBeanServer" value="true"/>
<property name="dumpStats" value="true"/>
<property name="statsInterval" value="10"/>
<components>
<!-- Write files to the outbox directory -->
<component id="fileSender"
service="foo:fileSender"
class="org.servicemix.components.file.FileWriter">
<property name="directory" value="outbox"/>
<property name="marshaler">
<bean
class="org.servicemix.components.util.DefaultFileMarshaler">
<property name="fileName">
<bean
class="org.servicemix.expression.JaxenStringXPathExpression">
<constructor-arg value="concat('sample_', /sample/@id, '.xml')"/>
</bean>
</property>
</bean>
</property>
</component>
<!-- Look for files in the inbox directory -->
<component id="filePoller" service="foo:filePoller"
class="org.servicemix.components.file.FilePoller"
destinationService="foo:fileSender">
<property name="workManager" ref="workManager"/>
<property name="file" value="inbox"/>
<property name="period" value="1000"/>
</component>
</components>
</container>
<!-- the work manager (thread pool) for this container -->
<bean id="workManager"
class="org.jencks.factory.WorkManagerFactoryBean">
<property name="threadPoolSize" value="30"/>
</bean>
</beans>
|
The JBI specification itself does not define how a component should be coded. Notice how ServiceMix defines two core components in an XML-style syntax, wired to specific classes and properties. Upon deploying this structure into ServiceMix, the environment will create a polling component in charge of reading an archive from the file system and another component for outputting the read values back to the file system.
This file system transfer is a very basic scenario for JBI, since the information is just funneled through the JBI environment (NMR) without any changes and outputted back to the same type of binding (the file system). But obviously, once in the JBI environment the capabilities are there to apply any business logic to the data, such as BPEL or schema validation, and redirect it to any other type of binding, such as HTTP or RSS, not just the file system.
As you no doubt realize, the possibilities for manipulating and distributing data once it enters the JBI are vast, but even though JBI figures to be at the center of SOA in terms of Java, the specification JSR-208 is not without its critics. IBM and BEA, which are major movers in the Java/J2EE landscape, have opted not to support this new initiative. Although, there are other niche players like ServiceMix and a few closed source developments that are betting a best-of-breed JBI market will emerge in the same fashion J2EE did.
If you are currently using Web services in Java or making use of messaging-based designs for complex integration tasks, you should pay close attention to JBI's evolution since it can provide you with a more robust platform for performing such tasks. Even if you are somewhat skeptical of the value added by a JBI/ESB to the J2EE stack, it should merit your attention since it just might become the de facto "third container" in application servers or a lightweight container extension, as in Spring, for providing SOA in Java developments.