ESB Book - New Cover

The book "Modern ESB Architecture for SOA" I am writing together with Mark and Arnaud now has a new and final cover.

End-of-time Prophecies on Middleware, SOA, ESB and else

When Nostradamus pronounced and published his famous prophecies in the 16th century he did not need to worry about target consumer categories. His predictions - some of them interpreted as end-of-time prophecies or just plagues, earthquakes, etc. - where all-encompassing. Unfortunately, none of his writing was ever interpreted as predicting an event before it actually ocurred. :-)

So, what about those target consumer categories? I came across these when reading an excellent article by Steve Vinoski with the title "Is Middleware Dead? (IEEE Internet Computing, vol. 8, no. 4, 2004, pp. 94-96). This article is also about predictions -- in the technology and market domain this time.

Steve Vinoski wrote this article in response to "The End of Middleware", where Jonathan Schwartz of Sun touted middleware to be dead. The assumption behind this pronounciation: everybody would use Sun's Java Enterprise System then there would be no need to integrate with other middlewares. Of course, it did not pan out this way.

Similar pronouncements about the death of CORBA, SOA, ESB and many other technologies have been made. Steve points out that such predictions frequently do not take the target consumer category into account. According to Crossing the Chasm, there are five such categories in a technology adoption lifecycle (- innovators, - early adopters, - early majority, - late majority, - laggards).

When an "early adopter" feels that a certain technology is dead -- it may be alive and kicking from the point of view of the "laggard". One-size-fits-all solutions are therefore impossible. Where are ESBs on that adoption bell curve? Pretty much at (or slightly after) the peak, I'd say.

SOA-ESB book page & interview

Thanks to Thomas Erl for just setting up this brand-new page on the upcoming ESB Architecture for SOA book. There is an associated audio podcast on InformIT where Joe McKendrick interviews Mark Little and myself about some of the ESB-related patterns that made it into the SOA design patterns book.

Steve Jones on the Business Service Bus (BSB)

I've read the post about Business Service Buses (BSB) by Steve Jones and the associated GoogleDoc with interest. Steve describes how a enterprise-wide BSB mediates multiple lowever-level and more domain-specific buses (DSB). I've seen such a model (I call it "hierarchical ESB topology") used in practice by at least one client.

pro arguments:

• divide and conquer philosophy: hide and package structural complexity, only expose services to the upper level that are required there -- hide domain-internal services
  
• the bus infrastructure effectively models the organizational structure
  
• distributed governance -- i.e., each business unit can manage and control governance according to its particular requirements (also see the IBM article Choose an ESB topology to fit your business model)
  

cons:

• extra complexity ("middleware for your middleware")
• heterogeneous technology mix - leads to duplicate license costs, operational & maintenance costs
  

An alternative?
An alternative to the hierarchical ESB topology that Steve proposes would be the "intermediary layer" pattern: Only the business-unit or domain-specific services are encapsulated by an ESB or other type of intermediation layer (legacy wrappers or adapters, domain-specific intermediation services, XML appliances, etc.). This intermediation layer is necessary so that a standard SOAP + WS* protocol can be exposed to the upper level.

Instead of using the BSB one would then rely on the SOAP stack plus the advanced WS-standards to govern the reliability, security, availability, location, routing and other non-functional aspects of the message exchange. The endpoints exposed by the different intermediary layers would also need to agree on messaging patterns and on data formats (see www.soapatterns.org: canonical schema (158)).

I've modified Steve's diagram and replaced the BS with "SOAP and WS*" so that it looks like this:



Now I'd be really curious: what are the pros and cons of this alternative model compared to the original hierarchical topology pattern?

Microsoft ESB Guidance v 2.0 out

Congratulations to Dmitri Ossipov and his team. They've just released version 2.0 of the Microsoft ESB Guidance.

• MSDN site: http://msdn.microsoft.com/esb
• Community Extensions: http://codeplex.com/esb

From Adlai Maschiachs MS blog:

The Microsoft ESB Guidance provides architectural guidance, patterns, practices, and a set of BizTalk Server and .NET components to simplify the development of an Enterprise Service Bus (ESB) on the Microsoft platform and to allow Microsoft customers to extend their own messaging and integration solutions. The Microsoft ESB Guidance consists of a series of interoperating components that support and implement a loosely coupled messaging environment that makes it easier to build message-based enterprise applications. The services and components fall naturally into the following seven categories:

• Web services. These expose internal services such as itinerary processing, exception management, resolution of endpoints and maps, BizTalk operations, UDDI interoperation, and transformation of message content.
  
• Itinerary services and centralized store. These include agents for performing transformations and message delivery. You can resolve itinerary from the store and create custom services that participate in Itinerary processing.
  
• Itinerary on-ramps. These receive external messages using either SOAP or WCF. On-ramps expose the itinerary SOAP header and perform itinerary processing, using the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
  
• On-ramps. These receive external messages in a range of formats and transports, such as HTTP, JMS, WMQ, FTP, Flat File, and XML. They are typical BizTalk receive locations that optionally use the Microsoft ESB Guidance pipeline components and the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
  
• Off-ramps. These implement send ports for the delivery of messages using formats and transports such as SOAP, WCF, JMS, WMQ, FTP, HTTP, Flat File, XML, or any other custom formats. They are typical BizTalk send ports that optionally use the Microsoft ESB Guidance pipeline components and the Microsoft ESB Guidance Resolver and Adapter Provider Framework for dynamic resolution of endpoints and metadata.
  
• Exception Management Framework. This includes the exception Web service, the exception management API, and components that enrich, process, and pass exception details to the ESB Management Portal.
  
• ESB Management Portal. This provides registry provisioning, exception mediation, alert notification, and analytics.