More on Web services and distributed objects

Dave Orchard posted a response on my last post about the relationship between services and distributed objects. Today, the answer is that Web services are not less brittle than distributed objects, largely because of tooling. How come I blame the tools? Because vendors keep telling developers that they shouldn't have to know any XML details to make Web services work. Instead, it should just feel like something that they're already familiar with: method calls and objects. In confusing something familiar with something easy, vendors are building the same thing we had before. My point is that it isn't really the details (because tooling is going to try to hide them), but the model that matters. If most developers see distributed objects, than that's what Web services will be. The obvious point of contrast in the .NET world is WSE's low-level messaging API. Yes, it still uses objects and methods, but the methods have one in parameter and a return value, both of which are messages.

My concern about using EPRs to reference stateful instances of services actually depends on how toolkits choose to implement it. If a toolkit dispatches a call to an object instance that lives just long enough to process the input message and generate an output message (if any) and leaves it to that object to map additional header info to some sort of state management mechanism, that might be okay. If a toolkit does that mapping for you, i.e., it uses the header info to map to an object that maintains state, that would not be okay. The difference is that in the first case, the developer is forced to be deliberate about how state is managed in their system.

So why do I want to force the developer to do more work that the plumbing could potentially hide? The answer is easy: I believe that the only way we'll get the organic ecosystem of loosely-coupled services that we all want is if developers are deliberate about how they deal with message data, behavior and state. Right now, we rely too much on our tools to handle a lot of these details for us, and they make assumptions that let us down.

(This may still qualify as “yucky thinking” from Dave's perspective. If so, I'll try to do better.)