Re: [soa-rm-ra] Questions on action model

[Francis McCabe <frankmccabe@mac.com>]

Scott,
  We will bear your thoughts in mind ... :)


  And yes, we have had discussions on the other issues:

1. A service may have several actions. (Unlike the WSDL scenario). We  
have not tried to attach pieces of the description to individual  
actions, but that is a potentially good suggestion (from that would  
follow that policies would also be individuated).

2. We have had quite a lot of discussion about MEPs. In section  
4.4.1.2 (ca line 1394) we outline a few of the MEPs that we feel are  
archetypal. However, we specifically chose not to enumerate a long  
list of potential MEPs.
   In our opinion, MEPs are closely connected to choreography, which  
is an area that we want to say more on in the RA.
   In the RM, we modeled this by identifying two aspects of the  
behavior model: the action model and the process model. The former is  
about what actions are possible and the latter is about temporal  
relationships between actions. The process model is, of course,  
closely aligned with many people's concepts of choreography.

Frank

On Oct 9, 2007, at 3:53 PM, Scott Came wrote:

> Thanks, Frank.
> I don't think it's important to elaborate this in the RA too far, but
> some clarification around lines 1011-1015, encapsulating the points I
> made, would be helpful in avoiding the kind of confusion that  
> tripped me
> up.
> Also, does the subcommittee have thoughts on the two other questions I
> raised, specifically:
> 1.  Isn't it true that a properly defined service may have multiple
> actions, each of which has its own set of policies?  An example is
> different access control policies (willingness) for some effects
> (updating data) than others (reading data).
> 2.  What about MEPs?  Might the separate actions on a service require
> different MEPs?
> Thanks.
> --Scott
> -----Original Message-----
> From: Francis McCabe [mailto:frankmccabe@mac.com]
> Sent: Monday, October 08, 2007 12:03 PM
> To: Scott Came
> Cc: soa-rm-ra@lists.oasis-open.org
> Subject: Re: [soa-rm-ra] Questions on action model
>
> Scott,
>   I think that you are right about actions wrt RWE. We have not
> 'unpacked' the RWE a great deal in terms of actions; but yes, the
> atomic components of RWE are going to be from actions.
>
>   However, I am not sure that there is much need to fully elaborate
> this in the RA. I am willing to be persuaded either way.
>
> Frank
>
> On Oct 8, 2007, at 9:39 AM, Scott Came wrote:
>
>> I have some questions regarding draft 0.2 of the RA, in the area of
>> the action model.  I scanned the list archives for answers, and
>> none were readily apparent, so...
>>
>> Regarding lines 1011-1015, there is a statement that real world
>> effects (note the plural) are defined for a service, not the
>> individual actions on a service.  Similarly, policies are
>> associated with the service and not individual actions.
>>
>> I am struggling with the practical implications of this.
>>
>> It seems if you allow a service to produce multiple real world
>> effects, and the plurality of effects is of significance to
>> consumers, then at least in some cases I would think you'd want to
>> provide independent access to those.  (Otherwise, you may as well
>> just roll them all up into one macro "effect".)  So, if you accept
>> that a consumer may choose to achieve some of a service's effects
>> and not others during a particular interaction, how would the
>> consumer do so other than by invoking specific actions?  And, if
>> the consumer is to invoke specific actions to achieve particular
>> effects, wouldn't the service provider necessarily need (per
>> awareness) to tell the consumer which actions produce which
>> effects?  Otherwise what distinguishes the actions?
>>
>> An example may help...  A corporate accounting department provides a
>> service for business units to use in managing employee timesheets.
>> (The corporation is large and diverse enough that business units
>> may build their own time accounting systems, but by policy everyone
>> must access the central corporate capability for some basic
>> functions.)  The time accounting service provides access to basic
>> CRUD capabilities for employee time:  add time records, read (view)
>> them, update existing ones, and (perhaps) delete records under
>> certain circumstances.  If you are willing to grant that these four
>> actions (create, read, update, delete) are appropriate within a
>> single service action model, then clearly they produce distinct
>> (though related) real-world effects (underneath the "umbrella"
>> effect of "manage employee time records"), and certainly will have
>> different policies associated with them (there may well be tighter
>> access control on changing data than viewing data, for example).
>>
>> A possible objection to this characterization of the service is
>> that it tightly couples each of the four C/R/U/D operations in a
>> single service.  The problem with this objection is that there is
>> no universal benchmark for tight-coupling.  Coupling and cohesion
>> are competing forces that need to be balanced in any design
>> decision.  Achieving that balance is an engineering problem solved
>> based on the particulars of the situation.  In an SOA, since one of
>> the primary objectives is agility and resiliency, I would hope the
>> architect would make that decision primarily on the basis of
>> whether the four actions are likely to change at the same time, or
>> not at all.  But certainly other factors may come into play.
>>
>> It seems you would want to give the architect the freedom to
>> achieve the right balance there, rather than force his or her hand
>> by saying services must be designed such that the actions do not
>> achieve distinct objectives and do not have distinct policy
>> requirements.
>>
>> This line of reasoning may be completely out in left field;
>> however, if it is, I would urge some more thorough discussion in
>> section 4.2.2 of how service design principles should impact the
>> scoping of services, their RWEs, and their action models.
>>
>> I also have one more specific follow-up question, not addressed in
>> section 4.4.1.2:  In an RA-conformant concrete architecture (as
>> such is envisioned now), can the actions in a single service's
>> action model use different MEPs?  Can one action use request/
>> response and another use event notification?
>>
>> Thanks for your help!
>>
>> --Scott
>>
>> Scott Came
>>
>> Director, Systems and Technology
>>
>> SEARCH--The National Consortium for Justice Information and  
>> Statistics
>>
>> (916) 212-5978
>>
>> (916) 392-2550 x311
>>
>> scott.came@search.org
>>
>>
>>
>