Integration is a necessary evil using which we can interconnect systems, applications and services to facilitate seamless information flow within and across Organization boundaries. We have been using technologies like JSP, EJB, JMS, etc. in the Java world for building Enterprise Applications (EA). But if we have to interconnect such applications, we will need Enterprise Application Integration (EAI). Many a times we also use EA technologies and tools to do EAI. This will give a short term solution to our integration problems, which may not scale up when we want to perform integration at Enterprise (Customers, Vendors, Partners, ...) level. Java Business Integration (JBI) is the new specification trying to fill this gap of EAI in the Java world. So next time when you want to integrate, don't write a single line of Java code, instead plug and assemble JBI based integration libraries to control your message flow! Does it looks promising? Believe it or read the article below to get yourself convinced.

In this article by Binildas Christudas, we will look into Integration in general and to JBI and ESB in particular. We will then explain few functionalities usually done by integration components like protocol conversions, content transformations, etc., with some code snippets too.

EAI - The Broader Perspective

No one should have (or will) ever dared to build a 'Single System' which will take care of the entire business requirements of an enterprise. Instead, we build few (or many) systems,and each of them takes care of a set of functionalities in a single Line of Business (LOB). There is absolutely nothing wrong here, but the need of the hour is that these systems have to exchange information and interoperate in many new ways which have not been foreseen earlier. Business grows, enterprise boundaries expands and mergers and acquisition are all norms of the day. If IT cannot scale up with these volatile environments, the failure is not far.

Let me take a single, but not simple problem that today's Businesses and IT face - Duplicate Data. By Duplicate Data we mean data related to a single entity stored in multiple systems and storage mechanisms, that too in multiple formats and multiple content. I will take the 'Customer' entity as an example so that I can borrow the 'Single Customer View' (SCV) jargon to explain the problem. We gather customer information while he makes a web order entry or when he raises a complaint against the product or service purchased or when we raise a marketing campaign for a new product to be introduced or ... The list continues, and in each of these scenarios we make use of different systems to collect and store the same customer information. 'Same Customer' - is it same? Who can answer this question? Is there a Data Steward who can provide you with the SCV from amongst the many information silos existing in your Organization? To rephrase the question, does your organization at least have a 'Single View of Truth', if it doesn't have a 'Single Source of Truth'? Information locked away inside disparate, monolithic application silos has proven a stubborn obstacle in answering the queries business requires, impeding the opportunities of selling, not to mention cross-selling and up-selling. Yeah, it's time to cleanse and distill each customer's data into a single best-record view that can be used to improve source system data quality. For that, first we need to integrate the many source systems available. Today, companies are even acquiring just to get access to it's invaluable Customer information! This is just one of the highlights of the importance of integration to control Information Entropy in the otherwise complicated IT landscape.

Figure 1. The 'Single Customer View' Dilemma

So Integration is not an end, but a means to end a full list of problems faced by enterprises today. We have been doing integration for many years. There exist many platforms, technologies and frameworks doing the same thing. Built around that, we have multiple Integration Architectures too, amongst which, the Point to Pont, Hub and Spoke, and the Message Bus are common. Figure 2 represents these integration topologies.

Figure 2. EAI Topologies

Let us now look at the salient features of these topologies to see if we are self-sufficient or need something more.

Point to Point

In Point to Point, we define integration solutions for a pair of applications. Thus, we have two end points to be integrated. We can build protocol and/or format adaptors/transformers at one or either end. This is the easiest way to integrate, as long as the volume of integration is low. We normally use technology specific APIs like FTP, IIOP, Remoting or batch interfaces to realize integration. The advantage is that between these two points, we have tight coupling, since both ends have knowledge about their peers. The downside is that if there are 6 nodes (systems) to be interconnected, we need at least 30 separate channels for both forward and reverse transport. So think of a mid-sized Enterprise with some 1000 systems to integrate!

Hub & Spoke

