[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
Yes - it helps. We are essentially agreed. The way the UML was formed, it declares all of the assertions. I'll work on it this week. Duane On 5/8/07 8:01 PM, "Francis McCabe" <frankmccabe@mac.com> wrote: > 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]