OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [soa-rm-ra] Questions on action model

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.
-----Original Message-----
From: Danny Thornton [mailto:danny_thornton2@yahoo.com] 
Sent: Thursday, October 11, 2007 3:55 PM
To: Scott Came; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] Questions on action model


Thank you for the summarization.  The only statement I
have an exception with is 3, A service has one

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.


--- Scott Came <scott.came@search.org> 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:klaskey@mitre.org] 
> Sent: Thursday, October 11, 2007 11:09 AM
> To: Scott Came
> Cc: soa-rm-ra@lists.oasis-open.org
> 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]