Hub And Spoke Architecture is also called as the Message Broker. It provides a centralized hub (Broker) to which all applications are connected. Each application connects with the central hub through lightweight connectors. The lightweight connectors facilitate application integration with minimum or no changes to the existing applications. Message Transformation and Routing takes place within the Hub. The major drawback of the Hub and Spoke Architecture is that if the Hub fails, the entire Integration topology fails.

Enterprise Message Bus

An Enterprise Message Bus provides a common communication infrastructure which acts as a platform-neutral and language-neutral adaptor between applications. This communication infrastructure may include a Message Router and/or Publish-Subscribe channels. So applications interact each other through the message bus with the help of Request-Response queues. Sometimes the applications have to use adapters that handle scenarios like invoking CICS transactions. Such adapters may provide connectivity between the applications and the message bus using proprietary bus APIs and application APIs.

Service Oriented Integration (SOI)

Service Oriented Architecture (SOA) provides us with a set of principles, patterns and practices, to provide and consume services which are orchestrated using open standards so as to remove single vendor lock-into provide an agile infrastructure where services range from business definition to technical implementation. In SOA, we no longer deal with single format and single protocol, instead we accept the fact that heterogeneity exists between applications. And our architecture still needs to ensure interoperability and thus information exchange.

Enterprise Service Bus (ESB)

Roy Schutle from Gartner defines an ESB as:
"A Web-services-capable middleware infrastructure that supports intelligent program-to-program communication and mediates the relationships among loosely-coupled and uncoupled business components."

In the ESB Architecture (Refer Figure 2), applications communicate through an SOA middleware backbone. The most distinguishing feature of the ESB Architecture is the distributed nature of the integration topology. This makes the ESB capabilities to spread out across the bus in a distributed fashion, thus avoiding any single point of failure. Scalability is achieved by distributing the capabilities into separately deployable service containers. Smart, intelligent connectors connect the applications to the Bus. Technical services like transformation, routing, security, etc. are provided internally by these connectors. The Bus federates services which are hosted locally or remotely, thus collaborating distributed capabilities. Many ESB solutions are based on Web Services Description Language (WSDL) technologies, and they use Extensible Markup Language (XML) formats for message translation and transformation. The best way to think about an ESB is to imagine the many features which we can provide to the message exchange at a mediation layer (the ESB layer), a few among them is listed below:

• Addressing & Routing 
• Synchronous and Asynchronous style invocations 
• Multiple Transport and protocol bindings 
• Content transformation and translation 
• Business Process Orchestration (BPM) 
• Event processing 
• Adapters to multiple platforms 
• etc...

Service Aggregation in ESB

ESB provides you the best ways of integrating services so that services are not only interoperable but also reusable in the form of aggregating in multiple ways and scenarios. This means, services can be mixed and matched to adapt to multiple protocols and consumer requirements. Let me explain you this concept, as we will explore more into this with the help of sample code too.

In code and component reuse, we try to reduce ‘copy and paste’ reuse and encourage inheritance, composition and instance pooling. Similar analogy exists in SOI where services are hosted and pooled for multiple clients through multiple transport channels, and ESB can do this in the best way integration world has ever seen. We call this as the notion of shared services. For example, if a financial organization provides a ‘credit history check service’, an ESB can facilitate reuse of this service by multiple business processes (like a Personal Loan approval process or a Home Mortgage approval process). So, once we create our 'core services', we can then arbitrarily compose these services in a declarative fashion so as to define and publish more and more composite services. Business Process Management (BPM) tools can be integrated over ESB to leverage service aggregation and service collaboration. This facilitates reuse of basic or core (or fine grained) services at Business Process level. So, granularity of services is important which will also decide the level of reusability. Coarse grained or composite services consume fine grained services. Applications that consume  coarse-grained services are not exposed to the fine-grained services they use. Composite services can be assembled from coarse-grained as well as fine-grained services. To make the concept clear, let us take the example of provisioning a new VOIP (Voice Over IP) Service for a new Customer. This is a composite service which in turn calls multiple coarse grained services like 'validateOrder', 'createOrVerifyCustomer', 'checkProductAvailability', etc. Now, the createOrVerifyCustomer coarse grained service in turn call multiple fine grained services like 'validateCustomer', 'createCustomer', 'createBillingAddress', 'createMailingAddress', etc.

