[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
Frank: This makes even less sense. For a normal relationship, it is not a problem. Yes - you can have Husband and Wife and each <<loves>> the other. Aggregation is a special type of association. It is essentially saying that "A" is aggregated from 1 or more instances of "B". It is illegal in UML to have an aggregation from a sole class with a cardinality of "0" as far as I know. You cannot have "A" existing if it is solely built out of instances of "B" and has zero instances. It hast to be at least 1. What bothers me, is we are explaining the two things by saying each is composed of the other. Do you agree with all or any of these statements: 1. Policies are aggregations of contracts. 2. Contracts are aggregations of Policies. (together, these two constitute a circular reference) 3. A Policy can exist without a contract, yet it cannot exist if it is not aggregated out of at least one contract, which is also true. 4. the inverse of <3> 5. Policies are aggregated form Contracts which are aggregated from Policies that are aggregated from Contracts .... (repeat until infinity) Do any of these make sense? The RM defines a contract as: " A policy represents some constraint or condition on the use, deployment or description of an 658 owned entity as defined by any participant. A contract, on the other hand, represents an 659 agreement by two or more parties. Like policies, agreements are also about the conditions of use 660 of a service; they may also constrain the expected real world effects of using a service." This is not what the UML represents. Duane On 5/8/07 7:15 PM, "Francis McCabe" <frankmccabe@mac.com> wrote: > I do not know about UML, but it is quite common to have a mutual > recursion relationship in data structures as well as in programs. > That is what seems to be going on in this case. > It should work in UML so long as the cardinalities involved are 0..* > > Frank > > > On May 8, 2007, at 6:51 PM, Duane Nickull wrote: > >> 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/ >> >> <Picture 44.png> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]