Well….the project is humming a long….more cool things we’re doing. Here’s an email I sent out to some folks in the community
Announcing – August 2007 Community Release (CTP3) of ESB Guidance – http://www.codeplex.com/esb By Marty Wasznicky As a result of our ongoing partnership with Patterns & Practices, we’ve released a new August Community (CTP3) build of the ESB Guidance on ESB Guidance community site, where all future iterations will be released until our final release in October later this year. The CTP3 build introduces some new and augmented features such as: New Resolver and Adapter Provider Framework provides “messaging” level end point resolution support for UDDI WS-MetaDataExchange Business Rules Engine XPath STATIC Messaging level Transformation services (uses new Resolver Framework). Allows BizTalk Maps to be executed in pipelines based on the following resolution methods UDDI WS-MetaDataExchange Business Rules Engine XPath STATIC Request-Response support for on and off ramps (partial) WCF Adapter integration UDDI publishing and query service BizTalk runtime query service New Dynamic Resolution Sample Third party SOA Management and Governance integration: SOA Software Integration ESB Guidance documentation in CHM format J The August 2007 CTP3 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 all 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, Amberpoint and SOA Software. 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 with the framework 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 in 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 these 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. A more thorough description and screen shots of the SOA Software integration with BizTalk can be found below. Cheers! Enterprise-level applications must support robust and reliable management features in order to comply with business requirements, Government legislation, service level agreements (SLAs), and customer and trading partner expectations. The SOA Software Management Point for BizTalk Server 2006 is an extension to SOA Software’s Web Services Management Point, applied specifically to the BizTalk Server 2006 environment, providing run-time governance for any BizTalk application regardless of transport. The Management Point integrates natively with SOA Software Service Manager and Workbench products. Unlike the typical Web Services Management Point, this implementation is associated with services provided by BizTalk environment, expressed in terms of BizTalk server Receive Locations and Send Ports. Due to the arbitrary nature of Receive and Send Ports (configured against a variety of BizTalk Adapters) these services are not necessarily associated with Web Services, but can be treated as such in terms of the SOA Service Manager and SOA Workbench. Figure 1 shows the SOA Service Manager Web application displaying the Workbench page for an example application. The left-hand tree view allows users to navigate through the applications and services installed within BizTalk, while the right-hand pane allows users to view application details, operations, access ports, categories, rules, and monitoring information. Figure 1 The SOA Service Manager showing the monitoring features available in the Workbench page You can monitor all the operations within an application (all Send Ports and Receive Locations), or specific operations, and the Workbench shows a list of the messages passing through the selected Send Ports and Receive Locations. When you double-click on a message in the list, the Workbench displays details of the message, and its context properties (provided that recording is enabled). Alternatively, you can select a specific service and monitor in real time messages passing through that service. The SOA Service Manager provides Wizards that help you set up the SOA Service Manager for use with BizTalk Server. For example, Figure 2 shows Wizard that helps you install and configure the BizTalk Integration Point that links BizTalk Send Ports and Receive Locations to the SOA Service Manager. Figure 2 The SOA BizTalk Integration Point installation and configuration Wizard After installation, the Service Manager can display details of the Send Ports and Receive locations configured by the Wizard. Figure 3 shows the Operations page displaying the name, interface, policy, and number of virtual operations for three Receive Locations and a Send Port. Figure 3 A list of BizTalk Send Ports and Receive Locations displayed by the SOA Service Manager The SOA Service Manager provides a mechanism that allows you to create and edit monitoring policies. For example, Figure 4 shows the screen for applying a policy template and activating monitoring for an application. Figure 4 The SOA Service Manager showing the monitoring features available in the Workbench page The SOA Service Manager also provides usage information for applications, services, and individual Send Ports and Receive Locations. This information includes charts displaying the relative usage of each operation and usage over time, service usage, and response time information. Figure 5 shows some example. Figure 5 A selection of the charts that the SOA Service Manager can generate to assist in monitoring server and application behavior and performance In addition, SOA Service Manager includes features that allow you to view details of individual messages, including the size, response time, operation name, and the associated SOAP messages, as well as any exceptions that may occur in the BizTalk runtime environment, as shown in Figure 6. Figure 6 The SOA Service Manager showing details of an individual message SOA Software Service Manager and Workbench products are products from SOA Software, Inc. that integrate with BizTalk Server 2006. For more details of SOA Software and their products, and to download the latest installation and operational instructions, see http://www.soa.com/
Field Program Manager, Connected Systems Division
BizTalk Integration
Monitoring Policies and Usage Information