All About Interop : Interop

Geneva supports OASIS WS-Trust, SAML

DotNetInterop — Fri, 07 Nov 2008 19:09:00 GMT

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

DotNetInterop — Thu, 06 Nov 2008 00:55:00 GMT

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.

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

DotNetInterop — Wed, 05 Nov 2008 00:39:00 GMT

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

DotNetInterop — Thu, 30 Oct 2008 00:48:00 GMT

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

DotNetInterop — Sat, 25 Oct 2008 00:04:00 GMT

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

DotNetInterop — Wed, 15 Oct 2008 17:21:00 GMT

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

DotNetInterop — Wed, 15 Oct 2008 00:54:00 GMT

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

DotNetInterop — Mon, 13 Oct 2008 23:00:00 GMT

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

DotNetInterop — Thu, 09 Oct 2008 18:36:00 GMT

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

DotNetInterop — Sat, 27 Sep 2008 06:43:00 GMT

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

DotNetZip users: Please Test Unicode support (free zip library for .NET)

DotNetInterop — Fri, 19 Sep 2008 22:49:00 GMT

DotNetZip is an open-source library to allow any .NET application to read and create zip files. If you want your ASP.NET page to grab an uploaded zipfile and unpack it on the server, DotNetZip can help you. If you want to generate a zipfile from a server-based app like an ASP.NET page and send it as a download, DotNetZip can be the library you need. If you have a windows forms app or a WPF app that needs to read or write zipfiles, DotNetZip can help. If you have an agent application that watches for files to be dropped into a directory, then zips or unzips them, DotNetZip is the thing you need.

DotNetZip has been available as an open source project on CodePlex for about a year. In that time I've added a bunch of features as requested by people who are using it - support for passwords, support for stream-based interfaces, zipfile comments, the ability to remove entries from zip files, progress events for zipping up or unzipping, finer control over the use of compression, and so on.

The #1 most requested feature for the DotNetZip library is Unicode support - people want to be able to zip up files that have filenames with non-ASCII characters.

I've produced a preliminary release with support for Unicode, and I'm asking for people to try it out, test it and tell me if this does what they need it to do. The thing is, Unicode was added to the PKWare specification for zip files only about a year ago. There are few tools out there that properly support the spec. In particular, Windows XP and Windows Vista do not support the PKWare Unicode specification in the "compressed folders" feature. In Windows, if you click on a zip file that complies with the PKWare spec, you won't get what you want to get. And it's not just Windows. Most tools don't support Unicode zip files. As a result, I don't know how to test the Unicode support effectively.

Because zip tools that do Unicode are few and far between, I used a fallback approach in the library. In the latest prelim release, DotNetZip uses the IBM437 code page to encode non-ASCII characters by default. This is not in the PKWare spec, but zip files that people have sent me are using this encoding. IBM437 in zip files may be a quiet, unspecified, de-facto standard, "good enough" for many people. Of course, using the IBM437 mode, you cannot do Chinese characters, which is a huge hole. But IBM437 does cover characters with umlauts and tildes and so on, a lot of Latin languages.

And now I'm asking for your help. I'd like everyone who uses DotNetZip to try out the new Unicode and IBM437 stuff. It is available in the latest v1.6 prelim release availalble on the releases tab.

For tests:
Use the library to zip up files that have "Unicode filenames", or more accurately, filenames with characters that cannot be represented in 7-bit ASCII. This might be characters with umlauts, tildes, and so on, in addition to characters from the non-Latin languages - Hebrew, Greek, Cyrillic, and of course, Chinese.

See if it works, see if the files zip up and unzip properly. See if the files open in Explorer the way you expect. See if it works intuitively, if the library behaves the way you would like it to behave. See if the zip files can be read by other tools and libraries (7-zip or zlib or winrar). That kind of thing.

You will have to check the doc on the UseUnicode property on the ZipFile to see the options and the details of the implementation. I encourage you to try all your tests with that flag both ON and OFF - to see how it behaves and what you would prefer.

If find something that breaks, or surprises you, then please do report it. If you are really ambitious, you can write up a test case that reproduces the problem you observed and attach it to a new workitem.

The new Unicode support in the library is easy to describe, but it is hard for me to test. It is hard for me to know if I am testing the right things. I need help on this, before I can declare the unicode support useful, stable, and interoperable.

Check it out!

Many many LINQ Providers

DotNetInterop — Fri, 12 Sep 2008 18:28:00 GMT

When LINQ shipped, it included a provider model, to encourage people to make other systems and data stores accessible from the coolness-that-is-LINQ.

Back in February, Charlie Calvert published a long list of LINQ providers. In July, Robert Shelton later reblogged it. Charlie also has a list of LINQ Links. Nice to see. By my count there are 33 different LINQ providers listed. I'll bet there are more by now.

You can also search for more on LINQ providers.

Using the WSDL-First design approach with WCF services

DotNetInterop — Fri, 05 Sep 2008 17:07:00 GMT

Couple of helpful posts from the archives for you.

If you are care about interop, then you probably want to use a contract-first or WSDL-first design for your web services. In other words, you will not simply decorate server-side code annotations (in Java) or attributes (in .NET) and generate WSDL dynamically from that running code. That approach works in demonstrations, but it does not lend itself to good interoperability in the long run.

So you start with WSDL. Since you are WCF-savvy, you are confining yourself to the subset of XML Schema that is friendly to WCF. The restriction isn't too onerous, though, especially as it improves interoperability significantly, and also simplifies your life since you don't have to read and understand all of the XML Schema spec! Ok, so following those rules, you write the WSDL. And then you generate from that WSDL the server-side stub code, and the client-side proxy code, using the web services toolkits of your choice. On the .NET side, that toolkit is obviously WCF (and the tool itself is svcutil.exe); on the Java side, maybe the JAXWS reference implementation, or AXIS2, and so on. But the trick is, the generated code on the .NET side is muy bueno if you write your WSDL following a few additional simple rules, which are not mentioned in the above linked doc.

For example, if you want to pass a collection in your interface, and you will be using WCF on one or both ends of the wire, then you want to use an explicit complexType for the array in the WSDL/XSD. This is not required by WSI Basic Profile, nor is it mentioned anywhere in the official WCF doc as far as I know. Nonetheless, follow this rule for best results. Do not define your arrays with an element and a @maxOccurs="unbounded" attribute in your schema; if you do, you will get the XmlSerializer with WCF, rather than the DataContract serializer, and that is probably not what you want. More on this tip here.

Also, use only one part in each wsdl:message (to comply with WS-I Basic Profile) and set the message part attribute @name = "parameters" to make the messages document/literal wrapped, versus bare. If you're not sure, you want wrapped.

Finally, another tip: when using collections in service interfaces (or more specifically, data contracts), you can use the svcutil.exe tool to specify that collections be represented in the generated .NET code as one of the Generic collection types, rather than a vanilla array. This is done with the /collectionType option on the svcutil.exe command line. See this post for more detail on that idea.

I think there might be a similar codegen hint on other web services toolkits but I could not find the right switch on AXIS2.