[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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----- 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:metz_rebekah@bah.com] 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 Associate Booz Allen
Hamilton Voice:
(703) 377-1471 Fax:
(703) 902-3457 From: Bashioum, Christopher
D [mailto: 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: Please
see comments below, marked with [JMC]. Joe Joseph
Chiusano Associate Booz
Allen Hamilton O:
202-508-6514 C:
202-251-0731 Visit
us online@ http://www.boozallen.com From: Bashioum, Christopher
D [mailto: 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 Joe From:
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:dnickull@adobe.com] 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 ******************************* From: Metz
Rebekah [mailto:metz_rebekah@bah.com] From:
Bashioum, Christopher D [mailto: 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:metz_rebekah@bah.com] 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
Associate Booz
Allen Hamilton Voice:
(703) 377-1471 Fax:
(703) 902-3457 From: Ken Laskey [mailto:klaskey@mitre.org] inline On Dec 7, 2005, at 4:00 PM, Metz Rebekah wrote: Comments inline… From: Ken Laskey [mailto:klaskey@mitre.org] Sent: Wednesday, December 07, 2005 3:43 PM To: Jones, Steve G Cc: marchadr@wellsfargo.com; tmathews@lmi.org; mattm@adobe.com;
soa-rm@lists.oasis-open.org; frank.mccabe@us.fujitsu.com;
goran.zugic@semantion.com; McGregor.Wesley@tbs-sct.gc.ca; dnickull@adobe.com;
sallystamand@yahoo.com 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: 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 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: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. Ken 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. - Dan -----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. 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: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 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 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 Goran ----- Original Message ----- From: Duane Nickull 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 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: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. -matt 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. Goran -----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. TM 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" 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: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" 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 ! |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]