OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Concur with (and grateful for) Duane's correction of my depiction of encapsultation (that's what I get for writing during an all-day meeting):p

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: Matt MacKenzie [mailto:mattm@adobe.com] 
Sent: Thursday, April 13, 2006 9:35 AM
To: Duane Nickull; Chiusano Joseph; SOA-RM
Subject: RE: [soa-rm] for discussion - additional suggested changes to PR1 (Part 1)

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]