Subject: RE: [wsdm] Discovery recap
Status of the discovery issues after today's call: [Disc01]: hibernate (submitted to WSRF, we'll address it if they don't do it in a satisfactory manner) [Disc02]: open (ongoing discussion on the mailing list with Tom, Igor, others...) [Disc03]: hibernate (assumption that Relationships will provide the needed framework, to be flushed out and confirmed when we have Relationships covered) [Disc04]: open (AI to William to send proposal to the list) [Disc05]: open (AI to Andrea to send proposal to the list) [Disc06]: open (AI to Heather to send proposal to the list) [Disc07]: closed (in spec wording, we should use WSDM concepts of manageability capabilities rather than WSDL concepts of portTypes) [Disc08]: hibernate (assumption that Relationships will provide the needed framework, to be flushed out and confirmed when we have Relationships covered) [Disc09]: open (AI to Fred to send proposal to the list) [Disc10]: open (low priority, no AI assigned) [Disc11]: hibernate (assumption that Relationships and notifications will provide the needed framework, to be flushed out and confirmed when we have Relationships covered) Regards, William > -----Original Message----- > From: Vambenepe, William N > Sent: Friday, May 21, 2004 5:01 PM > To: firstname.lastname@example.org > Subject: [wsdm] Discovery recap > > > > Hi all, > > Trying to recap where we are on this "discovery" work. I am naming the > different discussions/issues so we can address them clearly > (no I won't > give an EPR to each one). Note that these are limited to MUWS > discovery > issues, not MOWS. > > [Disc01] > This is the issue of finding a WSDL from an EPR. I didn't hear any > disagreement on the wording that we came up with for the corresponding > requirement during the conf call last week. This requirement (to be > passed to WSRF) reads in three parts: > > 1) Any EPR used to reference a WS-Resource must provide sufficient > information for the consumer to retrieve the WSDL description of the > WS-Resource. > > 2) The EPR must contain enough information to disambiguate which port > and/or service to use. > > 3) The WSDL component model of the WS-Resource must be complete (must > include, inline or import the schema of all referenced elements) > > [Disc02] > This is the first part of the "WSDL->EPR" requirement that we > discussed > on the phone this week. The way I understand this issue, it is "if I > only have a WSDL document, how can I tell whether this WSDL document > contains enough information for me to invoke a WS-Resource behind it > (without needed extra info in the form of an EPR)". Some > argue that this > not an issue and this feature is not needed (people will get > an EPR, not > a WSDL so there is no need to go from WSDL to EPR). Others > argues that, > especially in the case where the ReferenceProperties element > of the EPR > is empty, one might want to just use WSDL and we need to help > them do so > by addressing this issue. > > [Disc03] > This is the second part of the "WSDL->EPR" requirement that > we discussed > on the phone this week. It is the issue of providing a way > (e.g. a WSDL > operation, a Resource property...) to retrieve a list of EPRs from > "someone". > > [Disc04] > From one manageability endpoint to other manageability > endpoints of the > same resource (to discover all the manageability capabilities > offered), > including endpoints from the same and different manageability > Providers. > We discussed that one 2 weeks ago but didn't talk about any way to > address it yet. > > [Disc05] > From several manageability endpoints to the realization that > they manage > the same resource. This is the "what if ResourceId fails us" story. > We've talked about "correlatable properties" but haven't yet done much > to address this. > > [Disc06] > Discovering to what extend optional management capabilities are > supported by a manageability endpoint. E.g. some capabilities > might only > be accessible in certain states. Or some of the capabilities we define > might not be granular enough and people might pick and choose > what part > of a portType they implement. Or a manageability endpoint might limit > what it sends (for example limit based on the size of the > reply message, > you can't ask for all the resource properties if the resource > properties > doc is too big). Etc. Can someone smell meta-data? > > [Disc07] > Identifying a "management" WSDL, a "management" EPR. > I am having a senior moment here, I can't recall why I put this one in > my original list. And why it survived our review in the conf call 2 > weeks ago. We already decided that the muws:Identity portType > was acting > as marker, so I am not sure what else is needed. Can we close this? > > [Disc08] > From the manageability endpoint of one resource to manageability > endpoints of other related resources. This is the "start from one > resource and follow the relationships to discover other resources" > approach. > > [Disc09] > From management repository to EPR. This is the topic of the > thesis that > Fred is currently writing as part of his action item to the > group... ;-) > Basically, how much do we want to specify about the involvement of > registries in MUWS. > > [Disc10] > "hello world" multicast (like WS-Discovery). Do we want to look into > this for discovery on a subnet or not? Not a high priority > requirement. > > [Disc11] > This was brought up by Mark Ellison on an email sent 5/20. The idea is > that one might discover resources by registering for notification on > events related to discovery (creation/destruction). We'd need > to define > who you register with and what this registration looks like. > > Regards, > > William > > > 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.