Resolving endpoints

[Paul Harrison]

Ray Plante wrote:

>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?
>  
>
I'm not too bothered whether the endpoint be attributes of values - but 
it is important whether they be optional or not. I would like to see 
them as being optional, then it would be necessary to look in the wsdl 
to find the real end point, which would give the service implementer 
some flexibility when publishing - They would only have to change the 
wsdl if they wanted to change the physical location of a service, rather 
than check all of the registry entries that might exist. I think that 
there is even an argument for not including the endpoints in the 
registry at all and always insisting on picking them up from the wsdl - 
but I am not sure if this is going to far for some people.

>  
>
>>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.  
>
>  
>
It was thinking only of enumerating the IVOA Support Services (I did not 
use the latest jargon in my original post!) - just because it might not 
be that easy to persuade some web services toolkits to use standard 
names for ports, and this would give the possibility of an extra level 
of indirection.

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