Hi:
I guess I have to put my oar in this water. At the Agility
Forum at the Iacoa Center (for the Agile Enterprise) at Lehigh Univ., I was on a
team called the Agile Virtual Extended Enterprise technical committee and I
supported the DARPA/NSF effort called Next Generation Enterprise on the
Virtual Enterprise Team. Both of these organizations used the following as
the definition of agility--"The ability to successfully respond to unexpected
change in the organization's environment."
What do you think?
Bob
From: Ken Laskey [mailto:]
Sent: Thursday, October 11, 2007 2:09 PM
To: Scott
Came
Cc:
Subject: Re:
[soa-rm-ra] Questions on action model
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:
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:]
Sent:
Wednesday, October 10, 2007 7:12 PMTo: Scott
CameCc: : Re:
[soa-rm-ra] Questions on action model
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:
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:]
Sent: Tuesday,
October 09, 2007 7:31 PMTo: Scott
CameCc: : Re:
[soa-rm-ra] Questions on action model
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
7151 Colshire
Drive
fax: 703-983-1379
McLean
VA
22102-7508
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S
H305 phone: 703-983-7934
7151 Colshire
Drive
fax: 703-983-1379
McLean VA 22102-7508
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7151 Colshire Drive
fax: 703-983-1379
McLean VA 22102-7508
