[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Disc02] (was: RE: [wsdm] Discovery recap)
Just to recap my position on [Disc02] in order to get it closed ASAP. Here it is. I'd suggest WSDM TC to recommend to WSRF TC that 1) it must be clear how to use "singleton" (regular Web services) pattern with WS-ServiceGroup, WS-ResourceProperties, etc. 2) it is clarified how to determine that WS-Resource or "singleton" patterns are used given a WSDL document 3) the "singleton" pattern is defined and allows message exchanges without ANY required headers I believe that there is a lot of value in being able to use WS-ResourceProperties, WS-ServiceGroup, etc. in regular Web service implementations. Those operations and schemas do not have to be reinvented. It should be possible to use them with or without headers and initial EPRs. PS. I think fulfilling 1)-3) is technically very easy. -- 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: Thursday, May 27, 2004 10:54 AM To: email@example.com 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. 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.