Jumping the Hurdle: Moving from OO to SOA

A comment made by Udi Dehan on my most recent article (the Benefits of a Service-Oriented Architecture) got me thinking.  In the comment and on his blog he has been contemplating the differences between OO and SOA and, more importantly, how programmers can adjust.

First of all, I believe that the idea that the debate is an either/or proposition is wrong.  Not everything should be represented as a service.  Nor should everything be represented as an object.  There are times when the interface represented by a service layer is the better way to go.  However, even for the more devout SOA believers, that idea that the implementation of a service won't contain objects is ludicrous.

That having been said, I believe that designing using SOA is more of a mindset than a programming style.  And the trick to becoming proficient is to be aware of the differences between OO and SOA, at the conceptual level.  At first glance, it might seem that the main difference devolves into an argument about Remote Procedure Calls (RPC) versus document-based method calls.  However, I believe that the distinguishing characteristic is actually more likely to be statefulness than the calling technique. 

In a traditional object-oriented application, the typical sequence of steps to invoke a method is as follows:

  1. Instantiate an object
  2. Optionally set some property values
  3. Call the method, including any necessary parameters
  4. Wait for a response

Inherently, these steps are stateful. An instance of the object must exist before the method can be called.  Properties in the object can be set, either through the constructor or by direct assignment.  The fact that these properties are available for use within a method means that the object maintains state.

But what about static methods.  It is possible to define a method on a class that doesn't require an instantiated object to be used.  The methods don't have access to the instance-level properties and methods.  How could they? No instance has been created.

However, even static methods can be stateful. Classes can also define static properties.  Static properties can be assigned values, values that can be used by static methods.  Therefore the mere inclusion of static methods is not a sufficient condition for statelessness.

“But wait a second”, you say. “What if the static method didn't use any static properties?  What if all of the external values required by the method are included in the parameter list?  Surely that's not stateful!”

Of course, you'd be right.  If all of the required information is available to a method through the parameter list at the time of the call, it is no longer a stateful operation.  But here's the real kicker.  Convert the parameter list into an XML document. Pass the document into the static method and you have just created the skeleton of a service.  A message (the XML document) is passed into a service provider (the static method) which intrinsically knows how to process it.

And therein lies the difference between OO and SOA.  It's not that the two aren't related.  It's that SOA is much more demanding about how programmers interact with it. Kinda nice when knowledge sneaks up like that, isn't it?