[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Policies and Contracts - notes for currrently posteddocument
Frank: Concur. That is why I had specific the "abstract model" behind WS-Policy. It is relatively simple. Some parts from the spec that might fit in with the RA level of abstraction: 1. Policies will often be associated with a particular policy subject using multiple policy attachments. 2. When multiple attachments are made, the effective policy, for a given policy subject, is the combination of relevant policies. The relevant policies are those attached to policy scopes that contain the policy subject. See also: http://asir.selvasingh.com/blog/wspolicy/policy-data-model.jpg Microsoft had some great graphics I wanted to look at but they seem to be removed from the google image search. Duane On 2/19/07 4:09 PM, "Francis McCabe" <frankmccabe@mac.com> wrote: > Martin, Duane, Michael: > For the most part, the specific policy frameworks in WS-Policy etc. > are too close to the metal for the RA work. > We are almost as abstract as the RM itself; our focus has been on > different concerns: what it takes to use a SOA, build a SOA and own a > SOA. > So, we take a similar approach to policy frameworks as the RM: but > we should be a bit more directed in where policies show up and the > kind of machinery needed to use/build/own policy systems. > Frank > > On Feb 19, 2007, at 3:48 PM, Duane Nickull wrote: > >> 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* >> ********************************************************** >> > -- ********************************************************** 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* **********************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]