Tom Hollander has a series on how to get MSMQ, WCF and IIS to work in a mulit-server scenario; this is an extension to an earlier post about a pub/sub message bus using WCF and MSMQ.

1. Part 1: basic setup: no security, no transactions, single server
2. Part 2: advanced setup: transport security, no transactions, multi-server
3. Part 3: final setup: transport security, transactional, multi-server

Notice how little you have to change in code, to switch from having your service listen on http to having it listen to a remote MSMQ and supporting transactions. This really shows how robust and powerful WCF is.

Last week I was at the MS SOA & BP conference on the Microsoft campus in Redmond, the overall theme of the conference focused on the ESB (Enterprise Service Bus) and ISB (Internet Service Bus) powered by BizTalk server and biztalk.net respectively. Another theme was the focus on modeling, allowing developers to focus more on business problems and less on the plumbing.

The keynote

The keynote focused on the next wave of products for building Service Oriented Applications, called "Oslo", focused on modeling business processes and exposing them on the service bus. This modeling is currently done by different people using different tools, but the next version of Visual Studio will allow business analysts, architects, developers and operations to work on the different views of the same model using the same tool (Visual Studio).

The products included in "Oslo" are:

• BizTalk Server “6” – Process Server, based on Workflow Foundation and Windows Communication Foundation
• BizTalk Services (biztalk.net) – Internet Service Bus, authentication, communication and workflow outside the firewall
• Visual Studio "Rosario"
• System Center “5” – Operations – infrastructure support
• .NET Framework 4.0

Other sessions

Steve Swartz and Clemens Vasters had 4 great sessions (SA 208, SA 209, SA 310, SA 309), using the demo shown during the keynote about event planning, they show how they build it using modeling and the biztalk.net ISB. Since the same sessions are planned for TechEd Europe, the slides or the video should be on the web soon.

Don Smith showed the next version of the Web Service software factory called the modeling edition (Session FT 206). This release allows you to model your WCF services with a tool similar to the current class diagram and generate code based on that, instead of the previous versions, that generated code first. More info and the download on the Service Factory homepage on Codeplex.

Other interesting sessions were the overview session on Biztalk 2006 R2 (FT 309) and several deep dive sessions about WCF adapters (FT 400), testing Biztalk solutions (FT 306) and error handling (FT 201).

Channel 9 coverage

ARCast.TV - App Of The Future: The Internet Service Bus (Part 1 of 2)
ARCast.TV - App Of The Future: The Internet Service Bus (Part 2 of 2)
ARCast.TV - SOA Business Process Conference Day 1 Recap
ARCast.TV - SOA and Business Process Conference Day 2 Recap
ARCast.TV - SOA and Business Process Conference Recap - Day 3

Part 2: Adding Soap headers to the client

Adding headers to the client is even easer than adding them to the server, which I showed in part 1: Adding Soap headers to a webservice. As you can see the headers are also added to the WSDL and the wsdl.exe tool or the VS webreference wizard will add them to the proxy.

<wsdl:binding name="Service1Soap" type="tns:Service1Soap">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" /> 
    <wsdl:operation name="HelloWorld">
      <soap:operation soapAction="http://tempuri.org/HelloWorld" style="document" /> 
      <wsdl:input>
          <soap:body use="literal" /> 
          <soap:header message="tns:HelloWorlduserNamePasswordHeader" 
                                      part="userNamePasswordHeader" use="literal" /> 
      </wsdl:input>
    <wsdl:output>
        <soap:body use="literal" /> 
    </wsdl:output>
  </wsdl:operation>
</wsdl:binding>

If that doesn't work or the headers are not in the wsdl, you can add the property manually and associate the header with the method using the soapheader attribute. This works exactly the same as for the server.

WebClient.zip (8.59 KB)

Update 23 Oct. 2007: Replaced the zip with a version which compiles.

There are a number of reasons you may want to add custom headers to a SOAP message:

• Passing security information outside the body, so the code handling the security is uncoupled from the business logic;
• Adding timestamps;
• Everything else which is not actually part of the message, but is required for/used by the infrastrcture.

Luckily adding custom Soap headers is easy in the .NET framework.

Part 1: Adding SOAP headers to a webservice

After creating your basic webservice.

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service1 : System.Web.Services.WebService {

   [WebMethod]
   public string HelloWorld() {
       return "Hello, world!";
   }
}

And defining your soapheader; any xml serializable class, deriving from SoapHeader.

