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


We hit some of the things in Jeff's email, but I want to take on a few pieces I wanted to chew on more.

First, let's try to sort out Capability, Functionality, and Action.  

1. To begin, most occurrences of function* in the RM is functionality or could easily be replaced by functionality and are not intended to refer to programming calls.  So for clarity, I suggest we use the term Functionality unless we really mean programming functions.

2. The RM defines:

Capability: A real-world effect that a service provider is able to provide to a service consumer.

Real world effect: The actual result of using a service, rather than merely the capability offered by a service provider.

Now it is a bit of a strain to get these two definitions to work together.  I suggest the following:

Capability: The underlying resource or set of resources that enables the realization of real world effects.

Functionality: The set of business needs satisfied by some set of real world effects.  Functionality may be expressed through a textual description or through reference to any defined taxonomy of functions or similar vocabulary.

Leave Real World Effect as is.

While I agree with Jeff that we SHOULD NOT create new definitions of core RM  concepts, I would like to finesse the Capability glossary entry to work better with the RWE entry and our current needs.

Action (as an abstract concept): the application of intent by a participant (or agent) to achieve a real world effect.

Action (in a more concrete sense): An activity on the part of Service Participants to make use of Capabilities to realize Real World Effects.  An Action is initiated by receiving a message at the identified endpoint, using the identified protocol, carrying the necessary information corresponding to the the identified structure and semantics, and conforming to identified policies and contracts when realizing the identified RWE.

Now I realize the latter definition conflicts with Frank's interpretation and I include that strictly for discussion sake.  But I will also repeat my observations and questions from a 20 May email:

Back to Frank's context for action, an agent sends a message because it knows the RWE will be the message recipient, e.g. a service, taking certain "action".  Let's assume the action is the application of intent by the service.  Is making this indirection explicit really necessary?  Action against the service makes no sense if the service doesn't follow with an action.  Do we lose anything by saying the message sender invokes the service's action.  Interaction will still be the sequence of actions -- each a joint action between sender and receiver -- leading to the RWE.

3. Use of the term "invoke".  Again, my use in the RM was without any intent to tightly coupling to other computing models, and so no particular significance should be given to its use.  In fact, I remember Frank not liking the use of that term, and maybe I should have heeded his warning.

4. Now to Figure 10.  First, if we say the Service Provider Agent is the Service, I'm assuming we're staying abstract , so we're talking about the class Agent being the class Service and we're not yet referring to implementations.  Is this correct?

Second, I don't see the Agent having Intent but we obviously need a connection between Intent and Action, so I propose the following mod for Figure 10


If the Participant is the Service Provider, I can see the logic in the Agent being the Service.  

Now if the Participant is the Service Consumer and the Action is sending the message, then the Consumer Agent is something used to create and send the message.

If the Participant is the Service Consumer and the Action is setting off the unspecified machinery towards realizing the RWE, would the Consumer Agent again be the Service?

A Mediator is sequentially a Listener and then a Speaker.  It listens for a request to mediate, and in this role is likely a Provider.  Once it receives the message, it needs to put into play the mediation machinery and it becomes the consumer of a particular mediation process (here assuming there are numerous mediation processes possible and the Mediator sends the request to one of these).  So the Mediator follows whatever we say about the Consumer and the Provider.

5. The role of Action Model at runtime.  The Action Model MUST specify any required preconditions for each Action to do its thing.  Whether the precondition is satisfied needs to be checked at runtime.  The Process Model probably is more relevant at runtime unless an Action can proceed independently from other Actions.

This should be enough to get the discussion going again.

Ken


On May 23, 2008, at 2:03 PM, Jeffrey A. Estefan wrote:

OK Folks,
 
The hot topic of the day is "Action."  Here is my initial (Part I) attempt based on interpretation of the content described in the RM v1.0 Std and the RA v1.0 PRD1 and mapped to one of the simplest examples of a service offering, the classic temperature conversion service.  I do not propose to have all the answers here.  Where there are open questions, I will note them with the hope that these questions will spur conversation from the RA editors and SC members who have been actively engaged in discussion surrounding this topic.  I encourage you to read through the entire note before responding to the individual open questions summarized below.
 
