All About Interop

Enable .NET 3.5 goodies in IIS vdir

2008-12-05T20:29:00Z

Some of you may be oddballs like me: you like .NET, you program in .NET, but you don't always use Visual Studio. You hand-code everything for some applications. You often open up a text editor and just start writing a source module, with no wizards, no project templates, etc. You hand-code your MSbuild files. You hand-code your web.config files.

Oddballs like us cannot rely on the code-generation that comes with Visual Studio. So when we write a new ASP.NET application, and we want to use the .NET 3.5 goodies in that app - things like var types, and LINQ - we need to explicitly specify that we want .NET 3.5 compilation. Same is true if you are writing a WCF service and want to use REST or any of the var types or LINQ.

I've done this twice now and had to search for the way to do it both times. I'm putting here as a "note to self" and also as a reference for anyone else. These are the custom magic incantations for web.config, if you want to enable .NET 3.5 in your ASP.NET app, or in your WCF Service - eg, the cool REST stuff from .NET 3.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <system.web>
    <compilation debug="false">  
      <assemblies>  
        <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>  
        <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
      </assemblies>  
    </compilation>  
  </system.web>


  <system.codedom>  
    <compilers>  
      <compiler language="c#;cs;csharp" extension=".cs"   
                type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"   
                type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="OptionInfer" value="true"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
    </compilers>  
  </system.codedom> 

</configuration>

Geneva supports OASIS WS-Trust, SAML

2008-11-07T19:09:00Z

Last week at the PDC 2008, Microsoft released the public beta of “Geneva”.

“Geneva” is three things:

Geneva Server. This is a security token service (STS), as defined in the OASIS WS-Trust specification. This thing issues and transforms claims, manages user access, and enables automated federation.

Geneva Framework. This is a managed (.NET) Framework that helps developers build claims-aware applications and services, that connect to the STS. You can use it to process claims on either side of an authorization transaction (requestor or responder).

Windows CardSpace Geneva. This is just an extension of the CardSpace thing in Windows you know and love today. chances are, you've seen it, but you don't use it. In a nutshell - CardSpace is a set of Windows features and user-interface that lets users navigate access decisions and control how personal information is used. Everyone has multiple claims as part of their identity: you are a student at UW, you are an employee of BigCorp, you are a member in good standing of a particular club, you have received a particular security clearance, You have a bank account with number 4444-444-44 at BigBank, etc. CardSpace lets you decide which of the many claims you can make about your identity, to disclose to a particular service or server. Rather than disclosing "everything" about you to every server or service, you disclose only what you need to disclose for the particular transaction. That is one aspect of the identity model, and CardSpace is the thing in Windows that makes that possible.

CardSpace technology, and actually, the Identity Metasystem concept, is pretty cool. If you haven't looked at it, you should. The problem with CardSpace and more generally, using claims-based access control (CBAC) in an application, has always been that it was impractical. Microsoft delivered a client (CardSpace), but we didn't deliver an STS! And we didn't deliver an easy way for the server to evaluate and verify claims. Therefore developers didn't have an easy way to employ CBAC in their apps. Geneva will change this.

Now, some of you are thinking, "ok, this sounds interesting but I don't know what you are talking about with this WS-Trust thing and 'claims based access control'. And I can understand that. Here's the thing - instead of hand-crafting access-control logic into your application, instead of managing your own user list and access control list, you can "outsource" this job to an STS. The Authorization Manager (sometimes called AzMan) is similar in philosophy, so if you understand the utility of AzMan, then you will get the idea of CBAC. But AzMan is not standards based, not federated, not truly claims-based (it is role based, which is less general than claims-based), and not usable in Web services transactions. Imagine generalizing AzMan and federating it and using only standard protocols, and that's where we're headed with Geneva. You're gonna want to use this.

I said "Geneva is standards based." The key to standards is support by the vendors, in tools, frameworks, servers, and so on. Currently, WCF from Microsoft supports WS-Trust, as does the WSIT from Sun. WebSphere App Server v7.0 announced support for WS-Trust just last month, but I haven't had the time to test it with Geneva. Not sure of other frameworks. The key is, with Geneva, the server is now here, and people can and will start building on this. I think with the release of the Geneva CTP, we'll start to see broader adoption of WS-Trust and standards-based CBAC among frameworks.

