Service Oriented Java Business Integration
You’re all in the business of software development. Some of you are architects and developers while few others are technology managers and executives. For many of you, ESB is encroaching and JBI is still an unknown—a risk previously avoided but now found to be inescapable. Let us tame these buzzwords in the context of SOA and Integration.
also read:
While you do the day to day programming for solving business problems, you will be generating business code as well as business integration code. The traditional Java/J2EE APIs provide you with enough tools and frameworks to do the business coding. The business code will help you to implement a business service such as creating orders or finding products. On the contrary, business integration code wires together multiple applications and systems to provide seamless information flow. It deals with patterns of information exchange across systems and services, among other things. This is where the new Java API for Integration—Java Business Integration (JBI) seeks attention.
JBI provides a collaboration framework which has standard interfaces for integration components and protocols to plug into, thus allowing the assembly of Service Oriented Integration (SOI) frameworks following the Enterprise Service Bus (ESB) pattern. JBI is based on JSR 208, which is an extension of Java 2 Enterprise Edition (J2EE). The book first discusses the various integration approaches available and introduces ESB, which is a new architectural pattern which can facilitate integrating services. In doing
so, we also introduce ServiceMix, an Apache Open Source Java ESB. Thus for each of the subsequent chapters, we limit our discussion to a major concern which we can address using ESB and then also showcase this with samples which you can run using ServiceMix. If you are a person with a non-Java background, the book still benefits you since most of the integration wiring happens in XML configuration files.
The aim of this book is to prepare an architect or developer for building integration solutions using ESB. To that end, this book will take a practical approach, emphasizing how to get things done in ServiceMix with code. On occasions, we will delve into the theoretical aspects of ESB, and such discussions will always be supplemented with enough running samples. The book, thus, attempts to distill some of the knowledge that has emerged over the last decade in the realm of Java Integration. Quite different from the other books in the related topics, you don’t need a 4GB RAM or some heavy, vendor specific IDE/Workshops to run the samples. Instead, get set with the latest JDK and a text editor and few other lightweight frameworks including Tomcat and you are ready to go. Enough about the hype, supplement with what you’ve heard with some substance and code. Happy Reading!
What This Book Covers
Chapter 1 begins with a quick tour on Enterprise Integration and the associated issues so that you can better understand the problem which we are trying to solve, rather than following a solution for an unknown problem. We also introduce Enterprise Service Bus (ESB) architecture and compare and contrast that with other integration architectures.
Chapter 2 introduces Java Business Integration (JBI) and inspects the need for another standard for Business Integration, and also looks into the details on what this standard is all about.
Chapter 3 introduces ServiceMix, which is an open source ESB platform in the Java programming language, built from the ground up with JBI APIs and principles. It runs through a few other ESB products also.
Chapter 4 looks at how we have been binding services locally or remotely even before the ESB became popular. The chapter will demonstrate how tunneling using conventional J2EE tools will help to expose even technology-specific API services. An example of such a service is an EJB service to be exposed through firewalls over HTTP so that the service becomes technology agonistic.
Chapter 5 introduces XFire, which is a new generation Java SOAP framework to easily expose web services. Here we demonstrate the integration capabilities of the XFire. Then we can do integration using XFire within the JBI
Architecture also.
Chapter 6 teaches you JBI packaging and deployment. After going through this chapter the reader will be able to build, package, and deploy integration artifacts as standard JBI packages into the JBI container.
Chapter 7 teachs you how to create your own components and deploy them onto the JBI container. This chapter visits the core API from the ServiceMix as well as from the JBI specification which will function as useful helper classes using which you can develop integration components quickly.
Chapter 8 shows you how to bind Enterprise Java Beans components to the ESB. EJB is the Distributed Component paradigm in the Java-J2EE world and the industry has a lot invested in this technology. Coexisting services with those components will help you to reuse those existing investments so that we can continue building new systems based on higher levels of SOA maturity.
Chapter 9 shows POJO Binding using JSR181 to the ESB. POJO components can be easily exposed as WSDL-compliant services to the JBI bus.
Chapter 10 illustrates how to bind the web services to the ServiceMix ESB, thus creating a web services gateway at the ESB layer.
Chapter 11 looks at how Java Message Service (JMS), which is a platform dependent messaging technology, can increase the QOS features of web services by making web services accessible through the JMS channel.
Chapter 12 introduces Java XML binding and XStream, which is a simple open source library to serialize the Java objects to XML and back again. We will show the XStream integration with ESB demonstrating streaming of data across
the bus.
Chapter 13 visits the JDK Proxy classes and then explains the JBI Proxy in detail with examples. We show a practical use of the JBI Proxy—Proxying the external web services in the JBI bus.
Chapter 14 explains versioning in the SOA context and explains various strategies and approaches to versioning services. It also explains and demonstrates a versioning sample leveraging the targetNamespace attribute. Versioning services, especially versioning of web services, is a topic of heated discussion in many forums and sites.
Chapter 15 explains that the EAI patterns are nuggets of advice made out of aggregating basic Message Exchange Pattern elements to solve frequently recurring integration problems. We can look at EAI patterns as design patterns for solving integration problems. This chapter will demonstrate many of the common EAI patterns.
Chapter 16 looks into a sample use case. One of the useful applications of ESB is to provide a “Services Workbench” wherein which we can use various integration patterns available to aggregate services to carry out the business processes.
Chapter 17 visits a few selected QOS features such as Transactions, Security, Clustering, and Management which can impact the programming and deployment aspects using ESB.
Bind Web Services in ESB — Web Services Gateway
Since SOI is all about integrating multiple SOA-based systems, web services play a critical role in the integration space. This chapter is all about the importance of web services in integration. We will use the samples to illustrate how to bind web services with the ServiceMix ESB to facilitate integration. We will cover the following in this chapter:
Web services and binding • Introduction to HTTP • ServiceMix’s servicemix-http component • The consumer and provider roles for the ServiceMix JBI components • servicemix-http in the consumer and provider roles • Web service binding (Gateway) sample.
Web Services
Web services separate out the service contract from the service interface. This feature is one of the many characteristic required for an SOA-based architecture. Thus, even though it is not mandatory that we use the web service to implement an SOA-based architecture, yet it is clearly a great enabler for SOA.
Web services are hardware, platform, and technology neutral The producers and/or consumers can be swapped without notifying the other party, yet the information can flow seamlessly. An ESB can play a vital role to provide this
separation.
Binding Web Services
A web service’s contract is specified by its WSDL and it gives the endpoint details to access the service. When we bind the web service again to an ESB, the result will be a different endpoint, which we can advertise to the consumer. When we do so, it is very critical that we don’t lose any information from the original web service contract.
Why Another Indirection?
There can be multiple reasons for why we require another level of indirection between the consumer and the provider of a web service, by binding at an ESB. Systems exist today to support business operations as defined by the business processes. If a system doesn’t support a business process of an enterprise, that system is of little use. Business processes are never static. If they remain static then there is no growth or innovation, and it is doomed to fail.
Hence, systems or services should facilitate agile business processes. The good architecture and design practices will help to build “services to last” but that doesn’t mean our business processes should be stable. Instead, business processes will evolve by leveraging the existing services. Thus, we need a process workbench to assemble and orchestrate services with which we can “Mix and Match” the services. ESB is one of the architectural topologies where we can do the mix and match of services. To do this, we first bind the existing (and long lasting) services to the ESB. Then leverage the ESB services, such as aggregation and translation, to mix and match them and
advertise new processes for businesses to use.
Moreover, there are cross service concerns such as versioning, management, and monitoring, which we need to take care to implement the SOA at higher levels of maturity. The ESB is again one way to do these aspects of service orientation.
HTTP
HTTP is the World Wide Web (www) protocol for information exchange. HTTP is based on character-oriented streams and is firewall-friendly. Hence, we can also exchange XML streams (which are XML encoded character streams) over HTTP. In a web service we exchange XML in the SOAP (Simple Object Access Protocol) format over HTTP. Hence, the HTTP headers exchanged will be slightly different than a normal web page interaction. A sample web service request header is shown as follows:
GET /AxisEndToEnd/services/HelloWebService?WSDL HTTP/1.1 User-Agent: Java/1.6.0-rc Host: localhost:8080 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive POST /AxisEndToEnd/services/HelloWebService HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: localhost:8080 Cache-Control: no-cache Pragma: no-cache SOAPAction: "" Content-Length: 507
The first line contains a method, a URI and an HTTP version, each separated by one or more blank spaces. The succeeding lines contain more information regarding the web service exchanged.
ESB-based integration heavily leverages the HTTP protocol due to its open nature, maturity, and acceptability. We will now look at the support provided by the ServiceMix in using HTTP.
servicemix-http in Detail
servicemix-http is used for HTTP or SOAP binding of services and components into the ServiceMix NMR. For this ServiceMix uses an embedded HTTP server based on the Jetty.
In Chapter 3, you have already seen the following two ServiceMix components:
- org.apache.servicemix.components.http.HttpInvoker
- org.apache.servicemix.components.http.HttpConnector
As of today, these components are deprecated and the functionality is replaced by the servicemix-http standard JBI component. A few of the features of the servicemix-http are as follows: Supports
- SOAP 1.1 and 1.2
- Supports MIME with attachments
- Supports SSL
- Supports WS-Addressing and WS-Security
- Supports WSDL-based and XBean-based deployments
- Support for all MEPs as consumers or providers
- Since servicemix-http can function both as a consumer and a provider, it can effectively replace the previous HttpInvoker and HttpConnector component.
Consumer and Provider Roles
When we speak of the Consumer and Provider roles for the ServiceMix components, the difference is very subtle at first sight, but very important from a programmer perspective. The following figure shows the Consumer and Provider roles in the ServiceMix ESB:
The above figure shows two instances of servicemix-http deployed in the ServiceMix ESB, one in a provider role and the other in the consumer role. As it is evident, these roles are with respect to the NMR of the ESB. In other words, a consumer role implies that the component is a consumer to the NMR whereas a provider role implies the NMR is the consumer to the component. Based on these roles, the NMR will take responsibility of any format or protocol conversions for the interacting components.
Let us also introduce two more parties here to make the role of a consumer and a provider clear—a client and a service. In a traditional programming paradigm, the client interacts directly with the server (or service) to avail the functionality. In the ESB model, both the client and the service interact with each other only through the ESB. Hence, the client and the service need peers with their respective roles assigned, which in turn will interact with each other. Thus, the ESB consumer and provider roles can be regarded as the peer roles for the client and the service respectively.
Any client request will be delegated to the consumer peer who in turn interacts with the NMR. This is because the client is unaware of the ESB and the NMR protocol or format. However, the servicemix-http consumer knows how to interact with the NMR. Hence any request from the client will be translated by the servicemix-http consumer and delivered to the NMR. On the service side also, the NMR needs to invoke the service. But the server service is neutral of any specific vendor’s NMR and doesn’t understand the NMR language as such. A peer provider role will help here. The provider receives the request from the NMR, translates it into the actual format or protocol of the server service and invokes the service. Any response will also follow the reverse sequence.
servicemix-http XBean Configuration
The servicemix-http components supports the XBean-based deployment. Since the servicemix-http component can be configured in both the consumer and provider roles, we have two sets of configuration parameters for the component. Let us look into the main configuration parameters:
servicemix-http as consumer: A sample servicemix-http consumer • component configuration is shown as follows: The following table gives the explanation for the main configuration parameters: Attribute Name Type Description Mandatory or Not service QName Service name of the proxy Mandatory endpoint endpoint String Endpoint name of the proxy Mandatory endpoint interfaceName
QName Interface name of the proxy Not Mandatory endpoint targetService QName Service name of the target Not Mandatory. Default endpoint is the value of the service attribute targetEndpoint String Endpoint name of the target Not Mandatory. Default is endpoint the value of the endpoint attribute role String Whether a consumer or a Mandatory. Value should provider be consumer locationURI URI Http URL where this proxy Mandatory endpoint will be exposed so that the ESB clients can access the proxy service. defaultMEP
URI The MEP URI by which Not Mandatory clients interact with the consumer component soap boolean If it is true, the component Not Mandatory. Default will parse the SOAP value is false. envelope and pass the contents to the NMR wsdlResource Spring If it is set, the WSDL will Not Mandatory Resource be retrieved from this configured Spring resource.
Thus, the locationURI attribute in the servicemix-http consumer refers to the Http URL where this proxy endpoint is exposed, so that the ESB clients can access the proxy service. Later we will look at how to generate static cli-ent stubs out of this proxy URI.
servicemix-http as provider: While configuring the provider, there are a few •aspects to be taken care of with respect to the WSDL. If we have the sample WSDL as shown as follows:
Now, while configuring the provider component you need to ensure that the service (IHelloWebService) and the endpoint (HelloWebService) match the service name and port elements of the WSDL that you use to correctly return the WSDL for the endpoint. Moreover, the service name will use the targetNamespace for the WSDL (http://AxisEndToEnd.axis.apache. binildas.com).
A sample servicemix-http provider component configuration is shown as follows: The following table the gives the explanation for the main configuration parameters: Attribute Name Type Description Mandatory or Not service QName Service name of the exposed Mandatory endpoint endpoint String Endpoint name of the exposed Mandatory endpoint interfaceName QName Interface name of the exposed Not Mandatory endpoint role String Whether a consumer or a provider Mandatory. Value should be provider locationURI
URI Http URL of the target service. Mandatory Attribute Name Type Description Mandatory or Not soap boolean If it is true, the component will Not Mandatory. parse the SOAP envelope and pass Default value is the contents to the NMR false. soapAction String The SOAPAction header to be send Not Mandatory. over HTTP when invoking the Default value is “”. web service wsdlResource
Spring If it is set, the WSDL will be Not Mandatory Resource retrieved from this configured Spring resource. servicemix-http Lightweight Configuration
In addition to the XBean-based configuration, servicemix-http can also be deployed based on the lightweight mode to use in an embedded ServiceMix. The configuration would be as follows:
Web Service Binding Sample
We will now look at a complete sample of how to bind a web service to the ServiceMix. While doing so, we will also see how to use the Apache Axis client-side tools to generate stubs based on the binding at ServiceMix. Normally we point to the actual WSDL URL to generate client stubs, but in this example we will point the tools to the ServiceMix binding. Then the ServiceMix binding will act completely as the web service gateway visible to the external clients, thus shielding the actual web service in the background.
Sample Use Case
By using a web services gateway, you can use the intermediation to build and deploy the web services routing application. But keep in mind that the routing is just one of the various technical functionalities that you can implement at the gateway. For our sample use case, we have an external web service, deployed and hosted in a node remote to the ESB. In the ESB, we will set up a Web Services Gateway, which can proxy the remote web service. The entire setup is shown in the following figure:
Along with the previous discussion, we need the servicemix-http in the consumer and provider roles. MyConsumerService is a servicemix-http component in the consumer role and IHelloWebService is a servicemix-http component in the provider role. Both of them are shown in the following figure:
Let us now take a closer look at the gateway configured in the ESB. Here, we configure servicemix-http in both the consumer and provider roles and hook it to the NMR. Any client requests are intercepted by the consumer and the consumer then sends the request on behalf of the client to the NMR. From there the request will be routed to the destination web service through the provider. The message flow is marked in sequence in the following figure:
Deploy the Web Service
As a first step, if you haven’t done it before, edit examples.PROPERTIES (provided along with the code download for this chapter), and change the paths there to match your development environment. The code download for this chapter also includes a README.txt file, which gives detailed steps to build and run the samples. We have a simple web service in the codebase present in the folder ch10\ServiceMixHttpBinding1_ws. To deploy the web service, first change directory to the ch10\ServiceMixHttpBinding folder and execute the ant command as follows:
cd ch10\ServiceMixHttpBinding ant
In fact, the build.xml file will call the build in the subprojects to build the web service as well as the ServiceMix subproject. The web service is built completely and the war file can be found in the folder ch10\ServiceMixHttpBinding1_ws\dist\AxisEndToEnd.war. To deploy the web service, drop this war file into your favorite web server’s webapps folder and restart the web server, if necessary.
Now to make sure that your web service deployment works fine, we have provided a web service test client. To invoke the test client, execute the following commands:
cd ch10\ServiceMixHttpBinding\01_ws ant run
We can also check the web service deployment by accessing the WSDL from the URL: http://localhost:8080/AxisEndToEnd/services/HelloWebService?WSDL Let us list out the WSDL here, since we want to compare it with the WSDL accessed from the ServiceMix binding later to cross check the similarities. This is provided in ch10\ServiceMixHttpBinding\HelloWebService-axis.wsdl
XBean-based servicemix-http Binding
For XBean-based deployment of servicemix-http, our xbean.xml matches the following:.
The previous execution of ant has already built and packaged the service assembly for the sample.
Deploying and Running the Sample
To deploy the ServiceMix sample, we have the following servicemix.xml: To bring up the ServiceMix, change directory to ch10\ServiceMixHttpBinding and execute the ServiceMix script as follows.
cd ch10\ServiceMixHttpBinding%SERVICEMIX_HOME%\bin\servicemix servicemix.xml
We can now test our ServiceMix deployment by using the following test client: ch10\ServiceMixHttpBinding\Client.html Access WSDL and Generate Axis Stubs to Access the Web Service Remotely Now for the really cool stuff. As we discussed earlier, we have set up the ServiceMix as a separate web service gateway in front of the actual web service deployment. Now we have to check whether we can access the WSDL from the ServiceMix. For this, we can point our browser using the standard WSDL query string, like:
http://localhost:8081/services/HelloWebService/?wsdl or
http://localhost:8081/services/HelloWebService/main.wsdl Note that, the above URL points to the locationURI attribute configured for the consumer component, which is http://localhost:8081/services/ HelloWebService. The WSDL placed in
location ch10\ServiceMixHttpBinding\ HelloWebService-esb.wsdl, matches the following code:
If we compare the two WSDL, the major difference is in the service description section. Here, ServiceMix forms the service and port name taking values from service and endpoint attributes of the consumer service—MyConsumerService and HelloWebService respectively.
If we are able to retrieve the WSDL, the next step is to use the Apache Axis tools to auto-generate the client-side stubs and binding classes, using which we can write simple Java client code to access the service through HTTP channel. The Axis client classes are placed in the directory ch10\ServiceMixHttpBinding3_AxisClient.
To do that, we have to use the wsdl2java ant task. Let us first declare the task definition and execute that task to generate the stub classes.
The task will extract the WSDL from the specified location and generate the following client-side artifacts:
- com\binildas\apache\axis\AxisEndToEnd\HelloWebServiceBindingStub. java
- com\binildas\apache\axis\AxisEndToEnd\IHelloWeb.java
- com\binildas\apache\axis\AxisEndToEnd\MyConsumerService.java
- com\binildas\apache\axis\AxisEndToEnd\MyConsumerServiceLocator. java
The Client Java class can be written against these generated files as follows:
public class Client { private static String wsdlUrl = "http://localhost:8081/services/HelloWebService/main.wsdl"; private static String namespaceURI ="http://AxisEndToEnd. axis.apache.binildas.com"; private static String localPart
= "MyConsumerService"; protected void executeClient(String[] args)throws
Exception { MyConsumerService myConsumerService = null; IHelloWeb iHelloWeb =
null; if(args.length == 3) { myConsumerService = new
MyConsumerServiceLocator(args[0], new QName(args[1], args[2])); } else {
myConsumerService = new MyConsumerServiceLocator(wsdlUrl, new
QName(namespaceURI, localPart)); } iHelloWeb =
myConsumerService.getHelloWebService(); } public static void main(String[]
args)throws Exception { Client client = new Client();
client.executeClient(args); } }
To build the entire Axis client codebase, assuming that the ServiceMix is up and running, change directory to ch10\ServiceMixHttpBinding3_AxisClient, which contains a build.xml file. Execute ant as shown as follows:
cd ch10\ServiceMixHttpBinding\03_AxisClient ant
This will generate the required Axis client-side stubs and compile the client classes. Now to run the client, execute the following command: ant run
Summary
We started this chapter by introducing the servicemix-http JBI component. Then we looked at the samples of binding web services to ESB using the servicemix-http binding component. By doing so, we have, in fact, implemented a complete functional web services gateway at the ESB.
A lot of times, we utilize this pattern to expose useful web services hosted deep inside your corporate networks protected by multiple levels of firewall. When we do so, the web services gateway is the access point for any external client. It should mock the actual web service not only in providing the functionality but also in exposing the web services contract (WSDL). Now, do you want to improve the QOS attributes of your web service?
The next chapter will take you through a similar exercise by demonstrating how to access your HTTP-based web services through an MOM channel like JMS.
