On Mon, 20 Nov 2006, Doug Tody wrote:
> Avoiding for the moment the issue of VOSpace vs S3; S3 of course does
> have a REST interface as well as SOAP; I don't know the statistics, but
> I'll bet 80-90% of the traffic is with the REST interface, as that is how
> these things generally run.
>
> Seriously, SOAP is a nice technology, but like much new technology
> it is over-hyped. The main thing it gives you is a formally defined
> interface (via WSDL), and automatic language bindings - essentially
> IDL/CORBA for the Web. But this does come at a cost, and may not be
> cost effective unless you need to bind enough interfaces to make the
> cost worth the effort to invest in the technology needed to automate
> the language bindings.
The other aspects of SOAP are that it is independent of transport protocol and has an envelope/body structure that separates the concerns of the service from the concerns of the middleware. These two combine to make it easier to _standardize_ things like security across a range of services.
As an example of a benefit to IVOA, when we work on the specs for VOSpace and UWS-PA interfacess, which are both SOAP, we don't need to consider security. We write something like "most VOSpaces should have controlled access using IVOA standards" and "any UWS-PA service that needs controlled access should also implement the IVOA security standard" and we're done. The details are elsewhere and we _know_ that we can fit the security spec to the others because SOAP gives us a way of doing so.
As an example of a benefit to the service implementors, a secured SOAP service in Java can be a composite: servlet engine + unsecured service code + security-plug-in implementing WS-Security. That is, the security doesn't disrupt either the HTTP server or the basic code for the unsecured service. There are services built this way in Edinburgh using AstroGrid parts.
Now compare the situation for a secured DAL service using HTTP-get. The security standard says "HTTPS with RFC3820 support". To get the RFC3820 support, I'm having to write my own HTTP server and JSSE provider! Because the message and its security metadata are intertwined with the transport, I have to change the transport - which I'd much rather treat as a given - to change some aspects of the message.
SOAP uses more complex messages than REST which in turn uses more than stateless HTTP-get, but the interface complexity allows one the chance to manage the implementation complexity.
Cheers,
Guy
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2006-11-21Z10:04:56