[XmlRoot("userNamePasswordHeader")]
public class UserNamePasswordHeader : SoapHeader {

   public UserNamePasswordHeader()
       : base() { }

    [XmlElement("userName")]
    public string UserName;

    [XmlElement("password")]
    public string Password;

}

Hooking everything up is straightforward. One way is to add a field or property to the webservice class to hold the soapheaders and add the soapheader attribute to the method to associate the headers to it. Adding the unknownheaders fields allows the method to intercept the undefined headers. This results in the following class:

public class Service1 : System.Web.Services.WebService {

    [WebMethod]
    [SoapHeader("UserNamePasswordHeader")]
    public string HelloWorld() {

        string userName = this.UserNamePasswordHeader.UserName;
        return "Hello, " + userName;
    }

    public UserNamePasswordHeader UserNamePasswordHeader;

    public SoapHeader[] UnknownHeaders;
}

Offcourse you can use the value of the headers in the method call, but usually you want to process the headers in a soap extension.

A soapextension, a class deriving from the SoapExtension class, can also be used to add headers to response messages, by adding them in the ProcessMessage method during the BeforeSerialize stage.

public class TimeStampExtension : SoapExtension{

    public TimeStampExtension()
        :base(){}

    public override object GetInitializer(Type serviceType) {
        return null;
    }

    public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute) {
        return null;
    }

    public override void Initialize(object initializer) {
        // do nothing
    }

    public override void ProcessMessage(SoapMessage message) {
        
        switch( message.Stage ){
            case SoapMessageStage.BeforeSerialize:
                  AddTimeStamp(message);
                  break;
            default:
                // do nothing
                  break;
        }
    }

    private void AddTimeStamp(SoapMessage message) {
        message.Headers.Add(new TimeStampHeader());
    }
}

Seting up the soap extension is done in the web.config file.

<configuration>
  <system.web>
    <webServices>
      <soapExtensionTypes>
        <add type="WebService.TimeStampExtension, WebService" group="High" priority="2"/>
      </soapExtensionTypes>
    </webServices>
  </system.web>
</configuration>

Source: WebService.zip (4.63 KB)

This is a short walkthrough on how to get the REST and POX sample from the Vista SDK to work on IIS. I assume VS 2005 with SP 1 and IIS 5.1, but the changes required on IIS 6 are the same.

Before we begin make sure you have .Net 3.0 installed and either the Vista SDK or the WCF Samples. And IIS, with the mappings for Asp.Net and WCF.

The sample we'll modify to work with IIS is located in "TechnologySamples\Scenario\PoxMessaging\CS" directory. And since there are no code changes the VB sample should work too.

First load the solution and make sure the it actually compiles and works, so we have a known base system we can work from. Do this by first starting the server and next the client, if you don't get any un-handled exceptions, then everything works, so we're good to go.

Next create a new Web Application Project, names ServiceHost in the solution and make sure it uses IIS for hosting in the Properties Web tab.

Remove all files VS created in your new project, except for the web.config and copy all files from the service project, except for program.cs and app.config. Finally add a reference to the System.Runtime.Serialization and the System.ServiceModel assemblies. Now the project should compile, but won't do anything interesting.

To register the endpoint, we have to copy the serviceModel configuration from the app.config in the service project to the web.config. So add the following to the web.config file:

 










contract="Microsoft.ServiceModel.Samples.IUniversalContract" />

This is the same as the config in the app.config, with the baseAddresses node removed, since those are supplied by IIS.

Now add a new file to the web project named: "customers.svc" with the following content:

<%@ ServiceHost Language="C#" debug="true" service="Microsoft.ServiceModel.Samples.CustomerService" %>

Save all files and if you surf to http://localhost/servicehost/customers.svc/customers/1 , you should see the following:

http://tempuri.org/Customer" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

Do note how the "/customers" part maps to the endpoint you specified in the web.config and the "/1" to the id of the customer. If you leave off the "/1" you should get a list of customers.

Which indicates the GET HttpMethod is working, to get the other methods working, we have to make some changes to the IIS configuration. In the properties of the ServiceHost virtual directory in IIS, click the Configuration button.

Now find the .svc mapping in the Application Mappings, click Edit and select "All Verbs".

That's all there is to it. To test it you'll need to make some changes to the client project, to make sure it uses the correct URLs to access the service. See the attached solution for details.

 POX-REST-IIS-Sample.zip (11.69 KB)