n-1+Soup [Danny Malks' Blog]

Service Orientation and Object Orientation

Deepak Alur recently posted 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.

Compare	Service Oriented	Object Oriented
What is it?	Modeling, Design, Architecture	Modeling, Design, Architecture, Progamming (Languages)
Exposes	Services	Methods
Granularity	Business-Level (Very Coarse Coarser) (also see this)	Object/Component-Level (Fine to Coarse Finer)
Interaction	Service-Level, Inter-Service via service requests	Object/Component-Level, Inter-objects/components via method calls
Interaction Model	Document-based or RPC exchanges with services	RPC parameters exchanges with objects/components or invocations of polymorphic signatures with document-like self-contained arguments
Programming Languages	You choose - OO Languages (see here), Procedural Languages (see here)	Lots of choice here too...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

Some comments:
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.

Posted at 01:09MD Nën 01, 2005 by malks in General  |  Comments[2]