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 sensed wrong!  Thanks, Ken.


From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Thursday, October 11, 2007 6:23 PM
To: Scott Came
Cc: soa-rm-ra@lists.oasis-open.org
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.




On Oct 11, 2007, at 8:08 PM, Scott Came wrote:


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

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:






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





1.         The action model of a service may contain

multiple actions

2.         The actions in a given service's action model may


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


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,













From: Ken Laskey [mailto:klaskey@mitre.org] 

Sent: Thursday, October 11, 2007 11:09 AM

To: Scott Came

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








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





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









On Oct 11, 2007, at 1:35 PM, Scott Came wrote:










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





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.



Ken Laskey

MITRE Corporation, M/S H305      phone: 703-983-7934

7151 Colshire Drive                         fax:       703-983-1379

McLean VA 22102-7508




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