On Apr 12, 2006, at 3:02 PM, Metz Rebekah wrote:
A couple of thoughts on the OO/SOA comments.
________________________________________
Sent: Saturday, April 08, 2006 6:07 PM
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?
The object may not provide context because there is very little explanation that goes with an object. The methods of an object allow a fixed set of operations where these operations are all that you can do with this object and the operations, no matter how generally useful, can only be used on that object. While services may have interface requirements on the objects with which it is prepared to include in an interaction, the operation (capability) is more generally accessible.
* 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?
Instantiation is a core concept for OO -- a class has no real use unless it leads to an instance. What the instance is and how it is used is implementation but not the idea of instance itself.
Frank earlier made the point that a differentiator is OO is a programming paradigm while SOA describes architecture.
* 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.