UWS SOAP

Dave Morris dave at ast.cam.ac.uk
Wed Oct 1 02:30:32 PDT 2008


It is possible to do this fairly easily in Java.

In our VOSpace implementation one webapp can provide multiple VOSpace 
webservices.
The SOAP endpoint URLs contain the target identifier.
For example, if I have service identifiers 'abc' and 'xyz', then the 
SOAP endpoints would be :
    http://hostname/context/services/abc
and
    http://hostname/context/services/xyz

All http post requests are passed to a simple http servlet at
    http://hostname/context/services/*
the servlet extracts the identifier from the URL (e.g. 'abc' or 'xyz') 
and then passes the request on to the Axis SOAP servlet.

Alternatively, you can just read the http URL from the HttpRequest 
object from within the Axis service code itself.
Either of these techniques mean you can create a unique SOAP endpoint 
for each job and handle them with the standard Axis SOAP servlet.

Hope this helps,
Dave

Paul Harrison wrote:

> Hi,
>
> I am trying to finalize the SOAP binding section of the UWS standard  
> and am trying to find an interoperable way to represent the job  
> identifier as an (effective) argument to various operations.
>
> The obvious way is to simply include the jobId as part of the SOAP  
> body input message for the various options - this is pretty much  
> guaranteed to be interoperable at the basic WS-I level - however it  
> might not be the most "elegant" solution. Earlier drafts of the UWS  
> standard have assumed that WS-Addressing would be used in some  
> fashion, but have not detailed exactly how.
>
> In WS-Addressing (http://www.w3.org/TR/ws-addr-core) it would be  
> possible to encode the jobId in the End Point Reference so that there  
> were effectively different end points for each job in a similar way 
> to  the REST binding for UWS. However, I am unsure as to how 
> interoperable  such a scheme might be, as it might not match the model 
> of addressing  that might be in the assumed by many of the SOAP stack 
> toolkits.
>
> Any opinions/experiences in this area would be welcome.
>
> Regards,
>     Paul.
>
>



More information about the grid mailing list