RE: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)

["Metz Rebekah" <metz_rebekah@bah.com>]

A couple of thoughts on the OO/SOA comments.
________________________________________
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Saturday, April 08, 2006 6:07 PM
To: SOA-RM
Subject: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)

This is the follow-up to the question I raised at the end of the last telecon on where to suggest other changes to PR1.  Many of these come over from the previous thread on "comments collected from SOA-RM presentation".  Hopefully, I've incorporated everyone's major points but I welcome the coming discussion to highlight any I missed ;-)

Note, this email does not include the two points requiring considerably more thought:
- how to rephrase (rename) shared state and its use with real world effect in lines 277-286 and in section 3.2.3
- arrows and their directions in diagrams
These are being worked separately; hence, the (Part 1) in the subject line.

1. Suggest incorporating some of the discussion of differences with OO by adding to lines 218-221 as follows:

Unlike Object Oriented Programming paradigms, where the focus is on packaging data with operations, the central focus of Service Oriented Architecture is the task or business function - getting something done. This distinction manifests itself in several ways:
* OO has intentional melding of methods to a given data object.  The methods can be thought of as a property of the object.  For SOA, one can think of the services as being the access to methods but the actual existence of methods and any connection to objects is incidental.
[RLM]  Would it be fair to characterize OO as follows: The object (thing) is primary and all other concepts rely upon the object as context?

* To use an object, it must first be instantiated while one interacts with a service where it exists.
[RLM] I suggest that instantiation is strictly a technical implementation term here and would be better suited to a discussion w/in the context of a reference architecture.   Both this statement and the second seem to differentiate OO and SOA from a system design paradigm rather than an architectural perspective.  Maybe we need to poke a bit more at that differentiator?

* An object exposes structure but no way to express semantics other than what can be captured as comments in the class definition.  SOA emphasizes the need for clear semantics.

Both OO and SOA are as much a way of thinking about representing things and actions in the world as these are about the specifics of building a system.  The important thing is understanding and applying the paradigm.  So the question is not "what is a service?" any more than it is "what is an object?"  Anything can be a service in the same way anything can be an object.  The challenge is to apply the paradigms to enhance clarity and get things done.  SOA provides a more viable basis for large scale systems because it is a better fit to the way human activity itself is managed - by delegation.