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

[Duane Nickull <dnickull@adobe.com>]

Michael:

Comments inline:


On 2/19/07 11:22 AM, "michael.poulin@uk.fid-intl.com"
<michael.poulin@uk.fid-intl.com> wrote:

> 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.
No problem and thank you for helping with this work.
> 
> 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.
DN: The key word in the first sentence is "may" which indicates that it
might not be the case in 100% of instances.  Nevertheless, this could use
further clarification.  I think that the Reference Architecture is the best
place for this given the RM tries to avoid any concreteness.  When we talk
about the service description only as a concept in the RM, it should not be
tied down to tangible constraints.

> 
> 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).
DN: A contract is not necessarily a concrete artifact.  It is a conceptual
agreement between the two parties.  Its non-explicit nature within the RM
means that it might be implemented in the RA in many ways.  I think that
this information is very insightful however for the RA team to discuss.
> 
> 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)
DN: I would want to be careful with the "self contained" in the event it
precludes the reference of other artifacts which may be useful to potential
service consumers.  Can you elaborate on the notion of self contained?  I
think what you are saying is useful to the RA group.

> 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
DN: This again might preclude other methods of communicating the policies
(perhaps out of band).  WS-Policy and WS-PolicyAttachment use models where
such is used and I would want to encourage the alignment of the RA with
those models.  Nevertheless, I think that you have hit upon a problem that
needs to be explored and discussed.  In many cases, the Service Description
is the starting place for a consumer to investigate a service.  Capturing
the entire semantics of a service policy within such an entity might be
troublesome in some cases but might also be a best practice in some
architectures.

> 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.
DN: I have no problem, with this.
> 
> 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
Dn: Is this the same as the execution context?

> 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)
DN: most of this is common fodder for discussion.  I wish you would be able
to be present when this can be discussed.  The chair can maybe schedule some
time?

Duane
> 
> 
> 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*
**********************************************************