Bind Web Services in ESB-Web Services Gateway

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.

This book is available for purchase at packtpub.com Service Oriented Java Business Integration

Read Service Oriented Java Business Integration Book Review.

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.