RE: [wsdm] Discovery recap

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

Hi all,

The current state of the "discovery" issues (thanks Richard for the F2F
minutes).

[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...). AI to Igor to send summary to the list.

[Disc03]: hibernate until Relationships are done at which point we'll
check whether this meets our needs.

[Disc04]: hibernate until Relationships are done at which point we'll
check whether this meets our needs.

[Disc05]: open (Igor sent reworked proposal after F2F, comments by
William and Tom, discussion progressing)

[Disc06]: open (AI to Igor to propose an approach to "capabilities
taxonomy")

[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]: hibernate (until after [Disc09] is addressed

[Disc11]: hibernate until after [Disc09] (Proposal from William using
relationships and notifications sent on the list)


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.
> 
> 
> 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.