[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
Duane Well, a rather technical example of a mutually recursive data structure is the 2-3 tree (nodes either have 2 or 3 children). As to policies & contracts, I am not sure I agree with any of the assertions. 1. I definitely do not agree that a policy is an aggregation of contracts. It may contain/reference them but (a) that is not required and (b) that does not seem quite like aggregation 2. Ditto for contracts. 3. A policy does *not* need a contract. 4. Ditto for contracts. If the issue is aggregation, then the solution is obvious ;-) It seems to me that the relationship between a contract and a policy is a kind of dependency. A contract may depend on a policy and vice- versa. But it is not required (hence the lack of fear about infinite regress). Does that help? Frank On May 8, 2007, at 7:44 PM, Duane Nickull wrote: > 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]