WCF: namespaces in WSDL

2008-07-20T21:50:00Z

I've been working with WCF services a lot lately and I always specify namespaces for my service- and data-contracts. But I noticed that - by default - the WSDL of such a WCF service is generated in two parts:

a part that resides in the namespace "http://tempuri.org/",
a part that resides in the namespace I specified for the service.

The first WSDL contains an import of the second one. This also results in two separate .WSDL files when you download the meta-data (I leave any generated XML Schemas containing the data-contracts out of it in this post).

Although this works fine, I wondered whether or not it is possible to combine these WSDL files in to one file that uses the namespace I specified for my service, and get rid of this ugly "tempuri" namespace. And guess what, this is easy!

Here's an example of a service I will use to demonstrate how to do this:

           [ServiceContract(Namespace = "urn:wcfsamples:mywcfservice")]  
public interface IMyWcfService  
{  
   [OperationContract]  
   string GetData(int value);  
}  
                
// implementation of the service  
public class MyWcfServiceImpl : IMyWcfService  
{  
   public string GetData(int value)  
   {  
      return string.Format("You entered: {0}", value);  
   }  
}

This must look familiar. Now, to make sure the WSDL that is generated for the service (once you created a host) consists of only one part that resides in the specified namespace, you must take the following steps:

Add a ServiceBehavior attribute to the implementation-class, and specify the service's namespace.
Add the bindingNamespace attribute to all (non meta-data exchange) endpoints you configured for the service.

Example of step 1:

           [ServiceBehavior(Namespace="urn:wcfsamples:mywcfservice")]

Example of step 2:

Finally, here's a fragment of the WSDL that is generated for the service:

<xml version="1.0" encoding="utf-8" ?>
<wsdl:definitions name="MyWcfServiceImpl" targetNamespace="urn:wcfsamples:mywcfservice" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http:// ...

That's it. When you now download the meta-data for this service, you get only one .WSDL file. Exactly what I wanted.

I hope you find this information useful. And remember: let's keep our WSDL tidy!

Service Versioning with the Managed Service Engine

2008-04-18T10:25:00Z

While checking out Microsoft's SOA website, I found an application called the Managed Services Engine (MSE). In the accompanying description I read that this application offers so called "Service Virtualization". In the list of features I found one that I was particularly interested in: service versioning. So I decided to check it out. For the MSE a Codeplex project has been created where the tool can be downloaded. I downloaded the bits and installed them. It comes with a clear installation manual I followed without any problems.

The MSE consists of two parts:

Service Catalog – which handles the administration of the services.
Service Runtime – which hosts the services.

Both parts are implemented as a Windows service. The service catalog can be administered using the supplied MSE management console snap-in. The idea behind the MSE is that you create and host end-points in the MSE which in turn calls existing services to handle the implementation. That’s where the term "virtual services" comes from. In this blogpost I’d like to zoom in on a killer feature: service versioning. For every service operation that you define in the MSE, multiple versions can be defined. The MSE has a MessageBroker component which will call the appropriate implementation for a certain version based on the incoming message. Let’s assume the following situation:

The AddIntegers operation on the CalculatorService expects 2 integers as arguments and returns the sum of these integers as result. The AddIntegerArray operation on the AdvancedCalculatorService expects an array of integers as argument and returns the sum of these integers as result. In the MSE catalog, two versions of an operation called AddIntegers is defined. Obviously, the 1.0 version is handled by the CalculatorService and version 1.1 is handled by the AdvancedCalculatorService.
But how can we call a specific version of the AddIntegers operation? This is easy. You just call the AddIntegers operation and pass it a message that corresponds with the expected schema of the version you want to call. For example: if we want to call the 1.0 version, we would sent the following message (SOAP headers have been omitted for clarity):

<AddIntegers xmlns="urn:infosupport-com-calculator"> <x>4</x> <y>8</y> </AddIntegers>

But if we want to call the 1.1 version, we send the following message:

<AddIntegerArray xmlns="urn:infosupport-com-advancedcalculator"> <inputValues> <int xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays">4</int> <int xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays">8</int> <int xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays">5</int> </inputValues> </AddIntegerArray>

This way 1.0 clients and 1.1 clients can both call the AddIntegers operation and the MSE makes sure the appropriate implementation is called. In the WSDL of the service, only 1 version of a certain operation is published at a time. The MSE management console offers some cool features to configure stuff like this. For example, you can specify which versions of a method are active and which version is actually published in the WSDL, simply by setting some check-boxes and radio-buttons:

Another cool feature is the ability to retire the implementation corresponding to a specific version of an operation, while keeping the version available on the virtual service. Say - for example - we need to take down the CalculatorService but we have several existing clients that call the 1.0 version of the AddIntegers operation. We can make this happen by instructing the MSE to send requests for version 1.0 to the AdvancedCalculatorService. Every version of an operation in MSE is equipped with a so called ChannelMoniker which specifies the address of the implementation service and the action that is to be called on this service for a specific version. By changing the address and action for version 1.0 you can make it point it to the AddIntegerArray operation on the AdvancedCalculatorService. Additionally we can specify an XSLT with which the MSE will automatically transform the incoming 1.0 request to an 1.1 request and do the same for the response (from 1.1 to 1.0). Once this is done, you can bring down the CalculatorService but still call the 1.0 version of the AddIntegers operation on the virtual service. I think that’s pretty cool.

In this blogpost I’ve focused on service versioning, but the MSE has more features in store. Whether you’re able to employ the MSE - as is - in your current project or you need some inspiration because you’re building some sort of service framework, I think it’s worth investigating.

Have fun!

Edwin van Wijk

WCF: namespaces in WSDL

Service Versioning with the Managed Service Engine