[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Questions on action model
Ken: Regarding your #1… I think this kind of specific guidance is
best reflected in a set of principles. I don’t believe there will be a
“one size fits all” set of rules that tell you, in every situation, how to
design a service properly. The best you can do is identify the principal
forces at play—those factors that, at a minimum, the designer should at least
consider when setting service boundaries. Those forces are represented in
principles that say what should characterize a proper service. Proper
application of these principles (selecting among the sometimes competing
forces) requires the skill of a designer, but well-stated principles accelerate
the design process and bound the designer’s discretion somewhat, in pursuit of
an overall design objective. And not just any old set of principles
will do. SOA has an overall purpose—to increase agility, adaptiveness,
responsiveness to change—so the principles should be included only to the
extent they promote the design of services that contribute to this purpose. Some design principles commonly identified
with SOA are: loose-coupling, abstraction, autonomy, statelessness.
These were articulated, among other places, in Thomas Erl’s “SOA:
Concepts, Technology, and Design”. I see he has a new book out that
explicitly focuses on principles. I know of no open-standard (e.g.,
OASIS) statement of these principles; I think it would be great if the RA could
reference them somehow. I’m also not aware of any articles specifically
addressing design principles, but will look and post anything I find. Regarding your #2… I believe a single service description
artifact is the right approach, largely for the reason of discoverability as
you mention. But, within that single artifact, I believe there will
generally be policy statements that apply to individual actions. Thanks…good discussion! --Scott From: Ken Laskey
[mailto:klaskey@mitre.org] Scott, I'll agree with your analysis in principle but I'd like to get more
specific for the RA. 1. What can we say as specific guidance about defining the service
boundaries and what is the range of things it makes sense to include as
operations of a service? With your example of the Time Management
Service, it is also possible that I have a general purpose Viewing Service and
the time record is one of the things I can view. Now the partitioning may
just fall onto the combination of competency and artistry of the service
designer, but I hope we can say more. 2. If I attach things such as policies at the endpoints, how do I reflect
that in the service description? As I mentioned before, if the service
description is the information set on which I base discovery, I am assuming I
can't have things sprinkled outside of the service description that might be
critical criteria for the user. Also, I'm always up for collecting (and hopefully eventually reading)
good, concise analyses of how to approach these problems. Books are
sometimes tough to consume but articles and chapters are more doable. If
you have any particular favorites for providing insight, please pass these
along. Ken On Oct 10, 2007, at 10:53 AM, Scott Came wrote:
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
----------------------------------------------------------------------------- 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]