This is just something to remind myself next time I need to implement a WCF service using the BasicHttpBinding with transport-only security (SSL + client certificates)':

• WCF expects that the "Require SSL" option in IIS is enabled.
• If Metadata Exchange is needed, configure the MEX endpoint with a custom binding with the right settings; otherwise the service won't start.
• Remember to set httpsGetEnabled="true" option in the <serviceMetadata> service behavior instead of the usual httpGetEnabled attribute.
• WCF does not understand the "Accept Client Certificates" option in IIS. It treats it the same as "Ignore Client Certificates" option.

To use client certificates:

• Enable the "Require Client Certificates" option in IIS
• On the service side, use a custom binding to set the requireClientCertificate option of the httpsTransport binding element:

  <bindings>

     <customBinding>

        <binding name="sslBasicHttp">

           <textMessageEncoding messageVersion="Soap11" />

           <httpsTransport requireClientCertificate="true"/>

        </binding>

     </customBinding>

  </bindings>

• On the client side, use basicHttpBinding with the security mode set to "Transport" and the option clientCredentialType set to "Certificate" on the <transport/> element.

Windows Communication Foundation

Udi Dahan posted a few days ago an entry (rant?) on Web Services as an interoperability option between .NET and Java and the potential pitfalls in that. Based on my personal experience, I can't help but agree with him that there's still a ways to go.

Now, don't get me wrong; using Web Services is still simpler in many cases than the other options available, but it's no silver bullet. More to the point, interoperability is not something you get for free; it's something you have to architect, design, code and test for.

Here are some (random) observations on this from my own personal experience:

Know who your clients are and what tools they use

Sometimes you will have to make trade offs in the design of your service contract based on who your service consumers will be and what tools they are using. In an ideal world this wouldn't be necessary, but alas, that's not where we live. For example, Java tools tend to favor certain specific patterns. Or maybe your consumer will be an integration tool or maybe even a legacy platform using one of the many, lesser known SOAP stacks available. Those usually have specific restrictions.

If you know your consumers will be using Java, try to find out what specific SOAP stack they are using (from the plethora available for Java) and explicitly test against it. It will be a worthwhile use of your time. If your consumers are LOB applications, modern third party packages with built-in WS support, or desktop applications (i.e. MS Office) then again special restrictions might apply, so try to find out before hand.

Understand SOAP Encoding and Messaging Patterns

A lot of people still don't know the difference between SOAP RPC/Encoded and Document/Literal. Microsoft took the initiative back in 2001/2002 when the .NET ASMX stack turned on Doc/Literal encoding by default (a wise move, imho), but Java toolkits took a long while to catch up.

Even today, a lot of Java toolkits will default to RPC/Encoded even if they support Doc/Literal and, unfortunately, a lot of Java developers don't know their kits well enough to turn on the right settings. To be fair, a lot of .NET developers don't know how to change the encoding settings either, but we forgive them because of the sensible defaults in the platform

Know the basics

Study and learn how to apply the basics of the WS-I Basic Profile in your platform of choice. Take good care in ensuring you follow the basic guidelines for service/message contract design, and learn what options are available in your platform to control service and message generation.

Here are some good resources to keep in mind for .NET:

• How to Apply the Basic Profile
• Building WS-I Basic Profile Compliant Web Services using ASP.NET 2.0

Beyond the Basics

If you thought interop with plain old SOAP (POS?) could be hard, then be double wary when you get into the WS-* specs, which are sure to complicate things further and bring a lot of extra interop challenges. WS-Security and its related specs, in particular, can give you some nasty headaches. Some thing to watch out for:

• Again, check which toolkits and clients your consumers will be using. Make sure they support the exact protocol versions you expect to be using.
• Make sure you've tested interoperability using the specific protocol features you expect to use. For example, if you're using WS-Security, make sure you can interop at a basic level with the message confidentiality, message authentication options and token kinds you plan to enable.
• WS-Security interoperability problems, in particular, can be nasty to diagnose because most implementations throw extremely uninformative error messages that don't tell you much. Yes, even WCF falls into this trap.
• Watch out for interrelated specs in use. For example, when using WSE to add advanced security to your services, it would by default add a bunch of WS-Addressing stuff that caused extra interoperability issues, because there were several [incompatible] WS-Addressing versions. Add to this that WS-Security was a lot farther down the standardization path than WS-Addressing.
• Know your platform limitations: If you're using .NET 1.1, then you've got very limited options (WSE 2.0); If .NET 2.0/3.0 then at least you have a much more modern WSE 3.0 and WCF options at your disposal.