So let's get started...
 
Believe it or not, in the RM, we use the word "action" ten times and the plural "actions" twenty-seven times, yet we never actually defined what action is.  We introduced the notion of an Action Model and defined it to be "the characterization of permissible actions that may be invoked against the service," but never action.  We were very careful about distinguishing between "private action" from "public action," but again, we did not define action.  This is why it was important for us to do so in the RA.  Indeed, Frank did so on lines 754-755 of the RA PRD1.  Here, Action is defined as "the application of intent by a participant (or agent) to achieve a real world effect."  We'll come back to this definition and its associated models in a bit, but first, let's elaborate more on the Action Model.
 
For a simple temperature conversion service that has the capability of converting degree expressed in Fahrenheit units to degree expressed in Celsius (centigrade) and vice versa.  The service's functions are two: 1) given a numeric value that represents degree Fahrenheit, return a numeric value that represents degree Celsius, 2) given a number value that represents degree Celsius, return a numeric value that represents degree Fahrenheit.  Simple enough, right?  So what is the Action Model for this service?  From a implementation technology point of view, this service could be implemented using a distributed object computing model, which exposes two operations that represent the two functions described above.  For the sake of this discussion, it does not matter whether that technology is Java RMI, CORBA, Jini, .NET, COM+, DCOM, Openwings, XML Web services, or some other distributed object computing technology.  It's just that in order to realize this service, at least in today's world, it's likely to a variant of a distributed object computing model that exposes remote operations (functions) that the consumer can invoke.
 
So again I ask, what is the Action Model for this service?  Well, it has to be a description of those two functions, right?  The reason I am making this point is because of the operative word "invoke" in our definition of Action Model.  This leads to the question of functions versus "characterization of the permissible actions that may be invoked against the service," which, of course, defines the Action Model.  We don't spend a lot of time talking about functions in the RM with the exception of Service Functionality, which is part of the Service Description artifact.  On lines 602-603 of the RM, the sentence reads "A service description SHOULD unambiguously express the function(s) of the service and the real world effects (see Section 3.2.3) that result from it being invoked."  But that also sounds like Capability.  So as you can see, we've already introduced some ambiguity in our model that we need to resolve.  How do we distinguish between functions (or functionality) and capabilities (or capability) and permissible actions (or Action Model)?  Do the permissible actions correspond to operations?  Or is that an implementation detail?  I suspect the latter, and why the RM was wise in using "action" instead of "operation."
 
Now let's return to the RA in which Action is finally defined.  For this discussion, I am referencing the material described in Section 3.5.1 Actions, Real World Effects and Events.  As noted earlier, this is the Section in which I feel Frank has done a fairly nice job in defining what Action really is, which is "the application of intent by a participant (or agent) to achieve a real world effect."  That seems reasonable enough.  Now, let's explore the visual model shown in Fig. 10 (line 766).  This model depicts the relationships between key concepts such as Action, Intent, Event, and Real World Effect.  Well, we know from the RM that the Real World Effect (RWE) is the actual result of using a service (as opposed to the capability being offered).  On lines 767-769 of the RA PRD1, Frank introduces yet another definition of RWE and to be honest, I don't think we should do that.  In fact, in the RA, we should not create new definitions of core RM concepts at all.  We should only define terms like Action that were not specified in the RM.  But I digress.  We should capture this point in our issues spreadsheet.  What is more important here is to disambiguate the model depicted in Fig. 10.
 
