RE: [wsdm] Discovery Scenarios [fred]

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

Tom,

Due to [A ServiceGroup is a WS-Resource, following the implied resource pattern] as defined in http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/6580/WS-ServiceGroup.March%2031.f.doc, one would need to obtain an EPR to talk to a ServiceGroup. So that does not solve a problem of obtaining initial EPRs just yet.

Either WSDM or WSRF has to clarify 
	1) that a ServiceGroup can be used in a singleton pattern
	2) describe a normative way to determine whether a singleton pattern can be used to communicate to a ServiceGroup [or WS-Resourse in general, for that matter]

I think it is reasonable to allow a management interface and a query collection interface to be implemented by the same endpoint in an intention to provide EPRs for the resources managed by a given Web service endpoint.


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

-----Original Message-----
From: Tom Maguire [mailto:tmaguire@us.ibm.com] 
Sent: Friday, May 21, 2004 10:31 AM
To: fred.carter@amberpoint.com
Cc: Wsdm (E-mail)
Subject: Re: [wsdm] Discovery Scenarios [fred]






I think it is perfectly reasonable to be able to locate WS-Resource qualified endpoint references.
I also think it is perfectly reasonable to standardize an interface for querying/retrieving a collection or related WS-Resources.  (BTW, there is one of these already WS-ServiceGroup ;-) )

I think it is unreasonable (perhaps even outright wrong) to require that the management endpoint interface and the interface for querying/retrieving a collection MUST be implemented by the same endpoint.



Fred Carter <fred.carter@amberpoint.com> wrote on 05/20/2004 06:38:22 PM:

> <ScenarioPart>
>
> My scenario, unless I mentioned another to which I wasn't paying 
> attention during the call, is as follows.
>
>     Manager is started.  It is given either a WSDL file (which 
> corresponds to an endpoint for a manageability endpoint) or a URL 
> (which corresponds to said endpoint -- assumed to have some known capabilities).

More precisely you mean that a manager is "given" a service element and port, somehow.

>
>     Manager wants to use said endpoint to do its manager application 
> thing.  To do so, it needs to find the resources available.
>
>     Now what?
>
> that's it.  I think this is the fundamental part of the so-called 
> "WSDL->EPR" requirements.
>
> </ScenarioPart>
>
> <FredsCommentary>
>
> Responses to anticipated issues:
>
>     Well, why not start with EPR's.
>         1) Cause we didn't.
>         2) Cause many web service applications follow the above 
> pattern

Today

>     Use [insert name] registry here.
>         1) Small site, I don't have one.
>         2) My first implementation will be the simplest one.  Later, I 
> will add complexity with more moving parts, etc.

It is fine if you "want" to implement an interface that provides query and retrieval on the same endpoint as the management interfaces.  That is clearly an implementation choice; requiring ALL implementations to make that same choice is overly constraining.

>
>     Why should we do this?  Why isn't this left unspecified?

Not asking for the interfaces to be left unspecified but rather requesting that we give the implementers latitude in where and how they implement that interface.

>         1) Our intent, insofar as I can tell, is to provide a 
> specification which is usable as is.  We have made a number of 
> decisions and taken directions based on the capability of extant tools 
> and software stacks, to ensure that the specification is adoptable.  
> If the we rely on a implementation specific stuff to start up, 
> especially for the simplest case (a small number of resources, one 
> container, no uddi, etc.), I think we have an adoption problem.

But you are relying on implementation stuff.  You are suggesting (I think) that EVERY implementation MUST provide this interface.  If we create hardened requirements for collocation of interfaces in an implementation we introduce a fragility in the standard that will eventually cause us grief/pain perhaps even thwarting adoption.

>         2) We can certainly argue that there are should be some other 
> [heretofore nonexistent] specification in which the belongs.  And that 
> may even be true.  But we want folks to adopt & implement now, so 
> basing our work on more things that might come real soon now seems 
> fraught with peril.

Lots of questions here.  What do you think the product adoption cycle of a standard is?  As always wrt dependencies on other work; however, reinventing, over-sepcifying, or ignoring other work are equally fraught with peril.

>         3) One /could/ make whatever a solution might be (say, the 
> ListEPRs operation, for purposes of argument) optional so that "tiny 
> manageability provider endpoints" (or dynamic ones) could function 
> without fear, but I think we should provide the definition nonetheless.

+1 to this.  Normatively describe the interface and make it optional.

> At a higher level, I think that any system wherein access to said 
> resources is provided by other access providers (e.g. WSRF-based 
> things
> :-) ) must have a means by which one can determine which resources are 
> accessed via what access provider (modulo permissions, etc.).  This is 
> a bootstrap issue.  It may be that there are options (e.g. use some 
> registry), but then one must be able to find said registry. (Perhaps 
> we define some appropriate fault or property that directs the caller 
> to said registry when necessary.)  Consequently, I tend to think that 
> this is a general problem for WSRF.

Some aspect of this may be WSRF.  However, I think you will find that WSRF TC will not standardize service implementations.  They MAY standardize a fault mechanism (which is an interesting idea).

>
> [It may be appropriate higher up in the chain (it may be some of the 
> defined mechanism behind ...Addressing), but since WS-Addressing is 
> agnostic on what the properties are used for, it may not be 
> appropriate there.]
>
> </FredsCommentary>

<snip/>

T o m   M a g u i r e

STSM, On Demand Architecture
Poughkeepsie, NY  12601

internet:                 tmaguire@us.ibm.com
phone:                     845.433.9401 (t/l 293-9401)



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.