RE: [wsdm] Discovery recap

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

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: wsdm@lists.oasis-open.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.