Designing a right Enterprise Service Bus for your organisation
Connecting systems, people, processes, and things has become a key business imperative today. Therefore, the technologies that facilitate this integration are fast emerging as the #1 priority for most CIOs and CTOs. The recent buzz around ESB Enterprise Service Bus is therefore quite natural. However, this buzz is matched by the ambiguity with which the term is defined. This blog is an attempt to give you an overview of the basic terminologies, architecture, ESB functions, and different implementations around the concept of an ESB architecture.
ESB Enterprise Service Bus is a standardized integration platform that combines messaging, web services, data transformation, and intelligent routing, to reliably connect and coordinate the interaction of a significant number of heterogeneous applications with transactional integrity. It can also be defined as a software architecture model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA).
In the absence of an ESB oriented architecture, heterogeneous systems can be integrated by using an alternate architecture (as shown in the image). This ESB architecture is, however, difficult to scale and maintain. Also, adding a new application would mean interface customizations of all other interacting applications/systems.
The ESB Architecture:
In an ESB architecture, applications are indirectly connected via ESB, rather than being directly connected to each other. ESB Enterprise Service Bus is responsible for all the embedded logic needed to make the systems interact/integrate.
ESB Core functionalities
Below are some of the core functionalities of an ESB oriented architecture:
- Decoupling — One of the most important things that you can do via ESB is to decouple clients from service providers.
- Transport Protocol Conversion — ESB gives you the ability to accept one input protocol and communicate with another service provider on a different protocol.
- Message Enhancement — ESB allows you to isolate the client and make some basic changes to the message. For example, changing date format of incoming message or appending informational data to messages.
- Message Transformation — ESB lets you transform an incoming message into several outgoing formats and structure. For example, XML to JSON, XML to Java objects.
- Routing — ESB has the ability to redirect a client request to a particular service provider based on deterministic or variable routing criteria.
- Security — ESB protects services from unauthorized access.
- Process Choreography & Service Orchestration — ESB manages process flow and complex business services to perform a business operation. Process choreography is about business services while service orchestration is the ability to manage the coordination of their actual implementations. It is also capable of abstracting business services from actual implemented services.
- Transaction Management — ESB provides the ability to provide a single unit of work for a business request, providing framework for coordination of multiple disparate systems.
Some of the popular ESB Enterprise Service Bus implementations are:
- Jboss ESB (http://www.jboss.org/jbossesb/)
- Apache Servicemix (http://servicemix.apache.org)
- Open ESB (http://www.open-esb.net/)
- Mule ESB (http://www.mulesource.org)
- JBoss Fuse (http://www.jboss.org/products/fuse)
Each of the above mentioned ESB Enterprise Service Bus implementations offer different functionalities. It is advisable to pre-define your specific needs, and then evaluate which product is best suited for you. In order to choose a particular ESB Enterprise Service Bus implementation which best suits your requirements, you may use the following criteria:
- Usability — How complicated is the installation? How many tools are needed? Is the development environment intuitive?
- Maintainability- How do you administer the product? Is there a GUI for monitoring the services?
- Functionality- Are all the required functionalities offered?
- Flexibility- Can you customize functionalities of the product to fit your needs?
- Expandability- Is it possible to expand the product? Is the product and its interfaces based on standards?
- Enterprise Support- What support options are offered (“business hours”, “24/7” hotline vs. Email vs. on-site support, etc.)? Can the required service level agreements be guaranteed? Is support offered in your preferred language?
- Community- Are there active public forums or mailing lists? Are numerous articles, tutorials, and videos available? Is the product supported by several companies?
- Connectors- Are adapters for all required technologies available? Are there adapters for B2B products such as SAP or Salesforce? How easily can you build your own adapter?
- Cost- What is the full cost (total cost of ownership) of the product — including maintenance, all required ancillary products, connectors, etc.?
- Licensing- What licensing or subscription model is used? What happens when requirements change (more computers, more CPUs, switching to virtual machines, etc.)? Are upgrades available for free? Are downgrades possible, too? Are the costs “foreseeable” at all, is the price list even understandable?
Adaptive Web Services for Modular and Reusable Software Development: Tactics and Solutions -By Ortiz, Guadalupe and Javier Cubo
Originally posted in HCL tech blog. Read here.