SOAP + WSDL in Mozilla | September 12th, 2005
I sure am behind the times. I just saw found out about the SOAP and WSDL support in Mozilla / Gecko based browsers. This is very cool and I am not sure why more people are not using this � especially in AJaX circles.
The other interesting thing that I found was that you can extend the DOM in Mozilla to support Microsoft HTML Component files or HTC�s - these are used in Internet Explorer to implement things such as SOAP and WSDL support. So you can in fact have SOAP and WSDL support in Gecko with either the built in objects or using HTC�s.
Ok so why aren�t more AJaX people using this built in support for SOAP + WSDL in Mozilla? If you prefer to generate JSON on the server and pass that up you are just crazy since you could instead pass it up as XML embedded in SOAP and then use XSLT on the client to (very quickly) generate HTML or CSS or whatever from the XML.
October 23rd, 2005 at 11:31 am
Might be late to comment on this - but I use SOAP for all AJAX messaging. From the server side its great as we use Apache AXIS to generate the SOAP message automatically from our java classes. This gives me an extremely clean architecture.
But on the client side - it took a fair while to get a cross browser SOAP layer in place. This is for IE and Moz only (the target platforms for our web apps). Some of the problems faced were creating an XML layer that hide all the differences between IE vs Moz (eg using XPATH, dealing with document namespaces) and then a SOAP layer that provides javascript proxies to the web services (including the ability to add custom serializers/deserialisers), uses XHR for IE, but SOAP Calls for Moz, and so on.
The upshot of it is - its not a trivial exercise. I wanted to leverage off the automatic Web Service capabilities thats available in most server side technologies (especially in the J2EE world), but also not get bogged down with manipulating XML in the javascript client. Hence the need for a solid client side SOAP/XML layer. The nice thing is - most XML (as long as it doesn�t use attributes) can automatically be converted to JSON. And JSON to XML.
Then theres using XSLT which is great for dealing with result sets, but overkill (I think) when dealing with services that return simple entity objects.
So the JavaScript coder really has to know their stuff, and be capable of engineering a layer into their framework. Personally, I am very happy with what I�ve done, but it took time. I can easily imagine someone saying bugger that, we�ll add the layer server side, and simply spit out JSON.
October 23rd, 2005 at 11:32 am
Simon that sounds like a good solution to me. Do you find it much slower than just sending/receiving the data in XML or JSON? I certainly agree that XML + XSL is overkill for returning simple objects - it should only be used when dealing with result sets as you say. Have you looked at using the IE SOAP behaviour? I totally hear what you are saying about leveraging the inherant Web Services capabilities on the server!
October 24th, 2005 at 11:32 am
Hi Dave,
um - I haven�t benchmarked sending JSON vs XML from our backend. It was really too simple to use use Apache AXIS (and reap the benfit of its stability, scaleability and performance) than roll our own server side JSON layer. It would still be a good comparison to make though - perhaps when I get time!
The JSON proponent�s concern is one of bandwidth - and the default XML out of AXIS is element rather than attribute centric, which of course gives bigger documents. This works ok for single objects - as a 6k vs 4k document over broadband with the inherent web latencies (and chunks of data sent) I don�t see as a big deal. Plus for time elapsed I�d also have to consider speed through AXIS vs speed through a JSON layer, and then scaleability as well. For bigger documents, compression will certainly help, attribute centric XML as well.
For ease of use, when I recieve a document I automatically walk the SOAP payload and create the equivalent JavaScript object (I can attach custom deserializers to override this and extract the XML manually if need be). Having this layer I found great - as I can throw JavaScript exceptions to pick up both SOAP faults and any application faults or failed operations that I find (I like having a solid exception framework).
Interestingly - I found dealing with different namespaces (the SOAP namespace, and then my application namespace) in a SOAP document the ugliest bit of the SOAP interface. So walking the XML DOM and creating the JavaScript object means I don�t have to use namespaces in XPATH. However, when dealing with big and complex response documents - not all of which are bound to a particular UI element - I can turn off automatic derserialization to JavaScript and use XPATH to cherry pick what I want.
Yep - I broke open the IE SOAP behaviour to have a look at how it does things. It is of course just a bunch of code (and not that pretty I might add) that uses XHR as its transport mechanism. I found a lot of its code related to interpreting a WSDL and then proxying the service in JavaScript. Moz does this natively through its WSDL analyser. I ended up rolling my own proxy function. My context is one of SOAP as application services, rather than public services, so I don�t need the discovery and auto proxying that a WSDL analyser gives. So when my HTML/JavaScript app is served up, it already has its proxies in place - its doesn�t then need *another* hit to pull back the WSDL and dynamically proxy ( = wasted time).
So I modelled my SOAP layer on some of the Moz SOAP examples, but swap out the moz SOAPCall for an XmlHttpRequest when dealing with IE. I could also use XmlHttpRequest all the time, but I thought I�d keep SOAPCall in there to see if it made Moz any faster (it doesn�t). Also, the Moz SOAP layer also supports custom serializers/deserializers, which I ended up re-implementing so that I could use a single approach for both IE and Moz.
http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/Soap_Scripts_in_Mozilla.html
Of course with all this in place - I then built an automatic testing tool that I put all the application service calls and process flows in, and test them all in an instant. This gives complete vindication to having a solid layer in place with a clean service API. All application services can be automatically tested (and stress tested) from the browser (ie in their context of use). So during development, my service guys can continually test and re test, without having to walk through a GUI trying to create test scenarios and excercise all the GUI nuances to test their service. Know I know there are web app testing tools out there - but GUI Rich JavaScripted DOM widgets are much harder to automatically interact with (as you no doubt know), than your bog standard HTML page - testing the services directly is soooooo much simpler, and can cope with a fluid UI development team that refine and change UI behaviour every release.
PHEW! If I had a blog I�d put all this in it � !!
Cheers.