La CTP d'août 2007 de l'ESB guidance pour Biztalk 2006 R2 (c'est quoi déjà l'ESB Guidance ?) intègre le support de WCF. Ainsi les rampes d'accès en entrée et en sortie de l'ESB reposent désormais sur WCF plutôt qu'ASMX au bénéfice de la simplicité des développements et de la flexibilité de la configuration (support des protocoles WS-*, gestion des modes de transport, d'éncodage..). De plus, finies les pénibles phases de génération des proxy client pour consommer des services, grâce au dynamisme de WCF (entendez la ChannelFactory).

Seconde nouveauté : l'ESB Guidance supporte des scénarios de type requête / réponse avec des hautes performances, en évitant le recours à des orchestrations. Cette fonctionnalité est qui plus est extensible grâce à un framework de résolution et de fournisseur d'adaptateur (entendez le Resolver & Adapter Provider Framework). Ce framework permet ainsi de découpler le consommateur du fournisseur du service et préfigure l'utilisation de policy au niveau du traitement des messages.

Par ailleurs, la CTP3 intègre deux services de gestion opérationnelle de l'ESB, à savoir le "Biztalk Query Service" un service d'interrogation de la configuration et de l'activité, et un service de gestion des entrées dans l'annuaire UDDI.

Dernier bonus : la CTP3 permet d'intégrer l'ESB Guidance aux outils de gouvernance d'Amberpoint et de SOA Software. Je vous invite à regarder de plus près l'offre de ce dernier partenaire qui met les bouchées pour supporter et compléter les fonctionnalités de management proposées par l'ESB Management Portal.

Les nouveautés telles que présentées dans la documentation de l'ESB Guidance

This August 2007 CTP release focuses on the incorporation of Windows Communication Foundation (WCF), Request-Response Messaging, and the introduction of the Resolver and Adapter Provider Framework. The latter provides the runtime resolution and transformation support to enable both one-way and request-response pure messaging scenarios. The former (specifically the BizTalk WCF adapter) makes it possible. Hence, key to this release, is the continued refactoring and integration into BizTalk Server 2006 R2—scheduled for release in September 2007. Additionally, we are releasing several infrastructure-based services to support our ongoing development work for the ESB Management Portal, as well as for two key SOA Governance partners.

Our first goal was simply to ship WCF Adapter versions of our existing On-Ramps and Services, so that—over time—we could retire the older ASMX versions. WCF offers many advantages over ASMX, with the separation of interface and implementation being just one. WCF, specifically the WCF Adapter within BizTalk, goes a long way towards providing full Web Service WS* support for customers, without the need to write significant code. The WCF adapter makes WS-Security and WS-AtomicTransactions as easy as enabling a checkbox. More importantly, its loosely typed nature enables the use of true dynamic-resolution Web Services with BizTalk. This removes the requirement for generating and referencing SOAP Proxies compiled into .NET assemblies for routing to every resolved end-point (as was the case prior to the introduction of the BizTalk WCF Adapter).

Our second goal was to develop a robust architecture for high performance yet flexible runtime resolution and transformation at the messaging level, without the need for the existing Orchestration-based services developed in previous releases of the ESB Guidance. This architecture is required to support full Request-Response pure messaging scenarios. It must also support customers who want to develop their own resolution methods and plug them into our architecture, without having to rewrite our existing code.

The result is the Resolver and Adapter Provider Framework, which supports dynamic loading, caching, and invocation of registered Resolvers. The Resolver determines the end-point configuration and URI, given certain facts. The Adapter Providers then set the specific properties of a BizTalk Adapter. Adapter Providers leverage the same dynamic loading, caching and invocation mechanisms as Resolvers. This framework goes a long way towards enabling us to provide simple messaging scenarios, such as “transform-validate-route”, with all the configuration and information externally driven by policy from a registry or custom repository. Our primary goal was to develop an architecture that could separate the consumer from the service, enabling us to move towards more policy-driven messaging scenarios.

Our third goal was to develop and introduce some comprehensive, Web-based infrastructure services that both our ESB Management Portal and other third parties can query and leverage. The first of these services, the BizTalk Query Service, exposes BizTalk application, service, messaging, and health information. This service provides users with the ability to ask questions such as:

  •  "What applications are deployed?"
  •  "Where are they deployed?"
  •  "What servers are they running on?"
  •  "Which services are running and which are stopped?"
  •  "Which host is the service running under?"
  •  "What server is the host running on?"
  •  "Is the host started on server B or server A?"
  •  "Give me a list of the services deployed since 1/1/2007."


The second of the new services, the UDDI Service, supports querying and modifying the registration information stored UDDI based registries. 

Finally, we pursued the development of tighter integration with key SOA Governance vendors such as Amberpoint and SOA Software. Customers should not be forced to regard these, as well as our, technologies as isolated "black boxes" with one not able to leverage the features and functions of the other. A seamless integration experience, where one leverage the assets of the other, provides greater synergy, reduces complexity, and will lower the total operational cost of the solution. This can provide immediate benefits to our customers. For example:

  •  SOA Governance tools and analytics can extend, and provide end-to-end visibility and tracking for the BizTalk native messaging subsystem and solutions; providing customers with a “one management view” of the solution.
  •  BizTalk can enable SOA Governance vendors to become “transport-agnostic”; providing a functional transport bridge, rules, and orchestration technologies for customer solutions.  
  •  Integration of the technologies can provide centralized enforcement and management of end-points and policy across the entire solution, regardless of the transport or technology (such as WS*, FTP, FILE, MQSeries, JMS, SAP, Tibco, Peoplesoft, or Siebel) it uses.


We have been working with Amberpoint and SOA Software for several months and are now starting to see the results of our efforts. In fact, SOA Software has almost completed development of their integration code that demonstrates end-to-end SOA governance monitoring and policy enforcement within BizTalk. In this release, we include some of the documentation regarding the new SOA Software Management Point for BizTalk, as well as some screenshots and the URL of their web site where you can obtain more information. Ultimately, I believe that the team accomplished the goals we set out for this release. We look forward to active feedback from all our users.