One hand giveth, the other taketh away

If you're using WCF, understand the choices it makes for you and how to work around them. For example, Data Contracts in WCF aim to improve interoperability by severely limiting the kind of XML structure you can use (elements only and so on). This, however, doesn't help you if you have to work with specific schemas designed by someone else (like standard industry schemas), so be ready to fall back to the old trusty XmlSerializer.

Another thing that might impact you is WCF's default behavior in generating split WSDL descriptions where the schemas are imported (and possibly other WSDL documents as well if your service elements have different namespaces); a lot of external tools choke on those service descriptions. Again, let me point to Christian Weyer's excellent article and code sample to ease the pain of this.

Web Services, Interop

My good friend Christian Weyer shows how to take advantage of WCF's extensive extensibility model to improve interoperability with other Web Services stacks by simplifying the WSDL generated by WCF to get rid of all the <xsd:import> and factored WSDL files. Here, he takes my InlineXsdInWsdl behavior to new heights and adds a bunch of hosting goodness to make using it a lot simpler.

Cool stuff, and really useful stuff to have around! Thanks for sharing!

Windows Communication Foundation, WCF Extensibility, WSDL

I've spent some time playing with the recent BizTalk Services CTP SDK (way cool stuff!), and ran into a weird error that perhaps others might run into: Sometimes, but not always, I would get an error when trying to use any of the BizTalk Services WCF extensions, like the relay channel, during initalization.

For example, if I wanted to start the service part of the Echo sample included with the SDK, sometimes I'd get the following exception during the host.Open() call:

at System.ChannelFx.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open()
at Microsoft.ServiceModel.Relay.Samples.Program.Main(String[] args) in C:\Pro
gram Files\BizTalk Services SDK\Samples\EchoSample\Service\Program.cs:line 32

I couldn't figure out why this was happening at first because I couldn't always repro it. What I'd do then is just start closing stuff (thinking perhaps it was some sort of resource exhaustion) until it started working again. But then I noticed that whenever this was happening, the Cardspace Card Selector UI, when launched manually through the Control Panel, would fail to start up as well. I would get the following error and then the infospace.exe process would hang in memory until I manually killed it through Task Manager:

Checking the windows Application Log I'd see this:

The Windows CardSpace user interface process failed in its initialization phase. This might be due to an error during the creation of the private desktop. Exception of type 'Microsoft.InfoCards.UIAgentInitializationException' was thrown.

Not very useful, but it was a place to start. I started looking again to see what I had running (all sorts of stuff) and trying stuff out until I found the culprit: Console. I love using Console instead of the regular cmd.exe plain because it is more configurable and has a tabbed interface. Plus, I have configured default shells for both cmd.exe and PowerShell that I can launch quickly with a single keystroke.

For some weird reason, though, it appears that the Cardspace Card Selector User Interface refuses to start on my Windows Server 2003 R2 virtual machine (VPC2007) as long as Console is running. Close Console, and both Cardspace and the BizTalk Services SDK samples start working again perfectly.

No idea why this happens, as the Cardspace UI works just fine even though Console is running on my main Vista machine, but there you go.

BizTalk Services, Cardspace

Recently the Connected Systems Division at Microsoft has been working on some experimental public stuff that is way, way cool. From all they are working on, there is now two publicly available experimental services you'll really want to check out:

The STS: Security Token Service

This is an open identity provider service that integrates with Cardspace to provide authentication for the other CSD services. Building a robust, secure, scalable and fully fledge STS is not trivial, and this is really good stuff.

The Relay Service

The relay service is really exciting, as it provides a way for applications exposing services (which might be behind the firewall) to expose a public endpoint that can be accessed from outside the firewall, without the developer having to care about the network topoogy. Basically, when the service is started it registers with the Relay service to define a public endpoint through which a client can access it.

Both of these services fully integrate with the .NET 3.0 platform (particularly WCF), and they are really interesting ideas that the CSD is exploring. And there are even more of these kind of things coming down the pipeline which are even more exciting! Really recommend keeping an eye on these!

Note: Do remember this is just lab, experimental stuff. It is not production ready for now. There are no SLAs, no confidientiality, support or guarantee about them!

WCF, STS, Relay Service