- We are not alone in this confusion about the overlaps and differences between
all things in SOA.
- 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)|
|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
|Interaction Model||Document-based exchanges with services||RPC
parameters exchanges with objects/components
|Programming Languages||You choose – OO Languages (see
here), Procedural Languages (see
|Java, C++, C#, Smalltalk (see
Scripting: Ruby, Python (see
|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)
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 Complexity||High – lots to worry about – standards, interoperability,
|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
Everest – but it is not all into thin air
|As low as Death
Valley – 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.