SOA: OO and SO - How You Gonna Get There?
It
is encouraging to see James Gosling blog
about Service-Oriented Architecture (SOA). It is encouraging because:
- 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) |
| 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 here), Procedural Languages (see here) |
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 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.
SOA OO
Software
Architecture Programming
Add comment October 18th, 2005