I'd like to take attempt a summarization of this
"attempt"...please let me know if I've misconstrued
1. The action model of a
service may contain
2. The actions in a given
service's action model may
distinct real-world effects, meaning that a consumer
interact with (invoke?) some subset of actions and
3. A service has one
description, but that one
specific reference to particular actions in order to
individual effects, and it also may specify specific
individual actions, though those specific individual
viewed as part of one whole policy for the service.
4. The process model of a
service shows how a
with (invoke?) specific actions in sequence to
function aligned with the service's RWE
5. There may be multiple
processes in the process
different sequences and different functions
6. A consumer may interact
with (invoke?) a single
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
invoking an action through message exchange; that
service exchange information (in the form of a
8. Interaction with different
actions can be by
9. The decision about service
boundaries-which of
actions should be in a given service's action
model-can be productively
guided by a set of design principles, which the RA
future time. Principles
should be carefully and
The example again is an Employee Time Management
model of this service might consist of four actions:
update existing time records, delete time records,
records. A process model
for this service may, for
that it makes sense to view time records prior to
it is also possible to add time records in
isolation...without any of
the other actions being involved.
The overall RWE
management of employee time, but each action has a
independent value to a consumer.
There is no
whether it makes sense to include all four of these
service-without more analysis, it is not clear
service model or not. However,
there are some
design principles that an
architect (creator of a concrete architecture) can
determination: loose
coupling, statelessness,
________________________________
Sent: Thursday, October 11, 2007 11:09 AM
Subject: Re: [soa-rm-ra] Questions on action model
Indeed I do not expect we (and anyone else) will
cookbook for defining services.
However, it is
principles that I think will be valuable and with
consistent. Thomas Erl's
book may provide a good
anyone can summarize between now and when I
eventually make it to a book
store (or log into Amazon), we can begin considering
Note when we mention principles, we have to do much
which are familiar but overused and never really
specifically took shots at loose-coupling and
put agility into that category.
When we state the
we can), those SHOULD be phrases that convey enough
cannot be automatically misconstrued (by accident or
Again, I'm energized to revise the service
description model but have a
long list of household chores to catch up on first.
Alternately, you can come over and fix the lawn
On Oct 11, 2007, at 1:35 PM, Scott Came wrote:
I think this kind of specific guidance is best
principles. I don't
believe there will be a "one
rules that tell you, in every situation, how to
properly. The best you
can do is identify the
play-those factors that, at a minimum, the designer
consider when setting service boundaries. Those
in principles that say what should characterize a
Proper application of these principles (selecting
competing forces) requires the skill of a designer,
principles accelerate the design process and bound
discretion somewhat, in pursuit of an overall design
And not just any old set of principles will do. SOA
purpose-to increase agility, adaptiveness,
responsiveness to change-so