One last thing to point out: In the cloud, the Microsoft Services Connector and the .NET Access Control Service, both announced at PDC as well, are built on “Geneva” technology and share the same claims architecture.

More Information:
Kim Cameron’s blog
Vittorio Bertocci’s blog
Get the Geneva beta
Single stop resource on Geneva

A list of “Geneva” sessions recordings at PDC:

code	Title	Presenter(s)	Link
BB11	Identity Roadmap for Software + Services	Kim Cameron and Vittorio Bertocci	http://channel9.msdn.com/pdc2008/BB11/
BB42	Identity: "Geneva" Server and Framework Overview	Stuart Kwan and Caleb Baker	http://channel9.msdn.com/pdc2008/BB42/
BB43	Identity: "Geneva" Deep Dive	Jan Alexander	http://channel9.msdn.com/pdc2008/BB43/
BB44	Identity: Windows CardSpace "Geneva" Under the Hood	Rich Randall	http://channel9.msdn.com/pdc2008/BB44/

Connect WebSphere and Java applications to SQL Server

2008-11-06T00:55:00Z

FYI: The MS JDBC Driver is completely tested by IBM for use with WebSphere App Server v6.1 and v7.0.

From the IBM Announcement for WebSphere Application Server v7.0:

WebSphere Application Server V7.0 does not include the WebSphere Connect JDBC driver that had been provided in WebSphere Application Server V6.1. To replace the functionality provided by the WebSphere Connect JDBC driver, WebSphere Application Server V7.0 is tested with the DataDirect Connect for JDBC driver and the Microsoft SQL Server JDBC Driver, which may be obtained from DataDirect Technologies or Microsoft.

Connect your WebSphere/Java apps to SQL Server with this driver. Actually, you can connect *any* Java application to SQL this way - it doesn't have to be running in WebSphere. If you develop in Jetty or Tomcat or JBoss or Geronimo, the MS JDBC Driver will work fine for you.

