Why not use Amazon S3?

[Guy Rixon]

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-337523