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


I thought we had vetted the glossary and I'm surprised some of the definitions are so weak.  I think part of what we are seeing is that after all this time working on the RA (and me teaching the courses at MITRE), we actually know the material better than when we finished the RM.

Capability vs. underlying capability: no difference was intended.  I started adding the underlying adjective to emphasize that one builds SOA on top of domain solutions and saying SOA doesn't solve unsolved problems.

Electric utility example: I think that accurately gets the capability vs. functionality distinction.  The generating capacity is the capability but the functionality needed (the business service) is to get electricity to power electric things we want to run.

Your last paragraph: A nuclear reactor is one of the resources for the electricity generating capability.  I don't think there is anything inconsistent there.  As for the remainder of the paragraph, I lean towards your interpretation.

I'm expecting another spirited and enlightening call tomorrow.


On May 27, 2008, at 6:27 PM, Jeffrey A. Estefan wrote:

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

Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7515 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]