[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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] 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
----------------------------------------------------------------------------- Ken Laskey MITRE Corporation,
M/S H305 phone:
703-983-7934
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]