Re: [soa-rm-ra] reaching closure on Action

["Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>]

Colleagues,

 

OK.  I'm going to pretend to be colorblind as Mary suggested and I'm going to apply one of our core architectural principles---the principle of parsimony.

 

Here's what I see are the essential core concepts around Action and their relationships (textual description only):

 

* Action (defined as before, cf, Lines 754-755 of PRD1) but emphasize this is Separate Action.

* Joint Action (defined as before, cf, Lines 810-812 of PRD1) but move defn to follow Action.

 

ARGUMENT (in favor of Joint Action):  In SOA-based systems, a Service doesn't "act" unless "acted upon".  This is why the concept of Joint Action is so important.

 

* Drop the concept of Communicative Action (CA) in favor of Interaction.

 

ARGUMENT:  The latter (Interaction) is already a core concept in the RM and, in my opinion, all we're doing by introducing yet another abstract concept like CA is adding gratuitous complexity.

 

* Interaction facilitates Joint Action

 

* Interaction (we've agreed for this RA) is accomplished via Message Exchange

 

* Messages are the medium of Interaction between a Consumer Agent and a Provider Agent (i.e., Service).

 

* Actions (and Events) are conveyed through Messages.

 

CLARIFICATION:  Actions are not carried out by Messages, but the intent of Actions is embodied in the content of Messages.  Later, after we get closure on Action, we need to expand this notion to include Events.

 

* Interaction is dependent on the visibility of a Service and its interface (i.e., Service Visibility and Service Interface).

 

* The Action Model (which is part of the Service Interface) describes, in a manner that can be used by a Consumer Agent, the permissible actions that can be invoked against the service.  It serves a purpose analogous to a function or method signature.

 

* Message Exchange Patterns (MEPs) are defined as part of the Process Model (which, as with the Action Model, is part of the Service Interface).

 

ARGUMENT:  MEPs are temporal in nature.  With the exception of my proposed visual model for Service Interface, I have yet to see any of the visual models proposed thus far capture this fact.

 

Alright friends.  That should be enough for now.  Today, I'll volunteer to take notes since I'll be on travel overseas attending an INCOSE event for ten days, beginning on Friday.  I'll do my best to call in remotely but no guarantee.

 

Happy architecting!

 

 - Jeff E., JPL