Gosh – if this email came through in
some weird format for everyone else, I am terribly sorry about the wacky
formatting of this email thread. Not sure if everyone saw it as I did,
but at least my outlook client puked =)
Uh-oh. We seem to be starting to
head back to the service as an object as opposed to an act. I still do
not believe that a service is an ‘object.’ In fact, I
believe that assumption has caused much of the difficulty in figuring out what a
service actually is.
What is invoked is a capability,
consistent with the execution context and so to produce real world effects. The
actual invocation and performance of the capability is the service; i.e. the
action. Hence I maintain that visibility, interaction and effect are the interrelated
concepts often (yet confusingly) referred to with a shorthand nomenclature of ‘service.’
As far as roles go, the very essence of the
word service is the recognition that <someone> does <something> for
<someone else>. I would agree that any other specification of this
generalization (uh…isn’t that an ontology) belongs in something other
than the RM.
Rebekah
Rebekah Metz
Associate
Booz Allen Hamilton
Voice: (703) 377-1471
Fax: (703) 902-3457
From: Ken Laskey
[mailto:]
Sent: Wednesday, December 07, 2005 4:19 PM
To: Metz Rebekah
Cc: Jones, Steve G; ; ; ;
; ;
; ; ;
Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
inline
On Dec 7, 2005, at 4:00
PM, Metz Rebekah wrote:
Comments inline…
From: Ken Laskey
[mailto:]
Sent: Wednesday, December
07, 2005 3:43 PM
To: Jones, Steve G
Cc: ;
; ; ;
; ;
; ;
Subject: Re: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
If I invoke a service, I
am a service consumer. It does not matter if I invoke the service on my own
initiative or am told to do it (through a targeted instruction or as part of a
more complex set of instructions), I am still the service consumer.
[->] Agreed.
I could glibly say that
if I "provide" a service, I'm a service provider, but I fear things
are not that simple. Is the entity that created the service its provider, or
the one who maintains it, or the one who hosts it, or the one who pays for it,
or ...?
[->] I see this being
a question of ‘what are the roles’ versus ‘who plays the
roles’. At first pass, it seems right that we recognize the
roles @ the RM level and leave the details of determining the best way to
decide how to assign some entity into that role to the RA.
I think it is easy to
start naming roles but difficult to stop, and the roles will get more
use-specific.
Luckily, from the RM
standpoint, we don't care.
[->] or do we just
delegate =)
... to someone who has no
choice but to care ;-)
To be used within the
context of SOA, the service must be visible, must be able to take part in an
interaction
[->] Here it sounds
like the service is an active player in an interaction. Isn’t it
that the service consumer and provider interact (as specified…?
Isn't the service an
active player? I invoke it to get its real world effect, so it certainly sounds
like it does something.
(as specified by the
established execution context), and must produce a real world effect (which I
assume may in some circumstances be null). It has been "provided" but
we don't care how or by whom.
So, in summary, there's a
lot of muddy water but sometimes we can avoid playing in it. :-)
[->] Or we can draw a
circle around it and leave that to the RA =)
... at which point you
initially choose RA cases that you can more cleanly defined. You eventually get
to the tougher ones, but we should learn to ride a bicycle before we get a
motorcycle (unless Duane has a different perspective)
Ken
[->] Rebekah
Ken
If I make a service
available for someone to invoke (and here I would say that "make
available"
On Dec 7, 2005, at 4:47
AM, Jones, Steve G wrote:
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.
Steve
From:
[mailto:]
Sent: 06 December 2005
19:09
To: ;
; ; ;
; ; ;
Cc:
Subject: RE: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
I agree with Ken.
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.
Wes
-----Original
Message-----
From: Ken Laskey
[mailto:]
Sent: December 6, 2005
2:02 PM
To:
; ; ;
; ; ;
Cc:
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.
Ken
At 01:45 PM 12/6/2005,
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.
- Dan
-----Original
Message-----
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;
- 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.
Ken
At 12:23 PM 12/6/2005,
Duane Nickull wrote:
Goran:
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.
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: Goran Zugic [ mailto:]
Sent: Monday, December
05, 2005 8:47 PM
To: Duane Nickull; Matt
MacKenzie; MATHEWS, Tim; Sally St. Amand;
Cc:
Subject: Re: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
Duane,
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.
Goran
----- Original Message
-----
From: Duane Nickull
To: Matt MacKenzie ;
; MATHEWS, Tim ; Sally St. Amand ;
Cc:
Sent: Monday, December
05, 2005 5:02 PM
Subject: RE: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
Goran:
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.
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: Matt MacKenzie [ mailto:]
Sent: Monday, December
05, 2005 12:51 PM
To: ;
MATHEWS, Tim; Sally St. Amand;
Cc:
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.
-matt
From:
[ mailto:]
Sent: Monday, December
05, 2005 3:36 PM
To: MATHEWS, Tim; Matt
MacKenzie; Sally St. Amand;
Cc:
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.
Goran
-----Original
Message-----
From: MATHEWS, Tim [ mailto:]
Sent: Monday, December 5,
2005 12:34 PM
To: 'Matt MacKenzie',
'Sally St. Amand',
Cc:
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.
TM
From: Matt MacKenzie [ mailto:]
Sent: Monday, December
05, 2005 11:58 AM
To: Sally St. Amand;
Cc:
Subject: RE: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
"Componentization"
Sally,
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.
-matt
From: Sally St. Amand [ mailto:]
Sent: Monday, December
05, 2005 10:19 AM
To:
Cc:
Subject: Re: [soa-rm]
Proposal: Reorganization of SOA-RM Draft for Better
"Componentization"
Frank
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.
Sally
!
