Resolving endpoints

Ray Plante rplante at ncsa.uiuc.edu
Fri Jul 2 09:13:59 PDT 2004


Hey Paul,

On Fri, 2 Jul 2004, Paul Harrison wrote:
> 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>

Yeah, this occured to me, too, as being more WSDL-like.  The reason I
resisted this was I was hoping that including the URL could be
optional; that is, the receiver (e.g. the harvesting registry) could
look this up if desired.  To do this, however, it still needs the
portname.  I think the only way to make the URL optional in this case
is with xsi:nil="true", which must be explicitly set.  Optional
attributes (or optional child elements) are much easier to deal
with--you just don't include them.  

Having the portnames sans address is useful because you can see which
ports the service supports, nice if some are optional.  

I'm on the fence.  What do you think?

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

This is interesting as it may be useful for something else I'm working
on.  Were you envisioning the enumerated type values only include
those from IVOA Support Services (assuming we split things up by port,
which we may not)?  Or would it include other "standard" ports
(e.g. skynode).  The latter would be difficult from a standardization
point of view.  In our resource metadata model, metadata specific to a
particular standard service is in its own schema and standardized
separately.  

cheers,
Ray




More information about the registry mailing list