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


Ken,

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
Description?  

Danny

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

> Michael,
> 
> 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
> component?   
> 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.
> 
> Ken
> 
> On Feb 25, 2007, at 10:00 AM,
> michael.poulin@uk.fid-intl.com wrote:
> 
> > 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
> designation/ 
> > 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
> important  
> > 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
> (http://java.sys- 
> > con.com/read/250503.htm ).
> >
> > - Michael
> 
>
------------------------------------------------------------------------
> 
> ------------------
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:     
>   703-983-1379
> McLean VA 22102-7508
> 
> 
> 
> 
> 



 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news


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