A new August Community build (CTP3) is available on the ESB Guidance on ESB Guidance community site.
The CTP3 build introduces some new and augmented features such as “messaging” level end point resolution support for UDDI, WS-MEX, BRE and more (BizTalk Maps can also be executed in pipelines using the same resolution methods). This release also adds support for the WCF adapter, UDDI publishing and queries and much, much more.
Congratulations to Marty and the entire ESB Guidance team!
Are there any plans to move MS from the centralized (BizTalk) ESB to the decentralized model?
http://udidahan.weblogs.us/2007/06/30/no-such-thing-as-a-centralized-esb/
The Hub-and-Spoke style just seems like a dead-end (for the same reasons they dont use a single hub for the entire IP network at the office). I wish MS would step up to bat on this (or clarify if I am just off my rocker).
Evan,
You are correct - ESB requires a distributed bus pattern, not a centralized server. The Microsoft ESB Guidance uses BizTalk but does not require a centralized BizTalk server - this would make no sense since it wouldn't be a bus pattern. I encourage you to take a look at the documentation at the link above or, better yet, download the guidance and test out some of the sample appplications.
The Microsoft ESB Guidance consists of several samples and components including:
The ESB Core Engine, which integrates the services and provides agents for generic and custom orchestrations, transformations, and message delivery
ESB Core Services, such as:
The Resolution and Adapter Provider Framework, which supports dynamic transformation, dynamic routing, and dynamic end-point resolution
The Exception Management Framework, which provides unified exception management for Orchestrations, NACKs, and BizTalk Failed Message Routing
ESB Support Components and Services, such as pipeline components, map resolution services, and a comprehensive client application for developing and testing solutions
An ESB Management Portal, which publishes exceptions and supports an "edit and resubmit" capability for failed operations
Sample Applications that demonstrate common scenarios:
The Context On-Ramp sample demonstrates sending messages to an ESB application through an On-Ramp Web Service.
The Repair and Resubmit Custom Exception Handler sample demonstrates a custom exception handler that allows users to view a failed message process, edit the message, and resubmit it for processing. It includes examples of both strongly typed and loosely typed exception handlers.
The Message Persisting Custom Exception Handler sample demonstrates a custom exception handler that stores the failed message in a disk file, serialized for rendering within an InfoPath template.
The BizTalk Failed Message Routing ESB Processing sample demonstrates the ESB capabilities for capturing exceptions that occur during any stage of a BizTalk application. This can include failed routing or parsing messages of any type (such as PDF, flat file, binary, and XML).
The JMS MQRFH2 Component sample demonstrates the integration of IBM MQ Series systems with Microsoft ESB Guidance applications. This sample demonstrates how to receive JMS messages, access and edit the JMS headers within BizTalk, and send the messages back to JMS through MQ Series.
The Namespace Component sample demonstrates the addition and removal of namespaces from a message. This sample implements four different uses cases that demonstrate various techniques for removing a namespace, or building a namespace dynamically for the inbound document.
The Transformation Service sample allows external applications to submit a document to the ESB and have it transformed using a map deployed within BizTalk, without persisting the message in the Message Box database. Installing this sample deploys maps that the ESB Client Application uses.
The Dynamic Resolution sample resolves destinations using various resolution methods, and routes messages to the corresponding target. This sample demonstrates use of the Resolver and Adapter Framework through the Dispatcher Pipeline Components. It also demonstrates use of the Transform Pipeline component in both one-way and two-way (Request-Response) pure messaging scenarios. This sample implements fifteen uses cases demonstrating various resolution and transformation options.
Again, download the docs or better yet install and test-drive the samples before you make a decision about the guidance.
John,
I have gone through all the steps you've indicated. However, the docs and samples talk more about a load-balanced farm of biztalk servers that still serve as a logical broker, than a true distibuted solution. Such a solution would have some kind of agent at each endpoint - as some of the competing vendors have implemented.
Regardless, it's always a pleasure to read your thoughts on the matter and look forward to continuing the conversation with you.