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

From
Jeffrey A. Estefan <>
Date
2008-06-11T14:38:53+00:00
ID
001801c8cbd0$d560dbf0$
Thread
Re: [soa-rm-ra] reaching closure on Action
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