Enterprise Service Bus (ESB) within an environment that includes Sitecore

How would/could an Enterprise Service Bus (ESB) work within an environment that includes Sitecore?

So on #slack I had a great conversation with another Sitecore genius. They are going down the road of implementing a service bus into their landscape.  So I took that conversation and thought I would blog about it. 

First of all, the definition of an ESB:
An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.
(http://searchsoa.techtarget.com/definition/enterprise-service-bus)

Layman’s terms: A tool that can centralize all or some service requests for one or more consumers from the service's source system.

Sitecore comes with a plethora of services via a great API suite.  Sitecore has its own data dictionary that may align with what your corporation needs or not.  Sitecore APIs for the most part mainly touches the Sitecore landscape.  Granted the pipeline customization ability is fantastic to touch other IT assets, but for arguments sake, out of the box Sitecore APIs really only affect Sitecore “stuff”.

In many of my implementations of CMSs (especially Sitecore – because it is supreme), the CMS is only one piece of the pie in each environment.  To tie all of the IT assets together most go with a design pattern that involves an ESB.  

Now this is where the meat of this blog begins.

Problem:

Let’s say we have a custom CRM, an Ecommerce platform, and a Tic-Tac toe score keeping system.  And most importantly your Sitecore CMS.  Many of those systems have exposed services for reusability and API capabilities.  These services can have versions, different contracts, etc that have different data models to adhere to.  How do we solve this potential traffic jam?

Solution:

Your options:

1. Keep track of it in your head (please retire, and enjoy your senile mind-hood which you have probably entered into at this point). Problem of a 1 to 1 contract for each function is needed from source system to consumer exists.
2. Keep up with them in a spreadsheet. (Usually it is recommended that after 50 services – it’s time to mature up a bit in your architecture). Problem of a 1 to 1 contract for each function is needed from source system to consumer exists.
3. Invest in an ESB to be the central hub.  The good ones come with a service registry to keep track of all endpoints and their respective versions.  The ESB usually comes with a translation and queuing layer as well for data model translation and queuing. Problem of a 1 to 1 contract for each function is needed from source system to consumer goes away.

Here is an example of #1 and #2 in play...

Here is an example of #3

Keep in mind, the ESB is a tool like any ole hammer.  Unless you know how to use it, it could be just another thing to nail a nail in.  

Also, this tool if too many people have access needs a bit of governance to ensure spaghetti doesn’t start to take place.  I like to eat spaghetti, but I don’t like to work with it all the time.

Whatever your design strategy is, I hope you follow the KISS principle.  Keep It Simple Silly!