Wednesday, 18 June, 2008
Application Integration on an ESB!!
Introduction to an ESB:
In computing, an enterprise service bus (ESB) refers to a software architecture construct. This construct is typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards, which provide fundamental services for more complex architectures via an event-driven and standards-based messaging engine (the bus).
An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.
ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. Although it is a common belief, ESB is not necessarily web-services based.ESB should be standards-based and flexible, supporting many transport mediums. Based on EAI rather than SOA patterns, it tries to remove the coupling between the service called and the transport medium.
Concept of ESB in IBM's point of view :)
An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond. The ESB is not a new software product — it's a new way of looking at how to integrate applications, coordinate resources and manipulate information. Unlike many previous approaches for connecting distributed applications, for example RPC or distributed objects, the ESB pattern enables the connection of software running in parallel on different platforms, written in different programming languages and using different programming models.
Examples of the enterprise service bus patterns exist today, built using existing integration tools available in the IBM Business Integration portfolio of products. For a business, an ESB can manage connectivity needs by providing standards based application integration with support for Web services, message based transport and mediation (transformation and routing) oriented toward a service based infrastructure (often referred to as a service oriented architecture).
Application Integration on an ESB
Applications are integrated based on one or more of three relationships: Data Synchronization and Consistency, Multi-Step Processes, and Composite Applications.
ESBs support the implementation of all three integration patterns above. As such, an ESB forms the core backbone of any integration solution and all integration brokers have some form of an ESB embedded within.
The ESB : Key Middleware Infrastructure for Business Components
An ESB is a middleware platform that supports intelligent routing of information between business components distributed across a network. Unlike other platforms, ESBs support both request/reply as well as event-driven interactions between business components on a single technology base with a shared component model and common tools for design, development, deployment, security and administration.
ESBs have four important characteristics that distinguish them from other forms of middleware:
1. Communication - an ESB must support both request/response communication as well as one-way event-driven communication. Most ESBs typically support communication over a variety of protocols such as SOAP/HTTP and JMS among others. The better ESBs support distributed peer-to-peer communication for enhanced fault-tolerance and scalability, together with features such as store-and-forward.
2. Intelligent Routing and Mediation - an ESB must make it's client applications (i.e. business components) independent of each other by allowing the routing of data between components to be controlled externally. This is typically accomplished via routing rules that direct messages between business components connected to the ESB across the network. The better ESBs allow routing rules to be changed on-the-fly, allowing enterprise business processes to be modified dynamically in response to changing business conditions. The ESB serves as an intermediary between business components connected to the bus, allowing it to provide address indirection, rules-based routing and other features essential for the development of distributed applications.
3.Message Envelopes - an ESB must have a method of creating or accessing metadata that documents the request/reply and event-driven interfaces of business components that exchange information across the bus. ESB Metadata is typically represented in XML, with interface definitions in WSDL.
4.Web Services - an ESB must support basic Web-Services standards for communication, including WSDL, SOAP and XML over multiple transports.
Importantly, an ESB can be used not only for application integration but also for the development of general purpose distributed applications connecting business components created by independent teams of developers.
See you all with another excellent topic :)