Understanding Web Services in an ESB Environment
By Stephen Todd, Master Inventor, IBM Academy of Technology, IBM
Most organizations considering or in the midst of deploying a service-oriented architecture (SOA) are familiar with the concept or even the many varied definitions of the term enterprise service bus (ESB). In fact, ESBs are becoming a critical part of an SOA.
Interestingly, Gartner just released data stating that more than half of all large enterprises will have at least the core of an ESB running by year-end 2006. The rising interest in ESBs is based on their ability to increase scalability, ease of change and quality of service for large and frequently changed SOA and event-driven architectures.
With the anticipated increase in ESB deployments as well as the rise in SOAs, the following takes a look at the role of Web services in an ESB.
An ESB, as we know, is an architectural pattern that enables you to optimize the distribution of information between different types of applications across multiple locations. The ESB pattern is founded on and unifies message-oriented, event-driven and service-oriented approaches to integration.
Providing connectivity and integration for Web services-focused applications and services, the core characteristics of an ESB provide:
- Standards-based application integration
- Support for Web services, message-based transport and publish-and-subscribe (event-based) integration
- Intelligent routing
Still, it is important to understand the following points about ESBs:
The term enterprise does not necessarily have to encompass the whole of an organization. One of the attractions of an ESB is that you can start small, perhaps with only two to three physical instances and expand to fit evolving business circumstances.
The term bus is used to convey the notion of information being carried between originators and receivers, using different communications models and data formats, to many different destinations.
The bus provides a common backbone through which applications can interoperate.
An ESB should possess some degree of programming intelligence to determine routing or persistence, or to implement rules or content processing.
An ESB introduces new options for interoperation and helps enable information to flow to the people who need it, when they need it. In this way, an ESB can improve the responsiveness and accuracy of decision making.
What should an ESB deliver?
Ideally, an ESB should describe (at a high, logical level) what is going on within an enterprise, or subset of an enterprise. This description should be visual or graphical so that both the available resources and the flows (from sources to destinations) can be represented and depicted.
Besides describing the flows between the various nodes (sources, destinations, databases, local ESB processing, etc.), an ESB should enable you to lay on top of these resources the particular constraints associated with how flows are actually deployed and used.
The more an ESB can describe, the more capabilities can be automated. If applicable resources are described, network bandwidths set, systems located and transaction boundaries defined, you can then determine where potential problems might occur – and how these problem areas might be avoided or resolved. There should be a clear distinction between what is to be achieved, and how it is to be achieved.
In one sense, this approach envisions applications as existing on the edge of an ESB. The first step you should take is to integrate each application with an ESB. Having done this for several applications, you can then create new, logical combinations of applications out of the definitions of existing ones. An ESB’s flow capability effectively enables new combinations to be derived and implemented without opening up or rewriting the source or destination applications themselves.
In an ideal ESB environment, you should be able to define the applications and flows that shape your organization. You should also be able to add new combinations of applications and flows – or modify existing ones – easily.
Web services and ESBs
Combining Web services standards with an ESB can potentially deliver the broadest connectivity between systems. An ESB supports Web services with more established application-integration techniques, enabling the power of the new to be combined with the reach of the old.
Fundamentally, early Web-services standards were principally concerned with the format of what was being carried and less about the mechanism of the carriage. Web services were essentially remote procedure calls or one-way call formats. These services did not indicate how the data would be carried to the other end. You could assume that it would be by HTTP, but there was no discussion about different kinds of quality of service or other attributes that might be applicable.
The presumption was that any connection would be synchronous and that any asynchronous properties would have to be built, as required, on top of the synchronous connection by using a work-around.
Web services become interesting at several levels – particularly when Web services start to interact with each other. However, you must remember that not every application is written as a Web service.
Valuable legacy applications will almost certainly be in use. Product extensions like IBM CICS Web Services Bridge can help in these situations by enabling Web services and legacy applications to connect. These situations are where the ESB concept can come into focus.
An ESB offers a means by which modern Web-services applications and valuable legacy applications can make the most of each other and developers don’t have to create new applications to carry out the functions of the familiar ones that couldn’t be connected.
What an ESB adds is a common intermediary point or points where the rigidities of individual point-to-point connections can be avoided. In this instance, an ESB is effectively a switch for connecting multiple Web-services applications and legacy applications – or even other resources, like databases or application servers.
ESB: Is it an architecture or a product?
There has been much discussion and debate in the industry as to whether an ESB is a product or an architecture. However, there is little argument when it comes to providing connectivity and integration for Web services-focused applications and services that an ESB is the recommended path.
The answer to the question on architecture versus product really lies within the organization itself. Inherent in the term SOA is the word architecture and a critical component of a successful deployment is an ESB. For organizations that may not yet need an extensive integration of services yet want to provide universal connectivity and data transformation for applications whether or not they comply with standards, they may opt for a plug-in ESB product.
You may ask the architecture versus product question another way: are you looking to build an enterprise-wide strategy or build a bridge for connecting disparate applications?
From a Web services point of view, what advantage does an ESB offer?
Web services-based applications can be deployed to exploit an ESB with little or no modification to the application.
A benefit of Web services in an ESB context is that they enable you to take an architectural approach to decomposing IT solutions into pieces that can be reused. This helps increase efficiency because it makes the delivery of agile information systems that are responsive to changing business demands easier.
Similarly, loosely coupled, federated reuse of existing assets is made possible by combining the standardization inherent in Web services with the flexibility inherent in an ESB. The ESB offers the capability to support a wide range of devices, from PDAs to cell phones to telemetry devices to mainframes. The ESB can also support applications, from new Web services-based applications to legacy applications and enables them to work together as peers in a distributed environment.
A developer can write new applications for an ESB using the Web-services development infrastructure products that deliver the following benefits:
- Provide the means to define the SOAP message formats
- Help you easily enable disparate consumers and providers of services to interact properly
- Enable the application programmer to see the service as a standard method definition and then call that service using a standard remote method call. The benefit of this is that the programmer does not need to be involved in details of format or transport.
The adoption and proliferation of Web services standards will continue to grow and be in high demand. This will lead to a greater need for the conversion and wrapping capabilities of an ESB and underscores the need for the flexibility of an ESB in performing the transformations, routing and interconnection between legacy and new, Web-services based applications is unlikely to disappear.
We can expect even closer integration of Web services and other service-oriented architectures with ESBs, as well as closer integration with application servers. This tight integration has positive benefits for application server-based applications. You can use an ESB for Web-services delivery, whether as service consumer, provider or intermediate, while also improving implementation efficiency.
For these reasons, adopting Web services in conjunction with an ESB can help preserve your software and hardware investments. New applications can be written more easily using Web services because of modern development tooling and its improved usability. At the same time, these new capabilities can be combined, or integrated, with existing IT infrastructure and applications. As a result, an ESB can enable you to consider exploiting past investments in infrastructure and applications. Similarly, new investments in Web services-based applications are preserved as your organization’s infrastructure evolves.
About the Author
Stephen Todd studied mathematics at Oxford from 1965 to 1971 and later went to the IBM UK Scientific Centre in Peterlee (GB), where he specialized in digital image generation with large quantities of data. From 1979 to 1981, Todd researched at the IBM Research Laboratory in San Jose (USA) and returned to England in the late 1980s, where he again accepted a visiting professorship at an English college. His collaborations with William Latham began in 1987 while doing research at the IBM UK Scientific Centre in Winchester. He joined the IBM MQ (Messaging and Queuing) team in 1992, where he has been working especially on the interactions of messaging with its environment; including databases, transactions, and Web Services.More by Stephen Todd
IBM is the world's largest information technology company, with 80 years of leadership in helping businesses innovate. Drawing on resources from across IBM and key IBM Business Partners, IBM offers a wide range of services, solutions and technologies that enable customers, large and small, to take full advantage of the new era of on demand business. For more information about IBM, visit http://www.ibm.com.