October 31, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Enterprise Service Bus-Integration Demystified

  • June 9, 2005
  • By R Venkatavaradan & Arulazi Dhesiaseelan
  • Send Email »
  • More Articles »

Enterprise application integration (EAI) has become more realistic and pervasive since the advent of a service-oriented architecture (SOA). SOA has redefined the way businesses work. Integration is not an end; it is just a beginning to create a highly scalable integration infrastructure to seamlessly bind autonomous systems within an enterprise. The enterprise service bus (ESB) is the mantra for SOA-based enterprise integration.

Understanding ESB

SOA, or Service Oriented Architecture, is the buzz word today. SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.

An enterprise service bus (ESB) is a software infrastructure that enables service-oriented architecture (SOA) by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available. An ESB helps enterprises obtain the value of SOA by increasing connectivity, adding flexibility that speeds change, and providing greater control over use of the important resources it binds.

Features of ESB

Obviously, the definition of ESB is loose enough to bring in many players and projecting their products as ESBs. Having said that, ESB is a middleware, how to differentiate other middleware from ESBs is a million dollar question. Is it a simple messaging bus where messages can be published or subscribed? Or, is it a Web service platform where one can host Web services? Or, is it collection of XSL style sheets for transforming documents? Or, is it collection of industry standard adapters? Or, is it a chosen sum of all? The answer is yes and no.

If one looks at the reason for having ESB, probably the answer would become simpler. Integration traditionally has been difficult in I.T. systems. Various disparate systems exist ranging from mainframes and middlewares such as Tibco and Tuxedo, ERPs like SAP, Baan, and Oracle, and so forth. However, from the business and the end user perspective, what one wants to achieve or provide is an end-user service. The end-user service has to be realized and served using the resources existing in the enterprise in a simple manner. Newer and newer services have to be created quickly by the administrators. Administrators would ideally like not to know the intricacies of connecting to various systems/applications/services. For example, if there are services A and B, and one has to realize a service C that uses a combination of A and B, it should be as simple as connecting A and B using a graph. The middleware, call it ESB, should have Web service adapters to talk to different systems. In case they don't have one, they should at least provide an SDK or an Adapter Development Kit to realize the services. The above paragraph means that a lot of features are needed for ESB. Following are some of them.

Adapters

The middleware, call it ESB, should have Web service adapters that talk to different systems. In case they don't have one, you should at least provide a SDK to realize the service.

Transformation tools

The middleware should provide utilities or tools for transformation. It could be XSL-based transformation or SDK-based transformation. The transformation ideally should be UI driven and make life simpler for administrators.

Adaptive security

Support for adaptive and configurable security is a must. Security has to be provided at the messaging and transport levels. In the case of messages, it has to be standards based, such as WS-Security, XML Signature, and so forth. In the case of transport, it could be HTTPS.

Guaranteed messaging support

Messages get exchanged between applications. Some messages are to be persisted whereas some are not. Messages need to be retried in case of an application's unavailability. The message store should be configurable in terms of persistence, time of persistence, and so on.

Business process support

The middleware should support orchestration and business process flow to create higher-level services from lower-level services. The orchestration could be synchronous or asynchronous. It could be long lived or short lived. There should be support for compensating processes or services. Exceptions should be handled in a standard way. It should support standards such as BPEL.

Content-based routing and filtering

The middleware should support filtering and content-based routing. Based on the document's contents, the data should be routed to different services. Effectively, it means that the middleware should have a built-in filter.

SDK support

The middleware should have support for various languages. That is, the middleware's SDK should be available in at least well-known languages such as Java, C, Perl, and Python.

Reuse

The ESB middleware should leverage the existing system. If there is an existing message bus, it should be pluggable into the architecture. If there is a Web service container, it should leverage that for its purpose. It is possible, if the ESB itself is designed along the lines of SOA. Means, various features of ESB is realized using services that can be plugged and played based on deployment scenarios.

Standards

The support for standards is a must for ESB. This allows third-party services to become part of the ESB architecture. For example, if a third-party provider provides a mapping service, it should be made an integral part of the architecture so that it can be used during the definition of business services. Similar examples can be thought for a third-party "Security Service or Authentication and Authorization Service."

ESB exposed as a service

The ESB itself should be available as a service so that ESB-ESB integration and remote use of ESB is possible. For example, if an ESB1 is deployed in Enterprise A and another ESB2 in Enterprise B, ESB1 should leverage some of the services in ESB2 and vice versa. The communication between ESB should also be standards based, preferably SOAP.

Typical ESB Architecture



Click here for a larger image.

A high-level architecture of a typical ESB is depicted in the figure above.

The core of the ESB is the BPEL workflow engine. BPEL stands for Business Process Execution Language, an XML way of defining a business process that orchestrates Web services. The BPEL engine, to realize the end-user service, orchestrates among various services. These services could be business services realized via adapters or utility services like security, transformation, messaging, and the like. Adapters are meant to connect to back-end applications. Standard adapters like JCA, J2EE, SOAP, and .NET should be supplied with the products. For other adapters, an SDK in well-known languages like C, Java, and Perl should be made available. Channels provide an access mechanism for the services realized using ESB. The default channel should be SOAP or Web service based. There should be support for other channels such as JMS and SMTP. Here also, an SDK to plug-in custom channel should be provided by the vendor.

What is not shown, but part of a typical ESB, is the management infrastructure that allows viewing the status of services, service requests, applications, adapters, and so forth.





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel