RE: [wsdm] Groups - Manageable Relationships for WSDM .doc uploaded

[Heather Kreger <kreger@us.ibm.com>]

Wow! I should have travel issues more often! You guys were really productive!
This is a great start ... but I had some questions, maybe they were answered in the call that I missed.
<chair hat off>

Conceptual section:
1. Can a participant play several roles in a relationship? for example, be related to itself?
For example, if an application A is dependent on (uses) a security service S then security relationship: A uses S. But if A is depenent on a security service and also provides the security service itself, then security relationship: A uses A. The wording in the first paragraph made me wonder this...

2. When participants are NOT WSDM manageable resources... what are they? unmanaged resources? identities of resources?

Relationship Markup:
1. I think we’re mixing relationship type definition schema and relationship instance schema.

A relationship Type contains the type name, valid roles, directionality, and cardinality. You don't have to repeat this information for every instance of a relationship.

A relationship instance contains the type, participant (including the role and reference), and control point reference

2. Should we add the ability to define the WSDL interface a role must support in order be that role in the relationship? Or is it always the same as the role's URI. That doesn't seem quite right either.

3. Should we add a definition of the WSDL interface that a control point for this relationship would have to support?

4. Is the same schema used by relationship participants (I suppose through the relationship capability) as by relationships provided by non-participants (some third party)? Are we going to address the second case?

5. Why do we need multiple references (presumably of the same participant) in the same participant????? What is the use case for this?

On directionality, target/source semantics may be hard to preserve in relatoinships where there are more than 2 roles/participants or are peer type relationships. So, at first glance it seems more flexible to indicate directionality in its own element.

RelationshipCapability

1. Does it make sense to add some convenience operation here... 'getRelatedResources'? perhaps with a parameter of resource type to narrow the results.

2. Who sends these events? The relatoinship participant? A third party that is aware of (or caused creation of) the relationship?

Should there be a way to advertise relationship information about a resouce - relationships it can participate.. or must participate in. Allowable cardinality of the relationship (I can only be in one security service relationship, but I must be in one.)?

Thanks for all your work Igor and William.

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441) cell:919-496-9572

"Vambenepe, William N" <vbp@hp.com>

"Vambenepe, William N" <vbp@hp.com>

08/06/2004 09:48 PM

To	<Igor.Sedukhin@ca.com>, <wsdm@lists.oasis-open.org>
cc
Subject	RE: [wsdm] Groups - Manageable Relationships for WSDM .doc uploaded

Thanks Igor, this is a good merge of both your proposal and mine, as
well as the discussions that took place on the phone.

A few comments (in addition to Bryan's):

- I can go with multiple references per participant as long as we make
it crystal clear that these are all references to the same resource (and
by grouping them together the producer of this relationship element
asserts that these references point to the same resource). Also, we need
to specify that if the producer of this relationship element knows of a
manageability representation for participants in the relationship it
MUST include the EPR to this manageability representation as one of the
references for this participant.

- Having roles described as URIs is fine, but the current mechanism has
people create 3 URIs in most cases for each relationship type (one for
the type and one for each role in the "common" case of directional
binary relationships). And I don't find the <Direction/> element too
elegant. How about this alternative:
MUWS pre-defines three roles (and assigns URIs to them): a "source"
role, a "target" role and a "participant" role. When people create new
relationship types, if the relationship is binary and directional (e.g.
"DependsOn") they use the MUWS-defined "source" and "target". If the
relationship is non-directional and has only one role (e.g. "Neighbor")
then they use the MUWS-defined "participant" role. In all other cases
they create their own roles (and corresponding URIs) as necessary.
As a result we can drop the <Direction/> element. If the relationship is
binary and directional (the case in which <Direction/> would be useful)
then people who define the relationship type would use the MUWS-defined
"target" and "source" role URIs so the consuming tools would know in
which direction to draw the arrow.
With this approach we can support the exceptional case where the source,
target and participant roles are not enough without making the common
case more complex than needed.

- In the description of the "manageable" reference type, we need to make
it clear that not only is the content an EPR, it is an EPR that points
to a manageability representation of the resource (in the MUWS sense of
the term).

- Finally a small thing: I assume that minOccurs for <Participant/> is 2
not 1. I know it's not easy to express this in pseudo-schema, but maybe
a more correct way to write it is:
<Participant/>
<Participant/>+
Rather then just
<Participant/>+
But it still looks a bit strange.

Regards,

William

-----Original Message-----
From: Igor.Sedukhin@ca.com [mailto:Igor.Sedukhin@ca.com]
Sent: Friday, August 06, 2004 12:29 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Groups - Manageable Relationships for WSDM .doc uploaded

The document revision Manageable Relationships for WSDM .doc has been
submitted by Igor Sedukhin (Igor.Sedukhin@ca.com) to the OASIS Web
Services Distributed Management TC document repository.
This document is revision #1 of Manageable Relationships for WSDM .doc.

Document Description:
Assembled taking into account the discussion that we had. This one may
make everybody happy...
1) N-ary relationships
2) optional directionality
3) many references
4) controllable relationships
5) manageable relationships

Download Document:
http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/8515/Mana
geable%20Relationships%20for%20WSDM%20.doc

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsdm/document.php?document_
id=8515

Revision:
This document is revision #1 of Manageable Relationships for WSDM .doc.
The document details page referenced above will show the complete
revision history


PLEASE NOTE:  If the above links do not work for you, your email
application may be breaking the link into two pieces.  You may be able
to copy and paste the entire link address into the address field of your
web browser.



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
p.php.


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.