Re: [soa-rm] Policies and Contracts - notes for currrently posteddocument

[Duane Nickull <dnickull@adobe.com>]

Martin:

In general, I favor using the WS-Policy and WS-PolicyAttachment abstract
models for the RA.  There is no place to link them to the RM explicitly
given the abstract nature of the RM but the RA should probably reflect the
capabilities of those works.

Note that the WS-Policy stuff is used in many WS-* specs including WS-RX and
SX.

Duane


On 2/19/07 12:03 PM, "Smith, Martin" <Martin.Smith@DHS.GOV> wrote:

> Michael -- 
>  
> A good discussion --thanks.  It gave rise to a couple of thoughts:
>  
> 1.  Contracts are (typically) private between buyer and seller. Except that
> the contracts have to be made available to third parties (courts, arbitrators)
> for dispute resolution and enforcement.  I wonder if contract "instances" are
> a property of services at all.
> 2.  "Internal" policies are private to an organization (or individual, if you
> like), and represent documented guidelines for doing business and/or goals,
> presumably subject to waiver or revision via internal decision processes. I
> don't see that they are of any particular relevance to the external
> (observable) behavior of a service.  And maybe not to the RA.
> 3.  "External" (advertised) policies are really just a starting offer to the
> public in negotiation of a contract. The car dealer may have a "policy" of a
> maximum 10% discount for cash, but the salesman's invisible manager can
> probably cut a deal if it's the end of the month.
> 4.  There seem to be several OASIS (and other) activities dealing with
> policies and contracts. We should try to figure out if we are doing anything
> special in SOA-RM that requires a distinct language, or which of the other
> efforts is best suited to RA needs.
>  
> Regards,
>  
> Martin
>  
> Martin F. Smith
> Program Manager, Information Sharing & Identity Management
> DHS CIO Office
> 202 447-3743 (New! as of 10/2006)
> 202 441-9731 cell
>  
> 
> ________________________________
> 
> From: soa-rm-return-310-martin.smith=dhs.gov@lists.oasis-open.org on behalf of
> michael.poulin@uk.fid-intl.com
> Sent: Mon 2/19/2007 2:22 PM
> To: soa-rm@lists.oasis-open.org
> Subject: [soa-rm] Policies and Contracts - notes for currrently posted
> document
> 
> 
> 
> Hello,
> unfortunately, I will not be able to participate in the next telcon (28 Feb.)
> but would like to offer a few comments for the Policies and Contracts doc
> posted under
> TheArchitecture/ServiceView/PoliciesAndContracts
> This is a long message but, I think, it is better to discuss it first and then
> publish in Wiki.
> 
> In Section 1 - Policies and Contracts  relationships between policies,
> contracts and service description is contradictive to some degree. In one
> place, the doc says:
> "Policies and contracts may be associated with a service through the service
> description as defined in the visibility section of the RA architecture." In
> another place, the Visibility Section requires that the service description
> and policy  or at least a suitable subset thereof  be available..., that is
> Policy may exist outside of the description.
> 
> If we accept the first statement, we can say that service description may
> contain only policy(ies) or only contract. However, Service Contract is the
> agreement between service provider and concrete service consumer. Since a SOA
> service exists independently from consumers, there should be a form of
> description, which does not contain a contract, and, from another hand, if a
> contract with a consumer exists, it has either to refer to the service
> description (and policies) or include it (and policies).
> 
> Thus, the relationships I would like to propose are:
> 1)      Service Description is a self-contained and consistent entity which
> describes different aspects of the SOA service (for the sake of logic here, I
> have postponed the description of these aspects)
> 2)      If a service provider exposes any number of policies onto the service
> consumers for particular SOA service, all such policies are
> available/accessible/referenced via the Service Description only
> 3)      For each service consumer, a Service Contract is identified. The
> Contract contains references to a subset of applied providers policies, as
> well as functional, operational, and run-time characteristics listed in the
> Service Description  all adopted to particular consumers needs. Plus, the
> Contract includes and/or references to all policies exposed by the consumer
> onto the service provider. There may be one Contract for many consumers or
> each consumer may have individual Contract.
> 
> Finally, a Service Description should include:
> 1)      business and/or programmatic interfaces that may be exposed to the
> consumer; the  Service Contract lists only those interfaces that are agreed
> upon with particular consumer
> 2)      service versions that may be exposed to the consumer; the  Service
> Contract includes only those versions that are agreed upon with particular
> consumer
> 3)      Policies applied by service provider
> 4)      Service behavior characteristics in normal conditions
> A Service Contract may include:
> 1)  Policies required by service consumer
> 2)  agreed QoS characteristics  performance expectations (expected response
> time, throughput, etc.), scalability, failover, error handling and alerts,
> business (process) exceptions (different from technical exceptions), pre-known
> conditions (like delivery schedule)
> 3)      service priority  different for different categories of the customers
> 4)      additional provider obligations to the consumer(s)
> 
> 
> In Section 1.1 -  Policy/Contract Language  A policy and/or contract language
> is defined by a policy/contract language model.
> I suggest the contract language model has to encapsulate policy language
> model.
> 
> 
> In Section 1.2 - Mechanisms Supporting Policies and Contracts  The common
> policy architectural elements that are provided in this section are based on
> the minimal mechanisms required to provide policy guided delivery across
> distributed services within an ownership domain and between ownership domains.
> The same mechanisms can provide compliance assurance and/or auditing of
> contractual obligations between participants.
> I would agree with this if ALL elements/entries of the Contract are
> represented in the form of a policy. Otherwise, the statement is argumentive.
> 
> 
> Cheers,
> - Michael Poulin
> 
> 

-- 
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.           *
Chair - OASIS SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                    *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************