[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Groups - Modification of Policy_Contract_Businessdiagram (OASIS_Policy-Contract_Diagram.JPG) uploaded
Affects yes - I can buy that. Aggregation is a specialized type of relationship. This essentially says that a policy is an aggregation of one or more contracts and a contract is an aggregation of one or more policies. Aggregation is distinct from Composition in the fact that apparently both policies and contracts can exist without being aggregated into the other (as opposed to a composite relationship which the parts don't exist if the whole does not exist). Two questions: 1. Is the description above correct? I am thinking more to "no". 2. How can a policy exist by itself if it is aggregated *only* from contracts (or the other way around) if you find a case where cardinality = 0? I think that we didn't capture the logic well within this UML CVD. Here is another attempt. Side note - I just ran into Danny at Java One... Duane On 5/8/07 5:09 AM, "Ellinger, Robert" <robert.ellinger@ngc.com> wrote: > To the point: > > In many disciplines there are circular cumulative causation processes in > which a affects b which in turn affects a. Both ecological and > evolutionary processes are of this c3 type. Why should we not expect to > find them in this ecological model? > > For example, take T&Cs. If a consumer needs a particular service or > service component, but that component uses a protocol that is not > allowed to be used by the consumer's policy, I suspect that the consumer > will change the policy or create an exception--this may be especially > true as technology evolves. Conversely, if a consumer will consume most > of a service and is paying for, the contract between the consumer and > provider may cause a change (upgrade) in technology that would otherwise > be prohibited by the provider's policy. > > What you are showing is a c3 process. > > -----Original Message----- > From: Danny Thornton [mailto:danny_thornton2@yahoo.com] > Sent: Tuesday, May 08, 2007 1:28 AM > To: Ellinger, Robert; Duane Nickull > Cc: michael.poulin@uk.fid-intl.com; Francis McCabe; > 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 > >> We have both chickens and eggs. >> They both were derived from bad >> dinosaur DNA. > > For breakfast's sake, it's a good thing those dinosaur chickens started > laying eggs then. Doubly linked aggregation is valid as long as the > objects are dynamically created at run time. Something along the lines > of air contains bubbles and bubbles contain air, a poor example but the > first thing that popped in my head. > > The GoF composite pattern doesn't allow for this doubly linked > aggregation between the inheritance objects. For IT people this looks > like a better UML diagram than the doubly linked aggregation diagram. > Our options are to state one of the following: > > 1) A policy is a policy and a contract is a contract and they do not > reference each other. It is an either/or condition. Any policy a > contract touches turns the policy into a contract. This is currently > what is modeled in the RA. > > 2) A policy can reference a contract and a contract can reference a > policy - the air/bubble/air dilemma and the UML diagram that IT people > don't like. > > 3) A contract is a policy (plus more) and the contract can reference > other contracts and/or policies but a policy does not reference > contracts. I believe this is the policy/contract relationship given by > Steve and Duane. > > Any other relevant policy/contract relationships that we can diagram in > UML? We must be close to the end of spinning this thread. > > Danny > > --- "Ellinger, Robert" <robert.ellinger@ngc.com> > wrote: > >> 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 >> >> > > > > > ________________________________________________________________________ > ____________ > Never miss an email again! > Yahoo! Toolbar alerts you the instant new Mail arrives. > http://tools.search.yahoo.com/toolbar/features/mail/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]