Since SOI (Service Oriented Integration) is all about integrating multiple SOA-based systems, web services play a critical role in the integration space. This article 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.

In this article by Binildas A. Christudas, we will cover the following:

• 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's servicemix-http

Binding external web services at the ESB layer can be done in multiple ways but the best way is to leverage JBI components such as the servicemix-http component within ServiceMix. We will look in detail at how to bind the web services onto the JBI bus.

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.

The following are the 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.

Enterprise Service Bus integration solutions for Java developers Vendor-independent integration of components and services through JBI explained with real-world examples Hands-on guidance to ESB-based Integration of loosely coupled, pluggable services Enterprise Integration Patterns (EIP) in action, in code ESB integration solutions using Apache open-source tools http://www.packtpub.com/service-oriented-java-business-integration/book

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:

  <http:endpoint service="test:MyConsumerService" endpoint="HelloWebService" role="consumer" targetService="test:IHelloWebService" 
  locationURI="http://localhost:8081/services/ HelloWebService" soap="true" defaultMep="http://www.w3.org/2004/08/wsdl/in-out" 
  wsdlResource="http://localhost:8080/AxisEndToEnd/ services/HelloWebService?WSDL" />
  

  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 endpoint	Mandatory
  endpoint	String	Endpoint name of the proxy endpoint	Mandatory
  interfaceName	QName	Interface name of the proxy endpoint	Not Mandatory
  targetService	QName	Service name of the target endpoint	Not Mandatory. Default is the value of the service attribute
  targetEndpoint	String	Endpoint name of the target endpoint	Not Mandatory. Default is the value of the endpoint attribute
  role	String	Whether a consumer or a provider	Mandatory. Value should be consumer
  locationURI	URI	Http URL where this proxy endpoint will be exposed so that the ESB clients can access the proxy service.	Mandatory
  defaultMEP	URI	The MEP URI by which clients interact with the consumer component	Not Mandatory
  soap	boolean	If it is true, the component will parse the SOAP envelope and pass the contents to the NMR	Not Mandatory. Default value is false.
  wsdlResource	Spring Resource	If it is set, the WSDL will be retrieved from this configured Spring resource.	Not Mandatory

  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 client 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:

  <?xml version="1.0" encoding="UTF-8"?> 
  <wsdl:definitions targetNamespace="http://AxisEndToEnd.axis. apache.binildas.com"
  xmlns:impl="http://AxisEndToEnd.axis.apache. binildas.com"> <!-- other descriptions --> 
  <wsdl:service name="IHelloWebService"> 
  <wsdl:port binding="impl:HelloWebServiceSoapBinding" name="HelloWebService"> 
  <wsdlsoap:address location="http://localhost:8080/ AxisEndToEnd/services/HelloWebService"/> 
  </wsdl:port> 
  </wsdl:service> 
  </wsdl:definitions>
  

  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:

  <http:endpoint service="test:IHelloWebService" endpoint="HelloWebService" role="provider" locationURI="http://localhost:8080/AxisEndToEnd/ services/HelloWebService" 
  soap="true" 
  soapAction="" 
  wsdlResource="http://localhost:8080/AxisEndToEnd/ services/HelloWebService?WSDL" />
  

  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 endpoint	Mandatory
  endpoint	String	Endpoint name of the exposed endpoint	Mandatory
  interfaceName	QName	Interface name of the exposed endpoint	Not Mandatory
  role	String	Whether a consumer or a provider	Mandatory. Value should be provider
  locationURI	URI	Http URL of the target service.	Mandatory
  soap	boolean	If it is true, the component will parse the SOAP envelope and pass the contents to the NMR	Not Mandatory. Default value is false.
  soapAction	String	The SOAPAction header to be send over HTTP when invoking the web service	Not Mandatory. Default value is "".
  wsdlResource	Spring Resource	If it is set, the WSDL will be retrieved from this configured Spring resource.	Not Mandatory

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:

<sm:activationSpec> 
 <sm:component> 
  <http:component> 
   <http:endpoints> 
     <http:endpoint service="test:IHelloWebService" endpoint="HelloWebService" role="provider" locationURI="http://localhost:8080/AxisEndToEnd/services/HelloWebService" soap="true" soapAction="" wsdlResource="http://localhost:8080/AxisEndToEnd/services/HelloWebService?WSDL" /> 
          <http:endpoint service="test:MyConsumerService" endpoint="HelloWebService" role="consumer" targetService="test:IHelloWebService" locationURI="http://localhost:8081/services/HelloWebService" 
          soap="true" 
          defaultMep="http://www.w3.org/2004/08/ wsdl/in-out" 
          wsdlResource="http://localhost:8080/AxisEndToEnd/services/HelloWebService?WSDL" /> 
    </http:endpoints> 
   </http:component> 
 </sm:component>
</sm:activationSpec>

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:

