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] RE: updated service description

Danny, et. al.,

I think the thread between you, me, and Michael shows general agreement.  One of the things I hope to get out of IEE-1471 is to figure out what aspects get modeled in each view and where for consistency we ensure overlap.

I need to get back to Duane's comments to work more on the details of description, but that will probably wait until next weekend.


On Feb 25, 2007, at 8:40 PM, Danny Thornton wrote:


I agree with your thoughts that policies and contracts
are referenced from the Service Description and can be
fully defined elsewhere.  Many people in the industry
tend to think of the Service Description as a
contract.  The reasoning behind this is because it can
be said the consumer has to abide by the Service
Description and therefore it is a contract.  At the
implementation level, people often equate a WSDL to a
contract.  I see this view of a SOA contract as a
half-truth.  As stated in one of Michael’s previous
e-mails, WSDL does not capture the business meaning of
a service. The meaning of contract is rooted more in
the social structure than anything at the
implementation level.  In business a contract is a
legally binding agreement between two or more parties.
 It may or may not be personalized, it may be human
enforceable, it may be electronically enforceable. 
For electronically enforceable policies and contracts,
the computing mechanisms that enforce a policy or a
contract can be the same.  

One person's stated policy can be another person's
enforced contract.  Not abiding by stated policies can
have real world effects just like not abiding by a
contract.  Loss of a job for not following company
policy for example.  It is difficult for me to see a
clear distinction between a policy and a contract
other than what is stated in the OASIS SOA RM.  A
contract and a policy have a clear distinction at the
level of the social structure.  At the implementation
level, just tell me the rules that need to be
enforced, whether it is a policy or a contract doesn't
matter to me.

The Service Description encompasses more about the
social structure than the contracts so I do not put
contracts at the same level as Service Description. 
The contract is a subset of Service Description if the
contract is part of the Service Description. 
Discussions about contracts and policies and Service
Descriptions will tend to swirl around the following
three questions:  What is the distinction at the
business level between a policy and a contact?  What
is the distinction at the implementation level between
a policy and a contract?  Where do the various forms
of a contract fit in relation to the Service


--- Ken Laskey <klaskey@mitre.org> wrote:


I started to respond to this hours ago, then printed
out your paper,  
and finally make it past numerous distractions
(including a  
unexpected 3 inches of snow to shovel) to finally
collect my thoughts.

On your first point, I think of the service
description as being the  
executive summary and table of contents.  It gives
you the critical  
overview and tells you where to find more details. 
So while  
Interaction Policies & Contracts in the description
may explicitly  
lay out such things, these are more likely to be
fully defined  
elsewhere and referenced from the description.  Of
course, one  
benefit of this is that the policy, for example,
becomes reusable.

As for the personal nature of policy agreements, if
it is a one-time  
agreement,  I see it residing in the execution
context (whose  
concrete manifestation is still to be discussed). 
If the agreement  
is intended to be reused, it should be catalogued
somewhere.  The  
idea of a general purpose somewhere also needs to be
tackled, perhaps  
(definitely?) as part of the RA.

I then read your paper and if you went through the
TC emails, you  
could find discussions touching on but never
resolving many of these  
issues.  So here are some general questions and some
specifics ones  
relating to your paper.

- What is a service component?  If we have a
composite service, i.e.  
one that shows a single interface but is actually a
combination of  
other services, do you consider the constituent
services to be  
service components?  In the RM, we distinguish
between the capability  
and the service that provides access to the
capability.  Is an  
implementation of the capability also a service
Personally, I think I'd say yes to both where
changes to either can  
affect the client experience.

- Are "service functions" the same as RM actions?

- One of my favorites: what belongs in a SLA?  Some
views have it so  
complete that it basically becomes the service
description, i.e. it  
describes functionality, constraints, interface
details, and the  
birthdays of anyone who ever used it.  Personally, I
take a more  
minimalist approach and think of SLA as being
strictly a set of well  
defined metrics against which compliance can be
measured.  I agree  
with with your line that "a SOA service ... is
invoked ... when the  
client is fully aware of the service behavior and
conditions."  (We  
could quibble over "fully".)  To accomplish this, I
rely on an  
adequate service description, of which a
metrics-laden SLA is a  
part.  However, another part is an indication of how
one can obtain  
metrics collected against the service.  It is then
up to the client  
to compare the collected metrics with the SLA and
determine fitness  
for use.  For example, if I have a service that says
I will relieve  
80% of world hunger and the metrics show me only
relieving 70%, does  
my service provide value?

Enough for now.


On Feb 25, 2007, at 10:00 AM,

Hi Ken,
 I have two notes to the update (actually, to the
doc as it is with  
the update):

1) There is an entity in the Service Description
diagram named  
"Interaction Policies & Contracts". I think that
Contract belongs  
to another area than service description because
it is  
'personalized' based on consumer/provider
agreement. Yes,  
logically, a Contract is a special type of
description but it would  
be more comprehensive if we put it into
Interacting with Services  
Model  section.

2) You have mentioned <A discussion of how version
value should be impacted by change of version of
any of its  
components (or any descriptions?) still needs to
be discussed.> To  
me, a version of the service is one of very
characteristics of the service description (and,
respectively, of  
the service contract). I would propose placing
version as an entity  
in the Service Description diagram either under
Identity or at the  
level of Service Description entity because
version affects Service  
Reachability, Service Functionality, Interaction
Policies, and  
Service Interface entities. I have published a few
thoughts about  
SOA service versioning in SOA-WebServices Journal
con.com/read/250503.htm ).

- Michael


Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:     
McLean VA 22102-7508

8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.

Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508

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