Home

Note: moved from the Development site Sept 24 2008. small edits

The Oasis standards organization published a Reference Model for SOA ( Service Oriented Architecture ) not too long ago. In it, they compared SOA and OO ( Object-Oriented ) technologies. While I don't agree with them entirely ( or even mostly ) on the strengths and weaknesses of SOA versus OO technology, here is an extended quote of what they have to offer on the subject.

Unlike Object Oriented Programming paradigms, where the focus is on packaging data with operations, the central focus of Service Oriented Architecture is the task or business function – getting something done.

This distinction manifests itself in several ways:

· OO has intentional melding of methods to a given data object. The methods can be thought of as a property of the object. For SOA, one can think of the services as being the access to methods but the actual existence of methods and any connection to objects is incidental.

· To use an object, it must first be instantiated while one interacts with a service where it exists.

· An object exposes structure but there is no way to express semantics other than what can be captured as comments in the class definition. SOA emphasizes the need for clear semantics.

Both OO and SOA are as much a way of thinking about representing things and actions in the world as these are about the specifics of building a system. The important thing is understanding and applying the paradigm. So the question is not “what is a service?” any more than it is “what is an object?” Anything can be a service in the same way anything can be an object. The challenge is to apply the paradigms to enhance clarity and get things done. SOA provides a more viable basis for large scale systems because it is a better fit to the way human activity itself is managed – by delegation.

Methods as Activations

The first thing I noticed was the statement that "the methods can be thought of as a property of the object". One can think of object methods as properties only by working at it very hard. Methods are activations, usually of multiple objects and potentially of distributed projects in various states of  activation.

Perhaps the author(s) meant to indicate "closures", like PHP or Javascript closures, which are in no way an insignificant feature and are extremely useful for dynamic programming. But properties and closures are very different from object methods, which are ultimately something an object 'knows' how to do - it's a very powerful and generalized concept.

Delegation of Responsibility

The second thing I noticed was "to use an object, it must first be instantiated while one interacts with a service where it exists". That's a product of delegation, that is, the responsible object performing its assigned duties. That's what the Gemstone OODB does so well. In fact, it seems to me that the idea of delegation is very useful in "control of different ownership domains", which is at the core of the definition of SOA. 

Not Dynamic Enough ? Or Too Dynamic ?

The third thing was "an object exposes structure but there is no way to express semantics other than what can be captured as comments in the class definition". Ignoring the fact that class comments can be exported and that in most OO implementations, an object can publish its structural description as meta-data, the author misses a critical feature. In Smalltalk ( of which I am obviously a partisan ), you can go to the "Class class" and add a new variable for meta-data and, bingo!, every class object in the system suddenly has a new slot for meta-data. It couldn't be more extensible or dynamic. One criticism I hear about Smalltalk is that it's too dynamic and extensible. 

Mixing Apple and Oranges ?

The SOA verus OO debate may be the result of mixing partially unrelated issues, that is one would use OO technology ( or not ) to implement SOA architecture, depending on the circumstances. But when I see terms like "execution context" and "behavior model" as appear in the Reference Model, my attention is inescapably drawn to Smalltalk, which has had concrete implementations of those concepts since ... when ? ... the mid-1990s ? Or even late 1980s ? A long time. 

Are Agents the Same as Objects ?

The major extensions beyond the Smalltalk OO model seem to be on the area of interactions, such as Semantic Engagement, defined as "the relationship between an agent and a set of information that depends on a particular interpretation of the information". The word 'agent' is mentioned only a few times in the Reference Model, such as "one computer agent’s requirements being met by a computer agent belonging to a different owner", but the idea of agents seems to be the underpinning of several other definitions as well.

For example , the authors define Awareness as "a state whereby one party has knowledge of the existence of the other party". What are those parties ? In all likelihood they are software agents. The document continues on to say that "awareness does not imply willingness or reachability", again, clearly agent-like capabilities. 

Are Oranges Better Than Apples ?

So they seem to be mixing apples and oranges a bit in the Reference Model. Or maybe they are mixing oranges and grapefruits, which are similar but certainly not identical.

Nonetheless, the Reference Model is at least lucid enough to spark disagreements over exact definitions and details, which is a big improvement over much of the hazy, marketing-oriented literature about SOA one finds on the web.