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] Proposal: Reorganization of SOA-RM Draft for Better


Comments inline:

 

*******************************
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/
*******************************

 


From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Tuesday, December 06, 2005 10:39 AM
To: Duane Nickull; Goran Zugic; Matt MacKenzie; MATHEWS, Tim; Sally St. Amand; frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

 

I think we need to add some words to the RM to capture this discussion.  We cover part of this in the beginning of Section 3.2.1 but need to be more specific that:

- a service consumer can be a human or a software agent;

DN: given that we have scoped the RM for SOA to software architecture and it is abstract, is this correct and relevant?  How can a human interface with a SOAP node?  Since a human actor that invokes a service by using a SOAP client is invisible to the service tier, it is probably not correct or relevant as worded.  I think I know what you are trying to say though.



- a service consumer can invoke any number of services (including a single service in isolation) and can chain the output of some services to act as the input of others;

DN: save this thought for RA.


- from the perspective of a given service, the occurrence of such chaining would not be visible;

DN: agree


- the service consumer can be implementing a business process;

DN: or an unbounded array of other options.


- the specific of a business process do not change the basic SOA concepts as described in the RM; however, the specific architecture that one designs and implements will reflect the business process and make use of specific service instances that corresponds to the real world effects that the business process hopes to realize.

DN: concur.


Now that said, and in full appreciation that we agreed earlier that mechanisms which combine services (e.g. choreography, orchestration) are out of scope, is it sufficient for words, such as those suggested above, to be included somewhere within the current discussion or do we need to pull it out into a subsection on its own?  As an example of the former, we tried to deal with loose-coupling and coarse-grained with words at the end of Section 2.1.
DN: We used to have such words.  Are they out of the doc now?

 

 

D



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