and further responses inline
At 03:06 PM 12/6/2005, Duane Nickull wrote:
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:]
Sent: Tuesday, December 06, 2005 10:39 AM
To: Duane Nickull; Goran Zugic; Matt MacKenzie; MATHEWS, Tim;
Sally St. Amand;
Cc:
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.
But SOA is not necessarily Web services and the consumer somewhere along
the line is likely to be a human. OTOH, given Mechanical Turk
(
http://mturk.amazon.com), you never know when there will be a human
in the loop.
- 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.
yes, but the question is whether some things that will be explored more
fully in RA should be mentioned for completeness (or not leaving our
readers feel something is missing).
- 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.
agreed and can make this any process, such as a business process, where
"business" itself can be anything you want it to be.
- 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.
I think this is a point that needs to be made to avoid the question of
whether something is missing.
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?
I think there are a few words left in Section 3.2.1 but I wonder if these
are too little and too buried.
D
K2 (my wife is K)
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305
phone: 703-983-7934 |
| 7515 Colshire
Drive
fax: 703-983-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------
