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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] Policies and Contracts - notes for currently posted document


Hi Michael,

You provided a nice distinction between Web Service
and Service Description and I am in agreement with
almost everything you wrote in this particular e-mail.
 To help clarify description/policy/contract in the
RA, I'll give one example of a policy and a contract,
the business meaning, the relationship to the Service
Description, and the implementation mechanisms for the
policy and contract.  

Suppose business Global provides a service description
containing a policy that states the consumer of the
service should belong to a recognized government
agency. Part of using the service actually requires
invoking an action on the service with a true value
that the consumer is a recognized government agency. 
However, the service does not verify the truth of the
action.  The end result of ignoring the policy may be
that the consumer waisted their time and did not
obtain useful information for personal use. The
consumer was warned with the policy.  Global doesn't
really care if consumers violate the policy.

Global discovers that people really like its service
and that it is getting heavy usage.  Global gets
smarter about how they deal with consumers and they
incorporate an electronic mechanism to verify the
consumer belongs to a recognized government agency
(suspend the realistic impossibilities here and make
believe for a moment). Global decides to make the
policy a contract and now has a mechanism of
electronic measurability for the verification of the
assertion by the consumer.  Global and the consumer
now enter into a binding contractual agreement before
the consumer can use Global's service. 

More on the IT side of things, Global uses some Access
Management Suite of products to authorize actions by
the consumer.  Policies and/or contracts feed into
policy decision points that render authorization
decisions, the PDP doesn't distinguish between
rendering a decision for a policy versus a contract. 
For Global, the distinction between policy and
contract is only relevant at the human level where
some employed lawyer by Global or by the consumer
might take legal action for violation of a stated
contract.  

There are an infinite number of relationships and
types of enforcement a business/government may setup
that distinguish a particular policy from a contract. 


You may be interested in a discussion thread on the RA
mailing list, Jan23rd-Jan26th, where we discussed the
relationship of QoS and other possible business
contracts to the SLA.  

Danny Thornton
http://www.soamodeling.org

--- michael.poulin@uk.fid-intl.com wrote:

> Duane,
> 
> The reviewed document is from SOA-RA Wiki  from the
> ServiceView section. This certainly may not be a
> part of SOA-RM (in my response  message about David
> Linthicum, I mentioned one article I wrote in
> Sys-Con when considered SOA-RM for actual SOA
> development).
> 
> I think that Service Description is the thing which
> distinguish SOA Service from a Web Service and adds
> business meaning to the former. Since Service
> Contract is based on the Service Description, it
> becomes a concrete artifact in RA. What I try to
> achieve with this is to close the door (at least,
> shut it a little) to the populistic use of Web
> Services that expose non-service oriented IT
> artifacts into  SOA. That is, Web Services should
> not be equal to SOA because they do  not have
> business meaning, execution context, are not
> responsible for the business behavior of the service
> implementation and do not oblige service provider to
> agile with the business needs.
> Plus, Service Contract may be treated in similar way
> as Service Description (not a Policy) with regard to
> service discovery and invocation. Talking about SOA
> services that reflect business services, I would not
> invoke a service blindly, only because it is
> announced until I am sure it does not represent a
> risk to my business, i.e. I need a Service Contract
> in place.
> 
> As of Policies and Service Description/ Service
> Contract, I agree that Policies might not be the
> part of the Description/Contract text ( an
> preferably if they do not) but rather referenced in
> there. This does not preclude using them in
> WS-Policy and WS-PolicyAttachment. However,  WS !=
> SOA Service, and SOA may treat as providers as
> consumers policies, I think.
> 
> Now, service versioning is not the same as execution
> context though it is used to reflect the specific of
> the context. That is, particular version of the
> service may be used in the context A. However, the
> same version may be used in the context B but not in
> the context C. This totally depends on the consumers
> needs. Here (http://java.sys-con.com/read/250503.htm
> ) I tried to describe the SOA service versioning. 
> 
> I would be happy to present to discuss my notes in a
> telcon (I am in London, UK) but cannot do it on 28
> Feb. (I will be on vacations).
> 
> Cheers,
> - Michael
> 



 
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 


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