RE: [wsdm] Proposal for [Disc03], [Disc08] and [Disco11] (was RE: [wsdm] Discovery Scenarios [fred])

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

Hi Igor,

I like 1) except for the restriction to one kind of relationship. For
the sake of discovery, why would I be forced to limit myself to
"manages" relationships? If a WSEE tells me it "contains" a bunch of
services I am going to use that for discovery. If a service tells me it
"depends on" a set of services I am going to use that for discovery.

Obviously this will only be fully resolved once we have our relationship
work in place. But we might have enough common understanding on what
this is going to look like (just by looking at WSMF and WS-M) to not
invent specialized constructs that we know are going to be provided in a
more general way by relationships.

Regards,

William

> -----Original Message-----
> From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] 
> Sent: Sunday, May 23, 2004 1:17 PM
> To: Vambenepe, William N; Wsdm (E-mail)
> Subject: RE: [wsdm] Proposal for [Disc03], [Disc08] and 
> [Disco11] (was RE: [wsdm] Discovery Scenarios [fred])
> 
> 
> William,
> 
> Instead of solving the relationships in a way that I'm not 
> sure yet it will be solved, why don't we close [Disc03] by
> 1) either saying that a Relatinships managebility capability 
> will provide a way to query "manages" relatinship
> 2) or define a DiscoverResources manageability capability 
> with muws:ResourceList property which works as you described
> 
> We need to start talking about Relationships, however I 
> believe it was planned for later time. I think Heather and 
> myself took Relationships to champion, so we need to get our 
> act together to start the track.
> 
> In general, it may be reasonable to implement Relationhips 
> via ServiceGroup because usually it is more reasonable to 
> query relationshops that have many parameters e.g. category, 
> name, direction, etc. Again, I'd like to get a meaningful 
> discussion before comitting to muws:Relationship property.
> 
> Irrespective of 1) or 2) above we will still have two problems
> A) how to determine from WSDL that a singleton pattern could 
> be used to do 1) or 2)
> B) how exactly to use a singleton pattern to talk to a Web 
> service endpoint using WS-ResourceProperties, WS-ServiceGroup, etc.
> 
> I think that A) and B) are nor clear nor defined in WSRF yet. 
> So this could either be our requirement to WSRF or WSDM will 
> make it clear and normative (but optional) in the Discovery 
> section of the spec.
> 
> 
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> 
> -----Original Message-----
> From: Vambenepe, William N [mailto:vbp@hp.com] 
> Sent: Friday, May 21, 2004 9:46 PM
> To: Wsdm (E-mail)
> Subject: [wsdm] Proposal for [Disc03], [Disc08] and [Disco11] 
> (was RE: [wsdm] Discovery Scenarios [fred])
> 
> 
> I agree with Thierry's proposal. Using the issue names from 
> the "discovery recap" email, this proposal says that issues 
> [Disc03] and [Disc08] should be merged and the mechanism to 
> ask someone for the resources it knows about is to ask that 
> someone for the relationships they have.
> 
> Practically, one way to do this is to create a MUWS-defined 
> resource property called "muws:Relationship" of cardinality 0 
> to infinite. The exact type of this will come from our 
> group's work on relationships.
> Resources will use this property to expose relationships they 
> are engaged in (and know about).
> 
> There is only one correction I want to make on Thierry's proposal.
> 
> In the wording for [Disc03] I purposely wrote: It is the 
> issue of providing a way to retrieve a list of EPRs from 
> "someone". I didn't call this "someone" manageability 
> provider because currently what we define as the 
> manageability provider is not an entity to which you address 
> messages, it is an entity that allows WS-Resources to receive 
> messages.
> It does not have interactions of its own. I think it should 
> stay this way. The resource that exposes its relationships is 
> different from the conceptual "manageability provider" even 
> though it might in practice be the same code. So I would 
> slightly modify Thierry's proposal to not say that the 
> relationship is between the resource and the "manageability 
> provider". It is between the resource and some WS-Resource 
> that we happen to know about.
> 
> Here is an example:
> 
> The resources I am discovering are Web services. I am also 
> managing their container, as a WSEE resource. In practice, 
> the code behind the WSEE (say BEA WebLogic) is also the 
> manageability provider for the Web services. But my 
> interactions are with the WSEE as a Web Service Execution 
> Environment, not as a "manageability provider". I retrieve 
> the "relationship" resource property for the WSEE and it 
> gives me a bunch of "containment" relationships with each of 
> the Web services deployed in the WSEE. These give me the EPRs 
> of the manageable resources corresponding to these services. 
> Note that the WSEE might also have, for example, a 
> "dependency" relationship with the server on which it runs or 
> with a database it uses. As the requestor, it is my choice to 
> decide what relationships I care about. For example, if I am 
> a simple topology tool who just wants to draw a map of all 
> the resources present, I will consider all the relationships 
> exposed by the WSEE. If I am a Web service-centric tool that 
> only care about Web services, then I will only care about 
> resources that have a "contained" relationship with the WSEE.
> 
> How does this map to our "WSDL to EPR" discovery discussion? 
> Simple. If I discover a WSDL and this WSDL happens to have, 
> among its resource properties, the muws:Relationship resource 
> property, I might try to retrieve these relationships. Now 
> this invocation might fail if some reference properties are 
> needed, but this is a matter for issue [Disc02] which I don't 
> want to discuss here. Assume that the interaction succeeds, 
> either because the resolution of [Disc02] allows this or 
> because the implementer just decides to make a WS-Resource 
> available at this address which has an empty 
> ReferenceProperties element in this EPR.
> Then we retrieve a bunch of relationships that give us a 
> bunch of EPRs.
> We have in effect provided one way to retrieve EPRs from a 
> WSDL: send a 
> <wsrp:GetResourceProperty>muws:Relationship</wsrp:GetResourceProperty>
> request to the address in the WSDL and see what you get back. 
> Whether to make this pattern a best practice or not is for us 
> to decide.
> 
> As Thierry also notes, this also covers us with regards to 
> [Disco11], brought up by Mike Ellison. These "someone" whom 
> we ask for their relationship, we can also register with them 
> for notification on creation/deletion of relationships. So, 
> using my example above, I would register with the WSEE for 
> notification on creation/deletion of relationships. This way 
> whenever a service gets deployed/undeployed I will be 
> notified. Same thing for the "WSDL to EPR" example. That 
> WS-Resource that I asked for its relationships (whether this 
> WS-Resource is a manageable resource of its own with a 
> muws:ResourceId and other management capabilities or not) 
> might also be willing to act as a notification producer and I 
> can register with it for notification on destruction/creation 
> of relationships.
> 
> If people are comfortable with this approach, we can close 
> [Disco03], [Disco08] and Disco[11] (or rather hibernate them 
> until we get to the work on relationships). The discussion 
> would still go as to what to do with [Disco02] and whether to 
> submit a requirement on it to WSRF, but the [Disco03] part of 
> the discussion would be off the table and not need to go to WSRF.
> 
> Regards,
> 
> William
> 
> 
> -----Original Message-----
> From: Thierry Schang [mailto:tschang@tibco.com]
> Sent: Friday, May 21, 2004 3:12 PM
> To: Wsdm (E-mail)
> Cc: Thierry Schang
> Subject: RE: [wsdm] Discovery Scenarios [fred]
> 
> 
> I think we do need to have a "ListResources" functionality for each
> manageability provider.  This model is used by multiple agent based
> management systems, JMX and HP's WSMF are good examples of it.
> 
> The functionality itself can actually be handled like a relationship
> named "manages" and/or "isManagedBy" which can exist between the
> manageability provider and each EPR. 
> 
> Discovering new EPRs or changes in the EPR list can be done through
> relationship change notifications.  We haven't talked much about
> relationships yet in this group but it will probably provide 
> a mechanism
> to notify the manager of any relationship change, hence we get the
> functionality for free in this context.
> 
> thanks
> 
> Thierry Schang
> TIBCO Software Inc. - voice: 650 846 5781
> 
> 
> 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/leav
e_workgroup.php.