I am working since some years on ESB projects. Some time ago we put in place an esb to leverage some important operation in an enterprise.
There is two needs to differentiate in an enterprise scope:
The first on is the ability of certain applications to publish functionalities as web services.
The second one is a real enterprise wide viewpoint on howto organize, manage and route message s flowing to these applications.
In my experience, you don’t real need an esb to respond to the first need, as you may as well doing so with classic tools and code. An esb platform often may help you to implement these features faster, more centralized, as it often comes with some etl features.
The second need will bring you to implement a real ESB. Doing so will force you to dig deeper in what the esb represent as concept. You will inevitably be implementing design patterns.
In this article I will present the most important ones:
Transform, log, route
• A common ESB aggregate pattern. Transform incoming messages (Transform), log them (Monitor), and Route to endpoints.
Protocol switch
• Enables service requesters to dispatch their messages using a variety of interaction protocols or APIs, such as SOAP/HTTP, JMS, and MQ Integrator (MQI).
• Transforms requests into the targeted service provider’s format.
• Can be applied at the requester or the provider end of an interaction, at both ends, or anywhere in between.
• Mediations of this pattern can often be created automatically when there is a clear definition of formats and their relationship to each other
Modifier
• Updates the payload of the message without any change to the context information
• Transformation subpattern
• Message payload is transformed from one format (schema) to another to match definition of a message of the requestor to that of a provider
• Includes “enveloping and de-enveloping,” which is the process of putting a message in one network format inside the format envelope needed for transmission over another network or corresponding removal of an envelope
• Includes encryption
• Enrichment subpattern
• Message payload is updated by adding information from external data sources such as custom parameters of the mediation or database queries
Router
• Changes the intended route of a message, selecting between the service providers associated with the mediation
• Examples: gold customers to alternate, higher-SLA providers
Discovery
• Queries ESB registry to discover a set of service providers that match requirements of the requestor, selects one, and routes the message to it
• An enhancement of the routing pattern:
• Set of possible service providers is not preconfigured at the mediation
• Providers match requestor’s message format, QOS required, or the protocol supported from the mediation to the possible providers
• Example: Data center failover scenario. Bring data center online, register services, route traffic to it without having to updating the configuration of every mediation
Distribute
• Distributes the message to a set of interested parties and is usually driven by the subscribers’ interest profiles.
Monitor
• Used to observe messages as they pass through the ESB without changing them in any way. Examples:
• Monitor service levels
• Provide data for problem determination
• Chargeback Metering
• Record business-level events (transactions exceeding a certain revenue)
• Log messages for audits
Correlate (complex event processing)
• Derives complex events from message or event streams. Includes rules for pattern identification and rules that react to pattern discovery, for example, by generating a complex event derived from content of the triggering event stream.
Canonical adapter
• Set of messages and business objects used by all parties is normalized to a canonical format. The canonical adapter pattern converts endpoints’ native bus-attachment protocols to a standard protocol, normalizes payload, and reverses these transformations upon delivery. This is an aggregate of Protocol Switch and Transform patterns.
Proxy or gateway pattern
• Variant of routing or protocol switch pattern which maps service endpoints, possibly providing security functions (authorization and access control) and logging or auditing capabilities.
• May incorporate transform and monitor mediations to provide encryption and logging, or auditing. It may also aggregate and disaggregate messages in a one-to-many relationship.
Example: Service portals which act as a single point of contact for multiple services and hide the details of “internal” services
