The Microsoft BizTalk ESB Toolkit extends the functionality of BizTalk Server to provide a range of capabilities focused on building loosely coupled, connected service-oriented applications that incorporate itinerary-based service invocation and integration with SOA governance solutions.
Sentinet BizTalk Server Extensions enhance BizTalk Server ESB Toolkit capabilities by offering integration with Sentinet - the SOA Governance and API Management software solution for the Microsoft platform. Sentinet BizTalk Server Extensions version 1.0 offers advanced ESB Toolkit SOA Repository Resolver that integrates with BizTalk Server 2013/2013 R2, ESB Toolkit 2.2/2.3 and Visual Studio 2012/2013.
In this article I will describe how Sentinet Resolver extends ESB Toolkit capabilities, and then demonstrate how Sentinet Resolver can be used and tested in a sample use case.
ESB Toolkit is shipped with UDDI Resolver that integrates with the Microsoft UDDI Services and Registry. Unlike UDDI Registry that is limited in its capabilities, Sentinet offers robust and comprehensive SOA Repository that provides SOA Integration solutions with advanced SOA Governance and runtime Management capabilities. Combined with Sentinet SOA Repository, Sentinet Resolver provides BizTalk Server ESB architectures with advanced, and easy to use ESB configurations, dynamic messages routing and message security implementation capabilities.
The goal of an ESB Toolkit Resolver is to provide (among few other things) runtime resolution of service endpoints and their configurations, and ultimately to provide BizTalk ESB solutions with loosely coupled messaging. High-level diagram below shows where Microsoft UDDI Resolver and Sentinet Resolver fit in the ESB Toolkit architecture.
At runtime, Endpoint Resolution and Routing component (which is part of the ESB Toolkit Resolver Framework) uses Itinerary document (created in Visual Studio Itinerary Designer) to instantiate specific Resolver and to request Resolver to provide service endpoint and its configuration. Itinerary itself has to be configured with the reference to the service endpoint, so that resolver can use this reference to find requested endpoint in the Registry or Repository. At design-time (when Itinerary is created), actual physical address of the service endpoint is not known, neither what security policies service requires. ESB Toolkit runtime will later use resolved service endpoint to configure Off-Ramp dynamic Send Port that will send the message out to the actual physical service address with required service security settings. If service endpoint address, communication protocols or security requirements change – only Registry/Repository configuration has to be updated, but not the runtime configuration of the ESB or BizTalk Server artifacts.
So how is Sentinet Resolver and its SOA Repository, different from UDDI Resolver and its Microsoft UDDI Registry? To answer this question I will first start with few other simple questions, and then I will list all the most noticeable differences.
- What if resolved ESB endpoint requires specific client identity to call external service (like username/password, specific Windows account credentials or specific X.509 certificate)? This is a very common security requirement, but how can you configure UDDI Resolver/Registry with this identity? If you cannot do it – that will be the show-stopper and resolved endpoint will be useless. The answer - it is practically impossible in UDDI terms. I say “practically” because the effort of manually configuring UDDI tModels with complex XML that includes required identities (because that’s what it comes to) defeats the purpose of using SOA Governance in the first place.
- Even if you are able to find out what specific XML format has to be entered in the tModel, is UDDI Registry the right place to store the actual client identities? Definitely - not, because Registries/Repositories is the place to store and register your business services. Consumers of the services may use Repository/Registry to learn about identity types that are required to call provided services, but they should not be let know what specific credentials (like specific username/password) to use.
Unlike UDDI Resolver/Registry, Sentinet Resolver and Sentinet SOA Repository provides capabilities to flexibly and securely assign any specific client identity to the resolved ESB endpoint (via standard or custom WCF endpoint behaviors). And this is all done by configuring Sentinet Resolver, not the Sentinet SOA Repository (of course, all client credentials that are configured with the Sentinet Resolver can be stored encrypted).
Here is the list of additional benefits that Sentinet Resolver provides:
- Comprehensive SOA Repository.
- Ease of registering physical services.
- Comprehensive and yet simple to use Sentinet Administrative Console (browser-based Repository portal).
- Management and configuration of the resolved endpoints' custom behaviors.
- Sentinet Resolver can be configured with the variety of human-readable endpoint search criteria. Itinerary can define any keyword or human-readable identifier that was assigned to a service endpoint, or use a service path that points to a service in the Repository services hierarchy.
- Guarantee of unique resolution results.
- Advanced Resolver Testing capabilities. Sentinet Resolver configurations can be tested strait from the Visual Studio Itinerary Designer. Testing UDDI Resolver can only provide information about endpoint basic properties. These properties is what is needed by ESB at runtime. Sentinet Resolver provides extended information about resolved endpoints. In addition to endpoint basic properties, testing Sentinet Resolver reveals the properties that identify resolved service and endpoint location in the Sentinet Repository. Itinerary designers can test how Sentinet Resolver and its different search criteria affect resolution results before Itinerary itself is used at runtime.
Sentinet BizTalk Server Extensions are installed from a single MSI package. Once MSI is installed, you run Sentinet BizTalk Extensions Configuration Wizard application that helps to configure installation with secure connection to the Sentinet Server and its SOA Repository, and optional integration with Visual Studio Itinerary Designer.
Note, that Sentinet Resolver supports standard ESB Toolkit Caching, and additional configuration that provides guarantee of the Unique Resolution.
To see how Sentinet Resolver can be added and configured with itineraries, create a new itinerary, drop Itinerary Service shape configured with Messaging Extender, and add new Resolver. The Resolver Implementation property can now be configured with the Sentinet Resolver Extension.
You can now configure your Sentinet Resolver with properties that define flexible search criteria for the resolved Repository service endpoint, and service operation (by specifying Action property) that will be ultimately called by the ESB Off-Ramp service. You can immediately test your Resolver configuration and its search criteria by using Test Resolver Configuration menu option.
Unlike UDDI Resolver, Sentinet Resolver provides properties that define more intuitive endpoint search criteria such as service path in the Repository, service version and any combination of Keywords or phrases attached to the Repository service endpoint (ex: My ESB Endpoint will be used by the Sentinet Resolver to find required service endpoint as shows on the screenshot above). One of the most interesting property is the Resolved Endpoint Behavior where you can specify a named endpoint behavior that can add specific client identity to the resolved endpoint or any other custom behavior (for example the behavior can attach a custom SOAP header or add some other custom message processing). At runtime ESB Toolkit will attached WCF endpoint behaviors to the resolved endpoint. The behaviors are defined in the Sentinet Resolver central configuration file Sentinet.BizTalk.config, and they are referenced by itineraries by the behavior name property as shown below.
Sentinet Resolver configuration and its Repository search criteria can be tested right from the Itinerary Designer (see screenshot above). Unlike UDDI Resolver, testing Sentinet Resolver prints out not only the name-value collection of properties that will be used by the ESB at runtime, but also some additional details of the resolved endpoint. These details may be vital in determining if provided resolver configuration returns the intended Repository endpoint (but not some other endpoint that also happens to satisfy given search criteria).
Sentinet BizTalk Server Extensions package includes complete sample that demonstrates the use of the Sentinet Resolver by sending messages using sample itinerary and ESB Test Client application. The package, complete User Guide and sample Visual Studio project can be downloaded from here.
So what happens when you need to change Repository endpoint address, security policy and possibly even service identity so that itinerary continues to dynamically route messages to the new endpoint?
This is actually quite easy - Sentinet Repository Administrative Console provides very intuitive User Interface to access service structure (complete with service interfaces, operations and endpoints) with all the details of each service endpoint. Screenshot below shows part of the Sentinet Console with a CustomerSearch sample service registered in the Repository with the properties of the service endpoint. As soon as you change endpoint address, security policy or service identity - ESB will start routing messages to the new endpoint address and using new security policy.
The endpoint has one attachment, My ESB Endpoint keyword as shown on the screenshot below. If you move this attachment to a different endpoint (for example ep_serviceEndpoint2), ESB will also re-route messages to that endpoint because my sample itinerary above uses My ESB Endpoint keyword as a search criteria.
Sentinet BizTalk Server Extensions and Sentinet SOA Repository help to provide BizTalk ESB solutions with effective and loosely coupled messaging architectures.