Services in an SOA may be business processes (e.g. a la WS-BPEL, when
it's finished) - aka "process-oriented" services...
They may be "application-oriented" services (e.g. a calculation, an
inventory lookup)...
They may be "data-oriented" (or we can simply say "data") services (e.g.
a streaming sensor data service, a stock quote service)....
They may be infrastructure services (e.g. security, reliability/QoS,
semantic mediation, transaction/coordination a la WS-AT, WS-BA,
WS-Coord)...
and on...
and on..............
Kind Regards,
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
From: Duane Nickull
[mailto:]
Sent: Tuesday, December 06, 2005 5:34
PM
To: Metz Rebekah;
Subject:
RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
I disagree. SOA
does not need BPM nor will all SOA’s be used for BPM. BPM is one of
*many* possible “things” that
may use SOA as a base layer. Listing only BPM infers some form of
priority or preference. The SOA cannot see nor should it care that BPM
is there. TCP/IP is not aware of services or BPM either but will likely
be used in most implementations. It does not state anywhere in the
TCP/IP specs that TCP/IP implementations will reflect business requirements or
processes. Again – that is only one possible use of
many.
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/
*******************************
From: Metz
Rebekah [mailto:]
Sent: Tuesday, December 06, 2005 1:16
PM
To:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
How about
words such as “The specifics 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 <some>
business process. Within this context, the architecture should build
upon specific service instances which correspond to the real world effects
that the business process hopes to realize.”
I thought that the W3C recognized that IT service (in
particular web service) interactions always occur via a virtual agent on both
sides of the interaction? Here we’re starting to get into the notion
that there are several ‘levels’ of critical entities within a service
interaction that all remain congruent to one another within the course of a
service interaction.
Rebekah
From: Duane
Nickull [mailto:]
Sent: Tuesday, December 06, 2005 3:06
PM
To: Ken Laskey; Goran
Zugic; Matt MacKenzie; MATHEWS, Tim; Sally St. Amand;
Cc:
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:]
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.
- 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
