Service-Oriented vs. Object-Oriented

Avery is going through the thrashing of trying to morph an object-oriented mind into a service-oriented world. He’s getting the right answer, but I don’t think he’s getting there the right way.

Avery is trying to place them on equal footing and then decide which one is better to use, but he could have saved himself a lot of trouble by realizing up front that object-oriented programming and service-oriented programming are best used for different things. Object-orientation provides a many advantages to somebody programming who already has great deal of knowledge about the system. Encapsulation, polymorphism, and the bundling of code and data together all make it easy to produce elegant yet complex systems that require a great deal of pre-knowledge to use. But let’s face it, if you don’t have perfect knowledge of the system, knowing how to use an object is really hard. Throw distributed object-oriented computing into the mix, which brings problems like lifetime, persistance, and marshalling, and you have yourself a good old-fashioned nightmare. If you don’t believe me, you’ve never spent much time trying to make Microsoft’s distributed COM work right.

Service-oriented programming solves these problems by taking a step backwards, by taking objects out of the mix. It isn’t that different than the procedural coding style developed hand-in-hand with C and UNIX: You have a bunch of utility functions that are strung together in a certain order to Get Things Done. The difference between now and then is XML. Thanks to the beauty of , now we can make our procedures flexible enough to withstand the changes that so often break the tightly-bound world of objects. As a bonus, since it was built from the ground up on web technologies, we get a stateless, scalable, distributed system for free.

So when should you use one or the other? Avery is dead on when he states that a service-oriented system is totally money when it comes to subsystems that a) could be reused, or b) will probably morph over time but can’t break legacy systems. These cases need to be considered, though, since parsing XML is expensive. Use objects when everything is a single whole, and where the interfaces between the subsystems won’t be changing much. Even if you’re cross-process, if interfaces aren’t going to be changing, then just use remoting. It’s a heckuva lot easier than putting together a web service. The speed and elegance and expressiveness of objects are a big win for developer productivity. Often, I find that I leverage object-oriented capabilities to hide the fact I’m calling a service. It’s simple to wrap a call to customer.Login(credentials) can easily wrap a call to CustomerService.Login(credentials).