John Wood

The Two Faces of SOA

To OOP fanatics Service Oriented Architecture is a language that different applications speak to each other in order to integrate. The applications are usually developed using OO technologies, but SOA provides the glue between them because OO falls down in this regard.

And then to others SOA is procedural programming in disguise. More precisely it's seen as an emergence of concepts that include procedural programming, data centric programming, and ubiquitous protocol standards for communicating this data between the procedures. 

Don't get me wrong, SOA can quite happily exist in both worlds, for better or for worse. Clearly the latter group is utilizing SOA at a much deeper level, and the former's adoption could be seen as merely cosmetic and convenient. They both have that SOA signature though. But which is better off?

Some people have said that it is SOA's current implementation that limits it from integrating better with object oriented designs. I feel this is wrong because object orientation is fundamentally founded on the concepts of exposing data piecemeal and only through agents that encapsulate the data. This approach is diametric to SOA where the focus is on data sets and schema and discovering services that can add value to that data.

Talking of data sets, Microsoft sneaked in a very SOA like model with their DataSet implementation, which is clearly not object oriented (there was no way until recently, for example, to add your own 'business logic methods' to a typed DataSet). This model clearly puts the emphasis on data and writing services that 'do things' with this data. Poor man's SOA perhaps, but definitely smells like SOA to me. A programmer's use of DataSets is usually a good indication of which of the two camps they fit into.

I think the biggest benefit people have drawn from using SOA concepts at the application level, rather than inter-application level, is that of loose coupling. Objects just don't loose couple very well. Sure you can have interfaces, abstract base classes and polymorphism to produce something that seems quite 'loose' - but it's not really. It's far more difficult to put OO applications into a remoting situation to reap the benefits of client/server computing, because objects are so tightly bound to an application instance. It's also far more difficult to persist and version objects, simply because the data representation of an object is often an after-thought. And of course everyone knows the integration benefits of SOA.

To be honest there are benefits and drawbacks to both approaches. SOA is certainly the trend at the moment, mostly because people are looking for less complicated and more enterprise-sociable solutions than OO designs offer. As to which approach will prevail, only time will tell.