If you have .NET applications, or Office apps, of course you can connect them to SQL Server also. In this way, SQL Server can serve as a nice interop point between Java and .NET applications, or between Java and MS Office (Let's say... an Excel spreadsheet).

Some notes:

the MS JDBC Driver is a free download.
It is a full type-4 (100% Java) JDBC 3.0 driver, fully tested and compliant with Sun's verification suite.
It connects to SQL Server 2000, 2005 or 2008
It works from any JVM on any OS platform, including Linux
It works with the Express version of SQL Server (which is also a free download) and it works with the Standard and Enterprise versions, too.
There is forum support available for the driver
There's a tech preview of a JDBC 4.0 compliant driver, here.

If this is the sort of thing that interests you, be sure to check the team blog for the JDBC driver.

Such a deal! MSDN for startups

2008-11-06T00:20:00Z

Today Microsoft announced BizSpark: http://www.microsoftstartupzone.com/bizspark

This program gives ISV startup with less than USD$1m in annual revenue (lower amounts for some other countries - for example it's just USD$250k for Egypt) free access to MSDN subscriptions. Nice. You get Visual Studio, Expression, VSTS, SQL Server, BizTalk Server, SharePoint Server, Windows Server - all you need to build a software app on the Microsoft application platform.

There are some requirements: you have to be a software startup, privately held, and there's the revenue limit. If you don't qualify for that deal, there are others that may work for you. Here's a summary :

BizSpark - Free development software for ISVs.
Empower for ISVs - Accelerates ISVs development on the Microsoft platform with software, support, and other resources.
DreamSpark - like BizSpark, but for Students. Download Microsoft developer and design tools at no charge.
Free software - Free software and trial software.

Check it out...

REST in WCF: Varying response content type based on HTTP Request Headers

2008-11-05T00:39:00Z

Damian Mehers made a comment on my blog post from April, but I felt it was worth a full reblog.

Damian's used the same WCF extensibility points I used to produce some boilerplate that varies the response content type from JSON to XML, based on the Accept or Content-Type header of the GET request. He extends WebHttpBehavior to return an IDispatchMessageFormatter that does either JSON or XML.

    class WebHttpBehavior2Ex : WebHttpBehavior
    {
        protected override IDispatchMessageFormatter GetReplyDispatchFormatter(OperationDescription operationDescription, 
                                                                               ServiceEndpoint endpoint)
        {
            WebGetAttribute webGetAttribute = operationDescription.Behaviors.Find<WebGetAttribute>();
            DynamicResponseTypeAttribute mapAcceptedContentTypeToResponseEncodingAttribute = 
                operationDescription.Behaviors.Find<DynamicResponseTypeAttribute>();
 
            if (webGetAttribute != null && mapAcceptedContentTypeToResponseEncodingAttribute != null) {
                // We need two formatters, since we don't know what type we will need until runtime
                webGetAttribute.ResponseFormat = WebMessageFormat.Json;
                IDispatchMessageFormatter jsonDispatchMessageFormatter = 
                    base.GetReplyDispatchFormatter(operationDescription, endpoint);
                webGetAttribute.ResponseFormat = WebMessageFormat.Xml;
                IDispatchMessageFormatter xmlDispatchMessageFormatter = 
                    base.GetReplyDispatchFormatter(operationDescription, endpoint);
                return new DynamicFormatter() { 
                    jsonDispatchMessageFormatter = jsonDispatchMessageFormatter, 
                    xmlDispatchMessageFormatter = xmlDispatchMessageFormatter };
            }
            return base.GetReplyDispatchFormatter(operationDescription, endpoint);
        }
    }

And then in the DynamicFormatter code, he just picks the formatter as appropriate:

    class DynamicFormatter : IDispatchMessageFormatter
    {
        public IDispatchMessageFormatter jsonDispatchMessageFormatter { get; set; }
        public IDispatchMessageFormatter xmlDispatchMessageFormatter { get; set; }
 
        public void DeserializeRequest(System.ServiceModel.Channels.Message message, object[] parameters)
        {
            throw new NotImplementedException();
        }
 
        public System.ServiceModel.Channels.Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result)
        {
            Message request = OperationContext.Current.RequestContext.RequestMessage;
 
            // This code is based on ContentTypeBasedDispatch example in WCF REST Starter Kit Samples
            // It calls either 
            HttpRequestMessageProperty prop = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
 
            string accepts = prop.Headers[HttpRequestHeader.Accept];
            if (accepts != null)
            {
                if (accepts.Contains("text/xml") || accepts.Contains("application/xml"))
                {
                    return xmlDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                }
                else if (accepts.Contains("application/json"))
                {
                    return jsonDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                }
            }
            else
            {
                string contentType = prop.Headers[HttpRequestHeader.ContentType];
                if (contentType != null)
                {
                    if (contentType.Contains("text/xml") || contentType.Contains("application/xml"))
                    {
                        return xmlDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                    }
                    else if (contentType.Contains("application/json"))
                    {
                        return jsonDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
                    }
                }
            }
            return xmlDispatchMessageFormatter.SerializeReply(messageVersion, parameters, result);
        }
 
    }

It's pretty nifty and it requires no changes to the app logic. You need to use a custom ServiceHost and use a custom attribute on each Operation. Because it uses the HTTP headers and not the URI itself to determine content-type of the response, I think it has some nice benefits over the approach I described in April.

Damian's got a full VS2008 solution will all the boilerplate code.

check it out.

It just got easier to build REST apps in .NET

2008-10-30T00:48:00Z

The REST starter kit that we launched at PDC is now live! :: http://www.msdn.com/wcf/rest .

The WCF REST Starter Kit is a set of features, Visual Studio templates, samples and guidance that help people build REST apps using WCF. WCF, part of the .NET Framework, got some enhancements for REST support in the .NET 3.5 release. This starter kit is a bunch of blueprints and supporting material to make it easier to use what is in the Framework for REST.

Like, blueprints and guidelines for how to do caching, security, error handling, help page support, conditional PUT, push style streaming, type based dispatch and semi-structured XML support. Whoa!

The WCF REST Starter Kit also provides Visual Studio templates for creating REST style services such as an Atom feed service, a REST-RPC hybrid service, Resource singleton and collection services and an Atom Publishing Protocol service. In addition, there are samples, documentation and other guidance that help to use these new capabilities.

The goal is to provide a toolset that simplifies building RESTful services today, and to take feedback from the developer community on the features provided in the WCF REST Starter Kit that will shape future REST capabilities in WCF 4.0.

Microsoft joins AMQP

2008-10-25T00:04:00Z

Microsoft joins AMQP

It's very good to see this. For those that don't know, AMQP is the Advanced Message Queuing Protocol, a nascent middleware standard that describes an interoperable protocol for application messaging systems. Driven primarily by companies, and not by vendors, AMQP aims to introduce new innovation, more competition, and better interop between messaging subsystems.

If you've read any of my other blog postings you know that interop and messaging systems are near and dear to my heart. This is very good indeed for customers who build and run enterprise information systems with a great deal of heterogeneity. Imagine if MSMQ and the messaging infrastructure on RedHat Enterprise Linux used the same on-the-wire protocol, and supported the same service semantics. This would mean your messaging clients could talk to either message service with full interoperability and switchability.

Some nice possibilities here. Great to see it being driven so much by the companies themselves.

IIRF v1.2.15 is released - open source URL Rewriting on IIS6

2008-10-15T17:21:00Z

I have previously written about IIRF. Here I go again: IIRF has now has been updated to v1.2.15.

IIRF is Ionic's Isapi Rewrite Filter. It is a small, cheap, easy to use, URL rewriting ISAPI filter that combines a good price (free!) with good features. It is fast and powerful. It works on IIS 5.0, 5.1, 6.0, and 7.0.

You may have heard about the Rewriting Module for IIS7 from Microsoft. This is not that thing. This is a rewriter for IIS6 or 7.

It works with regular expressions. It's fast. It's written in C. It's open source. It does not require the .NET Framework. It works with PHP, Ruby, ColdFusion, JSP, ASP.NET, and anything else you can run on IIS.

Check it out.

DotNetZip revs to v1.6 – now with Unicode support

2008-10-15T00:54:00Z

The v1.6 release of DotNetZip is now available. DotNetZip is the open source Zip Library for .NET, available at http://www.codeplex.com/DotNetZip .

Major new features:

Unicode support, as well as support for arbitrary code pages. Now you can build zip files that have names with Unicode characters.
Large file support. Full streaming architecture means you can zip large files without loading them into memory all at one time.
Partial Trust - for running on shared hosetd ASP.NET servers

DotNetZip is still small, fast, and the easiest .NET zip library to use. Check this sample code:

      using (var zip = new ZipFile())
      {
        zip.AddDirectory(directory);
        zip.Save(targetZip);
      }

It is 100% managed code. People love it:

DotNetZip is powerful, too: it does password-protected zip files, zip comments, self-extracting zips, zip-to-stream, stream-to-zip, and more. You can use it in any .NET app - WinForms, console app, ASP.NET page, etc. In ASP.NET, you can write a zip archive directly to Response.OutputStream as a download to the browser client. On the codeplex site, there are lots of examples and the documentation is solid.

DotNetZip is free, but is donationware. For those who are happy with DotNetZip, I am accepting donations on behalf of my favorite charity.

Eclipse tools for Silverlight and .NET

2008-10-13T23:00:00Z

There is now an Eclipse project, Eclipse4SL, to produce tools that work with Microsoft Silverlight. See Neil Hutson's blog post for some details.

For those of you who have day jobs and find it hard to keep up with all the code-names and product names coming out of Microsoft, Silverlight is the name a cross-browser, cross-platform, and cross-device plug-in for rich interactive applications for the Web. Huh? Break it down:

Silverlight is a browser plug-in: Runs in IE, Firefix, Opera, and more.

As a plug-in, Silverlight provides a runtime, which is at it's core, .NET based. It is a lightweight version (subset) of the .NET Framework. When you write declarative code, you'll be using a .NET langauge

Silverlight is cross-platform: Microsoft produces versions to run on Windows and Mac and the Mono project is doing Moonlight for Linux.

Silverlight is for Rich Interactive apps. This means high-def video, audio, hypertext, dynamic data.

Bottom line, Silverlight is like Adobe's Flash, but built on a broad platform (.NET and the CLR) with mainstream language support (C# and VB) as opposed to a relatively narrow platform and runtime requiring ActionScript.

Because Silverlight uses a lightweight NET runtime, if the Eclipse4SL project succeeds, developers will be able to use Eclipse tools to create .NET applications. How about that! You will be able to edit XAML and C# in Eclipse!

Milestone 1 for Eclipse4SL is set for this week: October 14th there'll be a CTP of the tools. Feature complete in December. Nice! I love to see this. Love it, love it, love it.

From the Eclipse4SL website, Interop is a key criterion for success: Increased Interoperability: Eclipse will contain functionality that will help Java Developers build Silverlight applications that work better with Java Web Services using REST, SOAP, JSON and other standards. There's a company called Soyatec, a longtime Eclipse Foundation member, doing the analysis and development work.

For my part, I'm so glad we're getting to the point where we all can work together collaboratively to produce interesting stuff for customers. Next milestone: when a proejct like this doesn't warrant blog posts entitled "interesting times indeed."

Weblogic JMS with .NET

2008-10-09T18:36:00Z

This came out last month, I just learned about it from an email from Jesus today.

WebLogic Server 10gR3 now has an officially-supported .NET client for its JMS provider. Very cool. Some of you might be wondering, just what does that mean? It means there is a queue mechanism in the WebLogic Server, for a long time this has been called "Weblogic JMS". And you can connect to that queue subsystem via .NET applications. James Bayer has a blog entry on it, which you should check out.

pet peeve alert! Calling a queue "JMS" is strange and confusing. It would be like calling the Oracle database "Oracle JDBC" or "Oracle ADO.NET". Oracle Database is not the same as JDBC. JDBC is an API. ADO.NET is the name for an API. The database is not the API. The database (whether Oracle, Microsoft SQL Server, IBM DB2, or something else) exposes mutliple API families - some for Java, some for .NET languages, some for C and C++. The programmatic interfaces are distinct from the implementation.

With JMS, Sun and the Java guys have confused the issue. Maybe even on purpose: remember back when JMS was conceived, Sun had aspirations to make Java itself a platform - everything contained within Java as other things like the operating system and the database itself, and to the point, a messaging subsystem, recede into the background. Well, that didn't really happen, despite the huge popularity of Java as a programming language. Operating systems still matter, databases still matter, message queues did not get subsumed into the programming language. Java is a language and a VM and a base class library, but not a platform. Regardless, the side effect of Sun's unfulfilled platform aspirations for Java is that today, people call message and queue subsystems "JMS." Developers speak of JMS topics, JMS queues, JMS messages. But it is clear: just as JDBC is a Sun/Java API for databases, JMS is a Java API for Messaging subsystems.

IBM has always been very clear about this with its MQ product, later called MQSeries and then changed to "WebSphere MQ".   (For this post I'll just call it MQ.)   MQ is the implementation, and MQ exposes a bunch of different APIs - for C, for .NET, for Java, and I'm sure, for other languages. In what looks like a bit of schizophrenia, IBM also has message service within WebSphere Application Server, which is called WebSphere JMS if I am not mistaken, and which... you guessed it, exposes more than just a JMS programming interface.

For some reason, the queue infrastructure for some products has been called "JMS" as if that is the only API that has ever mattered. Seems like a result of shortsighted and wrongheaded product planning to me. And it's darned confusing, to boot.

A separate issue is that JMS is not merely an API! JMS actually injects some message protocol behavior, specifically the RFH2 header formatting stuff, which makes for tricky interop with other, non-Java applications through queue subsystems. Designing JMS this way presented a big, unnecessary obstacle to interop, and I've blogged on it previously.   IBM has had to introduce new APIs for MQ and its other queue subsystems, specifically to work around this interop barrier. I don't know a better way to solve it, than the way IBM did. But make a note to yourself - if you ever design a queue system or queue API, keep the API separate from the application protocol and message formatting.

Check it out!

Interop sessions at Oracle Open World

2008-09-27T06:43:00Z

Jesus and my collegue Kent Brown both spoke at Oracle Open World recently, on interop between WCF and WebLogic.

http://weblogs.asp.net/gsusx/archive/2008/09/19/speaking-at-oracle-open-world.aspx

But I found out after the fact! nice!

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

2008-09-25T18:25:00Z

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

2008-09-24T18:36:00Z

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

2008-09-23T18:32:00Z

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"%>