Re: [wsdm] Relations

[Homayoun Pourheidari <homayoun@bea.com>]

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.

begin:vcard
fn:Homayoun Pourheidari
n:Pourheidari;Homayoun
org:WebLogic Integration
adr;dom:;;2315 North First St.;San Jose;CA;95131
email;internet:homayoun@bea.com
tel;work:+1 408.570.8175
version:2.1
end:vcard