ExperiencesWithSoap

KeithB and colleagues are working on a demonstrator that makes a request to a SOAP web service from a java enabled mobile phone. The service in this case expects a UK postcode and returns a .gif of a map of the location.

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 http://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 http://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) ³host³³date³June 12, 2002³agent³Mozilla/4.0 (compatible; MSIE 5.12; Mac_PowerPC)³ExperiencesWithSoap

My manager seems to think that SOAP and webservices are the only way to achieve a service oriented architecture. So he has forced through a SOAP implementation that is now used in a variety of the company's product portfolio. The service provides authentication and entitlement functionality for subscribers to leading online journals. The problem is that the webservice he has pushed through has a COM Interop dependency and it also wraps up a legacy XML messaging application. So you can imagine how expensive our login in process is(huge xml payload, network latency issues,serialisation and deserialisation costs etc). The simplest thing to get this beast of an "architecture" to be responsive is to actually colocate the webservice with the web application, but this coupling introduces problems of its own as it causes conflict with an earlier version of the DLLs. So now we all have SoapInOurEyes and the business and the 10,000 paying user base are screaming for a faster application. What a bastard. --DeveloperFormerlyKnownAsMorpheus?