Still
disagree that all relationships are binary. Many are, and collections work
for grouping. But NOT ALL relationships are binary.
Andrea
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
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
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.
|