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