Re: [wsdm] Discovery Scenarios [fred]

[Fred Carter <fred.carter@amberpoint.com>]

Overall,

I don't think it's necessary to "require" that the "ListResources" 
operation exist at the same endpoint.  It think it should be allowed.

However, I think it should be possible to find out where the appropriate 
endpoint is.  So many of the same issues apply.  It could certainly be 
that we define that this is a WSDM property that is returned by a WSDM 
endpoint, and that it can be used with no EPR present.  That would solve 
most of the issues (the EPR list could be a similar property...).  But 
that's a solution, not a scenario ;-)



Thus quoth Tom Maguire (~ 21-May-04 9:29 AM ~)...
> 
> 
> 
> I am pretty sure that a WS-ServiceGroup is not normatively described as
> having to be a WS-Resource.
> 
> From terminology:
> 
> 
> ServiceGroup:
> 
> ·     A Web service that is a collection of other Web services or
> WS-Resources and the information that pertains to them. The purpose of the
> group is application domain specific. The means by which the membership in
> the ServiceGroup is formed may be through ServiceGroupRegistration, or
> through other means not defined by this specification.
> 
> 
> 
> "Sedukhin, Igor S" <Igor.Sedukhin@ca.com> wrote on 05/21/2004 12:05:55 PM:
> 
> 
>>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.
>>
> 
> 
> +1 to reasonable to "allow".  I just want to make sure we do not "require"
> that to be true.
No problem.  However, if separate, one must still be able to find it.
> 
> 
>>
>>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
Which is, unfortunately, when we are.  Once all this stuff is defined 
well, this will be easy, right :-).

Paraphrasing Mr. Phelps, "That job, which we have chosen to accept..." 
is ours.  "The Secretary may [later] disavow any knowledge of our 
existence."

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

Again, I think it reasonable to have it elsewhere.  As long as it's 
findable in a system in which this is likely to exist (which I'd prefer 
to be "soon" if not now).

>>
>>
>>>    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.
OK
>>
>>
>>>        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.
I think I'm asking that there be a defined means by which a manager 
[management application] can find things, and that such a means exist 
only in giant data centers (e.g. layers and layers of registries).

On the call, there was much discussion that the means of finding such 
things should not be normatively specified.  I think that failure to do 
so results in interoperability issues.

I don't want to have to rely on WS-I's to do things that the standards 
group should have done.

But I'm /sometimes/ not very politic :-/

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

Yes, so if there's something else that will work, I'm all for it. 
However, I'm hesitant to say that 1) here's  a spec that's dependent on 
other spec's which won't be done for years (or depend on things that 
aren't even in commitee), or 2) here's a spec that requires a huge layer 
of other infrastructure to do relatively simple things.  This is always 
a fine line to walk, one that must be walked nonetheless.

If the answer is ServiceGroups, maybe.  I think that one's pretty far 
off in WSRF's timeline (i.e. I'm not even sure it will be discussed 
before our current schedule says we're done...).  But it may be the 
answer.  I'm certainly open to it -- but we need someway to do things.

>>
>>
>>>        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.
(I'll refrain from agreeing with myself here :-)
>>
>>
>>>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).
I don't think I said _anything_ about implementations.  I think I said, 
or intended to say, that the standard must define the means by which 
users thereof can determine the resource list and/or provider to whom to 
talk.

That's an operational requirement, in some sense, but I tend to view it 
as a completeness exercise for the standard.  If, when all is said, 
done, and implemented, fully but "only" compliant systems cannot 
function, the standard has missed.

('"only" compliant' here means systems that are build using the 
standard, the whole standard, but nothing but the standard (of course, 
they must implement the referenced & required standards as well).  The 
point is that they should not be required to have some other proprietary 
stuff to function.)

>>
>>
>>>[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)
> 
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301