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

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

#1. May be, but, IMO, that is just too much. We'll explore taxonomies and extensible categorization at the F2F, but that is only for classifying the types of relationships themselves. Roles are URIs defined by relationship type itself. That is, when defining a category called "containment" one would also define two roles of "container" and "contained" and identify the roles with the URIs. This is in an english text document. The clients that need to understand the semantics of the relationship will need to bake-in the category identification of this type and also URI for the roles. The clients that do not need to understand the semantics of the relationship, can still understand the directionality by merely matching participants with role URIs indicated by SourceRole and TargetRole. It is important to be able to do so without necessrily having an apriori knowledge of the semantics of the relationship as custom relationship types are very much possible. 

#2. This sounds like BPEL partnerLink. This reltionship was to deal with arbitrary resources e.g. HDDs which may or may not be manageable not to say exposed as a Web service. Talking about interfaces that resources have to support is a far stretch. Why not just use BPEL partnerLink instead of this to represent such role-interface relatinship? Besides that could be one of the Reference dialects.

#3 Well what about a resource which is a Web service and is also manageable. Why can't I express a relationship which points to 1) ResourceID 2) functional WS EPR and 3) WSDM manageability endpoint EPR? Why would I need two relationships to express that? Besides there is no interoperability problem because Reference has dialects. Dialects are URIs which are defined. Therefore if the dialect is understood it will work. This is no more or less interoperable than wsrf:Selector with a dialect attribute.

#4 
If relationship provider wants to support events then yes it will need to implement wsn:NotificationProducer interface. There it will need to report wsn:TopicSpaces property which it may include any of the topic spaces indicated in the capability definition.
The client does 1) detects whether or not wsn:NotificationProducer interface is implemented by the WS endpoint which implements the manageable relationships capability 2) reads wsn:TopicSpaces property and finds out if topic it is interested in is available and 3) subscibes. Only then it can be sure that events are supported by the relationship provider.
Therefore if provider does not want to support events it just does not implement the notification producer interface or does not report topics spaces. 

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

-----Original Message-----
From: Peter Brittenham [mailto:peterbr@us.ibm.com] 
Sent: Thursday, August 12, 2004 8:32 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Groups - Manageable Relationships for WSDM .doc uploaded

Here are some comments on the latest version of the relationships document. 

1. Section 2: SourceRole and TargetRole

If these attributes are specifying the type of role, should this be a QName instead?  This allows you to define the type names within a specific namespace.  This also allows you to define a set of type names using XML schema.  Here is an example:

  <!-- Containment role types -->
  <simpleType name="Containment">
    <restriction base="QName">
      <enumeration value="muws-role:Container"/>
      <enumeration value="muws-role:Contained"/>
    </restriction>
  </simpleType>


2.  Section 2: Roles

Since it is possible that different roles may implement different interfaces to support the role, how would a participant advertise the association between the type of role and the interface that supports it? 
For example, a Container may have an interface that is unique to that role. 


3. Section 2: Reference element

I can't help but think that allowing more than one Reference per Participant may lead to interoperability problems.  Would it be possible to require just one reference that contains the resource ID, an optional EPR, and extension elements from any namespace?  The namespace for the extension elements could be used to understand the semantics of the elements instead of using the Dialect attribute.  By doing this, you allow references to resources that don't have an EPR (or resources where you don't know their EPR) and resources where you do know their EPR.  You also can specify reference information that is unique to the resource.

Here's an example of what I mean:

<Reference>
  <ResourceID>xsd:string</ResourceID>
  <ResourceEPR>wsa:EndpointReferenceType</ResourcepEPR> ?
  <xsd:any/> *
</Reference> 


4. Section 3.2: Events

I may have missed it, but is an implementer of the manageable relationships capability required to support these events?  Also, does supporting these events imply that you need to support a subscription interface?


Regards,
Peter Brittenham
IBM




Igor.Sedukhin@ca.com
08/11/2004 04:42 PM

To
wsdm@lists.oasis-open.org
cc

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 #2 of Manageable Relationships for WSDM .doc.

Document Description:
Added issue comments from the discussion. Fixed a few sentences. Added definition of the control capability.

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


View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsdm/document.php?document_id=8673


Revision:
This document is revision #2 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_workgroup.php
.