BizTalk 2009 : BizTalk Endpoint Management (part 2) - Endpoint Virtualization & Operation Versioning

3. Endpoint Virtualization

Now that you understand the basics of the MSE, let's take it one step further. Assume the MSE catalog repository has been filled with both your BizTalk-based WCF orchestrations as well as non-BizTalk services, or even non-Microsoft-based web services. All these operations need to be published to endpoint(s) to allow consumers to call them. Without the MSE, each application would need to have multiple service references to all required services, which would create a mess of intertwined endpoint configurations to manage.

Instead, MSE can help "virtualize" an endpoint. Endpoints in MSE are any combination of operation contracts (web methods) from one or more backend services dynamically created to expose a single view. For example, consider you had five backend services totaling 50 operations. Application A is being built that needs to use one operation from each of the five services. Instead of Application A adding five service references, a single virtual endpoint can be created in MSE to combine the five operations into a single MSE endpoint.

Figure 3 shows how individual methods can be virtualized into an application endpoint providing a simplified operational and development view into how services are used.

Figure 3. MSE endpoint virtualization

The design pattern from Figure 3 provides multiple benefits:

• Applications have to know only about their required operations and not be cluttered with operations that are not applicable to them.

• Virtual endpoints can have their own binding and policies allowing for application-level security.

• Messages can be routed through many tiers without requiring each application to have direct connectivity to all services.

• Backend service security can be defined once between the MSE and the service and not between each of the applications and the backend services.

For BizTalk orchestrations, this virtualization is very beneficial. Typically an orchestration contains one operation that is the only operation published in the WCF Service Publishing Wizard. Therefore, providing a mechanism to combine multiple WCF Service orchestrations into a single endpoint can simplify a large number of orchestrations URLs into a simple single view.

4. Operation Versioning

Another advantage to using MSE is the ability to support versioning of an operation. Instead of having multiple operations, each performing the same business logic but having different method contracts, the MSE can support transforming a request from one version to another and back again.

In the earlier section called "The Problem with WSDL," we described a problem whereby organizations would create methods similar to the following to support different method signatures for an operation:

[ServiceContract]
public interface IMathService
{
    [OperationContract]
    int AddIntegers(int IntegerA, int IntegerB);


    [OperationContract]
    int AddIntegersArray(int[] Integers);
}

Instead, wouldn't it be better to have a single AddIntegers(...) method that was always the "current" version and have the ability to transform between legacy operation contracts? This is where the power of MSE really shines. Whenever an operation is published, it is marked with two properties: Published and Active. Figure 4 shows the MSE screen displayed when you associate an operation to an endpoint.

Figure 4. Adding an operation to an endpoint

At any point in time, only one version of an operation can be Published, meaning that when a new application downloads the application metadata, it will receive the Published version, which guarantees they always receive the most current version.

At the same time, multiple versions of the same operation can be Active. This way, any existing applications that have been previously bound to an older version of the WSDL can continue to work without breaking.

Take, for example, Figure 5, which describes how version 1 of a service was exposed via MSE to Application A. If a new version of the service is available and the old definition is still required to be Active, then an XSLT must be provided to transform between the old version to the new and back again. Figure 6 shows how MSE transforms the message to and from the new version.

Figure 5. Version 1 of a service

Figure 6. Transforming the message

This model also has significant benefits to BizTalk developers. Our maps can get very complicated, and supporting multiple versions of different schemas within an orchestration can get very complex and error-prone. Although this could be accomplished using multiple maps on a receive port, externalizing this functionality into a service governance tier can help simplify the BizTalk deployment, and the pattern can also be leveraged for non-BizTalk services.