ExperiencesWithSoap

A sort-of handy thing to have on your PDA/communicator. Except...the damn thing crashes on several platforms because it runs out of memory. On closer examination, the aproximately 7000 bytes of .gif data are returned as aprox 7000 named properties on a UntypedObject? obect. Each property is called "unsignedByte" and has as its value a string containing the denary digits of the byte's value. That's something like a 13.5 byte overhead on each byte of data. And that's before all the XML syntax gets in there. While the XML parser is sorting this mess out the Java heap grows to about 1.5 Mb, way more than most phones have avilable. Whereas, if we did an honest-to-Tim-Berners-Lee REST style request we'd get the bytes plus the trivial overhead of the HTTP headers.

(NB, it turns out that the implementors of the web serivce in question have screwed the pooch, and that the SOAP spec mandates the use of a base 64 string encoding of arbitrary byte streams. Which makes the below slightly less of a problem, but the SOAP envelope doc is still a substatial overhead, and the sync problem with (de)serialsiers still holds.)

(OliBye suggests that if you're using SOAP over HTTP, then return the URL of the gif you want, and have another HTTP request to get it. If you use HTTP1.1 it will happen on the same socket connection, if you use HTTP1.0 set the Keep-Alive header. SOAP is plainly not for getting binary content like gifs, and it seems perverse to use it over HTTP to a server that's probably perfectly capable of answering a GET request for the gif! (This assumes you're using HTTP))

Give us some credit. The purpose of the exercise was to demonstrate exactly access to the given WebService using SOAP from a phone. We have no control over the server. And yes, it is perverse. The alternative loses on buzzword points, however.

<soapbox_moment> Or go one step further and abandon internet RPC in favour of a REST-ful architecture. See internet.conveyor.com/RESTwiki/moin.cgi/ for the bigger picture! </soapbox_moment> ;-) TimBacon

Indeed. In our case, for efficiency reasons we'd much prefer a REST style solution, plus we actually need a .png on the client, not a .gif and so are writing our own REST style service as a facade that gets the .gif from the SOAP server by speedy fixed connection to our server, which will convert it on-the-fly and supply the bytes of the resulting .png to the clinet in the normal HTTP way.

The web service we're using is in beta, so maybe things will improve, but how? SOAP lets you use your own custom serialisers and deserialisers, so in principle a given web service could use some binary enoding nearly as efficient as that used by, oooh just off the top of my head, CORBA. Remember CORBA? Those are starting to look like the good old days. Anyway, if you did that, there'd then be the headache of keeping the client and server in sync, an overhead which SOAP is meant to avoid. And it's an overhead that is unacceptable (for a bunch of reasons, not all technical) in the mobile arena. It's much less of an overhead in the desktop arena, but then desktops typically have high avilability and relatively high bandwith connectivity anyway!

BTW, if you haven't seen any, SOAP client code is disgusting. It's meant to be like RPC, but (unsurprisingly, given how it works) looks a lot more like preparing a statement and submitting it to a database.

For a much cleaner and leaner transport, take a look at Hessian, from www.caucho.com/

Which makes me wonder, just who is SOAP supposed to be good for? -- er, how about the sales guys at Microsoft and IBM? (TimBacon, also disappointed with SOAP)