[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
I got the point. However, I did not have an intention to define the Policies in any way but its reference point. That is, I am talking about where/how a Policy might be referenced in RA for particular service and my proposal is Service Description / Service Contract.
Following Martin's 4 lines of thinking:
1. Contracts may be private or public, it depends on concrete service provider, service and consumer. I can easy imagine a few public Contracts offered to different categories of consumers where several consumers share the same Contract; this is similar to a public API or WSDL in UDDI (though I do not interpret WSDL as a fully scaled Contract). As I said before, a Contract to me is one of the major distinguishers of the SOA services, in particular, in its business orientation vs. Web Services, for example. The Contract appears as a single definition of the obligations of the service provider to the consumers behind the service interface (i.e. it is about reflection of the business behaviour of the service and service execution in different business contexts). For example, if a service has two public interfaces, let's say WSDL and EJB (RMI-over-IIOP), and a consumer A is contracted to use both interfaces while a consumer B is agreed to use only WSDL, the service provider gets not responsible for QoS to consumer B if it access public EJB interface. In particular, the provider can limit the pool of EJB and deny requests from consumer B staying perfectly in the contract boundaries. So, my point, the Contract is at the same attribute level as Description but personalised.
2. I agree with Martin in most of the case but still think that "internal" policies might be useful for "internal" services, e.g. cross-divisional policies/services. I had such case when worked for one of the organisations in the Zurich Financial Group.
3. Agreed with Martin
4. Agreed with Martin. Does it make sense to look at some related vendors' products of we are limited by the OASIS sphere?
If you, folks, are interested I will be able to articulate some of my points tomorrow, at the telcon.
- Michael
Senior Manager
Fidelity Investments - Web Delivery
Phone: +44-173-783-6038
E-mail: michael.poulin@uk.fid-intl.com
Web: http://www.fidelity.co.uk/
Important: Fidelity Investments International, Fidelity Investment Services Limited, Fidelity Pensions Management and Financial Administration Services Limited (a Fidelity Group company) are all authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity's website - http://www.fidelity-international.com/world/index.html
-----Original Message-----
From: Francis McCabe [mailto:frankmccabe@mac.com]
Sent: 20 February 2007 00:10
To: Duane Nickull
Cc: Smith, Martin; michael.poulin@uk.fid-intl.com; soa-rm@lists.oasis-open.org
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]