[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Disambiguating Action (Part I) - Take 2
Hi Ken,
Capability as defined in the RM Glossary is
bunk. It seems circular with the defn for RWE. The
Glossary states that Capability is a RWE but then we say a RWE is the
result of using the service, not the capability offered. Tisk,
Tisk!
Frankly, we were not very good about keeping our
defs in the Glossary consistent with the text (take a look at the Glossary defn
for Service for example. Far too verbose as compared with the
much more accurate defn provided in the sentence on lines 303-305 of the
RM). This is why I lobbied so hard AGAINST including a Glossary in the RM
altogether. Readers tend to fall into the trap of using the Glossary defn
of terms instead of reading the spec for the complete context. As you
know, our compromise was to add the disclaimer at the top of the Glossary
section. The issue is still biting us. But, I digress. My
point with respect to creating new defns in the RA that are different from the
RM was really focusing on the core concepts, and RWE is one of those core
concepts. Capability and Functionality are more nebulous and therefore
open to let's just say
"re-interpretation." </soapbox>
The only distinction between Capability and
Functionality that I can see in the RM (forget about Action for the moment) is
in the Electric Utility example of Section 2.1.1 (lines 211-214). As an
aside, I notice we use "underlying capability" a lot in the RM. Perhaps to
distinguish it from a Capability that is brought to bear via a Service.
That's goodness.
Is Capability really the underlying resource or
set of resources? To me, that doesn't make sense and is not consistent
with the worked SOA example of the RM. Functionality describes what
something (in this case, a Service) does or is suppose to do. Actions, on
the other hand, are what are carried out upon "invocation" and in that way,
are closely tied to interaction, i.e., communication between service
participants. If we make the assumption (as we did with the RA) that
communication between participants is accomplished via message exchange, then
Actions "act" on the messages and perform work depending on the content and/or
context of the messages. I believe this is consistent with your recent
notions. Hopefully, we can build on this and come to an adequate
characterization of Action (and the associated Action Model).
Bye for now...
- Jeff
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]