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

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

Very much in sympathy with this.
In my OO language I go even further: it is not permitted for a sub- 
class to access instance variables of the super class (too easy to  
mess up the semantics of the super-class)
Frank

On Apr 13, 2006, at 6:34 AM, Matt MacKenzie wrote:

> In fact, encapsulation in the OO context is meant to keep object
> implementation details intentionally opaque, forcing you toward using
> accessors & mutators.  This is very strongly enforced in my teams,  
> because
> it gives component owners license to change the underlying model  
> without
> affecting consumers.
>
> Not-encapsulated:
> public class Foo {
> 	public String name;
> }
>
> Encapsulated:
> public class Foo {
> 	private String name;
> 	public String getName() {
> 		loadNameFromSomewhere();
> 		return this.name;
> 	}
> }
>
> -matt
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Thursday, April 13, 2006 7:21 AM
> To: Chiusano Joseph; SOA-RM
> Subject: RE: [soa-rm] for discussion - additional suggested changes  
> to PR1
> (Part 1)
>
> Joseph:
>
> I would tend to disagree with your assertion "encapsulation =  
> transparency".
> Encapsulation is defined within the OO context as the grouping of  
> data and
> the code that manipulates the data into a single object.
>
> A more accurate comparison would be that:
> - In OO, objects have a data model and so does a service in SOA
> - in OO, mutator or accessor methods may be exposed to interact  
> with the
> data; in SOA methods may also be exposed as part of the service to  
> mutate or
> access instances of the data model.
>
> I think that is what you meant to say.
>
> Duane
>
> *******************************
> Adobe Systems, Inc. - http://www.adobe.com
> Vice Chair - UN/CEFACT  http://www.uncefact.org/
> Chair - OASIS SOA Reference Model Technical Committee
> Personal Blog - http://technoracle.blogspot.com/
> *******************************
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Wednesday, April 12, 2006 12:17 PM
> To: SOA-RM
> Subject: RE: [soa-rm] for discussion - additional suggested changes  
> to PR1
> (Part 1)
>
> <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.