<Quote>
Is it
fair to say the thing is the static view and the action the dynamic
one?
</Quote>
Yes - I like that.
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:
[mailto:]
Sent: Thursday, December 08,
2005 11:17 AM
To: ; Metz Rebekah; Chiusano
Joseph; ;
Subject: RE:
[soa-rm] RE: Act versus Object versus...both?
The
notion of duality for a service is nice.
Is it
fair to say the thing is the static view and the action the dynamic
one?
Wes
-----Original
Message-----
From: Bashioum,
Christopher D [mailto:]
Sent: December 8, 2005 11:11
AM
To: Metz Rebekah; Chiusano
Joseph; Laskey, Ken;
Subject: [soa-rm] RE: Act versus Object
versus...both?
Wow -
that was a mouthful! ; )
So I
think you said that its ok as long as we all agree that a service is both
a thing and an action - is that correct?
From: Metz Rebekah
[mailto:]
Sent: Thursday, December 08, 2005 10:26
AM
To: Bashioum, Christopher
D; Chiusano Joseph; Laskey, Ken;
Subject: Act versus Object
versus...both?
The
phrasing Chris selected prompted something for me…let me see if I can put
words to it. After the discussions yesterday, I spent some time last
night reading linguistic research to try and better understand what about the
relationship between noun and verb forms of ‘service’ are sticking points for
me. As I suspected; it has to with the implications about the
relationships between these lexical forms. What was most interesting was
to realize the variety of aspects to be considered. However, I think
that I found what makes me want to tread careful and clearly understand and
distinguish between service as a noun and service as a verb.
In
addition, the phrasing you selected suggested that there are two active
portions of the ‘service scenario’:
1)
That
‘of bringing a desired
capability to bear’
2)
That of the
capability itself
I’m
looking right now at the first active portion only. I think we already
recognize the distinction between the two in wd-10. But this served as a
reminder to me.
Essentially, when
using the nominalized form of an active verb like ‘to serve’ in a sentence; an
abstract noun performs most of the work. Nominalization can also permit
the elision of the subject and object of a verb. Therefore, we can write about
a process or action and yet not mention who is involved. This is part of
the sticking point for me when it comes to a reference model in which we’re
trying to unambiguously define key concepts – because we’re using terminology
that permits us to unintentionally cloud the concepts when we are seeking
clarity.
Harrumph. To me
this still wasn’t completely satisfying.
So I dug
a bit further and discovered that there are many ‘types’ of nominalizations,
including ‘episodic nominalizations.’ An episodic
nominalization takes an active process and conceives it as a noun. So
far so good, for service as both noun and verb. However, here’s where I
found some interesting information about the intuition of language that is
captured by these different forms. Although quite similar, these two
forms represent a different semantics which conceptually develop. In an
episodic nominalization, the conception is no longer viewed as a process but
rather as a single episode (i.e. only as the sum rather than the sum of its
parts). Yes this starts to get into cognitive psychology and linguistics
( and I apologize to those who just want to know what does the word service
mean within the context of SOA but bear with me).
Where I
got to is that yes, we may actually be talking about the same thing but from
different angles. What I’m recognizing is that those angles come with
specific inferences and assumptions that stem from language itself that we may
not be explicitly aware of and which set up
confusion.
So what
am I saying? That the text in the draft works well to recognize that the term
service(noun) unifies several related concepts – and we do it justice to
recognize those interrelated concepts. Using the terminology above,
they’re conceptualized into a single episode. If we are clear about
that, then I’ll accept that a service can be intended as either.
(Now you
all know how I spent my evening)
Rebekah
Rebekah
Metz
Associate
Booz Allen
Hamilton
Voice:
(703) 377-1471
Fax: (703)
902-3457
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
!
