Disambiguating Action (Part I)

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