Web services and distributed objects, part n

My last post on SO an OO drew a number of comments. John agreed with me that if toolkits focused on message-oriented APIs instead of method-oriented ones, we'd be in a better place. That's one of the reasons I love WSE's low-level messaging API. Yes, it maps requests to methods, but they have one input parameter representing the request message and one optional return parameter representing the response message, if any. JoeW disagreed, observing that seeing messages vs. methods with multiple parameters didn't make any difference in terms of degree of coupling between services. I actually think that it does, not because of anything technical, but because it suggest that developers should think about service operations the same way they think about object methods. If you believe in the SOA tenet that service boundaries should be explicit, I think the WSE interface forces you to embrace that belief.

DaveO also commented on my thoughts about state management. He pointed out that there is no protocol-level difference between stateless services that access state internally and stateful services. I agree, but again my goal is to encourage developers to think about services differently than they think about objects. If toolkits make it really easy to build stateful services, then we’re going to end up right back at distributed objects again. This is another reason I love WSE’s low-level messaging API. Yes, it maps services to objects, but they only exist for the duration of a single invocation. Any state that has to be maintained across invocations must be stored outside the object instance.

Dave also asked how I felt about infrastructure state, as opposed to application state. His point, I think, is that secure conversations, reliability, atomic transactions and business activities all require different sorts of session state. Infrastructure that implements those protocols may need to use stateful service instances to do that. Does the need to support that outweigh the risk that developers might create stateful service instances as well, accidentally leading us back into distributed objects yet again? I don’t know.

I do think that there is a separate issue with infrastructure state that people should think about. Various WS-* specs define session-oriented protocols that rely on “meta connections” instead of transport connections. It is still unclear (to me at least) how much complexity and overhead management of that session state will add to a system. (Chris Keyser’s recent MSDN article about managing secure conversations in a Web farm provides an example.) Will the benefits these protocols provide outweigh these costs? Or will different designs based on transport-level techniques prove simpler to implement, despite (perceived) limitations?

I think the main thing for both APIs and state management is that I want tools that allow/require developers to be deliberate about what they’re doing. That’s the only way I’ve ever seen a distributed system work. I think Tomas summed it up nicely in his blog post:

“This is a really good example about how you want a toolkit (or framework, or whatever) to handle the mundane tasks, but leave the important ones to the developer.”

Amen, brother.