multiple descriptions [was: [soa-rm-ra] Questions on action model]

Michael,

I see your discomfort and if all we had were multiple, independently generated descriptions, this would certainly lead to ambiguity and contradiction.

I have often talked about a service description as being a table of contents, so less than the source of many description elements, it is the collection points of things created for other, related purposes.  For example, I do not see writing policies into each service description but I see those with expertise in rules systems developing policies in parallel and the service description author would link to the existing policies.  In the same way, I do not see duplicating my address and phone number for every service for which I am a responsible party, but I do see a link to the resource where my contact (and possibly other personal information) is maintained.

In this way, a different subset of possible description could be emphasized for different contexts, but the subsets would leverage common resources for the description elements.

At one time, I advocated the idea of a "complete description" where the description would explicitly collect the description elements needed for the context but would provide other links where additional description sets or description elements could be found.  The idea was a given description would highlight what was needed for the context but there would be tendrils to the rest of the world where more information resides.

Ken

On Oct 15, 2007, at 4:43 AM, Poulin, Michael wrote:
  
Duane wrote:  "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."
 
 
 
I have a lot of concerns about underlined statements.
 
 
 
1) Service description gets used as the service definition now. I agree that in an ecosystem not all information about the service is in the Service Descriptor. However, in this case, I prefer to recognise that I have different 'domains' in the ecosystem of services (voice, signs, UDDI, etc.) where the Service Description is the single unique one.
 
 
 
2) To me,  the "service description a consumer uses may be dependent on the entity the consumer interacts with when they use the service" looks much more like an execution context and related Service Contract than a service description. Again, "be dependent on the particular context the service description is provided" is either services ecosystem domain specific Description or the EC and Service Contract.
 
 
 
3) as I mentioned before, SOA RM states that EC is not a context of service interaction only ( though in many places it says so ) but also the context of service execution per se. If we allow "a service to have multiple service descriptions" (w/o defining concrete conditions where it is possible), we have to clearly distinguish it from a service to have multiple service descriptions in multiple service execution contexts - interaction and execution ones.
 
 
 
4) I, personally, dislike the idea of "a service to have multiple service descriptions", at least, in the same Service Description Repository. Though this is a lower level technical implementation detail,  it is VERY important for practical use of SOA and quoted statement above can easily screw it, which I hate.
 
 
 
- Michael
 
 
 
 
Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity’s website - http://www.fidelity-international.com/world/index.html 

 

 

   
    From: Duane Nickull   [mailto:] 
Sent: 12 October 2007   16:49
To: Ken Laskey; Scott Came
Cc:   
Subject: Re: [soa-rm-ra] Questions on   action model

  

Concur.  Look at the cardinality of WSDL. Not   everything is mandatory either.  On a purely logical level, consumers can   use only that which they require.  It is unlikley that any one service   description artifact would in fact contain *all* the information   required.

At least some info is known via alternative mechanisms   (voice, signs, UDDI, etc.)

Duane

On 10/11/07 6:22 PM, "Ken   Laskey" <> wrote:

  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

--   
**********************************************************************
"Speaking   only for myself"
Blog - http://technoracle.blogspot.com
Community   Music - http://www.mix2r.com
My Band -   http://www.myspace.com/22ndcentury
MAX   2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************

 
-----------------------------------------------------------------------------

Ken Laskey

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

7151 Colshire Drive                         fax:       703-983-1379

McLean VA 22102-7508

 

smime.p7s