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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
[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? 
</Quote>

I would say that even instantiation is out of scope of a reference architecture. In terms of OO and SOA, perhaps we can also consider the 3 primary aspects of object orientation and how they map/do not map to SOA. My thoughts:

(1) Encapsulation: Directly mappable to SOA; often known as transparency in SOA.

(2) Inheritance: Will be mappable, for Web services. By "will be" I mean that WSDL 2.0 (still in process - W3C Candidate Recommendation as of 27 March 2006) has a feature for interface inheritance through the "extends" attribute information item.

(3) Polymorphism: AFAIK, not mappable. That is, there is no standard mechanism for polymorphism for a Web service (i.e. service context). I foresee the need for this in the future - perhaps a sort of sCAM (services CAM).

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Metz Rebekah [mailto:metz_rebekah@bah.com] 
Sent: Wednesday, April 12, 2006 3:02 PM
To: SOA-RM
Subject: RE: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)


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.