Figure 3. Service Composition

Java Business Integration (JBI)

Java Business Integration (JBI) provides a collaboration framework which provides standard interfaces for integration components and protocols to plug into, thus allowing the assembly of Service Oriented Integration (SOI) frameworks. JSR 208 is an extension of Java 2 Enterprise Edition (J2EE), but it is specific for Java Business Integration Service Provider Interfaces (SPI). SOA and SOI are the targets of JBI and hence it is built around Web Services Description Language (WSDL). The nerve of the JBI architecture is the NMR (Normalized Message Router). This is a bus through which messages flow in either directions from a source to a destination. You can listen to Ron Ten-Hove, the Co-spec lead for JSR 208 here and he writes more about JBI components in the PDF download titled JBI Components: Part 1. JBI provides the best available, open foundation for structuring applications by composition of services rather than modularized, structured code that we have been doing in traditional programming paradigms. A JBI compliant ESB implementation must support four different service invocations, leading to four corresponding Message Exchange Patterns (MEP):

 
• One-Way (In-Only MEP): Service Consumer issues a request to Service Provider. No error (fault) path is provided. 
• Reliable One-Way (Robust In-Only MEP): Service Consumer issues a request to Service Provider. Provider may respond with a fault if it fails to process the request. 
• Request-Response (In-Out MEP): Service Consumer issues a request to Service Provider, with expectation of response. Provider may respond with a fault if it fails to process request. 
• Request Optional-Response (In Optional-Out MEP): Service Consumer issues a request to Service Provider, which may result in a response. Both Consumer and provider have the option of generating a fault in response to a message received during the interaction.

Service Oriented Java Business Integration

A Service Aggregation Sample

We talked about service aggregation which is one of the many functionalities we can implement at the ESB layer. In this section we will assemble an integration solution making use of JBI components to demonstrate Service Aggregation.

Sample Use Case

Let us assume that Acme Financials company is gradually implementing SOA and as a part of that you need to consolidate the available services and also need to implement few new composite services and business processes, either from already available services or by building new services. Two such services which are already available in Acme's Service Domain are, a 'Credit Service' and a 'Debit Service'. The Credit Service can credit an account if you provide the account ID and the amount to credit. Similarly the Debit Service can debit an account if you provide the account ID and the amount to debit. The new requirement is to create a 'Transfer Fund' service. Acme's Architects and engineers decided that they will not build Transfer Fund service from scratch, instead aggregate the Credit Service and the Debit Service services already available, which are time tested and found reliable.

Till yesterday, Acme's Credit Service and Debit Service were used by inter-LOB systems of Acme alone. Acme has been using Java Message Service (JMS) based Message Oriented Middleware (MOM) for all inter-departmental information exchange. But since Acme's business is expanding, it has decided to open the Transfer Fund service to its customers through the world wide web too. This means, the Transfer Fund service should now be accessible through both the JMS channel and the HTTP channel.

We will limit our requirements to the above since we want to keep the discussion simple.

Solution Architecture

Figure 4. Solution Architecture

Figure 4 shows the solution architecture for the problem statement described in the sample use case section. To realize this Architecture, we have to use any JBI compliant container. ServiceMix is an open-source ESB, which is now an official Apache project. ServiceMix is built from the ground up on the  Java Business Integration (JBI) specification and we will use that as our JBI container to demonstrate the sample. Let us look into various components required for the solution. 

