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

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

William,

I think for the purposes of the bootstrap discovery we'd need to define a specific relationship type. That itself may be done in Relationship work, but, IMO, Discovery needs to explain how to use it for bootstrap.

Imagine you get a WSDL, then you use a "singleton" pattern and query/retrieve relationships, then
A) what am I talking to via this singleton pattern (it is not a WS-Resource per se, so it is not supposed to be a manageable resource, so relationships of what to what am I retrieving)
B) if I wanted to discover what manageable resources share this given WSDL, then what relationships do I need to look for. "contains" relationship may not point to a resource that shares this WSDL. Why can't we have a predefined relationship type for this?
C) if I retrieve all relationships, then which relationships I need to be looking for when bootstrapping?

IMO, 1) is fine, but may be too open ended, 2) is easier for implementers to understand the bootstrap discovery without too many assumptions.


-- 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: Wednesday, May 26, 2004 6:04 PM
To: Sedukhin, Igor S; Wsdm (E-mail)
Subject: RE: [wsdm] Proposal for [Disc03], [Disc08] and [Disco11] (was RE: [wsdm] Discovery Scenarios [fred])


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.



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.