Summary of [Disc02] (was: RE: [wsdm] Discovery recap)

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

 The issue is about starting with WSDL and not having any EPRs yet. Then understanding how to locate and use WS-Resoures that share the given WSDL. Possible ways to do that:

1) A "marker" in WSDL which would indicate that a "singleton" WS-Resource pattern is used. In other words, there is no need to locate an EPR. WSDL is sufficient. This is a regular Web service. -> Such "marker" should be normatively defined by either WSRF or WS-Addressing. It could be simply presence/absence of particular <soap:hader> elements in the binding, for example.

2) A "list EPRs" portType with an operation to retrieve all EPRs which share a given WSDL endpoint. Such operation would always follow a "singleton" pattern (i.e. not require any initial EPRs to be located). WSDL binding of such operation would include a "singleton marker" as described in 1). -> WSDM could define such operation and require it to be bound as a "singleton", also WSDM Relationships manageability capabiluty could be used to do the same, however a simpler "list EPRs" operation is better for implementers.

3) A "registry" could be used to retrieve EPRs for a given WSDL document. For example, given a WSDL endpoint, locate all EPRs that share it. -> WSDM could define such "resource registry" profile of UDDI and/or WS-ServiceGroup.


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Vambenepe, William N [mailto:vbp@hp.com] 
Sent: Thursday, June 17, 2004 12:28 PM
To: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Discovery recap


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.


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.