All About Interop : WSDL

WSDL-First in WCF, versus WSDL-First in ASMX

DotNetInterop — Thu, 25 Sep 2008 18:25:00 GMT

I wanted to point something out regarding the WSDL-First item I posted yesterday.

This is a look at the interface generated by the SvcUtil.exe tool for WCF.

    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
    [System.ServiceModel.ServiceContractAttribute(Namespace="urn:Microsoft.Search",
         ConfigurationName="Ionic.Samples.Webservices.Sep21.IResearchServiceSoap")]
    public interface IResearchServiceSoap
    {
 
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Registration",
           ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Registration(string registrationXml);
 
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Query",
           ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Query(string queryXml);
 
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Status",
           ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Status();
    }

It looks quite similar to the interface that you can generate using the appropriate wsdl.exe tool if you would prefer to use the ASMX (or System.Web.Services) stack that first shipped in .NET v1.1, and continues to be available in .NET 3.5.

[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.42")]
[System.Web.Services.WebServiceBindingAttribute(Name="ResearchServiceSoap", Namespace="urn:Microsoft.Search")]
public interface IResearchServiceSoap {
 
    /// <remarks/>
    [System.Web.Services.WebMethodAttribute()]
    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("urn:Microsoft.Search/Registration", 
        RequestNamespace="urn:Microsoft.Search", 
        ResponseNamespace="urn:Microsoft.Search", 
        Use=System.Web.Services.Description.SoapBindingUse.Literal, 
        ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
    string Registration(string registrationXml);
 
    /// <remarks/>
    [System.Web.Services.WebMethodAttribute()]
    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("urn:Microsoft.Search/Query", 
        RequestNamespace="urn:Microsoft.Search", 
        ResponseNamespace="urn:Microsoft.Search", 
        Use=System.Web.Services.Description.SoapBindingUse.Literal, 
        ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
    string Query(string queryXml);
 
    /// <remarks/>
    [System.Web.Services.WebMethodAttribute()]
    [System.Web.Services.Protocols.SoapDocumentMethodAttribute("urn:Microsoft.Search/Status", 
        RequestNamespace="urn:Microsoft.Search", 
        ResponseNamespace="urn:Microsoft.Search", 
        Use=System.Web.Services.Description.SoapBindingUse.Literal, 
        ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
    string Status();
 
}

So as you can see, it is a very similar model. Different attributes support the different runtimes (System.Web.Services versus WCF), but it is very parallel.

WSDL-First development with WCF

DotNetInterop — Wed, 24 Sep 2008 18:36:00 GMT

A couple weeks ago I mentioned that you could do WSDL-First development with WCF, but I didn't go into detail as to how that would work. Somebody asked, so I guess I'll describe the specific steps. I want to use a real scenario, so for a WSDL, I will use the WSDL that Microsoft defines for Microsoft Office Research Services.

Did you get that? Microsoft Office defines a WSDL for Research Services. Any Microsoft Office program, Office 2003 or Office 2007, can call out to any service that implements the given Research Service wire contract. Office programs are web services clients. Ok, we're all clear on that, right?

And this it may be counter intuitive for some people. The client application, in this case, Microsoft Office, specifies the on-the-wire contract, the WSDL. Lots of people have a server-centric design perspective, and assume that the server defines the contract. That often makes sense, but not in this case. Because there are so many deployments of Microsoft Office out there, it makes sense for the client to define the contract.

Back to the WSDL. But let me be straight with you: on the website I referenced, I did not actually see a WSDL specifically defined for the Office Research Service. I'd expect to find it in the Schema Reference, but that reference includes XML Schema, not web services contracts. On the other hand, the Research Service SDK includes sample applications built on .NET and ASMX, and running those you can generate the WSDL that is being used. So... effectively the WSDL is implicitly published. I took some liberties with the WSDL available in that way and I came up with my own WSDL, like so:

<definitions
  xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:s="http://www.w3.org/2001/XMLSchema"
  xmlns:s0="urn:Microsoft.Search"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
  targetNamespace="urn:Microsoft.Search"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
>

  <types>
    <s:schema elementFormDefault="qualified" targetNamespace="urn:Microsoft.Search">

      <s:element name="Registration">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="registrationXml" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="RegistrationResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="RegistrationResult" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

      <s:element name="Query">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="queryXml" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>
      <s:element name="QueryResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="QueryResult" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

      <s:element name="Status">
        <s:complexType />
      </s:element>
      <s:element name="StatusResponse">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="StatusResult" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

    </s:schema>
  </types>


  <message name="RegistrationSoapIn">
    <part name="parameters" element="s0:Registration" />
  </message>
  <message name="RegistrationSoapOut">
    <part name="parameters" element="s0:RegistrationResponse" />
  </message>

  <message name="QuerySoapIn">
    <part name="parameters" element="s0:Query" />
  </message>
  <message name="QuerySoapOut">
    <part name="parameters" element="s0:QueryResponse" />
  </message>

  <message name="StatusSoapIn">
    <part name="parameters" element="s0:Status" />
  </message>
  <message name="StatusSoapOut">
    <part name="parameters" element="s0:StatusResponse" />
  </message>

  <portType name="IResearchServiceSoap">
    <operation name="Registration">
      <input  message="s0:RegistrationSoapIn"  wsaw:Action="urn:Microsoft.Search/Registration" />
      <output message="s0:RegistrationSoapOut" wsaw:Action="" />
    </operation>

    <operation name="Query">
      <input  message="s0:QuerySoapIn"  wsaw:Action="urn:Microsoft.Search/Query" />
      <output message="s0:QuerySoapOut" wsaw:Action="" />
    </operation>

    <operation name="Status">
      <input  message="s0:StatusSoapIn"  wsaw:Action="urn:Microsoft.Search/Status" />
      <output message="s0:StatusSoapOut" wsaw:Action="" />
    </operation>

    </operation>

  </portType>

  <binding name="ResearchServiceSoap" type="s0:IResearchServiceSoap">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

    <operation name="Registration">
      <soap:operation soapAction="urn:Microsoft.Search/Registration" style="document" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
    </operation>

    <operation name="Query">
      <soap:operation soapAction="urn:Microsoft.Search/Query" style="document" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
    </operation>

    <operation name="Status">
      <soap:operation soapAction="urn:Microsoft.Search/Status" style="document" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
    </operation>


  </binding>

</definitions>

Ok, starting with that WSDL, given to us by Microsoft Office, we now want to build a service that implements that WSDL, and we want to build it in WCF. We start with the svcutil.exe tool, which is shipped with the .NET SDK v3.0 , or later.

Continuing on with the thought from above: most people have a server-centric design perspective when it comes to web services; most people think the server comes first, then you build the clients...The svcutil.exe tool is also guilty of that. In fact there is documentation that describes how to build a client using the svcutil.exe tool, but as far as I know there is no doc that describes how to create a WCF service from a WSDL file using the svcutil.exe tool. We're going to fix that. Despite the fact that there is no doc for this, it is in fact a supported scenario. Constructing the service starting from the WSDL works.

Here's how you generate a server-side "stub" and the interface for that WSDL:

c:\netsdk3.0\bin\svcutil.exe /language:C# /out:IResearchService.cs /n:*,Ionic.Samples.Webservices.Sep24 ResearchService.wsdl

On the command line, I specify the output file, the language, and also the WSDL file itself. If there are external XSD files, you will need to specify those, too. In this case, the entire contract is contained within a single WSDL file. The last interesting bit is the /n switch, which I use to specify the namespace for all the generated classes. Without this switch the interface and the Data Access Objects are all generated into the default (global::) namespace, which I don't like.

You can see that I reference the .NET SDK v3.0 directory for the svcutil.exe tool. WCF first shipped in the .NET SDK v3.0. Even if you have .NET SDK 3.5 installed, (or Visual Studio 2008), you will still use the svcutil.exe from .NET 3.0. This is because of the russian-doll model of releases that .NET 2.0, 3.0 and 3.5 are.

Now, this is a command line, which is definitely not a GUI. But you can teach Visual Studio to do this for you. To do this, you need to go to the Tools menu, and select External Tools. Then click Add, and specify these settings for the svcutil tool:

Of course you have to specify the relevant path for the .NET SDK V3.0, for your installation. Regardless whether you run svcutil.exe from an MSbuild file, or from Visual Studio, here's what the generated interface looks like:

    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
    [System.ServiceModel.ServiceContractAttribute(Namespace="urn:Microsoft.Search",
        ConfigurationName="Ionic.Samples.Webservices.Sep24.IResearchServiceSoap")]
    public interface IResearchServiceSoap
    {
        
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Registration",
            ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Registration(string registrationXml);
        
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Query",
            ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Query(string queryXml);
        
        [System.ServiceModel.OperationContractAttribute(Action="urn:Microsoft.Search/Status",
            ReplyAction="")]
        [System.ServiceModel.XmlSerializerFormatAttribute()]
        string Status();
        
    }

The Office Research Service interface is a bit of a bummer, because the operations on this service interface just exchange strings. No complex types here. But trust me, it works the same if you use complex types in the interface. In that case, the output source file will include a .NET DataContract definition for the various complex types, along with XML namespace settings and so on. The silly thing is that the Office Research Service does actually send back XML. But rather than use xsd:anyType to allow any XML, or even a strictly-specified XML element, the office app just specifies a string. In effect, the XML is encoded as a string. When implementing the service, you would actually instantiate an XmlDocument and load in the string you get passed, if you know what I mean. This is normally something the web services runtime would do for you, if you specify your WSDL that way. But Office did not do that.

Ok, moving on.... Now, If you are sharp-eyed, you will notice that the command line to generate the server-side stub and interface is the same command line you would use for the Client proxy. And you're right. In fact if you look in the generated file you will find some client-specific proxy classes. No problem with any of that. For the client we need those proxy classes, but for the server we don't. In a server-specific project, that generated code will remain unused, or of course you could manually remove it from the generated file.

At this point, you have the interface. Now you need the implementation. In Visual Studio, if you begin to type in a class definition, and then type in a colon and specify the name of an interface, you can right click on that interface and ask Visual Studio to generate method stubs for all the interface methods. Perfect. As well, you will need to decorate your WCF Service class with the ServiceBehavior attribute. It looks like this:

    [ServiceBehavior(Name="WcfResearchLibrary",
                     Namespace="urn:Microsoft.Search",
                     IncludeExceptionDetailInFaults=true)]

After that, you fill in the implementation for those methods. Then you need to consider the service host for your app. If it will run in IIS, then you code up a .svc file; if you want to host it in a console app, then you use some of the boilerplate I mentioned in a previous post. And so on.

Then you need to deal with the configuration settings, another issue I dealt with in the previous post. And that's pretty much it.

You have now coded a WCF Service using WSDL-First design principles.

Flatten your WSDL with this Custom ServiceHost for WCF

DotNetInterop — Tue, 23 Sep 2008 18:32:00 GMT

Yesterday I mentioned using a custom service host to flatten the WSDL that is generated by a WCF service. This is something Christian showed us all how to do a long while ago, to improve interoperability between WCF-implemented services and consumers written on other technology stacks. Flattening WSDL is important for Interop purposes becausse many tools don't digest modular WSDL very well. When I say modular WSDL, I mean WSDL that imports other WSDL's or XSDs.

I realized that I had never actually published the code for my custom WCF service host that flattens WSDL.

So here it is. [updated 146pm US/Pacific time based on Natasa's comment]

using System;
using System.Collections;
using System.Collections.Generic;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.Xml.Schema;
using ServiceDescription = System.Web.Services.Description.ServiceDescription;
 
namespace Thinktecture.ServiceModel
{
    public class FlatWsdl : IWsdlExportExtension, IEndpointBehavior
    {
        public void ExportContract(WsdlExporter exporter, WsdlContractConversionContext context) { }
 
        public void ExportEndpoint(WsdlExporter exporter, WsdlEndpointConversionContext context)
        {
            XmlSchemaSet schemaSet = exporter.GeneratedXmlSchemas;
            foreach (WsdlDescription wsdl in exporter.GeneratedWsdlDocuments)
            {
                List<XmlSchema> importsList = new List<XmlSchema>();
                foreach (XmlSchema schema in wsdl.Types.Schemas)
                    AddImportedSchemas(schema, schemaSet, importsList);
 
                if (importsList.Count == 0)
                    return;
 
                wsdl.Types.Schemas.Clear();
                foreach (XmlSchema schema in importsList)
                {
                    RemoveXsdImports(schema);
                    wsdl.Types.Schemas.Add(schema);
                }
            }
        }
 
        private void AddImportedSchemas(XmlSchema schema, XmlSchemaSet schemaSet, List<XmlSchema> importsList)
        {
            foreach (XmlSchemaImport import in schema.Includes)
            {
                ICollection realSchemas =
                    schemaSet.Schemas(import.Namespace);
 
                foreach (XmlSchema ixsd in realSchemas)
                {
                    if (!importsList.Contains(ixsd))
                    {
                        importsList.Add(ixsd);
                        AddImportedSchemas(ixsd, schemaSet, importsList);
                    }
                }
            }
        }
 
        private void RemoveXsdImports(XmlSchema schema)
        {
            for (int i = 0; i < schema.Includes.Count; i++)
            {
                if (schema.Includes[i] is XmlSchemaImport)
                    schema.Includes.RemoveAt(i--);
            }
        }
 
        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { }
 
        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { }
 
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { }
 
        public void Validate(ServiceEndpoint endpoint) { }
    }
 
 
 
    public class FlatWsdlServiceHost : System.ServiceModel.ServiceHost
    {
        public FlatWsdlServiceHost() { }
 
        public FlatWsdlServiceHost(Type serviceType, params Uri[] baseAddresses)
            : base(serviceType, baseAddresses) { }
 
        public FlatWsdlServiceHost(object singletonInstance, params Uri[] baseAddresses)
            : base(singletonInstance, baseAddresses) { }
 
        protected override void ApplyConfiguration()
        {
            Console.WriteLine("ApplyConfiguration (thread {0})",
                              System.Threading.Thread.CurrentThread.ManagedThreadId);
            base.ApplyConfiguration();
            InjectFlatWsdlExtension();
        }
 
        private void InjectFlatWsdlExtension()
        {
            foreach (ServiceEndpoint endpoint in this.Description.Endpoints)            
                endpoint.Behaviors.Add(new FlatWsdl());
        }
    }
 
 
 
    public sealed class FlatWsdlServiceHostFactory : System.ServiceModel.Activation.ServiceHostFactory
    {
        public override System.ServiceModel.ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
        {
            return base.CreateServiceHost(constructorString, baseAddresses);
        }
 
        protected override System.ServiceModel.ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            return new FlatWsdlServiceHost(serviceType, baseAddresses);
        }
    }
}

And to use this, you would specify something like this in your .svc file:

<%@ ServiceHost
    Language="C#"
    Factory="Thinktecture.ServiceModel.FlatWsdlServiceHostFactory"
    Service="Ionic.Samples.Webservices.WcfService1"%>

Custom Config file for a WCF Service hosted in IIS

DotNetInterop — Mon, 22 Sep 2008 17:14:00 GMT

I am constantly developing new WCF services to try out various techniques, ideas, scenarios.

Many times for these quickie WCF applications I will just use a text editor to write the code. As you know there are multiple options for hosting your WCF services. For these quick apps, I will typically write a simple custom console host for the WCF service, what is sometimes called "self-hosting" the WCF service. You've seen some form of this boilerplate code many times:

        public static void Main()
        {
            string addressRoot= "http://localhost:5555/";
            string endpointSuffix= "MyWcfService";
            string endpointAddress= addressRoot + endpointSuffix;

            // get the type we are hosting 
            System.Type t1 = typeof(Ionic.Samples.Webservices.MyWcfService);

            var host = 
                new System.ServiceModel.ServiceHost(t1,
                                                    new System.Uri(endpointAddress));

            // Create the binding
            var basicBinding = new System.ServiceModel.BasicHttpBinding();
            basicBinding.Namespace = "urn:Ionic.Samples";

            host.AddServiceEndpoint
                (typeof(IService),
                 basicBinding, 
                 "");

            // add the "get metadata" behavior 
            // This will allow the service to emit WSDL when tickled at the proper HTTP endpoint
            var smb= new System.ServiceModel.Description.ServiceMetadataBehavior();
            smb.HttpGetEnabled = true;
            smb.HttpGetUrl = new System.Uri(endpointAddress);
            host.Description.Behaviors.Add(smb);

            System.Console.WriteLine();

            // Open the ServiceHost to create listeners and start listening for messages
            host.Open();
            System.Console.WriteLine("Service implementation: " + t1.ToString());
            System.Console.WriteLine("Service Address: {0}", endpointAddress);
            System.Console.WriteLine("The service is ready.");
            System.Console.WriteLine();
            System.Console.WriteLine("Press <ENTER> to terminate the service.");
            System.Console.WriteLine();
            System.Console.ReadLine();

            // Close to shutdown the service
            host.Close();
        }

But sometimes I need the WCF service to run for a longer period of time, maybe permanently. This is where the IIS host makes sense - for security and lifecycle purposes. And the ASP.NET deployment stuff works nicely for WCF services - I copy the Interface (IService.cs) and the Service Implementation code to the App_Code directory of IIS, and then copy the .svc file over, and I'm nearly there. The only thing the IIS-hosted service lacks now is the service configuration.

Deploying to IIS, I don't get to use my boilerplate ServiceHost code as above. Which means I don't have the programmatic control over the endpoint and the ServiceMetadataBehavior, and I don't get to specify an endpoint and any behaviors. So of course I have to embed the relevant configuration information in the .config file, which in the case of IIS hosting, is the web.config file.

A problem comes in when hosting multiple WCF services in a single IIS virtual directory: Each Service gets its own individual .svc file, but all services share a single web.config file. If I update a service, then I need to modify that single file. If I add a service, I need to edit the file. If I remove a service, I need to edit the file. And in each case the edits and changes for one service could affect the other services, if the edits are not done properly.

Ideally I'd like the IIS-hosted WCF service to have its own configuration, independent of any other services running from that same vdir. The .svc file is completely independent. Why can't the configuration also be independent? How can I do this?

I looked around and found the ServiceHostBase.ApplyConfiguration method. If I construct a custom service host, then I can override the ApplyConfiguration method and load my service configuration from... anywhere. I decided to establish a simple convention - I will look for a file in the server directory called <ServiceName>.config. This is not <AssemblyName>.config, which is the .NET default. In this case the assembly is likely going to be dynamically generated and named. So using the assembly name to find the config file is probably not right. The next option is to use the Service Name; this is something you specify in code in the [ServiceBehavior] attribute. Assuming you select a unique name for each service, that name ought to be useful for uniquifying the configuration file.

Then, it is a simple matter of loading in the configuration file, within the custom ServiceHost. This bit of black magic does the trick for me:

        protected override void ApplyConfiguration()
        {

            // generate the name of the custom configFile, from the service name:
            string configFilename = System.IO.Path.Combine ( physicalPath,
                                                             String.Format("{0}.config", this.Description.Name));
            
            if (string.IsNullOrEmpty(configFilename) || !System.IO.File.Exists(configFilename))
                base.ApplyConfiguration();
            else
                LoadConfigFromCustomLocation(configFilename);

        }

Then there is some supporting logic, to get the physical path and to actually load the configuration:

        private string _physicalPath = null;
        private string physicalPath
        {
            get 
            {
                if (_physicalPath == null)
                {
                    // if hosted in IIS
                    _physicalPath = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;
                    if (String.IsNullOrEmpty(_physicalPath))
                    {
                        // for hosting outside of IIS
                        _physicalPath= System.IO.Directory.GetCurrentDirectory();
                    }
                }
                return _physicalPath;
            }
        }

        private void LoadConfigFromCustomLocation(string configFilename)
        {
            var filemap = new System.Configuration.ExeConfigurationFileMap();
            filemap.ExeConfigFilename = configFilename;
 
            System.Configuration.Configuration config = 
                System.Configuration.ConfigurationManager.OpenMappedExeConfiguration
                (filemap, 
                 System.Configuration.ConfigurationUserLevel.None);
 
            var serviceModel = System.ServiceModel.Configuration.ServiceModelSectionGroup.GetSectionGroup(config);
 
            bool loaded= false;
            foreach (System.ServiceModel.Configuration.ServiceElement se in serviceModel.Services.Services)
            {
                if(!loaded)
                    if (se.Name == this.Description.ConfigurationName)
                    {
                        base.LoadConfigurationSection(se);
                        loaded= true;
                    }
            }
            if (!loaded)
                throw new ArgumentException("ServiceElement doesn't exist");         
        }

And of course to make this work, you will need to specify a custom ServiceHostFactory in the .svc file. The custom service host approach is useful for lots of things; in the past I used it for WSDL-Flattening or for modifying namespaces on SOAP payloads. Of course you can have a single custom service host that combines all those capabilities, if you like. For this post I am focusing only on the config file.

<%@ ServiceHost
    Language="C#" 
    Debug="true" 
    Service="Ionic.Samples.Webservices.Sep20.CustomConfigService" 

    Factory="Ionic.ServiceModel.ServiceHostFactory"

%>

For now, the logic that reads in a unique file per service will do, but in the general case I'd like to be able to read the configuration from a remote centralized repository, like a network share or a database. That is something left for the future.

I've attached all the code here in a zipfile.

WADL and WSDL and REST, oh my!

DotNetInterop — Wed, 06 Feb 2008 21:17:00 GMT

Hernan Garcia made an interesting comment on my post of yesterday: For REST, there is an alternative to the WSDL in SOAP and it is WADL.

Good point Mr Garcia - The adoption and practical utility of WADL is worth watching. The question for me becomes whether WADL+REST is actually better than WSDL+SOAP, or just different. Whether REST has succeeded to the extent that it has, in spite of lack of WSDL-like tools, or in fact, because of the lack of WSDL-like tools? Is the appeal of REST that there is no single set of tools, which thus limits the possibility to be overcome by galloping complexity, as some have characterized WS-*?

All interesting. It is by no means certain that clear answers to these questions will be coming soon, if at all. Seriously. In 2 years' time the tea leaves may be no clearer on any of these things.

Which gets me back to my earlier philosophy: the best approach for enterprise architects today is to think strategically, but act pragmatically.

With the communication framework built into .NET, Windows Communication Foundation (aka WCF), this is the philosophy we at Microsoft are trying to endorse. It is designed to support REST and SOAP today, as well as other non-standard protocols (via the WCF LOB Adapter SDK), in a single unified programming model. A contrast here is a variety of programming models for different communications protocols; in Java-land what I am thinking is; ECI/EPI for Mainframe and 3270 integration, EJB for transactional comms, JMS for queued comms, JAX-WS for SOAP, JAX-RS for REST, RMI for like-to-like communications. This is hard for any architect or programmer to keep up with. This variety seems to be the result of pragmatic design, rather than strategic design. Each step makes sense by itself. Each API is useful by itself. But all together, there's no cohesiveness. It's overwhelming.

WCF and Apache AXIS interop

DotNetInterop — Tue, 09 Oct 2007 18:24:00 GMT

I'm getting back to building and publishing working examples.

My latest is a working example of a WCF client communicating with an Apache AXIS 1.4 server, using web services. You can find it here. There's full source code available.

This one shows complex types with nesting being transferred between AXIS and WCF. There's no Security or Reliability, etc. No MTOM either.

If you all have requests or suggestions for other examples, let me know. For this particular example, I think one nice enhancement would be to show the raw XML messages being transmitted back and forth. I may do that.

Seems like a higher priority ought to be publishing an AXIS 2.0 service, with some more advanced capabilities (like MTOM); or showing an AXIS client communicating with a WCF service. I'm interested in your input!

Cheers!

-Dino

Improving WCF interop with Websphere/RAD by controlling WSDL Generation

DotNetInterop — Mon, 20 Aug 2007 21:56:00 GMT

I wrote about Christian's foray into this area a while back. Now comes news that other people are confronting the same issue, but with Websphere or Rational App Developer.

Here's the problem: WCF emits WSDL that is modular - the base WSDL file references other WSDLs and XSDs which are external. Christian found out that not all non-.NET tools (such as some PHP libraries he tried) can digest that modular WSDL, and a "flattened" WSDL works better in many cases. This apparently is also true with Rational Application Developer. If you are a WSDL hacker, you can, in 10-20 minutes, take a compound WSDL document and flatten it. But most people are not WSDL hackers and if they are, they don't want to be WSDL hackers. (Trust me on this)

Ideally, generating flattened WSDL out of WCF would be something you could just "turn on" - so that flat WSDL is automatically generated. In fact, this is exactly what Christian did. Modifying the WCF host so that the auto-generated WSDL is automatically flattened, is pretty simple, and general. This should improve interop with Rational Application Developer significantly.

By the way, Christian does his flattening trick by using a custom ServiceHost in WCF - the same extensibility point I used to improve interop with ASMX services, which I described in a prior post.

Interop between ASMX and WCF Services

DotNetInterop — Fri, 20 Jul 2007 04:08:00 GMT

My esteemed colleague, Kevin, is working on a project where the customer has a bunch of ASP.NET (ASMX) web services, and they are looking at migrating to WCF. The customer's goal is simplicity: in stage 1, they'd like to keep their ASMX files, keep the IIS hosting, but add a .svc file to also host the service also in WCF. In stage 2, they'd like to turn off the ASMX endpoint and use only the WCF (.svc) endpoint. All this while keeping the existing client code unchanged: no new code, no re-compile, nothing. A .NET app with a web service stub generated from wsdl.exe should be able to talk to the new service hosted in WCF.

This ought to be pretty simple, right? Kevin found an MSDN article on this topic, How to: Migrate a ASP.NET Web Service Code to the Windows Communication Foundation. This article seems to work, though it doesn't address the specific requirements for Kevin's customer, which included simplicity. Following this article, which by the way is the "right" way to migrate from ASP.NET to WCF, you essentially re-implement everything in WCF. Isn't there a simpler way?

What Kevin did was pretty straightforward and sensible, and he thought it should work. He had a simple .ASMX file, which looked like this:

<%@ WebService Language="C#" CodeBehind="~/App_Code/CommunicationService.cs" Class="CommunicationService" %>

The code-behind file contained the implementation of the service. It looked like this:

[WebService(Namespace = "urn:namespace1")] 
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] 
public class CommunicationService : System.Web.Services.WebService 
{ 

  public CommunicationService() { } 

  [WebMethod] 
  public ComplexType SendCommunication(CommunicationEntity Request) {...}

  ... 

Kevin created a new .svc file for the WCF stuff:

<%@ ServiceHost Language="C#" CodeBehind="~/App_Code/CommunicationService.cs" Service="CommunicationService" %>

And then he decorated the existing web service implementation class with the appropriate WCF attributes, something like this:

[WebService(Namespace = "urn:namespace1")] 
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] 
[ServiceContract(Namespace= "urn:namespace1")] 
[XmlSerializerFormat] 
public class CommunicationService : System.Web.Services.WebService 
{

  public CommunicationService() { } 

  [WebMethod] 
  [OperationContract(Action= "SoapAction1Here")] 
  public ComplexType SendCommunication(CommunicationEntity Request) {...} 

  ...

The OperationContract attribute decorates the service method, like WebMethod does for ASP.NET. The XmlSerializerFormat attribute on the service class tells WCF to not use the default DataContract serialization behavior, but instead to use the XmlSerializer. This, ostensibly, to maintain consistency and compatibility with data types that have been decorated with the XmlSerializer attributes, like XmlElement, XmlIgnore, XmlType, and so on.

This all sounds pretty easy right? The problem is that the actual XML messages expected by WCF for this service, were different than the XML messages expected and accepted by ASP.NET. Now it's XML, so, we don't need an exact string match. We need equivalence of the Xml Infoset. That means, element names must be the same, XML namespaces must be the same, but prefixes attached to the namespaces can be different. But we did not have infoset equivalence! The first puzzle was, WHY?

As in many scenarios involving interop between different web services libraries, it's the XML namespaces that cause lots of insidious problems. In this case, the ASP.NET-hosted web service was serializing and de-serializing the CommunicationEntity, using an XML namespace derived from the XmlTypeAttribute attached to that type definition. On the other hand, WCF was serializing the same object using the XML namespace associated to the ServiceContract. If those two xml namespaces are the same, no problem. But in general, they are different, and in this specific case, they were different. The result was that ASMX clients (and by this I mean .NET apps compiled with webservice stubs generated from wsdl.exe in .NET 2.0) would send a serialized XML stream to the WCF service, which was ever so close to the format WCF wanted. But close doesn't cut it, and so WCF would not de-serialize the request, and the app received a null instance for CommunicationEntity.

This stinks.

You would think it would be automatic, but it sure isn't.

The next puzzle was, how to fix this? If you are familiar with the ASP.NET and XmlSerializer model, there are lots of attributes you can apply to types to specify the namespaces to use, the element names to use, and so on. It's very flexible, so flexible that some people find it unfathomable. The WCF serializer is much simpler, which is nice, but on the downside, there is no special attribute that WCF uses to specify the namespace here.

After a little spelunking, I found what I think is a useful hack to work around this problem. It is a custom ServiceHost, which, in the OnOpening() event, changes the MessageParts where the part namespace disagrees with the namespace specified in the XmlTypeAttribute associated to the CLR type for that message part. Huh?

What this means is, now the WCF endpoint and the ASP.NET endpoint serialize and de-serialize the same way, for complex message types. Even better, when you query the WCF service for metadata, you get the "correct" WSDL – with the updated xml namespace.

The ServiceHost uses reflection to inspect the message parts and decide on whether to change the XML namespace or not. Reflection is expensive at runtime, but this happens only once, when the service is opened. So it should have essentially no impact, after startup of the service.

Here's the code:

using System; 
using System.ServiceModel; 
using System.ServiceModel.Description; 

// if your original .svc file was: 
// <%@ ServiceHost Language="C#" Debug="true" Service="CommunicationService" CodeBehind="~/App_Code/CommunicationService.cs" %> 
// 
// then use this, to get the custom service host: 
// <%@ ServiceHost Language="C#" Debug="true" Factory="dinoch.wcf.fixup.EnforceXmlTypeServiceHostFactory" 
//     Service="CommunicationService" CodeBehind="~/App_Code/CommunicationService.cs" %> 
// 
namespace dinoch.wcf.fixup 
{ 
  /// <summary> 
  /// This custom ServiceHost modifies the ServiceDescription to use the "preferred" 
  /// namespaces on message parts. The ServiceDescription is used by the WCF service 
  /// in generating metadata (eg WSDL) and also in driving the serialization behavior. 
  /// 
  /// We do this because the default behavior in WCF when using the XmlSerializer format 
  /// (via the XmlSerializerFormat attribute) is to NOT use the namespace specified in the 
  /// XmlTypeAttribute, if such an attribute is attached to the data type. This means that 
  /// WCF services will not accept the same input messages as ASMX Services, and will not 
  /// generate the same response messages as ASMX services - they will differ by XML namespace. 
  /// 
  /// The way this works - on opening the service, which happens before WSDL is generated and 
  /// before any messages and dispatched to methods, this ServiceHost modifies the ServiceDescription 
  /// of the service. It examines message parts, looks for XmlTypeAttributes attached to the 
  /// types associated to those message parts, and then compares the xml namespace used in the message 
  /// part to the xml namespace specified in the XmlTypeAttribute. If they namespaces differ, then 
  /// this ServiceHost overrides the default namespace, and uses the namespace from the XmlTypeAttribute 
  /// in its stead. 
  /// 
  /// Because this ServiceHost modifies the ServiceDescription before starting up the service, at runtime, 
  /// this technique has the same effect as applying an (imaginary) attribute 
  /// to the service implementation code; the metadata (WSDL) generated from this service 
  /// will indicate the desired namespace for the message parts. 
  /// 
  /// This ServiceHost has no effect on service operations that do not use the XmlSerializer. 
  /// 
  /// There is one catch: running svcutil.exe over the assembly 
  /// (as opposed to the service itself, hosted and running within IIS) will not 
  /// detect the proper namespaces. 
  /// 
  /// To use this service host, use something like this in your .svc file: 
  /// <%@ ServiceHost 
  ///     Language="C#" 
  ///     Debug="true" 
  ///     Factory="dinoch.wcf.fixup.EnforceXmlTypeServiceHostFactory" 
  ///     Service="CommunicationService" 
  ///     CodeBehind="~/App_Code/CommunicationService.cs" 
  /// %> 
  /// 
  /// For some additional background, see http://msdn2.microsoft.com/en-us/library/Aa395224.aspx 
  /// 
  /// </summary> 
  public class EnforceXmlTypeServiceHost : ServiceHost 
  { 
    public EnforceXmlTypeServiceHost(Type t, params Uri[] baseAddresses) : base(t, baseAddresses) { } 

    public EnforceXmlTypeServiceHost(object singletonInstance, params Uri[] baseAddresses) 
      : base(singletonInstance, baseAddresses) { } 

    public EnforceXmlTypeServiceHost() : base() { } 
    protected override void OnOpening() 
    { 
      ServiceEndpointCollection sec = this.Description.Endpoints; 
      foreach (ServiceEndpoint se in sec) 
      { 
        if (se.Address.ToString().EndsWith(".svc")) // eliminate mex endpoints 
        { 
          foreach (OperationDescription opDesc in se.Contract.Operations) 
          { 
            // Are we using XmlSerializer? 
            if (opDesc.Behaviors.Find<XmlSerializerOperationBehavior>() != null) 
            { 
              foreach (MessageDescription messDesc in opDesc.Messages) 
              { 
                for (int i = 0; i < messDesc.Body.Parts.Count; i++) 
                { 
                  MessagePartDescription part = messDesc.Body.Parts[i]; 
                  System.Reflection.MemberInfo info = (System.Reflection.MemberInfo)part.Type; 
                  System.Xml.Serialization.XmlTypeAttribute[] attributes = 
                    (System.Xml.Serialization.XmlTypeAttribute[])
                    info.GetCustomAttributes(typeof(System.Xml.Serialization.XmlTypeAttribute), true); 
                  if ((attributes!= null) && (attributes.Length > 0)) 
                  // check to see if the xml namespace specified to the XmlSerializer via 
                  // the XmlTypeAttribute attribute, disagrees with the xml namespace used 
                  // in the WCF message description. 
                  if (attributes[0].Namespace != part.Namespace) 
                  { 
                    // the namespaces do not agree. we need to swap them. 
                    // this won't work, the property is readonly 
                    // messDesc.Body.Parts[i].Namespace = attributes[0].Namespace; 
                    // Duplicate the old part description, except for the XML namespace 
                    MessagePartDescription newPart = new MessagePartDescription(part.Name, attributes[0].Namespace); 
                    newPart.Index = part.Index; 
                    newPart.MemberInfo = part.MemberInfo; 
                    newPart.Multiple = part.Multiple; 
                    newPart.ProtectionLevel = part.ProtectionLevel; 
                    newPart.Type = part.Type; 
                    // Replace the old part with the new one 
                    messDesc.Body.Parts[i] = newPart; 
                  } 
                } 
              } 
            } 
          } 
        } 
      } 

      base.OnOpening(); 
    } 
  } 

  public class EnforceXmlTypeServiceHostFactory : System.ServiceModel.Activation.ServiceHostFactory 
  { 
    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses) 
    { 
      return new EnforceXmlTypeServiceHost(serviceType, baseAddresses); 
    } 
  } 
}

And here's how you specify the custom ServiceHost in the .svc file:

<%@ ServiceHost
    Language="C#"
    Factory="dinoch.wcf.fixup.EnforceXmlTypeServiceHostFactory"
    CodeBehind="~/App_Code/CommunicationService.cs"
    Service="CommunicationService" %>

I hope this is useful! The same principle would apply, of course, when migrating from ASMX to WCF on the server side, if you are using a Java-based client, or a web service client on any other platform. So this definitely falls in the arena of interop. If any of you have other requests on interop topics relating to WCF, let me hear 'em!

Cheers,

-Dino