RE: [soa-rm-ra] Disambiguating Action (Part I)

[Danny Thornton <danny.thornton@scalablearchitectures.com>]

I think the tie between action and event and functionality/operation
could be addressed in figure 40 line 1886, "A message denotes either an
action or an event".

Looking at figure 10, line 766, if the Particpant is a service provider
then what else could the Agent be other than the service itself?  

About a service provider and events -  there could have a service that
affects and monitors changes to environmental conditions.

The realization of the action and information models can be achieved in
different ways at different granularity levels but the RA cannot dictate
what type of realization of the action/information model to implement.  

Here is my preference for the realization of the information/action
model for web services.
Create information models (captured in XML schemas) where each message
has an information model.  Looking at the EDXL Resource Messaging
standard as an example, there are information models and schemas for
messages like RequestResource, RequisitionResource, RequestInformation,
etc.  See
http://www.soamodeling.net/rr/Implementation%20Diagram/_12_5_57c01fb_1207919621966_13190_830.html
 for a web servie interface example.  Each message contains many data
elements.  Each message schema is then used as the reference for an
operation which has a name identical or like the message name itself. So
for example, a RequestResurceDeploymentStatus message/schema is invoked
via a resourceDeploymentStatusRequest operation. The message/operation
name are different because the EDXL RM standard does not follow common
naming conventions for request/response messages. In this example, the
public message and action and operation have a 1 to 1 to 1
realtionships, the action is an operation which is invoked by the
reception of the message.  
 
 
Danny

-------- Original Message --------
Subject: [soa-rm-ra] Disambiguating Action (Part I)
From: "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
Date: Fri, May 23, 2008 11:03 am
To: <soa-rm-ra@lists.oasis-open.org>

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