SOA: OO and SO – How You Gonna Get There?

is encouraging to see James Gosling blog
about Service-Oriented Architecture (SOA)
. It is encouraging because:

  1. We are not alone in this confusion about the overlaps and differences between
    all things in SOA.
  2. Hey! It is James Gosling talking about SOA!

I agree with James that there is a camp that things SOA and OO are distinct
camps. To me SOA is a goal and Object Orientation (Design/Programming/Modeling)
is one of the fundamental ways to get there. SOA is the destination and the
journey, and OO is the vehicle to get there in good shape. I say in good shape
because you can still get there without using OO, but you might not be in as
good of a shape as you would have if you had used OO.

For example, say you want to go from point A to point B and you have a choice
between using different modes of transportation (car, bicycle, skateboard, Segway,
on foot, etc.). Which one would you use? What? You want to know how far you
are going? Ok. Let’s say you are going to the next block to meet a neighbor.
What do you use? What if you are going a few blocks to get a carton of milk
from a neighborhood store? What if you are going the same few blocks but to
get your groceries for the whole week? What if you are going a few hundred miles
to visit your family? Would you use a skateboard or a Segway to travel a few
hundred miles to visit your family? (Not unless you want to make a new world
record). Now, would you choose to use the same mode of transportation for all
of these? Of course not. [If you do, you need to go back to the beginning and
read again until you get it right. :-)]

Why not think about SOA the same way? If SOA is the goal, the destination,
and the journey, then which means (modeling, design, programming, language)
would you choose to get there?

The following is an informal comparison of SO and
OO and how things fall in or out of place:

Compare Service Oriented Object Oriented
What is it? Modeling, Design, Architecture Modeling, Design, Architecture, Progamming (Languages)
Exposes Services Methods
Granularity Business-Level (Very Coarse) (also see this) Object/Component-Level (Fine to Coarse)
Interaction Service-Level, Inter-Service via service requests Object/Component-Level, Inter-objects/components via
method calls
Interaction Model Document-based exchanges with services RPC
parameters exchanges with objects/components
Programming Languages You choose – OO Languages (see
), Procedural Languages (see
Java, C++, C#, Smalltalk (see
more here
Scripting: Ruby, Python (see
more here
Standards No Holistic SOA standard. Bits and pieces based on Web Services Standards.
You have to figure it out on your own. Plenty of competing and overlapping
standards and specifications in Web Services space. (also see this)
CORBA (for
language-neutral distributed objects), J2EE
(for Java based distributed programming), .NET
How to model/design it? Emerging best practices. No standards yet. Lots of patterns and best practices. Excellent tools.
Mature knowledge base in industry.
Overall Maturity Low-Varies High
Overall Complexity High – lots to worry about – standards, interoperability,
integration, etc.
Medium to High depending on what you are building
Development Tools Emerging, Varied. Established Mature IDEs in the market
Hype Factor As high as Mount
– but it is not all into thin air
As low as Death
– but it is not all under the sea

To reiterate what James said,
I quote him: "Proper OO structuring is always a good idea."
Great advice from the wise. I for one am going to follow it.


Published by


Cofounder & CTO @