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.
Hi Deepak,
I think your articles show that you have some valuable ideas on SOA, but in this instance I believe you missed the essential point in James's blog.
Briefly, I believe (and I believe James stated) that <u>SOA is OO</u> applied to designing instances and interactions of distributed service components.
I've presented this view in the past, but I talk about this and other aspects of SOA more recently in my blog over on colmsmyth.blogspot.com - I'd welcome the opportunity to have a dialogue about SOA with you, either by mail, blog-comments, or perhaps most interestingly as blog-posts.
All the best,
Colm.
Posted by Colm Smyth on October 22, 2005 at 06:15 AM PDT #
Hi Colm,
I don't think I was missing the point James was making. I was only attempting to add to what he already said. I wanted to deal with the notion that SOA and OO are distinct.
Thanks for the comments and pointing me to your blog . I like it. Appreciate your insights.
Posted by Deepak Alur on October 22, 2005 at 10:10 AM PDT #
Posted by Colm Smyth on October 26, 2005 at 03:27 PM PDT #
Perhaps, I think the confusion in my entry was because I used "SOA" instead of "Service Orientation" as the title of the first column. I changed it to "Service Orientation" to make my comparison more appropriate.
I don't think SO and OO are distinct, and I don't think they are the same either. I can't think of SO or SOA is a <EM>subset of OO applied to web services invocation</EM>, if the emphasis is on "web services". I find it too restrictive to think of it that way if SOA is all inclusive (i.e. not just "web services"). But if the question was whether I thought <EM>SO</EM> (not SOA and not SOA applied to WS) <EM>was a subset of OO</EM>, then the answer is <EM>yes</EM>.
To reiterate my point (was and) is that SOA is an architecture and Service Orientation (SO) is the approach to get to SOA. SOA & SO can be achieved using OO better than any other approach. And as you put it, SO can be viewed as a subset of OO.
That helps? :-)
Posted by Deepak Alur on October 29, 2005 at 07:06 PM PDT #