BizTalk and Publish/Subscribe, EAI and the Enterprise Service Bus concept

So every-1 is talking about enterprise service bus architectures (basically pub/subscribe) and how that is a more cost effective and easier approach to EAI than the traditional hub/spoke model. Well first off, the notion of an ESB was first banded around by Sonic Software (of SonicMQ fame), and then legitimised by Gartner and more recently by IBM. Sonic have a product called Sonic ESB that they believe differentiates them from the traditional EAI vendors.

Their definition of an ESB as i could understand it is that it must have the following characteristics:-
- must be a 1st generation product (i.e. built after 2000)
- it must be built from the ground-up using XML, XSD, XSLT standards.
- MOM(asynch, pub/sub, store & forward) / Transformation / Content based routing.
- Highly connected (e.g. Web Services / J2EE)
- Monitoring (Helath and Activity Tracking)
- Distributed deployment.
- Single point of management / control.
- Location / Technology transparency.
- Fault Avoidance (ease-of-use) / Fault Tolerance (intelligent routing) / Redundancy.

In simple terms here is how ive differentiated ESB and EAI.
ESB - Simple intelligent routing, distributed peer-based architecture.
EAI - MOM, explicit routing, central hub, service broker.

On the face of things it looks like BizTalk 2004 has a lot of these features, but im not yet sure that BizTalk has a fully distributed deployment architecture that provides location transparency and a single point of management, i may be wrong - ( im just writing my current thoughts!), but i think the issue may related to how you can distribute BizTalk servers across an enterprise with multiple data-centers (over a WAN).

BizTalk 2004 has the concept of a BizTalk group (a domain or federated group in other words), which is effectively the scope for Administration, Routing, Message Tracking and all other services. All related BizTalk receive and processing servers are part of this scope. All servers within a particulary BizTalk group use the same MessageBox. This is an important point, since how and where you deploy your servers are impacted on the fact of the single MessageBox design.

Lets think about this, once a message is received (through the Receive Port and Receive Pipeline) it ends up in the MessageBox (where any meta-data like promoted properties of the schema are stored). Any interested parties ( whether its a map, rules engine, an orchestration or even a send port/pipeline) can subscribe to that message.

The MessageBox relies completely on SQL sever for its persistence, and since BizTalk does have a scale-out story by having multiple MessageBoxes (you still need to have a master MessageBox database - i am planning to test this.) you may be able to deploy those MessageBoxes in a distributed manner, although im not sure that is its primary design. I assume that it was designed to improve the scalability of the primary Master MessageBox. In any case there are better ways of improving the scalability, namely scale-up SQL Server (more on this later).

So BizTalk allows you to have multiple MessagesBoxes, you may be able to distribute these across the enterprise (although this may not be its primary design, and may introduce considerable latency issues), but assuming it does, it means that all the distributed BizTalk receive/processing servers can be part of a single BizTalk Group, and if that is the case you get the complete benefits of location transparency, and a single point of management.