Perfect - it makes 100% complete sense to me.
Joe
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: Bashioum, Christopher D
[mailto:]
Sent: Thursday, December 08, 2005 9:52
AM
To: Chiusano Joseph;
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
Thanks - that was helpful.
That
being the case, the RM concept of a service maps to a concrete "thing" called
a service, that performs the action of bringing a desired capability to bear
when invoked in the context of an SOA - or at least an RM conformant
SOA.
How's that for a beltway insider?
From: Chiusano Joseph
[mailto:]
Sent: Thursday, December 08,
2005 9:41 AM
To:
Subject:
RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better
Please see comments below, marked with [JMC].
Joe
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: Bashioum, Christopher D
[mailto:]
Sent: Thursday, December 08, 2005
9:31 AM
To: Chiusano Joseph;
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
Does that mean that all the elements in the concept map are only
concepts - none of them translate into objects or actions (or any other
concrete thing)?
[JMC] They translate into concrete things when an implementation is
created that conforms to the reference model (or an existing
implementation is mapped to it).
I thought one of the purposes of a RM was to identify and give a
language to the basic elements of the thing being modeled. I.e., and
SOA will have all the elements that are identified in the RM.
[JMC] A SOA
*implementation* may have concrete elements that map to the abstract
elements (concepts) that are identified in the
RM.
I think Ken's description is still the best one, that "a
service is a means to bring a capability to bear in an SOA
context". In this case, it is still a noun (or a thing) (or at
least I think so, my wife is the English major - not
me)
[JMC] It is
a noun, as well as an action (alluding to my prior recent post on this).
So in comparison, a political compaign (sorry, I live in Washington DC;)
can be thought of as a means to potentially bring a candidate into elected
political office (using very loose wording here), while "to campaign" is
the action that is associated with that noun. If one had a reference model
for campaigns, it would contain concepts such as "candidate", "policitical
party", "regions" (perhaps the region(s) of the country that their
campaign would cover - a gubernatorial campaign would cover one state, a
presidential campaign all states), etc. In order to campaign (the action),
one would leverage the campaign reference model as a means to guide them
in their action of
campaigning.
Joe
From: Chiusano Joseph
[mailto:]
Sent: Thursday, December 08,
2005 6:58 AM
To:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
I know we're trying
to avoid "+1"'s as much as possible on this list, so I will put it into
words: I completely agree with Duane on all his points just
below.
Duane, I'm glad you've started your
guide to concept maps - hopefully in time this will help the situation.
We have used concept maps for the DRM as well.
Joe
From: Duane Nickull
[mailto:]
Sent: Thu 12/8/2005 1:40
AM
To: Metz Rebekah; Bashioum, Christopher D;
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
I believe that
the problem, with is largely due to the fact there is no normative
reference for how to interpret concept maps. In this case, a
service is neither an action nor an object. It is imply an
abstract concept.
D
*******************************
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: Wednesday, December 07, 2005
7:18 PM
To: Bashioum,
Christopher D;
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
From:
Bashioum, Christopher D [mailto:]
Sent: Wednesday, December 07, 2005
5:06 PM
To: Metz
Rebekah;
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
Rebekah,
what about the
potential of an act?
[->]
The potential of service is an offer.
I have a
problem with the following
<Snip>
The actual
invocation and performance of the capability is the service; i.e. the
action.
</Snip>
if I understand
what you are saying here, it would imply that a service is not a service
until it is actually performing an action. During the time that it
is "waiting" to perform an action it is not a service, nor is it after
it has completed the action it was created to do.
[->]
yes, you are right. That is exactly what I’m implying. The
service isn’t performing the action, the implementation of the action
is. The service is the performance.
In Duane's
diagram, the service exists independent of the interaction.
However, the interaction is what causes the real-world effect.
I'm not sure I
buy the other statement that a service is an act as opposed to an
object. Isn't it an object (in that it exists) who's purpose is to
perform an act?
[->]
So I’ll ask a question in return. Let’s assume the statement is
true. If a service exists as an object that is independent of the
capability who’s purpose it is to perform; what differentiates the
service from the capability?
For that
matter, is the capability what is actually providing the "action" and
the service is the means to access that action?
[->]
From this perspective, what differentiates the service from the service
access point?
[->]
My point is that the conceptualization of service as an object doesn’t
provide resolution to these questions. It is for this reason that
I started examining service as a verb rather than a noun. From
that perspective, the concepts and the relationships between them
clarified.
Rebekah
From:
Metz Rebekah [mailto:]
Sent: Wednesday, December 07,
2005 4:37 PM
To:
Subject: RE: [soa-rm] Proposal:
Reorganization of SOA-RM Draft for Better
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
!
