I haven't been wholly convinced by the whole ESB motivation.

image

Andy Reay, colleague and Microsoft Architect, wrote to me recently in response. I really liked his reply so I quote it here with his permission

I see corporate wanting the following capabilities around their services:

  • -audit,
  • -policy enforcement,
  • -non-repudiation,
  • authorisation,
  • service orchestration,
  • service adaptation
  • flexible coupling of services,
  • - capacity management,
  • - integrity & availability.

It is certainly possible for some, or even all, of these capabilities to be implemented into service endpoints.

I assume we agree that as far as possible, these endpoints should be using a common implementation or framework, such as software factory based on WCF and backed with SQL Server for durability, failover support etc.

I agree that implementing these capabilities at the service endpoint is viable, especially in a green-field environment.

I believe however that finding such an organisation, one with the ability to service-enable all existing business applications and systems to common standards, would be quite rare.

In an enterprise where this is not the case, I believe there are often arguments for providing centralised implementation of these capabilities, and leveraging different communications protocols to realise certain services, e.g. One service might use SQL Server based messaging, while most may leverage Web Services.

Off-the-shelf products such as BizTalk provide high levels of robustness and scalability which remain hard to replicate, they also provide the adapter framework to become the service endpoint for many existing systems.

Leveraging such a product in whatever ways provide the quickest and most effective route to realising the value of SOA, agility, re-use etc. I believe is a good thing.

I also believe that in an enterprise above a certain size, or in a particular sector, centralised management and/or proof of compliance may also become a corporate mandate.

Having the option of delivering each capability using a centralised and/or distributed implementation, as is appropriate for the service/organisation makes a lot of sense to me. It’s all about having options.

I agree with his conclusion but I'm just not sure how many green fields one gets these days. I think its more about identification of reproducible patterns - ones that want to be kept for re-use. Any parts that can be reproduceable should be readily adapted.

Its similar to the notion that someday soon we may see all classes are services. Whether or not you may want to do this, whether its a good use of time, and whether or not there is tangible benefits is a topic for architectural debate and standards.

One mans architecture is another mans limitation.