RE: [soa-rm-ra] Groups - Modification of Policy_Contract_Business diagram (OASIS_Policy-Contract_Diagram.JPG) uploaded

["Ellinger, Robert" <robert.ellinger@ngc.com>]

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/