[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Groups - Manageable Relationships for WSDM .doc uploaded
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...
it is not limited by the definition of the information type. yes you can of you'd like to.
<wv>Yes, there is no restriction preventing this.</wv>
2. When participants are NOT WSDM manageable resources... what
are they? unmanaged resources? identities of resources?
whatever the reference tells you. The dialect tells you what kind of reference that is. Therefore it could be just a reference to a functional endpoint (WSA) or things like SCSI ID, etc. (that is if one defines such dialect)
<wv>In our conceptual model, they are "resources". Whether or not they are managed, at this point we don't know.</wv>
theoretically yes, practically it is hard to process. Locating definitions or baking-in the relationship type understanding is harder to code than just a relationship instance that basically tells you everything you need. <Type> placeholder is the one to do dereferencing to the semantics.
Without this one cannot build a "map" of the resources without understanding each relationship type. Which may not always be possible with custom extensions.
<wv>How about simply having an optional "target=true" attribute on a role. In the case of a directional binary relationship this gives you the target and you can draw your arrows. In more complex cases, you don't use this and you're on your own to figure out how to draw the relationship.</wv>
I don't think I intended to mimic BPEL partnerLink with a relationship. BPEL partnerLink may be one of the reference dialects. Such semantics as requiring to support particular WSDL portType to be in the relationship is part of the relationship definition and therefore overlays the markup.
<wv>Yes, if the needed portType is defined as part of the relationship then you don't need to repeat that info. In the case where there is a concrete realization of a requirement that needs to be fulfilled by participants, that would be a property of the relationship.</wv>
3. Should we add a definition of the WSDL interface that
a control point for this relationship would have to support?
That is the last section in that doc. It is TBD. I though to say things like it MUST be a WS-Resource and it MUST implement WS-RL. So yes, but this is a TODO.
<wv>I proposed a WSRP document for this resource in my initial proposal.</wv>
I guess yes (if I understand your question). The same markup is used to report relationships by participants and non-participants. The instance information would be the same. The thing is that the manageable relationships capability could be implemented by a participant or anybody else (e.g. a relationship service). This is said in the text.
<wv>+1</wv>
5. Why do we need multiple references (presumably of the same participant) in the same participant????? What is the use case for this?
There is an example in the doc. I can point one to a SCSI HDD which is a Web Service, however is not WSDM manageable. So the consumer of the relationship information could locate the HDD and access it as a Web Service. That is if 1) the provider knows two reference dialects and 2) if the consumer asks for them.
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.
No! The relationship assumes directionality, individual
participants are either on one or the other side of the direction. To
represent many related resources with varying directionality, use many
relationship instances. That is the right approach. I've added
multiple participants to model things like "A and B and C are
friends". (There was a more intricate use case from CIM).
<wv>Igor, if I understand what Heather is saying here, she was defending your <Direction/> element versus my suggestion that this be conveyed by using pre-defined roles for target and source. In any case, I want to make it clear that I want to allow arbitrary roles to be created. The question is whether to predefine some roles or not. I am not hell-bent on that. And earlier in this email, I proposed to use a simpler "target" attribute on a role to replace <Direction/> if we don't use predefined source/target roles.</wv>
RelationshipCapability
1. Does it make sense to add some convenience operation
here... 'getRelatedResources'? perhaps with a parameter of resource type to
narrow the results.
There is a WS-RF query example. This would be quite unnecessary. We can only guess what are the most common querties. Why build code around guesses?
<wv>Isn't all of spec writing an exercize in educated guesses? Many resource-constrained resources will not support XPath-based query but still need to be able to return their relationships on a certain kind. So I think such an operation would be useful.</wv>
2. Who sends these events? The relatoinship participant? A third party that is aware of (or caused creation of) the relationship?Whomever implemented the manageable relationships capability. It may be the participant itself or something that observes the participants from the outside. the provider of the capability emits the events.
<wv>+1. In general, whoever allows you to register for the events is responsible for making sure the events get emitted.</wv>
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.)?
This is too advanced for 1.0. See WS-ServiceGroup for participant rules, etc.
<wv>Not sure this is too advanced but I agree we need to look at this in the context of our collection mechanism.</wv>
08/06/2004 09:48 PM |
|
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]