BizTalk 2009 : BizTalk Endpoint Management (part 1) - The Problem with WSDL

It is always easy to integrate the initial application consuming a service. That's because the service is typically built for that specific application. But as the 5th, 10th, or even 50th application wants to join in using the service, any slight change to the original service can have exponential impact on testing as the number of consuming applications grows.

Changes to services are just one of many problems that you'll encounter as service-oriented architectures continue to grow. Without a common infrastructure focused on manageability, most SOAs become an unwieldy mess of intertwined services. These out-of-control services can end up negating the entire benefit of a service-oriented architecture. That's where the Managed Services Engine comes into play. It helps you gain and keep control over services and manage their change over time.

1. The Problem with WSDL

In today's environment, WSDL is static. It describes a service in its current form. Any changes to the service require a new WSDL to be published. Depending on the change, it can break existing applications.

To address this, organizations typically don't change existing services but rather create a duplicate method or possibly even a completely duplicate service. For example, let's assume we have a math service that has the following data contract:

[ServiceContract]
public interface IMathService
{

    [OperationContract]
    int AddIntegers(int IntegerA, int IntegerB);
}

This contract works fine for the first application, but the next application may need to support adding an array of integers. The only way to do add that support without breaking the first application would be to add another version of the same method that supports an array of integers. For example:

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


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

Although this example of adding support for new requirements is overly simplified, the problem becomes very large for both development teams and operationally as the number of methods changes over time. Typically organizations won't even know which applications use which version(s) of methods, so determining what methods to deprecate can become overwhelming if not impossible due to risk.

2. Where Does the MSE Help?

The Managed Services Engine sits in front of all services and acts as governance tool for understanding the end-to-end communication dependencies of all applications and services. Quickly, administrators can easily see via the Windows Presentation Foundation–based interface how components of the SOA relate to each other. Figure 1 shows an example of the Managed Services Engine WPF interface.

Figure 1. MSE user interface

The interface in Figure 1 is broken down into the groups described in Table 1.

Importing a WCF service into the MSE is as simple as running through a wizard. Start the wizard by selecting Tools Load Resources Web Service Metadata. Provide the wizard with the URL to the web service, and click Next to have MSE start reading the web service metadata. Figure 2 shows that MSE has detected the schemas, resources, and operations that are defined in the WSDL. The MSE will compare the schemas, resources, and operations against what is already defined in its catalog repository and import only the objects that are not yet defined.

Figure 2. MSE Web Service Metadata Import Wizard