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 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
----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7151 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
|