[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Questions on action model
Ken: I agree, careful and precise definition of
terms is critical. I view words like “loose coupling” and “stateless”
as mere labels (i.e., not normative) for the principles. The statement of
principle needs to be quite precise as to what the intended outcome is. I’ve
seen a pattern form used for principles that resonates with me: Principle Label Principle: X should Y. (X is
the outcome, product, decision that is constrained, to some end, by Y). Rationale: List of reasons why
constraining X per Y is a good idea (why doing so accomplishes some greater
objective) Implications: List of consequences
(especially ones not immediately obvious) arising out of constraining X per Y. As for repairing your lawn mower…I
tend to access that kind of capability through a service, rather than provide
it to myself! I will, in a separate post to be submitted
shortly, attempt to summarize this thread. Thanks. --Scott From: Ken Laskey
[mailto:klaskey@mitre.org] Scott, Indeed I do not expect we (and anyone else) will provide a definitive
cookbook for defining services. However, it is exactly those guiding
principles that I think will be valuable and with which the RA should be
consistent. Thomas Erl's book may provide a good starting point. If
anyone can summarize between now and when I eventually make it to a book store
(or log into Amazon), we can begin considering those. Note when we mention principles, we have to do much more than use terms
which are familiar but overused and never really defined. The RM
specifically took shots at loose-coupling and coarse-grained. I also put
agility into that category. When we state the principles (assuming we
can), those SHOULD be phrases that convey enough meaning that they cannot be
automatically misconstrued (by accident or on purpose) and then crisply
elaborated. Again, I'm energized to revise the service description model but have a
long list of household chores to catch up on first. Keep sending
ideas. Alternately, you can come over and fix the lawn mower. Ken On Oct 11, 2007, at 1:35 PM, Scott Came wrote:
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
----------------------------------------------------------------------------- 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]