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 getting one's head around the organizing principle for  
services is forever tricky. In the RM we tried to put a natural  
boundary on this by identifying a capability that the service mediates.

While it is clear that a service is typically organized around a set  
of actions, and one or more resources; I do not believe that there is  
a single 'syntactic' condition that can be applied to define a service.

Currently, we do not have a good higher-level handle on how to  
organize a large suite of resources and actions into well  
differentiated services. The usual route is to appeal to business  
function (e.g., accounts, sales, library book management etc.)


On Oct 11, 2007, at 2:54 AM, Poulin, Michael wrote:

> To Scott's "to group actions into a single service when they are  
> not (necessarily) related through a process model" -  I see "group  
> actions into a single service" based on "a process model" as a  
> specific task for a mediating service. In other cases, I base  
> action grouping on the business service/function/unit of work  
> model, not on a process. That is, the business model implemented by  
> SOA Service actually sets the boundaries of what may be in the  
> service (the task left is to decide if I need to group all  
> identified actions into one service or split them between several  
> services).
> Plus, if the relationship between business services/functions/units  
> of work gets understood in the enterprise, it allows for reasonable  
> prognosis of what might be changed in the future (by the business)  
> and how far existing service(s) may be extended (to agile with  
> business requirement changes)
> - Michael
> Important: Fidelity Investments International (Reg. No.1448245),  
> Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity  
> Pensions Management (Reg. No. 2015142) and Financial Administration  
> Services Limited (Reg. No. 1629709, a Fidelity Group company) are  
> all registered in England and Wales, are authorised and regulated  
> in the UK by the Financial Services Authority and have their  
> registered offices at Oakhill House, 130 Tonbridge Road,  
> Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity  
> only gives information on products and does not give investment  
> advice to private clients based on individual circumstances. Any  
> comments or statements made are not necessarily those of Fidelity.  
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential and/or  
> privileged material. If you received this in error, please contact  
> the sender and delete the material from any computer. All e-mails  
> sent from or to Fidelity may be subject to our monitoring  
> procedures. Direct link to Fidelity’s website - http://www.fidelity- 
> international.com/world/index.html
> From: Scott Came [mailto:scott.came@search.org]
> Sent: 10 October 2007 15:53
> To: soa-rm-ra@lists.oasis-open.org
> Subject: RE: [soa-rm-ra] Questions on action model
> Ken:
> Thanks for your reply.  I agree that stock quote checking, credit  
> card payment, and spouse reminder transmission are very likely to  
> be properly offered through separate services.
> I also agree that there probably should be only one service  
> description “artifact” (whatever that might be), with one policy  
> “artifact”, but I would add that the description and policy may  
> have distinct provisions for each action.  This seems to be true  
> whether all the actions of a service are part of a single process  
> model or not.  For instance, in the example you offered, there may  
> be policy provisions for the account debit action that have nothing  
> to do with the notification about the final bill payment.  If it’s  
> a corporation using the service, there may well be rules that say  
> the cardholder (ordinary employee) can receive notification that  
> the bill has been paid, but only accounting can authorize the debit  
> to the account.
> While it is true that WSDL places no limits on what you can “pack  
> into a service”, there are some good principles of design that you  
> apply to choose service boundaries.  I would think the same  
> principles would apply to any service, regardless of the transport/ 
> messaging protocol being used (e.g., web services or not).  As I  
> suggested in my original post, the loose coupling, autonomy, and  
> encapsulation principles (I’m paraphrasing here) proposed by Thomas  
> Erl and others suggest a balance of loose coupling and high  
> cohesion.  The architect designing a service (establishing its  
> boundaries…what actions belong in the service and which ones don’t)  
> should apply these principles to maximize the resiliency and  
> agility that SOA strives for.
> While the linkages of actions in a particular process certainly  
> would have significant bearing on the application of these  
> principles, there are other factors that would have a bearing as  
> well.  Information model dependencies are a good example.  One  
> reason you wouldn’t want the stock quote checker and the weather  
> report in the same service is that their information models are  
> likely to vary independently.  You wouldn’t want to force the  
> weather checkers to change their consumer implementations (having  
> to deal with a new service interface) just because a new piece of  
> information is added to the stock quote.  They would view that as  
> absurd.
> But in the Employee Time Management service, if corporate  
> accounting updates the chart of accounts, it’s likely that both the  
> viewing of time records and adding of new time records would be  
> affected.  If two objects are loosely coupled but highly cohesive,  
> they tend to change together or not at all.  So, applying these  
> principles would call for the viewing and adding of time records  
> being actions in the same service.  But they may not necessarily be  
> part of a single business process…you could view records without  
> adding new ones, for example.
> Bottom line point:  As an architect who designs a lot of services,  
> I would not want my alignment to the SOA-RM RA to be in conflict  
> with my need to apply design principles, which principles may call  
> for me to group actions into a single service when they are not  
> (necessarily) related through a process model.
> On the MEP issue, I am in agreement (for many of the same  
> fundamental reasons) that the actions of a service may require  
> different MEPs.
> Thanks.
> --Scott
> From: Ken Laskey [mailto:klaskey@mitre.org]
> Sent: Tuesday, October 09, 2007 7:31 PM
> To: Scott Came
> Cc: soa-rm-ra@lists.oasis-open.org
> Subject: Re: [soa-rm-ra] Questions on action model
> Scott,
> Lines 101-1015 are trying to wrestle with the question of what  
> actions make sense to have as part of a single service and if I  
> allow/encourage lots of description to be connected at the lowest  
> levels of the service, i.e. the endpoints where I invoke the  
> actions/operations, what does that mean for description of the  
> service and eventually service discovery.
> Let's see if I can expand on the questions.  If I think of the  
> actions as being similar to WSDL operations, there is no limit to  
> what I can pack into a single service.  So I can have a service  
> with operations to check stock quotes, to pay my credit card bill,  
> and to send reminders to my wife.  If fact, I can have a single  
> Ken's Service with many, many operations that does all the computer- 
> initiated tasks I can think of.  Then, certainly I would need to  
> fully describe the RWE of each operation and the associated  
> policies would probably vary enough to merit individual treatment.
> Intuitively, however, this doesn't seem like a good idea.  So in  
> the RM we talk about a service having a resulting set of RWEs and  
> policies about the interaction, but what is implied is that the  
> various actions are tied together in the process model because  
> there is a multi-step process that is necessary to realize the  
> RWE.  The RWE is what results from completing all the steps, and  
> policies would relate at the service level to say what is required  
> to complete the entire defined process.  In this case, describing  
> the service is fairly straightforward.
> Now can one service (as defined) have more than one RWE?  Yes.  If  
> I have a bill paying service and the funds are deducted from my  
> checking account (or any other account I designate) then RWEs  
> include a debit to my checking account, a funds transfer to whoever  
> sent me the bill, and possibly some accumulation of information to  
> the credit bureaus that keeps me in good standing.  There may be  
> multiple actions I need to invoke to handle parts of the bill  
> paying process and the MEPs used by each action could differ.  So  
> some form of request-response could provide my credentials whereas  
> a notification of the final bill paying could just be a one-way  
> notification.
> In your time charging example, I would lean to saying each CRUD  
> operation is a different service with possibly different policies  
> in defining who is authorized for each operation.  Is there any  
> particular benefit to bundling these into a single  
> modifyTimeCharging service?
> Hopefully, this has provided you some understanding of my thought  
> process.  I'd be happy to be argued into a different interpretation  
> if that would have a sounder basis.
> Ken
> On Oct 8, 2007, at 12:39 PM, 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
> ---------------------------------------------------------------------- 
> -------
> Ken Laskey
> MITRE Corporation, M/S H305      phone: 703-983-7934
> 7151 Colshire Drive                         fax:       703-983-1379
> McLean VA 22102-7508

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