The role of objects in service-oriented systems

Jon Fancey commented on my last post about OO and SO:

Dude, I agree with you 100%. I share your fear; like I think I said at the XML Dev Con though, I can't help feeling that with >6m developers on the planet and 100 people at the conference that what we say as a 'closed' group is largely irrelevant. I refuse to think like that because it's too depressing but come on, what is Indigo if it isn't a replacement for COM and .net remoting? Everyone is making Web services look to the developer like the next distributed object ecosystem with handy-dandy mapping to their favorite language. Why on earth do we need WS- atomic transactions etc otherwise? There are plenty of more losely-coupled ways to model such required abstractions. Way too few people are thinking that the message is what's important and how it gets from A to B is an implementation detail. I just don't know what to do about that. Maybe we're the ones that are wrong?

I don't think we're the ones that are wrong. If SO is really just OO with angle brackets, then it's pointless. If you think that the only problem with the distributed object technologies is that packets on the wire and interface definitions didn't use angle brackets, you are very much mistaken. The problem was brittle systems that had to be deployed en masse. That is what Web services aim to fix.

That's why the clause in the WS-Addressing spec submitted to the W3C that I cited last week bothers me so much. Do we really want to introduce the notion of “an instance of a stateful service“? What is the difference between that and a distributed object? More importantly, what does it mean in the context of a server farm? If a service implementation requires pinning to a particular server to work, then it isn't going to work in a real enterprise environment.

None of this is to say that objects don't have a place in the implementation of a service-oriented system. Objects are a good way to implement a service. There are just two things we should NOT do:

1. Believe that objects are actually integral to the Web services model for a distributed system. Objects are a very useful implementation technique, but nothing more. If a toolkit ends up using objects instances to represent stateful service instances, in which case we as an industry will have to figure out how to use that toolkit appropriately to build Web services the right way.
   
2. Assume that a generic object/xml will achieve what we really want. In general, you want an internal object model that you use to implement your core logic. It is almost never the object model you get when you consume a schema. Given that, you have to write code to translate from the data coming off the wire to your own internal format. That's true whether the data coming off the wire is viewed as raw XML or an object model that a serializer built for you. (I should note that, despite my reputation, I'm actually not against object/xml or object/relational mapping tools, provided they're based on your problem domain. I take that position because, while I've seen many examples of custom mappers that worked within the scope of a given system, I've yet to see on that was both generic and actually worked well enough to use.)

Many of use remember the pain involved in figuring out how COM+ and J2EE should really be used (or not used), despite what vendors and/or pundits said. So take heart Jon; we can do it again if we have to.