on Service Orientation (so) vs Object Orientation (oo), which is an interesting discussion.
While he's done a good job framing the discussion in a comparison table, I have some comments on his informal comparison.
Here's the table, with my modifications in green and bold
. I've struck through verbage that I thought should be removed and followed the table with some general comments.
|What is it?
||Modeling, Design, Architecture
||Modeling, Design, Architecture, Progamming (Languages)
|Very Coarse Coarser) (also see this) |Object/Component-Level (
|Fine to Coarse Finer)
||Service-Level, Inter-Service via service requests
||Object/Component-Level, Inter-objects/components via
||Document-based or RPC exchanges with services
parameters exchanges with objects/components or invocations of polymorphic signatures with document-like self-contained arguments
||You choose - OO Languages (see
here), Procedural Languages (see
||Lots of choice here too...Java, C++, C#, Smalltalk (see
Scripting: Ruby, Python (see
||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.
||High - lots to worry about - standards, interoperability,
||Medium to High depending on what you are building
||Established Mature IDEs in the market
||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
The granularity discussion is usually ambiguous, since there's no clear definition of "coarse" and "fine". Thus, I think simply relying on a comparative description makes more sense (ie: coarser and finer).
This point that a more comparative description is more valuable gets to a defining characteristic of this whole discussion, which I believe is one of scope. As we move from OO and Components to Services (and within services, as we move from smaller to larger EAI-based projects to B2B projects), the scope becomes broader
and with this broader context comes changing requirements, less control over messaging endpoints and protocols, less control of security schemes, less control of business document semantics, etc, etc. So as we broaden the scope,
there often is a greater value placed on standardization as a means to achieve the interoperability goals for which so many organizations strive.
As for Interaction Model, while aysynchrous, doc-based interactions are becoming more common and are preferred in many scenarios, there continues to be a large number of RPC-style interfaces. For simpler interactions, this is
a perfectly reasonable interaction model, and the simpler REST model has a valid place in the mix. Additionally, it's not uncommon for OO and Component signatures to accept self-contained document-like objects.
One more minor point on the "Programming Languages" category. I think it's a bit confusing, because it only applies to one dimension of the discussion. For example, one can do OO modeling/design and then do a C-based implementation. I maintained a codebase that
was done this way and I'd say it was a successful project, but maintenance was challenging because the code was not explicit at all (lots of pointers to functions, etc). So, while I would not recommend anyone design in a vacuum, there certainly
have been many examples of OO projects using an OO design with a more procedural implementations. (In fact, I've seen quite a few of these in Smalltalk, as well).
Well, that's all I've got for now. I think this is a good starting point for some valuable discussions.
What do you think?
Look forward to your commments on this topic.