[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Questions on action model
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]