• DebitServicePojo: DebitServicePojo is a POJO (Plain Old Java Object), which implements the debit functionality. 
• CreditServicePojo: CreditServicePojo is a POJO implementing the credit functionality. 
• debitService: debitService is a ServiceMix jsr181 component exposing DebitServicePojo as a services on the JBI Bus. This makes sure we have a JBI endpoint capable of exposing a WSDL for the underlying service. 
• creditService: ServiceMix jsr181 component exposing CreditServicePojo as a services on the JBI Bus. 
• Transaction Request: This is a SOAP (Simple Object Access Protocol) compliant Money-Transfer request. The request contains information so as to transfer some specified fund from one account to another. 
• recipients: recipients is a ServiceMix Static Recipient List which can forward an input message (Transaction Request) to a list of known recipients. This JBI component is designed based on the Recipient List EIP catalogue. In our case, the targets are debitTransformer and creditTransformer. 
• debitTransformer: An XSLT Transformer component, which can transform a Money-Transfer request to a Debit-Only request so that we can target the transformed request to the debitService. This JBI component is designed, based on the Message Translator listed in the Enterprise Integration Patterns (EIP) catalogue. 
• creditTransformer: A second XSLT Transformer component, which can transform the Money-Transfer request to a Credit-Only request so that we can target the transformed request to the creditService. 
• jmsConsumer: This is a ServiceMix JMS component configured in the consumer role. A ServiceMix JMS consumer endpoint is a server-side endpoint that can consume plain JMS, or JMS+SOAP requests and send them into the NMR to a given JBI endpoint. 
• JMSClient: A Java JMS Client which can send a fund transfer transaction request to the jmsConsumer. The JMSClient represents any systems in the LAN (like other LOB systems in intranet), making use of MOM for Quality of Services (QOS) like message persistance, guaranteed delivery, etc. 
• httpConsumer: This is a ServiceMix HTTP component configured in the consumer role. In the consumer role, this server-side http endpoint can consume plain HTTP, or HTTP+SOAP requests and route them into the NMR to a given JBI endpoint. 
• HTTPClient: A browser-based HTTP client which can send a fund transfer transaction request to the httpConsumer. The HTTPClient represents a  B2B consumer in the internet like a vendor's or partner's system.

We integrate the above components in the ServiceMix ESB so that message can flow through these components through the Normalized Message Router (NMR). In Figure 4, we represent the message flow with red arrow headed lines. A consumer application can choose either a HTTP channel (1h) or a JMS channel (1j) to send the fund transfer requests. This will be intercepted by either the httpConsumer or the jmsConsumer respectively, as the case may be. These JBI consumer components will next route the message to the recipients [(2h) or (2j)]. The recipients will route the transaction request to two transformers viz. creditTransformer (3c) and the debitTransformer (3d). The creditTransformer will transform the fund transfer request to a 'Credit-Only' request and route (4c) it to creditService. Similarly the debitTransformer will transform the fund transfer request to a 'Debit-Only' request and route (4d) it to debitService. creditService and debitTransformer are two 'fine grained services', which will in turn get invoked and the cumulative effect is a 'Fund Transfer'.

So far, so good - Nice integration literature. How do we do that in code? Let us now jump to that.

JBI based solution in ServiceMix ESB

Contrary to numeroue white papers in ESB which will give you literature alone, we are going to showcase our discussion with code. This section will list out the important code snippets in multiple sections.

Service Oriented Java Business Integration

POJO Implementing Debit & Credit Functionality

CreditServicePojo is a simple POJO, implementing the credit functionality.

package samples;
public class CreditServicePojo implements ICreditService{
    public void credit(String accountId, BigDecimal amount) {
        //Implement Credit Logic Here...
    }
}

CreditServicePojo implements a business interface. This is following the best practice of interface oriented programming, and is listed below for completeness of our code listing:

package samples;
public interface ICreditService{
    void credit(String accountId, BigDecimal amount) throws java.io.
           IOException;
}

Similarly, DebitServicePojo is another POJO, implementing the debit functionality.

package samples;
public class DebitServicePojo implements IDebitService{
    public void debit(String accountId, BigDecimal amount) {
        //Implement Debit Logic Here...
    }
}

