[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] RE: Act versus Object versus...both?
I think therefore I
am? Yes, it is a mouthful –
which is why I’ve struggled to clearly express it. We’re
almost there so I’ll try again: Service can be a noun and
service can be an action. But service (noun) != service (action). What
is in the ‘difference’ is important to understanding SOA! The noun service
expresses the action of service (together with several related concepts) as a
thing. When we take the static view of something active, we implicitly group
the action with additional concepts. This is unavoidable and results from
language itself. Therefore, when we use
the word service as a noun, and especially in a reference model, I would like
to ensure that we explicitly call out those interrelated concepts. 1)
Treating
service as a noun permits these related concepts to remain obscured to the
reader unless explicitly noted. 2)
Treating
service as an ‘active’ forces this explicit discussion because we
have to identify the actor and any object of the action Good
discussion this morning – it certainly is making me think! Rebekah Rebekah Associate Booz Allen Hamilton Voice: (703) 377-1471 Fax: (703)
902-3457 From:
McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs-sct.gc.ca] 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: 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: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]