Enterprise Service Bus integration solutions for Java developers Vendor-independent integration of components and services through JBI explained with real-world examples Hands-on guidance to ESB-based Integration of loosely coupled, pluggable services Enterprise Integration Patterns (EIP) in action, in code ESB integration solutions using Apache open-source tools http://www.packtpub.com/service-oriented-java-business-integration/book

Deploy the Web Service

As a first step, edit examples.PROPERTIES (you can download this file from the location http://www.packtpub.com/files//code/4404_Code.zip. Unzip the zip file and you will find examples.PROPERTIES in the folder named Chapter_10), and change the paths there to match your development environment. It also includes a README.txt file, which gives detailed steps to build and run the samples. Also all the required files mentioned in this article will be found in the same folder Chapter_10

We have a simple web service in the codebase present in the folder ch10\ServiceMixHttpBinding\01_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\ServiceMixHttpBinding\01_wsdistAxisEndToEnd.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

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://AxisEndToEnd.axis. apache.binildas.com" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://AxisEndToEnd.axis.apache. binildas.com" xmlns:intf="http://AxisEndToEnd.axis.apache. binildas.com" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/ soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
<wsdl:types> 
<schema elementFormDefault="qualified" targetNamespace="http://AxisEndToEnd.axis.apache. binildas.com" xmlns="http://www.w3.org/2001/XMLSchema"> 
<element name="hello"> 
<complexType> 
<sequence> 
<element name="in0" type="xsd:string"/> 
</sequence> 
</complexType> 
</element> 
<element name="helloResponse">
<complexType> 
<sequence> 
<element name="helloReturn" type="xsd:string"/> 
</sequence> 
</complexType> 
</element> 
</schema> 
</wsdl:types> 
<wsdl:message name="helloRequest"> 
<wsdl:part element="impl:hello" name="parameters"/> 
</wsdl:message> 
<wsdl:message name="helloResponse"> 
<wsdl:part element="impl:helloResponse" name="parameters"/> 
</wsdl:message> 
<wsdl:portType name="IHelloWeb"> 
<wsdl:operation name="hello"> 
<wsdl:input message="impl:helloRequest" name="helloRequest"/> 
<wsdl:output message="impl:helloResponse" name="helloResponse"/> 
</wsdl:operation> 
</wsdl:portType> 
<wsdl:binding name="HelloWebServiceSoapBinding" type="impl:IHelloWeb"> 
<wsdlsoap:binding style="document" transport="http://schemas. xmlsoap.org/soap/http"/> 
<wsdl:operation name="hello"> 
<wsdlsoap:operation soapAction=""/> 
<wsdl:input name="helloRequest"> 
<wsdlsoap:body use="literal"/> 
</wsdl:input> 
<wsdl:output name="helloResponse"> 
<wsdlsoap:body use="literal"/> 
</wsdl:output> 
</wsdl:operation> 
</wsdl:binding> 
<wsdl:service name="IHelloWebService"> 
<wsdl:port binding="impl:HelloWebServiceSoapBinding" name="HelloWebService"> 
<wsdlsoap:address location="http://localhost:8080/ AxisEndToEnd/services/HelloWebService"/> 
</wsdl:port> 
</wsdl:service>
</wsdl:definitions>

XBean-based servicemix-http Binding

For XBean-based deployment of servicemix-http, our xbean.xml matches the following:

<beans xmlns:http="http://servicemix.apache.org/http/1.0" xmlns:test="http://AxisEndToEnd.axis.apache.binildas.com"> 
<classpath> 
<location>.</location> 
</classpath> 
<http:endpoint service="test:IHelloWebService" endpoint="HelloWebService" role="provider" locationURI="http://localhost:8080/AxisEndToEnd/ services/HelloWebService" soap="true" soapAction="" wsdlResource="http://localhost:8080/AxisEndToEnd/ services/HelloWebService?WSDL" /> 
<http:endpoint service="test:MyConsumerService" endpoint="HelloWebService" role="consumer" targetService="test:IHelloWebService" locationURI="http://localhost:8081/services/ HelloWebService" soap="true" defaultMep="http://www.w3.org/2004/08/wsdl/in-out" wsdlResource="http://localhost:8080/AxisEndToEnd/ services/HelloWebService?WSDL" />
</beans>

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:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:sm="http://servicemix.apache.org/config/1.0" xmlns:binil="http://www.binildas.com/voipservice"> 
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config. PropertyPlaceholderConfigurer"> 
<property name="location" value="classpath:servicemix.properties" /> 
</bean> 
<import resource="classpath:jmx.xml" /> 
<import resource="classpath:jndi.xml" />
<import resource="classpath:security.xml" /> 
<import resource="classpath:tx.xml" /> 
<sm:container id="jbi" MBeanServer="#jmxServer" useMBeanServer="true" createMBeanServer="true" rootDir="./wdir" installationDirPath="./install" deploymentDirPath="./deploy" flowName="seda"> 
<sm:activationSpecs> 
</sm:activationSpecs> 
</sm:container>
</beans>

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:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://AxisEndToEnd.axis.apache.binildas.com" xmlns:intf="http://AxisEndToEnd.axis.apache.binildas.com"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://AxisEndToEnd.axis.apache.binildas.com"> 
<wsdl:types> 
<schema xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://AxisEndToEnd.axis. apache.binildas.com"> 
<element name="hello"> 
<complexType> 
<sequence> 
<element name="in0" type="xsd:string"/> 
</sequence> 
</complexType> 
</element> 
<element name="helloResponse"> 
<complexType> 
<sequence> 
<element name="helloReturn" type="xsd:string"/> 
</sequence> 
</complexType> 
</element> 
</schema> 
</wsdl:types> 
<wsdl:message name="helloRequest"> 
<wsdl:part element="impl:hello" name="parameters"> 
</wsdl:part> 
</wsdl:message> 
<wsdl:message name="helloResponse"> 
<wsdl:part element="impl:helloResponse" name="parameters"> 
</wsdl:part> 
</wsdl:message> 
<wsdl:portType name="IHelloWeb"> 
<wsdl:operation name="hello"> 
<wsdl:input message="impl:helloRequest" name="helloRequest"> 
</wsdl:input> 
<wsdl:output message="impl:helloResponse" name="helloResponse"> 
</wsdl:output> 
</wsdl:operation> 
</wsdl:portType> 
<wsdl:binding name="HelloWebServiceBinding" type="impl:IHelloWeb"> 
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/ soap/http"/> 
<wsdl:operation name="hello"> 
<wsdlsoap:operation soapAction=""/> 
<wsdl:input name="helloRequest"> 
<wsdlsoap:body use="literal"/> 
</wsdl:input>
<wsdl:output name="helloResponse"> 
<wsdlsoap:body use="literal"/> 
</wsdl:output> 
</wsdl:operation> 
</wsdl:binding> 
<wsdl:service name="MyConsumerService"> 
<wsdl:port binding="impl:HelloWebServiceBinding" name="HelloWebService"> 
<wsdlsoap:address location="http://localhost:8081/ 
services/HelloWebService/"/> 
</wsdl:port> 
</wsdl:service>
</wsdl:definitions>

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\ServiceMixHttpBinding\03_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.

<taskdef name="wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" loaderref="axis" > 
<classpath refid="classpath"/>
</taskdef>
<target name="wsdl2java"> 
<java classname="org.apache.axis.wsdl.WSDL2Java" fork="true" failonerror="true"> 
<arg value="-o"/> 
<arg value="${src}"/> 
<arg value="-x"/> 
<arg value="http://io.java"/> 
<arg value="http://localhost:8081/services/HelloWebService/ main.wsdl"/> 
<classpath> 
<path refid="classpath"/> 
<pathelement location="${build}"/> 
</classpath> 
</java>
</target>

The task will extract the WSDL from the specified location and generate the following client-side artifacts:

combinildasapacheaxisAxisEndToEndHelloWebServiceBindingStub.java
combinildasapacheaxisAxisEndToEndIHelloWeb.java
combinildasapacheaxisAxisEndToEndMyConsumerService.java
combinildasapacheaxisAxisEndToEndMyConsumerServiceLocator.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\ServiceMixHttpBinding\03_AxisClient, which contains a build.xml file. Execute ant as shown as follows:

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 article 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).

