wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] Relations
- From: Steve Graham <sggraham@us.ibm.com>
- To: "Andrea Westerinen" <andreaw@cisco.com>
- Date: Thu, 12 Aug 2004 12:19:46 -0600
+1 to Andrea.
Too many previous attempts at this problem
suggest n-ary relationships exist.
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Andrea Westerinen"
<andreaw@cisco.com>
08/12/2004 12:06 PM
|
To
| "'Homayoun Pourheidari'"
<homayoun@bea.com>, "'Potts, Mark'" <mark.potts@hp.com>
|
cc
| <wsdm@lists.oasis-open.org>
|
Subject
| RE: [wsdm] Relations |
|
Still disagree that all relationships
are binary. Many are, and collections work for grouping. But
NOT ALL relationships are binary.
Andrea
-----Original Message-----
From: Homayoun Pourheidari [mailto:homayoun@bea.com]
Sent: Tuesday, August 10, 2004 10:51 AM
To: Potts, Mark
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Relations
Mark, Let me try to use your words... Please see
below.
Cheers,
H.
---
Potts, Mark wrote:
Homyoun,
So I guess I see it differently
- member relationship s are seen in three ways from either side of
the relationship - Adam is my Father (John's perspective), John is
my son (Adam's perspective) - or from the perspective of the relationship
itself (I think this is what you are getting at). so from the perspective
of the relationship what is that between John and Adam?
child is an instance of an association (or relation) between
john and adam. parent is an instance of an association (or relation)
between adam and john. That is the perspective of the relation. I
am an association between two or more participants. One association
allows one participant to play a "child" role and another association
allows the other participant to play a "parent" role. It
is through the two associations that the roles are established.
The association is not parent
or chid - they are the roles the participants play in the association
- unfortunately in the example the the association is "relation"
(overloaded here but meant in the in the family sense) - i.e. these two
people are related. Having a ternary association here makes no sense
because there is a types association between each distinct member (whether
that be general, parent child or specific, father mother son daughter).
If you want to have a group relationship them that would be a containment
model, say family (where the members are all listed). This is why
service Groups in my mind have to be reworked to be a containment model
using relationships not something separate.
I think what you're saying here is that associations are
only binary. If so, I believe that as far as the association instance
is concerned it can be defined for use by two or more participants.
It all depends on how you define the semantics of the association
instance (or role). For this particular example that we're looking
at here, child/parent, the associations should be binary. However,
I already gave an example of an association which is not binary.
Nonetheless, for the sake of simplicity, I am not opposed to keeping associations
strictly binary and using a group model to providing the "family"
or more than binary relations. I think that works for the use cases
that I have looked at as well. But I believe Andrea had some use
cases where she thought a service group "family" model does not
quite work. I am waiting to see them before tightening up my opinion
on this..
Mark
From: Homayoun Pourheidari [mailto:homayoun@bea.com]
Sent: Tuesday, August 10, 2004 9:52 AM
To: Potts, Mark
Subject: Re: [wsdm] Relations
Mr. Potts, long time no hear...
Ok. So in the example that I gave, child and parent could be instances
of an association class with the name of the instance set to "child",
"parent", "mentor", or "abuser!" for that
matter. "MakesUseOf" is in effect a reference that is established
between the managed resources and the relation or association instance.
As for support for more than binary relations, the last wsdm discussion
we had on relations was centered around support for binary relations and
as such I positioned my examples that way. However, one can just
easily support ternary (or more) relationships by returning triplet values.
For example running getListOfParticipants on a relation like "works
with" can return((a,b,c) (d,e)) meaning that a,b, and c have
a ternary relation and d and e have a binary relation. For the first
case though (a,b,c) we will have to decide what the target value of getRelationships()
on "a" should be? Is it b or is it (b,c)?
Cheers,
H.
--
Potts, Mark wrote:
Ahhhh....... but isn't parent
a role of a person and is only created by the association that exists -
I think so.
John has a relationship to Adam,
but there can be many relationships that could exists (parent, mentor,
abuser!). The association is made and then the association has characteristics.
What this means is that the relationship is an association class that has
references to the two or more members in the relationship and those members
are identified in a particular role they play in that relationship.
Go take a look back at WS-Manageability
- I think someone wrote some pretty good stuff on relationships there
:))
Mark
From: Homayoun Pourheidari [mailto:homayoun@bea.com]
Sent: Monday, August 09, 2004 6:01 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Relations
Hi,
Replying to Igor's request to describe how I think relations should be
conceptually used with managed resources, I have attempted to describe
my view using the following UML diagrams. I hope this makes Igor
very happy :)
Cheers,
H.
---
Essentially, I believe Relations should be considered as stand-alone entities
and managed resources "MakeUseOf" these entities (this is how
I am trying to relate manged resources and relations without using the
word "use"). A manager should be able to go to a managed
resource and determine what relationships (a relation in addition to a
target name, the source is the managed resource itself) or go to
a relation and determine what managed resources "MakeUseOf" it.
For example in the following figure:
If a manager queries ManageableResource1 and run "getRelationships",
it should see the tuple:
(Relation1, Target1) where Target1 is the target of that relationship.
Same for ManageableResource2, running "getRelationships"
should yield the tuple: (Relation1, Target2). Note that Target1 and
Target2 maybe the same or may not.
Now if the manager goes to Relation1 and runs getListOfParticipants, it
should yield:
(ManageableResource1, Target1)
(ManageableResource2, Target2)
If ManagedResource1 runs RemoveRelationship(Relation1, Target1) the relationship
will be removed. Now if you run getListOfParticipants() on Relation1,
you should see: (ManagedResource2, Target2). If ManagedResource2
runs RemoveRelationship(Relation1, Target2) the relationship will be removed
but Relation1 still exists, but it's list of participants will be updated
according (with no participants at this point).
The Relation entity, should be fully discoverable and exhibit information
such as properties, operations, and notification types (for those that
are managing relations themselves) and also have metadata and policies
that it can attach to all of the above information. In essence, the
description of a Relation entity is very similar to a Managed Resource
description in wsdm.
Relation "implementations" can be managed resources in the same
or different domain than the managed resources that "MakeUseOf"
them.
To complete the picture above with a more concrete example, consider 5
managed resource, John, Jill, Nancy, Adm, and Eve. They have the following
relationships:
- John is "Child" of Adam
- Adam is "Parent" of John
- Jill is "Child" of Adam
- Adam is "Parent" of Jill
- Nancy is "Child" of Eve
- Eve is "Parent" of Nancy
Here
is the diagram describing this deployment:
Use the templates described above in applying the operations that are provided
and to render the results.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]