What you have seen above is the only Java code we need to write to realize the Integration Architecture! The rest all is about assembling components - In other words, we will configure off the shelf  ibraries. For this, the next step is to expose these component functionalities as WSDL compliant services to the NMR of the ESB. ServiceMix jsr181 component can expose these components as services on the JBI Bus.

<beans  xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0"
        xmlns:test="http://binildas.com/esb/jsrpojo">
  <jsr181:endpoint annotations="none"
                      service="test:creditService"
                      serviceInterface="samples.ICreditService">
    <jsr181:pojo>
      <bean class="samples.CreditServicePojo">
      </bean>
    </jsr181:pojo>
  </jsr181:endpoint>
</beans>

The above ServiceMix jsr181 component exposes CreditServicePojo as a service accessible for any other components in the JBI Bus, with the service name http://binildas.com/esb/jsrpojo:creditService. You may access the WSDL of the creditService too from the Bus. Similarly you can also expose the DebitServicePojo as a service with its WSDL exposed on the bus with the service name http://binildas.com/esb/jsrpojo:debitService, the code of which is shown below:

<beans  xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0"
        xmlns:test="http://binildas.com/esb/jsrpojo">
  <jsr181:endpoint annotations="none"
                      service="test:debitService"
                      serviceInterface="samples.IDebitService">
    <jsr181:pojo>
      <bean class="samples.DebitServicePojo">
      </bean>
    </jsr181:pojo>
  </jsr181:endpoint>
</beans>

The fine grained services are now ready and accessible at the JBI bus. We will now assemble the channels for external clients to access the service. First we will assemble a HTTP channel. For this, we configure a ServiceMix HTTP component in the consumer role.

<beans  xmlns:http="http://servicemix.apache.org/http/1.0"
        xmlns:test="http://binildas.com/esb/jsrpojo">
    <http:endpoint service="test:httpConsumer"
                      endpoint="httpConsumer"
                      role="consumer"
                      targetService="test:recipients"
                      locationURI="http://localhost:8081/services/
                                                 PojoBindService"
                      soap="true"
                      defaultMep="http://www.w3.org/2004/08/
                                  wsdl/in-only" />
</beans>

In the above configuration, service and endpoint refers to the service name and the endpoint name of the proxied endpoint. The role 'consumer' means that this component is a consumer to the JBI bus. When we speak of ‘Consumer’ and ‘Provider’ roles for ServiceMix components, the difference is very subtle at first sight, but very important from a programmer's perspective. These roles are with respect to the NMR of the ESB. In other words, a consumer role implies the component is a consumer to the NMR. targetService refers to the service name of the target endpoint. This means, httpConsumer service will route any of its messages only to the targetService. In our case, targetService is http://binildas.com/esb/jsrpojo:recipients, which will be explained shortly. locationURI refers to the the HTTP URL where this proxy endpoint will be exposed. External consumers need to point to this URL to access any service. Since we have configured the soap attribute to true, the component will expect SOAP formatted requests and parse the requests and send the content only to the NMR. The defaultMep refers to the default MEP uri to use which in our case is in-only. This means, the MEP is In-Only, and the external client will/need not wait for any response.

We also need a JMS channel so that clients can also access the service in a Messaging style. For that, we will assemble a ServiceMix JMS component, again in the consumer role.

<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
          xmlns:test="http://binildas.com/esb/jsrpojo">
    <bean id="connectionFactory" class="org.apache.activemq.
                ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:61616" />
    </bean>
    <jms:endpoint service="test:jmsConsumer"
                     endpoint="jmsConsumer"
                     role="consumer"
                     soap="true"
                     targetService="test:recipients"
                     defaultMep="http://www.w3.org/2004/08/wsdl/in-only"
                     destinationStyle="queue"
                     jmsProviderDestinationName="queue/A"
                     connectionFactory  ="#connectionFactory" />
</beans>

