issue. I did sense the "one description" position as the subcommittee
consensus, however...mostly from reading the RA 0.2 draft.
Thanks.
Thank you for the summarization. The only statement I
description.
be many service descriptions for a service. The
provided. Because of unforeseen possibilities for a
one service description.
Subcommittee:
I'd like to take attempt a summarization of this
thread. Note the word
"attempt"...please let me know if I've misconstrued
anything said so
far.
1. The action model of a service may contain
multiple actions
2. The actions in a given service's action model may
produce
distinct real-world effects, meaning that a consumer
may choose to
interact with (invoke?) some subset of actions and
not others
3. A service has one description, but that one
description may make
specific reference to particular actions in order to
describe their
individual effects, and it also may specify specific
policies for
individual actions, though those specific individual
policies can be
viewed as part of one whole policy for the service.
4. The process model of a service shows how a
consumer may interact
with (invoke?) specific actions in sequence to
accomplish some business
function aligned with the service's RWE
5. There may be multiple processes in the process
model, involving
different sequences and different functions
6. A consumer may interact with (invoke?) a single
action to
achieve a particular effect (whether that is a
process with one step, or
no process, is an issue I suppose)
7. The mechanism by which a consumer interacts with
a service is by
invoking an action through message exchange; that
is, the consumer and
service exchange information (in the form of a
message) to achieve some
effect
8. Interaction with different actions can be by
different MEPs
9. The decision about service boundaries-which of
all possible
actions should be in a given service's action
model-can be productively
guided by a set of design principles, which the RA
may include at some
future time. Principles should be carefully and
precisely defined.
The example again is an Employee Time Management
service. The action
model of this service might consist of four actions:
add time records,
update existing time records, delete time records,
and view time
records. A process model for this service may, for
example, indicate
that it makes sense to view time records prior to
updating them. But,
it is also possible to add time records in
isolation...without any of
the other actions being involved. The overall RWE
of this service is
management of employee time, but each action has a
separate effect of
independent value to a consumer. There is no
absolute rule regarding
whether it makes sense to include all four of these
actions in one
service-without more analysis, it is not clear
whether this is a "good"
service model or not. However, there are some
design principles that an
architect (creator of a concrete architecture) can
apply in making this
determination: loose coupling, statelessness,
autonomy, abstraction,
etc.
Thanks.
--Scott
________________________________
Sent: Thursday, October 11, 2007 11:09 AM
To: Scott Came
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
updated for today's economy) at Yahoo! Games.