OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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
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]