Here, Participant is used.  But we know from the Stakeholders and Participants Model of the RA (Section 3.1) that a Participant can be a Service Consumer, Mediator (third party), or Service Consumer.  If we were to replace Participant with say Service Provider in Fig. 10, does the model still work?  And where does the Service itself fit into the model?  If indeed Participant were Service Provider, one could envision the Agent to be the Service.  Is this a fair assumption Frank?  Open question.  And what would this mean in terms of Event?  Would a Service Provider care about events?  The only scenario I see that happening is in a V&V scenario.  In other words, the Service Provider or some entity (person or organization) working on behalf of the Service Provider is engaged in testing the Service prior to exposing its capabilities to the world.  Here, the Service Provider or supporting entity would actually be acting in the role of Service Consumer (for testing purposes) and Events could be relevant.  Again, open question to Frank.
 
Now, if we were to assume the Participant is a Service Consumer (or Mediator), does the model still work?   Kind of.  Where I think it breaks down is, again, on Action.  What action does the Service Consumer perform?  Is it sending a message?  Well, we don't get into that here.  And does just sending a message (which can certainly be consider an action initiated by the Consumer) cause the RWE to occur?  Certainly just sending a message cannot.  It is the actions performed by the Service Provider Agent (i.e., the Service) that are invoked as a result of the Service Consumer Agent sending the appropriate message that leads to a RWE.  So now the argument for Joint Action starts to become clearer (we think!).  But I will defer the discussion surrounding Joint Action until next time.  For now, let's see if we can resolve some of the potential ambiguities w.r.t. the Fig. 10 visual model I just described.
 
Summary of open questions and gut responses (looking for yours!):
 
1) How do we distinguish between Capability (or Capabilities), Functionality (or Functions), and Action Model (permissible Actions)?
 
For me, at least, it seems that Capability is at a higher level of abstraction than Functionality.  Capability could be described in natural language text that is part of summary description of the service, contained, of course, in its Service Description artifact, which could be included as a service registry-repository entry.  In terms of the simple temperature conversion service described above, Capability could be a simple brief description of what the service does without getting into the specifics of the underlying functions.  As with Capability, Functionality could be described in natural language text that is part of the Service Description artifact.   In terms of the simple temperature conversion service described above,  Functionality would be a bit more granular and would describe the two functions that the service offers; one from degree Fahrenheit to degree Celsius and the other from degree Celsius to degree Fahrenheit.
 
The Action Model (permissible actions) is very similar to Functionality (functions) except that the description of the permissible actions is intended for consumption by humans and non-human agents as part of the Service Interface, which is a critical component required at design time.  An example of a design time scenario is the following:  A human(s) uses the Action Model described in the Service Interface to construct code that would invoke the actions exposed by the Service.  From an implementation perspective, these actions would likely correspond to invocations on remote operations.  We do not make the connection between Action Model and Service Interface very clear in the RM with the exception of drawing a simple directed line from Behavior Model to Service Interface in Fig.  9 (line 565).  I did not see evidence of any text in the RM that supports this linkage, which is OK except that it leaves open some ambiguity.
 
What is not yet clear, is what role the Action Model has at run time (Interaction).  Perhaps none!  Maybe this is the point Frank is trying to make in distinguishing Action (which is not the same thing as Action Model) from Joint Action and Communicative Action, described in Sects 3.5.3 and 3.5.4 of the RA PRD1.  That said, I'd prefer we defer that discussion until Part II if we can.
 
2) Does the visual model depicted in Fig. 10 of the RA PRD1 (line 766) hold up for different types of Participants, i.e., Service Consumer, Mediator, and Service Provider?  How does Event play out in a Service Provider Participant role?
 
I do not have a gut response to this open question.  Please see my earlier discussion notes around this topic.
 
3) What is the role of the Service, currently not depicted in the model of Fig. 10. nor described in the supporting text?  From the Service Provider perspective, is it the Service Provider Agent that represents the Service?
 
I do not have a gut response to this open question.  Please see my earlier discussion notes around this topic.
 
Next time, I'd like to focus on Joint Action and how it relates to Interaction.  And the role of messages and message exchange to Action.  Maybe the latter will be a Part III discussion, we'll see.
 
Hoping for a spirited discussion that will hopefully converge on disambiguating Action for not only us but for our readers at-large!
 
Regards...
 
 - Jeff E., JPL
 


------------------------------------------------------------------------------------------

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]