ESB/SOA
ESB stands for Enterprise Service Bus is a mechanism by which messages are transported between a client and a service. Messages are transmitted as a flow wise and ESB brings that concept of forwarding requests and response such as transformation and routing to a Service-Oriented Architecture. Just removing the Enterprise Service part from ESB, Bus content denotes as a broker which provides services between applications. Unlike web services in SOA, there is no need of using point to point connection and SOA based scheme naming methodologies such as WSDL for slandered format for message passing, SOAP as a transmit protocol and UDDI as a deployment directory. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.
When ESB receives a message from a consumer, it has to route the message to appropriate application which may cause some practical issues unless you may use a bus which works fine for homogeneous systems. So when considering the protocols, message models, data type and etc using in various languages and platforms, ESB will have to transform the message into a format that the application can interpret. Then only responsible reply, most probably response from expected server can be achieved.
ESB provides the following facilities
- Message querying capabilities
- General agnosticism to operating-systems and programming-languages; for example, it should enable interoperability between Java and .NET applications
- Message routing
- Message transformation
- Adapters for legacy system
- The ability to apply business rules uniformly
- A standardized security-model to authorize, authenticate and audit use of the ESB
- Enriching messages from other sources
- Support for web-services standards
- Support for various Message Exchange Patterns (for example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe)
- Facilitation of the transformation of data formats and values, including transformation services (often via XSLT or XQuery) between the formats of the sending application and the receiving application
- The provision of a unified abstraction across multiple layers
In below i have added some useful links related to ESB/SOA and BPM
Part 01
DownloadPart 02
Key benifits of ESB
- Faster and cheaper accommodation of existing systems
- Increased flexibility; easier to change as requirements change.
- Standards-based
- Scales from point-solutions to enterprise-wide deployment (distributed bus).
- Predefined ready-for-use service types.
- More configuration rather than integration coding.
- No central rules-engine, no central broker.
- Incremental patching with zero down-time; enterprise becomes “refactorable”.
Above Key benifiits denoted are extracted from this link http://usmanshaheen.wordpress.com/2010/02/28/what-is-an-esb-and-when-to-use-one/
As i mentioned above if the system is likely used in a homogeneous environment, no need to have ESB at all. Routing and requesters may be achieved on a peer to peer basis. The benifit of an ESB is that it eases the process of creating SOA, within the boundaries of an ESB, support for multiple protocos and data transformation enables heterogeneous services to behave as they were homogeneous. Adapters allow us to expose legacy systems as reliable and secure messaging and queuing is also available through straight forward configuration rather than coding.
Programming for an ESB usually involves a visual environment, representing the logic as a flow of connected activities called a message flow or mediation flow. These flows are transactional, using mechanisms such as two-phase commit, so that the entire flow can be rolled back in the case of a failure, or committed in the case of success. These flows are stateless; in general, a message comes in, the flow performs various operations on the message, then an outgoing message is sent.
Given the stateless transactional nature of an ESB, high performance is a given. It's not uncommon for an ESB to handle millions of messages each day in a large organization.
Comments