Resolving endpoints

Wil O'Mullane womullan at skysrv.pha.jhu.edu
Thu Jul 1 06:18:23 PDT 2004


Indeed for me the point of SupportServives was to have standard names.
In this way we could include ?wsdl as a standard service - although I
think we already agreed this was a defacto standard.

Then we may cOntinue to store the endpoint only in the AccesUrl (as we do for skynodes) and have no ambiquity and no duplication...

On Thu, Jul 01, 2004 at 12:38:01PM +0100, Paul Harrison wrote:
> I fully endorse Guy's original point on this, that the current accessURL 
> situation is ambiguous when it comes to web services and WSDL. I think 
> that as a minimum we should have a separate regisitry element that 
> points to the WSDL (or add wsdl as an option for the use attribute ).  
> So we might have the following snippet of WSDL service definition
> 
>     <service name="test">
>         <port binding="tns:MyServiceBinding" name="MyService">
>             <soap:address location="http://localhost:8000/ccx/binding1"/>
>         </port>
>         <port binding="tns:HeartbeatBinding" name="HeartBeat">
>             <soap:address location="http://localhost:8000/ccx/test"/>
>         </port>
>     </service>
> 
> 
> there would be a registy entry like
>         <Interface>
>             <Invocation>WebService</Invocation>
>             <AccessURL 
> use="wsdl">http:www.astrogrid.org/astrogrid-applicationsCommonExecutionConnectorService.wsdl</AccessURL>
>             <ServicePort>MyService</ServicePort>
>         </Interface>
> 
> Where the entry for <ServicePort> points to the name attribute of the 
> <port> in the wsdl above. If we were to insist that the standard 
> services had standard names, the the <ServicePort> element could just 
> point to the  "main" service  that  was being offered - otherwise we 
> will have to come up with a way of saying in the registry which  each of 
> these are - possibly with multiple <servicePort> entries with attributes.
> 
>         <Interface>
>             <Invocation>WebService</Invocation>
>             <AccessURL 
> use="wsdl">http:www.astrogrid.org/astrogrid-applicationsCommonExecutionConnectorService.wsdl</AccessURL>
>             <ServicePort type="main">MyService</ServicePort>
>             <ServicePort type="heartbeat">HeartBeat</ServicePort>
>         </Interface>
> 
> This means that it is a more complicated to look up the endpoint for a 
> particular service, but this complexity is forced upon us by the 
> flexibility that is allowed by web services and WSDL. As Guy also 
> suggested it might be a good idea to have the lookupEndpoint() function 
> as part of the standard registry interface, so that most clients do not 
> have to worry about this complexity.
> 
> Paul.
> 
> Ray Plante wrote:
> 
> >Hi Guy,
> >
> >There is still ambiguity about what AccessURL points to in the case of Web 
> >Services.  In VOResource v0.9, it is defined to point to the WSDL; 
> >however, there was some desire for it to point to the endpoint for the 
> >reasons you described.  In the NVO registry, we didn't have a lot of 
> >Web Services defined (and that we critically depended on for our 
> >apps/demos), so it we were living with this ambiguity while we figured out 
> >what made sense.  
> >
> >There are still some issues to address related to our discussion of 
> >standard WSDL definitions that will affect this question.  For example, 
> >would we need or allow different parts of the interface to have different 
> >endpoints?  If so, which one should be the "accessURL"?  Should the other 
> >endpoints be placed in the registry as well? (probably so; then 
> >additional metadata are needed.)   I'm doing some experiments now with 
> >Axis to test some of the ideas we've batted around.
> >
> >cheers,
> >Ray
> >
> >
> >  
> >
> 
> -- 
> 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).



More information about the registry mailing list