[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Groups - Modification of Policy_Contract_Business diagram (OASIS_Policy-Contract_Diagram.JPG) uploaded
We have both chickens and eggs. They both were derived from bad dinosaur DNA. -----Original Message----- From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Monday, May 07, 2007 6:33 PM To: Danny Thornton; Francis McCabe Cc: michael.poulin@uk.fid-intl.com; soa-rm-ra@lists.oasis-open.org Subject: Re: [soa-rm-ra] Groups - Modification of Policy_Contract_Business diagram (OASIS_Policy-Contract_Diagram.JPG) uploaded Is it legal UML to allow either side to be aggregated from the other? For some reason, this seems illogical. A can be aggregated by one or more "B's" which in turn are aggregated from one or more "A's". Chicken and egg. Duane On 5/7/07 11:16 AM, "Danny Thornton" <danny_thornton2@yahoo.com> wrote: > We have stated that a policy may reference contracts and contracts may > reference policies. This is represented by the attached class diagram > "Policy Contract Relationship 1". Duane's statements below follow the > attached class diagram "Policy Contract GOF Composite Pattern". Would > it be more accurate to model policies and contracts as distinct and > separate entities as defined in "Policy Contract Relationship 2"? The > difference in the models is whether we say a contract is a set of > policies which contains a set of propositions or whether the set of > propositions are part of either a contract or a policy. > > Danny > > --- Duane Nickull <dnickull@adobe.com> wrote: > >> Correct. >> >> Policy - unilateral constraint declarations which , if not observed, >> may result in denial of service interaction. >> >> Contract - a bilateral or multilateral agreement to be bound by the >> terms of one or more set(s) of policies. >> >> Duane >> >> >> On 5/5/07 11:11 AM, "Francis McCabe" >> <frankmccabe@mac.com> wrote: >> >>> A quick follow up, >>> >>> It is also not fair to say that a contract is >> *more* than a policy. >>> >>> The distinction between them refers to the origin >> of the constraint: >>> a policy originates with a single participant (or >> proxy etc.) a >>> contract originates in an agreement between >> participants. >>> >>> >>> On May 5, 2007, at 11:07 AM, Francis McCabe wrote: >>> >>>> Again, I need to get completely clear on >> something: >>>> >>>> It is *not* reasonable to state: >>>> >>>> Contract is not only more than a Policy but also >> more than a SLA >>>> >>>> In some limited areas, you may constrain SLAs to >> focus on things >>>> like bandwidth etc., but other businesses will >> use SLAs to govern >>>> things like business opening hours, response >> times for service and >>>> so on. >>>> >>>> So, again, I do not yet see a particularly strong >> case for >>>> distinguishing SLAs from contracts. >>>> >>>> Certainly for our architecture we need to be as >> encompassing as >>>> required to support business via services, not >> simply to build yet >>>> another IT infrastructure. >>>> >>>> Frank >>>> >>>> On May 5, 2007, at 10:53 AM, >> michael.poulin@uk.fid-intl.com wrote: >>>> >>>>> I have a strong impression that in our March >> discussion about >>>>> Contract & Policies we have agreed that >> Contract is not only more >>>>> than a Policy but also more than a SLA. The SLA >> is explicitly >>>>> measurable (run-time) set of service >> attributes/characteristics/ >>>>> actions while a Contract can contain Commitments >> of the contract >>>>> participants that 1) are not visible through the >> service >>>>> interface; 2) may be not measured at run-time. I >> guess, it is the >>>>> time for me to show my version of a Service >> Contract Template we >>>>> are discussing in my organisation ( I will be >> able to do it not >>>>> earlier than on Tuesday next week). >>>>> >>>>> I have described an example of such contract in >> my article "Does >>>>> Web Services makes a Service for SOA?" In >> particular, a service >>>>> provider was obliged to gather audit info on all >> actions requested >>>>> by particular client and failed in it because >> its database was not >>>>> available for some time and several audit >> messages got lost. >>>>> If we are building high level RA, we cannot >> discard the scenario >>>>> I've just described. >>>>> That is, Contract is an agreed container of all >> service related >>>>> actions performed by the provider's SW >> system(s). With such >>>>> definition, I do know what to do in IT with >> Service Contract. >>>>> >>>>> Nevertheless, I am still unclear on >> Contract-Policy relationship >>>>> issue... >>>>> >>>>> - Michael >>>> >>> >> >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]