To add some
mud into the water…
Many Bus
architectures do “enrichment” of messages between consumer and
producer, including the invocation of other services to perform that
enrichment (e.g stock quote returns current price, enrichment provides
the last ten days closing price). They may also do calculations
that result in the non-connection or “empty” return from the service
(e.g. if you call for “last five minutes trades” after the market has
closed… its an empty set). So while I agree that the service
consumer is key it’s sometimes hard to identify the true consumer and
the true producer of a service within a virtualised bus.
From:
McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs-sct.gc.ca]
Sent: 06
December 2005 19:09
To:
klaskey@mitre.org; marchadr@wellsfargo.com; dnickull@adobe.com;
goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;
sallystamand@yahoo.com; frank.mccabe@us.fujitsu.com
Cc:
soa-rm@lists.oasis-open.org
Subject: RE:
[soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
The service
consumer is the key concept that indicates the entity that invoked the
service in the first place.
A brokering
service or service actor is merely a middle-man.
-----Original
Message-----
From: Ken
Laskey [mailto:klaskey@mitre.org]
Sent:
December 6, 2005 2:02 PM
To:
marchadr@wellsfargo.com; dnickull@adobe.com;
goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;
sallystamand@yahoo.com; 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 could argue
that a broker consumes the service on someone else's behalf. In
reality, service actor seems too nondescriptive because either the
consumer or the provider can be thought of as an actor.
At 01:45 PM
12/6/2005, marchadr@wellsfargo.com wrote:
I hate to
stir things up a bit, but can you change the service consumer term to
service actor?
Since in the
case of brokering the service actor is not consuming but brokering a
request to another service.
The broker
service can be a service actor upon the service but might not really
consume any part of the service since it is a pass through.
But I guess
this is a matter of opinion.
-----Original
Message-----
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;
- 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;
- from the
perspective of a given service, the occurrence of such chaining would
not be visible;
- the service
consumer can be implementing a business process;
- 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.
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.
At 12:23 PM
12/6/2005, Duane Nickull wrote:
I slightly
disagree with your assertions, probably based on semantics. For
a service to "participate" in a process, it would have to be aware of
the process (which many will not be). A better way to depict
this may be to state "services may be aggregated and used by
processes" and "processes may be represented/exposed as
services". There are really no limits to the number of layers
that can be present. Attached is a UML CVD depicting such.
A key
rationale of why process is not part of SOA is that services cannot
see process. They are not aware of whether they are being called
as part of a process vs. as an individual service. If the "s"
part of SOA cannot see or touch that, it cannot be part of the RM.
The chicken
and egg discussion you bring forward is a requirement for those
building services to strongly consider the business process when
designing their service infrastructure. Accordingly, it is not
really part of the RM for SOA yet I agree that it is a very important
consideration.
For your
messages to get to the list, you must join as a "applicant" rather
than an "observer" as per OASIS process.
*******************************
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: Goran
Zugic [ mailto:goran.zugic@semantion.com]
Sent: Monday,
December 05, 2005 8:47 PM
To: Duane
Nickull; 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
Thanks for
the response. Yes I would like to see the PPT. I hope you do not mind
if I add few more thoughts related to services and business processes:
Services
participate in a business process to add some value to it. They can be
governed and evaluated using business process metrics. One service can
participate in many business processes and provide value to each of
them according to the context within that process. As far as SOA is
concerned it is as important to know what the service does, how it can
be discovered, contacted, invoked, executed, etc. as it is to be able
to use it within the process context, measure it and assess its value
from the business process requirements point of view. SOA needs to
avoid typical new technology chicken and egg syndrome, e.g. companies
not producing services because there are no service friendly process
definitions to use them and not having SOA friendly process
definitions because there are no services to use. Services do not have
to know if they will be involved in the process upfront, they will be
contacted on demand according to the process script that is in effect,
and they will be contacted, checked if available, passed the
arguments, collected the response and according to their procedure
left alone to wait for another call. The process execution engine
however needs to invoke the service according to both service specific
information and the process specific information.
Having just
the service specific information in a model covers only one part of
the picture and I think it is fine as long as that model is a pure
service model. However I find it difficult to understand that the SOA
RM TC model is a SOA reference model when it does not include other
concepts of SOA. Unfortunately it seems that we cannot get to the
point where we could agree on a minimal set of supported SOA concepts
by a model to be the SOA RM. We do not have to and I do not want
to argue with you or anybody else in SOA RM TC. I am just trying to
see how our works can fit together in a most efficient way. We
obviously need more time to better understand each others thoughts and
ideas and I strongly believe that a constructive respectable
discussion is helpful for everybody.
By the way,
do you know what I am supposed to do to get my messages to the SOA RM
list. In spite of that I am the SOA RM TC observer I get a faliure
notice whenever I send a note to the SOA RM.
-----
Original Message -----
To: Matt
MacKenzie ; goran.zugic@semantion.com ; MATHEWS, Tim ; Sally St. Amand
; frank.mccabe@us.fujitsu.com
Cc:
soa-rm@lists.oasis-open.org
Sent: Monday,
December 05, 2005 5:02 PM
Subject: RE:
[soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
The service
layer enables the process layer over top of it, however during
runtime, services do not know if they are part of a process or being
called individually (it would generally be a bad idea to try to
maintain the overall state of a process within each service, although
it could be done). For maximum repurposing of services, it would
be better to have the service as a simple slave to the processes that
may use it.
Accordingly,
we made a decision that BPM, Orchestration, choreography is not a core
part of the RM for SOA. We generally seem to agree that many SOA
implementations will include a layer of BPM over top. We are
only addressing the SOA model, not the model for the underlying or
overarching layers.
I have a PPT
that explains this in more detail if you are interested.
*******************************
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: Matt
MacKenzie [ mailto:mattm@adobe.com]
Sent: Monday,
December 05, 2005 12:51 PM
To:
goran.zugic@semantion.com; 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
Process
orientation is only one of multiple potential integration with service
oriented architecture. SOA-RM is laying the foundation for
durable architecture based on the core concept of service
orientation. We recognize that process oriented architecture is
a natural fit with service orientation...but so are things like event
orientation.
From:
goran.zugic@semantion.com [ mailto:goran.zugic@semantion.com]
Sent: Monday,
December 05, 2005 3:36 PM
To: MATHEWS,
Tim; Matt MacKenzie; 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 that
SOA RM has done good job documenting well-known service related
concepts and defining some new ones.
I do not see
other details besides service and service-related concept definitions
in the current SOA RM committee draft right now. I look forward to
seeing the completion of the model you are working on with the
bottom-up approach.
Business,
business processes and collaboration aspects of business are important
to address in the model what is not the case with the current content
of the SOA RM committee draft. By a business process I mean a generic
business process entity which has common components (activities,
decisions, etc) and relationships between them that can be used to
model a business process in any environment regardless of what
business we support and technology we use. I agree with Sally that a
link between business processes and services should be one of key
requirements any SOA reference model should try to meet.
I am not sure
what SOA with services brings to business when the link between the
business processes and services and overall business process semantics
in the SOA context are not considered to be important aspects in a
SOA-based reference model.
-----Original
Message-----
From:
MATHEWS, Tim [ mailto:tmathews@lmi.org]
Sent: Monday,
December 5, 2005 12:34 PM
To: 'Matt
MacKenzie', '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
"Componentization"
Matt - I am
not sure what point you are trying to make by this? I agree with
your premise of a bottom up effort, as this was one of the operating
assumptions that was made from the beginning.
But, I am
confident it is the business environment that is independent from the
reference model.
From: Matt
MacKenzie [ mailto:mattm@adobe.com]
Sent: Monday,
December 05, 2005 11:58 AM
To: 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
"Componentization"
A reference
model actually needs to be a bottom up effort. We leave the ever
so popular ?top-down? approach to folks like ebSOA J
We?re
creating a vocabulary and general understanding of what I hope we can
call a discipline of computer science in the future. This means,
we need a durable reference model that is not dependent on the current
business environment.
From: Sally
St. Amand [ mailto:sallystamand@yahoo.com]
Sent: Monday,
December 05, 2005 10:19 AM
To:
frank.mccabe@us.fujitsu.com
Cc:
soa-rm@lists.oasis-open.org
Subject: Re:
[soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
"Componentization"
This is in
response to your request on last week?s conference call, if anyone has
comments speak now. I also think that the recent comments on
clarifying sections are a reflection of my issues with the
specification.
I agree with
the majority of points made/described in ver 10. My issues are with
what is not in this draft. Based on Fig 1 the Refe! rence Model is
guided by Reference Architectures, Concrete Architectures, Profile
& Related Models. They in turn account for requirements,
motivation & goals. This is creating a Reference Model from the
bottom up. I believe a Reference Model should reflect a top down
approach.
The Reference
Model needs to reflect the environment, the strategy and the
priorities of the business/mission/collaboration. This will
impact the construction of services. A service is a business task or
activity that is realized through technology. The draft does a good
job of describing how that realization happens. But it doesn?t provide
a sufficient link between processes and services. The draft makes the
point that the central focus of! SOA is the task of business
function?getting something done. A business process is made up of
tasks and activities to achieve a goal (getting something done). The
concept of creating the service from the tasks and activities in a
process is important. For example, where on the continuum of fine
grained to coarse grained should a particular service be; this will
affect interaction, reusability. The relationship between processes
and services needs to be in the Reference Model.
While I saw
that there is a note saying the glossary is still in flux, since one
of the objective of the Reference Model is a vocabulary, having less
in the glossary might be a better option. Is semantic integration a
guiding principle of SOA?
With respect
to conformance there needs to be business results. That is an SOA
should provide demonstrable mission accomplishments, e.g. ROI, match a
competitors distribution channel. SOA is not a technology. Conformance
should provide operational accomplishments, these should be
measurable.