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
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.
Applicability of ESB
The applicability of ESB is quite enormous. As ESB is a quicker way of realizing SOA; it is applicable wherever SOA is applicable.
Network management systems
ESB can be used to provide a consistent management interface for monitoring the health of various network elements like routers, hubs, switches, and so on.
Telecom
ESB can be used to expose telecom assets sich as SMS gateways and MMS gateways as parlay-X Web services, thus increasing the productivity as well as opening up of assets to external partners.
ESBs also can be used to integrate with OSS and BSS systems of a network operator.
Supply chain management
ESB can be used to publish and subscribe documents/events in the SCM system, integrate with back-end products, and provide content-based routing and transformation to process various documents.
Finance
ESB can be used asynchronously to process the trade order system and other applications via Web service interfaces.
ESB Vendors
Various vendors provide ESB. Existing middleware vendors, messaging system providers, Web service container providers, and J2EE container providers have ESB on their roadmap. Some of them are listed below:
- Cape Clear ESB—http://www.capeclear.com/products/
- Sonic ESB—http://www.sonicsoftware.com/products/sonic_esb/index.ssp
- Fiorano ESB—http://www.fiorano.com/products/fesb/fioranoesb.htm
- SeeBeyond eInsight—http://www.seebeyond.com/software/ican.asp
- Iona Artix—http://www.iona.com/products/artix/welcome.htm
- PolarLake ESB—http://www.polarlake.com/en/html/resources/esb/index.shtml
Conclusion
The purpose of this article is to introduce the basic concepts and a typical architecture of an ESB. Enterprises are moving towards standards-based integration technologies such as ESB, which offers them a highly scalable integration infrastructure solution. The complexity of traditional integration frameworks has been overcome by ESB. ESB helps enterprises scale in a more rapid fashion, without compromising reliability and performance. The purpose of this article is to introduce the basic concepts behind ESB. The authors are sure that the next wave of things to happen in EAI domain would be ESB because it standardizes and moves towards SOA.
References
What Is an Enterprise Service Bus?
http://www.forrester.com/Research/Document/Excerpt/0,7211,35193,00.html
ESB definition at LooselyCoupled.com
http://looselycoupled.com/glossary/ESB
Mule—ESB Messaging Framework
http://mule.codehaus.org
The Enterprise Service Bus: Building Enterprise SOA
http://developer.bea.com/pub/a/2004/12/soa_ibarra.html
About the Authors
R Venkatavaradan has been working as a solution and product architect in various domains ranging from middleware, J2EE, and Web services to telecom and mobility. He has a Masters Degree from the School of Automation, Indian Institute of Science, Bangalore. He has about 14 years of industry experience. His field of work ranges from signal processing to Web services, J2EE, Enterprise Application Integration, and so forth. He has extensively worked on Web service technologies such as WSDL, SOAP, and UDDI, and provided technical consultancy to various projects in the field of mobile, telecom, and EAI, which have been architected based on Web service concepts. He can be reached at venkatavaradan@gmail.com.
Arulazi Dhesiaseelan is a senior developer for Hewlett-Packard Company, India. He has a Master’s Degree in computer applications from PSG College of Technology in India. He has about five years of industry experience. He was involved in the UDDI4J project hosted at http://uddi4j.org. He has extensively worked on Web service technologies such as WSDL, UDDI, and SOAP. Currently, Arulazi is involved in developing ANA (adaptive network architecture)-based solutions for securing enterprise networks. He can be reached at aruld@acm.org.
