Dennis van de Laar

WCF and IsWrapped MessageContracts

The IsWrapped property on a messagecontract is keeping me busy. When working with WSSF it’s forcing you to set the IsWrapped property to true when you have more than one element in your message contract. This is because this required by the WS-I Basic profile1.1 standard. So you set the property to true and don’t have any idea what this will do to the proxy which is generated for you. In this post i will describe four possible scenarios and there effect on the proxy which is influenced by the choice you make. The possible scenarios are summarized in the table below:

Well I desgined a simple service called CaseService. This service implements the ICaseService interface. This interface contains one operation RetrieveCase which accepts a casenumber (string) as input paramter and returns a Case object.

The messagecontract I used are: RetrieveCaseRequest and RetrieveCaseResponse.

Scenario 1

In this scenario I set the property IsWrapped of the RetrieveCaseRequest to true and the IsWrapped property of the RetrieveCaseResponse to false. When I build this service and generate a proxy for this service this will give me the following code (I stripped code which is irrelevant for this post):

public WCFService.Client.Proxy.Case RetrieveCase(WCFService.Client.Proxy.RetrieveCaseRequest RetrieveCaseRequest)
        {
            WCFService.Client.Proxy.RetrieveCaseRequest1 inValue = new WCFService.Client.Proxy.RetrieveCaseRequest1();
            inValue.RetrieveCaseRequest = RetrieveCaseRequest;
            WCFService.Client.Proxy.RetrieveCaseResponse retVal = ((WCFService.Client.Proxy.CaseService)(this)).RetrieveCase(inValue);
            return retVal.Case;
        }

The extra generated messagcontract

[System.ServiceModel.MessageContractAttribute(IsWrapped = false)]
    public partial class RetrieveCaseRequest1
    {

There are two Request MessageContracts generated: RetrieveCaseRequest and RetrieveCaseRequest1. The RetrieveCaseRequest1 is a wrapper for the RetrieveCaseRequest. It looks like that the proxy will balance the request and response to the same IsWrapped setting. They are both send over the line with IsWrapped set to false.

The proxy will send the RetrieveCaseRequest1 (IsWrapped=false) and will receive RetrieveCaseResponse (IsWrapped=false). The RetrieveCaseRequest method in the proxy will accept a request messagecontract as input.

Scenario 2

In this scenario we will switch the IsWrapped settings. For the Request it will be set to false and for the response it will be set to true. Scenario 2 will give us the situation which is vica versa of scenario 1. There is one Request MessageContract and there are two Response MessageContracts: RetrieveCaseResponse and RetrieveCaseResponse1. The RetrieveCaseResponse1 is used as a wrapper contract for the RetrieveCaseResponse. Also notice the input parameter of the method RetrieveCase in the proxy. It’s a CaseNumber (string) and not a messagecontract like in scenario 1. It will wrap it into a messagecontract before sending it to the service.

public WCFService.Client.Proxy5.RetrieveCaseResponse RetrieveCase(string CaseNumber)
        {
            WCFService.Client.Proxy5.RetrieveCaseRequest inValue = new WCFService.Client.Proxy5.RetrieveCaseRequest();
            inValue.CaseNumber = CaseNumber;
            WCFService.Client.Proxy5.RetrieveCaseResponse1 retVal = ((WCFService.Client.Proxy5.CaseService)(this)).RetrieveCase(inValue);
            return retVal.RetrieveCaseResponse;
 }

Scenario 3

In the third scenario i have set both message contracts (request and response) to false. This results in the following proxy method:

public WCFService.Client.Proxy3.Case RetrieveCase(string CaseNumber)
        {
            WCFService.Client.Proxy3.RetrieveCaseRequest inValue = new WCFService.Client.Proxy3.RetrieveCaseRequest();
            inValue.CaseNumber = CaseNumber;
            WCFService.Client.Proxy3.RetrieveCaseResponse retVal = ((WCFService.Client.Proxy3.CaseService)(this)).RetrieveCase(inValue);
            return retVal.Case;
        }
As you can see, it will  accept a casenumber as input and a case object as return parameter. The proxy will wrap a messagecontract around the type before sending it to the service and strips the messagecontract before returning the response to the consumer of the proxy. Remember that you don’t always have the option to set the iswrapped property to false. When your messagecontract has multiple elements it will need the iswrapped property set to true.

Scenario 4

In this scenario I will set for both the Request and Response messages the IsWrapped property to true.

public WCFService.Client.Proxy2.Case RetrieveCase(string CaseNumber)
{
            WCFService.Client.Proxy2.RetrieveCaseRequest inValue = new WCFService.Client.Proxy2.RetrieveCaseRequest();
            inValue.CaseNumber = CaseNumber;
            WCFService.Client.Proxy2.RetrieveCaseResponse retVal = ((WCFService.Client.Proxy2.CaseService)(this)).RetrieveCase(inValue);
            return retVal.Case;
        }

As you can see this scenario contains the same proxy method as scenario 3.

I have experienced three of the four scenarios on projects and i was wondering how is it possible that my proxy is looking different when i am switching the iswrapped properties. I hope that this post will give you some information about the iswrapped property and will give you some ideas when you are running in the same kind of proxies with different faces.

Regards,

Dennis

Building transactional services with WSSF

When you are familiair with the WebService Software Factory (WSSF) you probably know that this tool uses three kind of models to make developing services much easier:

• DataContractModel
• ServiceContractModel
• HostModel

In this post I would like to focus on the ServiceContractModel. This model generates messagecontracts and a servicecontracts. The servicecontract looks like a normal  interface where signatures of methods are defined. The only difference is that a servicecontract also contains two kind of attributes:

• ServiceContractAttribute
• OperationContractAttribute

The properties of both attributes can be modified with the designer of WSSF. One drawback of WSSF is that it’s not possbile to add more attributes to the servicecontract. When you want to build a transactional WCF service with WSSF you have to do some coding by yourself. This isn’t a problem, but the combination of writing your own code and generate code with WSSF could become a problem if you not doing it right.

There are a couple of steps you need to take before your service is supporting transactions. For a guide step by step take a look here. In this post I will only talk about how you should decorate your interface and how to do this with WSSF. In your interface you are able to determine which operation could join or start a transaction. Foreach operation who should be available for a transaction you should decorate the operation with a TransactionFlowAttribute.  

Adding this attribute should be done by hand. When you have decorated your interface correctly and followed the steps in the blogpost above, then your ready to go. But what happens when you have checked in your code and your colleague is working on the servicemodel and clicks on the generate button. You don’t get any errors, but you don’t see any transaction enlisted anymore in your Distributed Transaction Coordinator (DTC). One of the steps you need for a transactional service is removed from your code. The servicecontract is regenerated, this means that the old servicecontract with the TransactionFlowAttribute is replace with the new one generated by WSSF.

I could only think of one solution to avoid such an situation. The solution would be adding the TransactionFlowAttribute to the class (the service) who is also implemeting the interface. This isn’t a perfect situation, but it could avoid strange behavior in your transactional service.

Regards,

Dennis