Web Services Enhancements

~ the goodbye ~

There is a sentence in a Microsoft support blog post from October 2012 that does more damage than any shutdown notice could. "Please note that even the latest version of WSE, WSE3.0, was never tested or supported on Vista or later operating systems." Vista shipped in January 2007. The post was written in 2012, about a product Microsoft was still nominally supporting, to explain that its final release had never been certified to run on any version of Windows released in the previous five years.

Web Services Enhancements was an add-on to the .NET Framework, first released in December 2002, that implemented the WS-* specifications: a sprawling committee-built stack for putting security and reliable messaging on top of SOAP. The pitch was reasonable. SOAP by itself could move an XML message between two machines, but it had nothing to say about who had signed that message or whether anyone had read it on the way. WSE filled that in, and developers could switch the behavior on in code at design time or through a policy file at deployment.

It arrived in three versions in three years. WSE 1.0 in December 2002, built against a draft of WS-Security that was still moving, using an older XMLSOAP namespace that the eventual standard abandoned. WSE 2.0 in May 2004 added Kerberos security context tokens and a policy framework built on WS-Policy. It could also carry SOAP over raw TCP instead of HTTP. WSE 3.0 arrived in October 2005 with a 64-bit runtime and the first proper Visual Studio design-time support. The versions installed side by side because they had to: 2.0 and 3.0 could not talk to each other.

This was enterprise plumbing, and I was not in the enterprise. I was a university student in Ankara through most of WSE's life, and the SOAP I met was the kind you read about in a distributed systems course rather than the kind you get paged about at two in the morning because a signed header stopped validating after a framework patch. Nobody writes nostalgia posts about WS-SecureConversation. It is in this file because somebody had to maintain it, and because the way Microsoft ended it is genuinely odd.

~ the chronicle ~

~ the specification pile ~

WS-* was an attempt to build the entire capability set of a distributed system as composable XML standards, written by committees including Microsoft and IBM. WS-Security, WS-Policy, WS-Addressing, WS-Trust, WS-SecureConversation, WS-ReliableMessaging. Each was a document with a Microsoft implementation somewhere inside WSE. The whole stack assumed that two systems which had never met could negotiate a secure session out of XML alone.

The idea lost, and it lost decisively to REST over HTTPS, which solved a smaller problem with equipment everybody already had. By the time WSE 3.0 shipped in 2005 the argument was already going the other way. What survived from the pile is narrow but real: WS-Security's message-level signing lives on in SAML assertions, and anybody doing enterprise single sign-on today is standing on parts of it.

~ the support date that belonged to something else ~

Windows Communication Foundation shipped with .NET Framework 3.0 in November 2006 and did everything WSE did, in one coherent programming model, with the same WS-* specifications underneath. WSE 3.0 was wire-level interoperable with WCF over HTTP, which was the migration path and also the admission. Microsoft published a guide called "Migrating WSE 3.0 Web Services to WCF" and stopped developing WSE entirely. There was never a WSE 4.0.

What there was instead is a support policy, and it is the strangest thing in this grave. Microsoft's rule was published plainly: "Support for WSE is tied to the Support Lifecycle of the Microsoft .NET Framework." WSE 2.0 inherited the lifecycle of .NET Framework 1.1. WSE 3.0 inherited the lifecycle of .NET Framework 2.0. So WSE never got an end-of-life date of its own. It got somebody else's, and that date was 12 July 2011, when .NET Framework 2.0 went out of support and took WSE 3.0 with it on the way past.

A product with no announcement and no final release, carrying an expiry date that nobody had chosen for it. It ended because something else ended.

~ what it got right ~

WSE was correct that messages need security of their own, separate from the pipe they travel down. HTTPS protects a connection between two endpoints, and the moment a message passes through a broker or a queue or a gateway, that protection ends and starts again as something new. Signing and encrypting the message itself survives every hop. That argument was right in 2002 and it is still right, which is why it keeps being reinvented under new names by people who have never heard of WS-Security.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »