[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 .. (email@example.com) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Vambenepe, William N [mailto:firstname.lastname@example.org] 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 (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:email@example.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/leave_workgroup.php.