SO and OO: on the edge of madness

I've been on the road for a couple of weeks, first at the Applied XML DevCon, then WinDev in Boston, then at the WS-I face-to-face last week in Miami. But now I'm back in the office with time to think and write...

At the end of October, I posted about OO and SO. Jon commented that it wasn't so much an issue of treating services like objects as of identifying information you want to operate on. I agree that you have to very careful to select identifiers whose meaning a service and a client can agree on and which will stable over time. (In fact, a lot of the work I did at MSDN was focused on solving this very problem.) But I do think that the object issue still exists...

As .NET Remoting demonstrates, you can use SOAP and WSDL to describe a rich distributed object system, including support for controlling object lifecycle from a client. But that doesn't mean that a Web service client can talk to you. In fact, in many cases, a remoting endpoint accessed via SOAP cannot be accessed using an ASMX client - a technology that shipped in the same release. Was the remoting stack doing anything wrong or illegal? Well, ignoring the cases where it refered to CLR namespaces as if they were well-known, the answer is no. What it did do, however, was make use of the legal extension points in XSD, WSDL and SOAP to include the information that a remoting client needed to achieve all kinds of rich interactions. Unfortunately, no other Web service kits knew about that special stuff, or what to do with it.

The most obvious problematic piece of this is instance lifecycle. So far, one of things that differentiates Web services from distributed object technologies is that, like traditional Web applications, Web services have been stateless (there is almost always state stored behind the Web service, but it isn't part of a service instance that's somehow bound to a specific client instance). It's interesting to note, then, the following paragraph from section 2 of the draft of WS-Addressing that was submitted to the W3C in August:

Endpoint references will be used instead of WSDL <service/> elements in the following cases:

• Specific instances of a stateful service need to be identified or its instance-specific configuration details need to be transmitted.

This makes it sound like an endpoint reference is -- or can be -- an object reference, a la' DCOM, CORBA or Java RMI.

Of course, nothing requires that someone use an EPR that way. But if vendors provide tools that hide all this stuff (and surely that is their goal), someone might not even know. In that case, we'll end up in a world where developers have to look at Web services as a whole and then figure out which bits to use to get the loose architecture they want instead of the is-it-a-service-or-is-it-an-object-oh-who-cares thing they might accidentally end up with.

Lately, I’ve started to wonder how much of a risk there is in drawing too close a connection between Web services and objects. I heard someone say last week that if we, the industry, couldn’t get XML to object mappings working for all of XML Schema, then Web services would fail. I don’t believe that’s true. But I do worry that people who want to send XML messages will look at all the Web service infrastructure as it is presented in the tools and conclude that it’s really for distributed objects and that if you just want to do XML messaging, you should look elsewhere.

This concern has been amplified this week because I’ve been spending time looking at various standards for industry-specific messages. If two businesses want to integrate their systems using IFX, OFX, OAGIS, Accord, HL7, Parlay-X, etc, how they choose to transmit their messages including using Web services is really an implementation detail. Clearly Web services provide a range of benefits as an implementation technique, but Web services themselves are not the goal. It’s really about getting a message payload to the other party in a format that they can understand. That can be done in any number of ways.

If we focus all our energy on making messages and endpoints look like objects, we are likely to ignore the people who just want to make systems interoperate by sending XML from A to B. If people who want to do that look at Web services, think “Hmmm. That’s about objects. I want to send XML. I guess it isn’t for me.”, and move on to send raw XML over HTTP, message queues, email or whatever, then the WS stack will be irrelevant. Put another way, while you can use SOAP/WSDL/XSD/etc. to build a distributed object system, that’s a dangerous place to go because you are using technologies everyone associates with Web services and building something that is not, at least in my opinion, a Web service. And muddying these waters at this point is a really bad idea.