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.
|