Enterprise Service Bus integration solutions for Java developers Vendor-independent integration of components and services through JBI explained with real-world examples Hands-on guidance to ESB-based Integration of loosely coupled, pluggable services Enterprise Integration Patterns (EIP) in action, in code ESB integration solutions using Apache open-source tools http://www.packtpub.com/service-oriented-java-business-integration/book

About the Author

Binildas A. Christudas

Binildas C. A. provides Technical Architecture consultancy for IT solutions. He has 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. Binil holds a BTech. degree in Mechanical Engineering from College of Engineering, Trivandrum (www.cet.ac.in) and an MBA in Systems Management, from Institute of Management, Kerala (www.imk.ac.in). A well-known and a highly sought-after thought leader, Binil has designed and built many highly scalable middle-tier and integration solutions for several top-notch clients including Fortune 500 companies. He has been previously employed by multiple IT consulting firms including IBS Software Services (www.ibsplc.com) and Tata Consultancy Services (www.tcs.com) and currently works for Infosys Technologies (www.infosys.com) as a Principal Architect where he heads the J2EE Architects group servicing Communications Service Provider clients.

Binil is a Sun Certified Programmer (SCJP), Developer (SCJD), Business Component Developer (SCBCD) and Enterprise Architect (SCEA), Microsoft Certified Professional (MCP) and Open Group (TOGAF8) Certified Enterprise Architecture Practitioner. He is also a Licensed Zapthink Architect (LZA) in SOA. Besides Technical Architecture Binil also practices Enterprise Architecture.

When not in software, Binil spends time with wife Sowmya & daughter Ann in ‘God's Own Country’, Kerala (www. en.wikipedia.org/wiki/Kerala). Binil does long distance running and is a national medalist in Power Lifting. You may contact Binil at biniljava@yahoo.co.in or binil_christudas@infosys.com.