[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Policies and Contracts - notes for currrently posted document
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* > ********************************************************** >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]