Ken--is there one sub-set in common? I feel there may
be, with extensions depending on the context.
From: Scott Came [mailto:]
Sent: Thursday, October 11, 2007 10:02 PM
To: Ken
Laskey
Cc:
Subject: RE:
[soa-rm-ra] Questions on action model
I sensed wrong!
Thanks, Ken.
From: Ken
Laskey [mailto:]
Sent: Thursday, October 11, 2007 6:23
PM
To: Scott Came
Cc:
Subject: Re: [soa-rm-ra] Questions on
action model
The RM says
The service description represents
the information needed in order to use a service. In most cases, there is no one
“right” description but rather the elements of description required depend on
the context and the needs of the parties using the associated
entity.
Thus, the implication is there may be overlapping
descriptions relevant to different contexts.
Ken
On Oct 11, 2007, at 8:08 PM, Scott Came
wrote:
Danny:
I don't personally have a strong feeling one way or the
other on this
issue. I
did sense the "one description" position as the
subcommittee
consensus, however...mostly from reading the RA 0.2
draft.
Thanks.
--Scott
-----Original
Message-----
From: Danny Thornton [mailto:]
Sent: Thursday, October 11, 2007 3:55
PM
To: Scott Came;
Subject: RE: [soa-rm-ra] Questions on action
model
Scott,
Thank you for the summarization. The only statement
I
have an exception with is 3, A service has
one
description.
In an ecosystem of services, there could
potentially
be many service descriptions for a service. The
service description a consumer uses may be
dependent
on the entity the consumer interacts with when
they
use the service, or it could be dependent on
the
particular context the service description
is
provided.
Because of unforeseen possibilities for
a
service to have multiple service descriptions, I
do
not think the OASIS SOA RA can qualify one service
to
one service
description.
Danny
--- Scott Came <>
wrote:
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
________________________________
From: Ken Laskey [mailto:]
Sent: Thursday, October 11, 2007 11:09
AM
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
=== message truncated
===
________________________________________________________________________
____________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and
Now (it's
updated for today's economy) at Yahoo!
Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
-----------------------------------------------------------------------------
Ken
Laskey
MITRE Corporation,
M/S H305 phone:
703-983-7934
7151 Colshire
Drive
fax: 703-983-1379
McLean VA 22102-7508
