OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

  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.


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  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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]