Resolving endpoints

[Paul Harrison]

Ray Plante wrote:

>Hey Paul,
>
>Thanks for your suggestion.  I think we're beginning to understand a bit 
>more of what we need in the Web Service description.  
>
>I like your use of 'use="wsdl"', and I think we'll need to list the 
>different port names as you suggested.  (Wil suggested the use of standard 
>names for standard ports/operations.  We can still have this and clients 
>can take advantage of this; however, we would need to allow names to be 
>listed for non-standard Web Services.)
>
>One question is, should we include each endpoint address along with the 
>names?  If you want to save the consumer the trouble of pulling them out 
>of the WSDL, then I think including them in the resource record makes more 
>sense than an extra method a la lookupEndpoint().  Consider that for 
>lookupEndpoint() to work, it needs (in addition to the desired port name) 
>to know which WSDL to extract it from, that means an argument that is either:
>  a.  the resource ID
>  b.  the resource record
>  c.  the service endpoint
>  d.  the WSDL
>
>This method is not such a great idea because...
>  o  c. and d. demonstrates that this is really a convenience
>     function--like a static function, if you will; it does not really
>     depend on special knowledge held only by that registry.  I'd
>     rather not impose another method on a registry to do something
>     that a client could go anywhere (including an generic library) to
>     have done.  
>
>  o  a. and b. imply that the registry has to look up the WSDL itself.  If 
>     it has to do that, it might as well do it once at harvest time and 
>     cache the info in its copy of the resource record.  If the
>     harvested record already has this info in it, you save on the lookup.
>
>  
>
I was really thinking of option a

>  o  the method is only relevant to Web Services.  There's nothing
>     else in our registry interface that is specific only to one
>     resource type, except getRegistries(), which I don't think we
>     need either.  
>  
>
I take this point about the registry interface - it was just a convience 
suggestion

>So, should we iterate on a revision to the Web Service interface
>description in the VODataService schema?  Just to set the baseline,
>the description looks like this in v0.5:
>
>   <interface xsi:type="vs:WebService">
>      <accessURL>http:www.astrogrid.org/astrogrid-applicationsCommonE
>xecutionConnectorService.wsdl</accessURL>
>   </interface>
>
>Your suggested modifications would change this to:
>
>   <interface xsi:type="vs:WebService">
>      <accessURL use="wsdl">http:www.astrogrid.org/astrogrid-applicat
>ionsCommonExecutionConnectorService.wsdl</accessURL>
>      <servicePort>MyService</servicePort>
>      <servicePort>HeartBeat</servicePort>
>   </interface>
>
>Now can we get the endpoints in?  We could either put it in as an
>attribute to servicePort, or we make servicePort a complex type with
>children.  What do you think?
>
>  
>
perhaps to be more in keeping with the form of the WSDL we should do 
something like

   <interface xsi:type="vs:WebService">
      <accessURL use="wsdl">http:www.astrogrid.org/astrogrid-applicat
ionsCommonExecutionConnectorService.wsdl</accessURL>
      <serviceEndpoint portname="MyService">http://any.org/endpoint1</serviceEndpoint>
      <serviceEndpoint portname="HeartBeatNonStandardName" type="heartbeat">http://any.org/endpoint2</serviceEndpoint>
   </interface>

with the type attribute being a enumeration of the standard services as 
well as a value meaning that this is intended to be a port offering the 
functional service (I cannot think of a good word to describe this at 
the moment!)

Paul.

-- 
Dr. Paul Harrison, Astrogrid Developer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572681 (direct), 571321 (switch) - 07904025192 (mobile).