OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] Relations



There is another case where
 
[Relationship Provider]
Relationships /property/
or
Relationships QueryRelationships(selector) /operation/
+
events
 
All of these, including yours are covered by the current proposals.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

 


From: Homayoun Pourheidari [mailto:homayoun@bea.com]
Sent: Monday, August 09, 2004 9: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]