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)? 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.
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)
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
!
