Introduction to Enterprise Service Bus DISTRIBUTED SYSTEMS RESEARCH GROUP http://nenya.ms.mff.cuni.cz CHARLES UNIVERSITY PRAGUE Faculty of Mathematics and Physics
What s the problem? o deploy disparate applications, platforms, and business processes o non-compatible data formats and noncompatible communications protocols Solution: Enterprise Service Bus (ESB) refers to a category of middleware infrastructure products or technologies, based on Web services standards, that enable a service-oriented architecture via an event-driven and XML-based messaging engine (the bus).
The Enterprise Service Bus An enterprise service bus (ESB) is a centralized, scalable, fault-tolerant, service-messaging framework that: Provides a transparent means for communicating with heterogeneous services over a diverse set of message protocols. Provides a shared messaging layer by which enterprise applications, services, and components can connect and communicate. Can transmit messages synchronously or asynchronously to service endpoints and intelligently transform and secure the message content to meet the requirements of each service endpoint. Should provide sophisticated error recovery, allowing for failed message delivery, scalability problems, duplicate messages, network failure, etc.
Minimum Requirements of ESB Message delivery The minimum capability requirements of an ESB as a message delivery system: Transforms messages from one format to another to accommodate the requirements of registered service providers Routes messages to registered services while providing defined Quality-of-Service (QoS) and Service-Level features Augments message content with information such as additional metadata about the message requester. Augments the message protocol to meet service provider requirements. Notifies registered message listeners of specific message requests Secures delivery of messages by enforcing authentication, authorization, non-repudiation, confidentiality, etc.
Transforming ESB Messages An ESB must be able to transform data into a common data format to enable effective communication between disparate applications, components, and services.
Routing ESB Messages An ESB should be able to determine the destination of a given message based on a number of factors Some of the mechanisms used for ESB message routing are: XML-based content routing Proprietary object-based routing, such as that used by JMS. External routing, where message routing is configured externally, and is therefore disconnected from the message content.
Itinerary based routing mechanism
Content based routing mechanism
Notifying Message Listeners An ESB should provide message-based listening capabilities to enable secured management of the message traffic and content.
Securing Message Delivery An ESB should provide security for each message-request, including authentication, authorization, nonrepudiation, confidentiality, and enforcement of security standards such as Kerberos and WS-Security.
The Decentralized Nature of an ESB An ESB should be designed modularly, around a decentralized model to be able to scale effectively to meet any messaging demands placed on it. Each runtime engine consists of: An administrator. A destination-based list of mediators. A namespace directory.
ESB Administration Each runtime engine retains an administrator that handles management functionality such as service provisioning, service registration, service discovery, message logging, metering, and monitoring.
Mediation of ESB Messages Each runtime engine also retains a list of mediators; each mediator is always associated on a one-to-one basis with a destination. After transforming, augmenting, and securing each message, the mediator routes the message to the destination.
Enterprise Fault Tolerance Some of the failure scenarios: Destination cannot be reached Message too large Message corrupted
ESB Capabilities
Monitoring ESB
Message History
ESB - implementation ServiceMix ESB (LogicBlaze) based on JBI Mule ESB Celtrix ESB Sonic ESB - Sonic ESB V6.1
Service Characteristics Reusable, Business-Level Building-Blocks Coarse-Grained Level of abstraction easily understood by business people Granularity critically affects usability! Event-Enabled Interfaces Easily composed into Event-Driven Business Processes Multi-Language No development restrictions Generalization of Web-Services Standards-based WSDL interfaces
Service Composition Unified Business/Technology Views Easy change-management, extensibility Logical design maps directly to the physical implementation Business Process model is the implementation Loosely-Coupled Service Composition Dynamically setup and auto-reconfigured middleware Event-Driven Business Processes Dynamic extensibility, change-management
Sonic ESB - Supply Chain process
Questions? Thank you for attention.