Service-Mediation Scenarios

ESB espresso-coffee beans

Enterprise Service Bus and Espresso

One of the few really-good boutique coffee-roasters and espresso specialists in Auckland labels its beans “esb”, for “ethically-sourced beans”. It’s something of a stretch, but espresso is important and beneficial in fundamental, foundational ways not dissimilar to the importance and benefits an Enterprise Service Bus can bring to integrated organisations.

Enterprise Service Bus: Lifecycle and Hype

Enterprise Service Bus as a concept has suffered from largely-unhelpful and massive over-hyping, which began relatively early in the largely-unhelpful and massive over-hyping of everything related to Service-Oriented Architecture. This hype saw much blurring of the ESB architectural pattern with specific commercial ESB product implementations. In those early stages, an ESB-first and an ESB-or-bust ethos crept into a lot of SOA initiatives, with muddled low-or-no-benefit results.

With experience, the hype around ESB has rightsized and the use-cases have been established so the benefits of using the ESB pattern (and not using the ESB pattern) can be understood. This period of stabilisation was characterised by three significant ESB stakes in the ground:

  • 2008: ZapThink’s edict that service consumers and service providers must never communicate directly.
  • 2009: Gartner embedding the behavioural subcomponents of ESB within the SOA Backplane, at the heart of the SOA Application Infrastructure Reference Architecture.
  • 2010+: ESB patterns have become a natural, normal, and expected capabilities of application-integration stack, and there is fair expectation that some medium-and-larger packaged-applications will be shipped with ESB components either embedded within them or included as templates for open-source edgeware componentry. In turn, and likely accelerated by the rise and rise of as-a-service solution offerings, ESB federations will start to be based around quite small application-specific ecosystems, raising the ante on the needs for solid industry standards.

Enterprise Service Bus Mediation Scenarios

The ESB implementation i’ve been closely involved with has focused deliberately upon service-mediation as its primary reason for being, and has insisted on the ESB remaining fully stateless. Holding a lightweight approach on what’s expected of the ESB has enabled the foundational basics to be attended to, and for questions about orchestration, business-process-management, and longer-running integration use-cases to be deferred until they’re understood fully and their needs are well-described. In these service-mediation-first scenarios, the ESB has been brilliant. Some of the foundational use-cases where benefits have been delivered are outlined below.

  • Service Mediation: The basic layer-of-abstraction premise of raw service mediation remains the predominant benefit of the ESB architectural pattern. Service mediation provides insulation against change, flexibile interoperability, and support for versioning. In addition, ESB platforms support monitoring and management, security, and metrics-collection.
  • RESTful: Faced with legacy integration middleware incapable of dealing with RESTful web services, and needing to deliver messages into a RESTful-only packaged application, the ESB was configured to provide a WSDL-based web-service proxy to the RESTful endpoint.
  • Document Style: Faced with the rpc/encoded web-service provided by a government agency, the ESB was used to create a document/literal proxy service, managing the translations between the two, and enabling modern libraries to be used by the bespoke applications needing to call the agency’s web-service.
  • Security Injection: Faced with a third-party communications service structured aroud the concept of one-application-user-for-each-organisational-customer, but needing for security and for activity-based-costing reasons to separate out the calling users, the ESB was used to require username-and-password tokens for access to its proxy service. After validating the caller locally, a parameter was passed in the service calls to the third-party service, and that parameter appears in the billing reports, enabling costs to be apportioned internally, and forcing internal governance processes to be followed when new users of the third-party communications service are established.
  • Security Injection: Faced with the need to provide differently-privileged web-service clients with different sets of attributes from the calls to the same business services, the ESB was configured to pre-process web-service results through XSLT masks to obscure or remove attributes specific clients are ineligible to receive. For example, an identity web service might return attributes such as the IRD/ATO/SSN tax-file numbers, or birthdates, or information about disabilities. Using XSLT masks, only those clients entitled to receive those attributes are provided with them.

Selected Highlights


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s