Most of the attributes above have the same meaning as there in ServiceMix HTTP configuration. We will look at the extra attributes here. connectionFactory refers to the connectionFactory to use, which we have configured as a Spring bean here. We have configured queue as the destinationStyle. So by mentioning jmsProviderDestinationName, the JMS provider creates a JMS Queue by calling Session.createQueue.

Irrespective of the consumer channel, the message has to be routed to http://binildas.com/esb/jsrpojo:recipients, which is a Recipient List. We will look at this Recipient List now.

<beans  xmlns:http="http://servicemix.apache.org/http/1.0"
        xmlns:eip="http://servicemix.apache.org/eip/1.0"
        xmlns:test="http://binildas.com/esb/jsrpojo">
  <eip:static-recipient-list service="test:recipients" 
                          endpoint="recipients">
    <eip:recipients>
      <eip:exchange-target service="test:creditTransformer" />
      <eip:exchange-target service="test:debitTransformer" />
    </eip:recipients>
  </eip:static-recipient-list>
</beans>

A recipient list can inspect an incoming message, and depending upon the number of recipients specified in the recipient list, it can forward the message to all channels associated with the recipients in the recipient list. In the assembly above, we have configured http://binildas.com/esb/jsrpojo:creditTransformer and http://binildas.com/esb/jsrpojo:debitTransformer as the recipients. Therefore, the same transaction request message will be routed to the two transformers configured here. Now we will look at the two transformers:

<beans xmlns:sm="http://servicemix.apache.org/config/1.0"
xmlns:test="http://binildas.com/esb/jsrpojo">
   <sm:container id="jbi" ...>
      <sm:activationSpecs>
         <sm:activationSpec componentName="creditTransformer"
                            service="test:creditTransformer"
                            destinationService="test:creditService">
            <sm:component>
               <bean class="org.apache.servicemix.components.xslt.
                             XsltComponent">
                  <property name="xsltResource" value="SoapRequestPart-
                             To-Credit.xsl"/>
               </bean>
            </sm:component>
         </sm:activationSpec>
         <sm:activationSpec componentName="debitTransformer"
                            service="test:debitTransformer"
                            destinationService="test:debitService">
            <sm:component>
               <bean class="org.apache.servicemix.components.xslt.
                                   XsltComponent">
                  <property name="xsltResource" value="SoapRequestPart
                      -To-Debit.xsl"/>
               </bean>
            </sm:component>
         </sm:activationSpec>
      </sm:activationSpecs>
   </sm:container>
</beans>

The creditTransformer uses SoapRequestPart-To-Credit.xslto transform the fund transfer request to a 'Credit-Only' request and route it to creditService. Similarly, the debitTransformer uses SoapRequestPart-To-Debit.xsl to transform the fund transfer request to a 'Debit-Only' request and route it to debitService.

We have provided a HttpClient.html which can send the following fund transfer transaction request to the httpConsumer at the URL: http://localhost:8081/services/PojoBindService/

<?xml version="1.0" encoding="UTF-8"?>
<e:Envelope xmlns:e="http://schemas.xmlsoap.org/soap/envelope/">
   <e:Body>
      <transactionReq
         xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
         xmlns:n1="java:com.binildas.j2ee.bea.EightOneTwo.
                                        BankTransaction"
         xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:type="n1:TransactionReq">
            <fromAccountId xsi:type="xsd:string">1</fromAccountId>
            <toAccountId xsi:type="xsd:string">2</toAccountId>
            <action xsi:type="xsd:string">Transfer</action>
            <amount xsi:type="xsd:decimal">100</amount>
      </transactionReq>
   </e:Body>
</e:Envelope>

Referring to the above transaction request, let us look at the SoapRequestPart-To-Credit.xsl code.

<xsl:stylesheet version="1.0"
                   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
                   xmlns:m="http://www.binildas.com/j2ee/bea/
                      EightOneTwo/BankTransaction">
   <xsl:output method="xml"/>
   <xsl:template match="/">
      <m:credit xmlns:m="http://www.binildas.com/j2ee/bea/ 
                        EightOneTwo/BankTransaction"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema">
         <string xsi:type="xsd:string">
            <xsl:value-of select="/transactionReq/toAccountId"/>
         </string>
         <bigDecimal xsi:type="xsd:decimal">
            <xsl:value-of select="/transactionReq/amount"/>
         </bigDecimal>
      </m:credit>
   </xsl:template>
</xsl:stylesheet>

The above XSL transformation, if we apply to the transaction request, we will get a Credit-Only transaction request which is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<m:credit xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
          xmlns:m="http://www.binildas.com/j2ee/bea/EightOneTwo/
            BankTransaction"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <string xsi:type="xsd:string"></string>
   <bigDecimal xsi:type="xsd:decimal"></bigDecimal>
</m:credit>

This Credit-Only transaction request is then routed to creditService which will in turn invoke the credit method. Similarly, the SoapRequestPart-To-Debit.xsl transforms the transfer request to a 'Debit-Only' request and route it to debitService which is not repeated here since it is very similar to the Credit scenario.

Last but not the least, we also have a JMSClient. But before that, let me remind you that we haven't written a single line of Java code for all our integration steps above. Don't you think this is a step ahead when compared to our traditional programming style of inlining routing and transformation and endpoint (... and, the list continues) details into our business purpose Java code?! These are just few of the features provided by JBI and I hope you would also love to hear directly from Peter Walker (Co-Spec Lead, JSR 208) more on JBI.

OK, now we have the JMSClient code in Java to send messages to the integration solution, which is in no way different to our familiar JMS programming.

public class JMSClient {
   private static final String REQUEST_FILE = "/Message.xml";
   public static void main(String[] args) throws Exception {
      ActiveMQConnectionFactory factory = 
       new ActiveMQConnectionFactory("tcp://localhost:61616");
      ActiveMQQueue pubTopic = new ActiveMQQueue("queue/A");
      System.out.println("Connecting to JMS server.");
      Connection connection = factory.createConnection();
      Session session = connection.createSession(false, 
       Session.AUTO_ACKNOWLEDGE);
      MessageProducer producer = session.createProducer(pubTopic);
      connection.start();
      InputStream inputStream = JMSClient.class.getClass().
       getResourceAsStream(REQUEST_FILE);
      int available = inputStream.available();
      byte[] bytes = new byte[available];
      inputStream.read(bytes);
      inputStream.close();
      String requestString = new String(bytes);
      System.out.println("Sending request: " + requestString);
      producer.send(session.createTextMessage(requestString));
      System.out.println("Closing.");
      connection.close();
   }
}

Summary

Enterprise Service Bus is a new architectural style of integrating systems, applications and services using SOA principles at the core to provide a distributed and federated service container capability. JBI helps Java developers to design and implement ESB based integration solutions using the J2EE stack. JBI provides Specifications, Reference Implementations (RI),  tools and frameworks to do integration.

Service Oriented Java Business Integration

About the Author

Binildas A. Christudas provides Technical Architecture consultancy for IT solutions. He has got over 13 years of IT experience, mostly in Microsoft and Sun technologies. Distributed computing and Service Oriented Integration are his main stream skills, with extensive hands on experience in Java and C#.NET programming. He currently works for Infosys Technologies where he heads the J2EE Architects group servicing Communications Service Provider clients. Binil has worked with several organizations including IBS Software Services and Tata Consultancy Services. Binil is a Sun Certified Programmer, Developer, Business Component Developer and Enterprise Architect, Microsoft Certified Professional and Open Group (TOGAF8) Certified Enterprise Architecture Practitioner. He is also a Zapthink Licensed Architect (LZA) in SOA. He spends free time with wife Sowmya & daughter Ann in "God's Own Country" (Kerala). Contact Binil at biniljava<{at}>yahoo.co.in or binil_christudas<{at}>infosys.com.