JavaOne Talk: RIAs Done Right

RIAs Done Right: Grails, Flex, and EXT GWT

View more PDF documents from michael.galpin.

AJAX, the REST Killer

I was at a demo today that was showing off an application that was designed to be a reference implementation / blueprint app. Of course it had some AJAX based features in it. One of the AJAX calls allowed an existing object to be edited, and another would delete said object. I noticed that the AJAX was using HTTP GET. I pointed out to the developers that since this was supposed to be a blueprint app, it should get everything right and use POST for both of these. Of course it should really use a PUT for the update and DELETE for the delete, but browsers just don't support that.

After the presentation, one of my colleagues pointed out that a lot of times we are forced into GETs because of cross-domain calls. He was right, and made me realize how the hack-that-is-AJAX is always rearing its ugly head. Cross domain calls are part of life for any large, distributed site. In an AJAX world you either have to use JSONP style calls, i.e. using a Script tag to make your call, or you have to use a server proxy. Of course going directly to the appropriate domain is much more efficient, so JSONP is going to usually win. There's no way to do an HTTP POST on a Script tag, so there you go. Forget all about respecting the REST protocol.

Of course Flash and Silverlight (gotta include it now!) both allow for declarative cross domain security. No need for JSONP hacks. Now if only they both supported HTTP PUT and DELETE...

Flash and HTTP Headers Redux

A few months ago I wrote about the lack of access to HTTP headers in Flash. I recently came across some other people talking about this. This has caused debate about Flex being able to support REST.

The opinion seems to be that Adobe does not allow this because not all browsers will provide this information to the Flash player. I have not seen a list of what browsers have this limitation, though I will speculate it must be older versions of popular browsers... Some of the evidence of this is that this is provided in AIR. In AIR, it is the runtime itself that makes HTTP requests. In a SWF running in a browser, the runtime relies on the browser. So restrictive browsers could be an issue on a SWF, but never for an AIR app.

Could another reason be security? In particular, cookies are passed back-and-forth via HTTP headers. There are numerous cases of cookies being stolen by malicious JavaScript, which has total access to HTTP headers. Adobe made a lot of significant security improvements between Flash Player 8 and 9. In a world of mashups, are they better off continuing to deny access to HTTP headers?

All of that being said, I recently ran across another case where this causes problems. I had a SWF that could be loaded by two different pages. It needed to show slightly different features depending and have a different look and feel depending on what page it was on. The easiest thing to do would have been for it to "know" what page was loading it by looking at the referrer on the HTTP request that loaded the SWF. This is a header of course, and thus not available. Instead a FlashVar could be passed in to tell the SWF what to show. That's a better way to do it, but required changing the code of the page hosting the SWF, which was not an option. The hack that had to be used was to have to logical copies of the same SWF, foo_A.swf an foo_B.swf. The SWF could then look at its this.loaderInfo.URL to figure out what to show.

Attributes vs. Elements

I was reading an article on developerWorks that I didn't write... It was about XML and Java. Sound like a tired, old subject? This had an interesting take: How the choices you make when writing XML influence your Java application code. One of the central themes was on using Attributes vs. Elements. One of the basic points was that using attributes leads to faster code. I decided to test this theory.

I took a pretty simple XML document. It was actually one that I had written recently for a real problem. I created two versions of the same document. One used elements exclusively. The other used attributes whenever it was possible. I then tested how fast it was to access two pieces of data. One was "shallow", i.e. near the root of the document. The other was heavily nested. In both examples, the data was an attribute in the attribute favored approach. I repeated the test over 10,000 iterations and tested it against three XML parsing technologies: the standard DOM implementation included with Java 6, using XPath with dom4j, and using the StAX implementation included with Java 6. For the DOM and dom4j techniques, I also examined the parsing time.

The results were a little surprising. I found no differences with attributes vs. elements for DOM. This was true for both traversing the tree and for parse time. I don't mean a negligible difference, I mean no difference at all. It was so surprising that I had to double check my code a few times. The big difference for DOM was that the code for the attribute favored approach was definitely simpler, which was one of the points in the developerWorks aritcle.

The dom4j story was different. It was slightly faster to parse the attribute document, but it was a bit faster to retrieve values on the element document. I was surprised by this, but the differences were very small, probably not statistically significant (I didn't test this, though.) The code was virtually identical, of course, since we were using XPath for the traversal. The dom4j was much slower than the DOM approach, which is again not too surprising.

Finally, the StAX tests showed faster results for the attributes document. There was a larger difference than in any of the other tests. This makes sense because you don't have to go as far in to the attributes document (a start element event contains the attribute data, but does not contain text child node) and there are less events fired in an attribute document vs. an elements document. For example, bar is three events, but is two events. Also, StAX was faster than either DOM or dom4j, as you would expect. The StAX code for the attributes document was also slightly simpler than it was for the elements document.

So if you're using DOM or StAX, you should definitely favor attributes over elements. It will be less code and in the StAX case, faster code. If you're running dom4j and XPath (or maybe XQuery) based navigation, then it doesn't matter as much and elements based seems ok. This really is important, as a lot of these "modern" RESTful web services are heavy on the elements format over the attributes format. This is doubly bad for web services, since there's obviously a much larger byte-cost on elements style documents.

Update: As request, I am attaching the source code I wrote for this little micro-bench. I tweaked it a little as I realized there was an inefficiency in one of my dom4j methods. This tweak made dom4j faster on the attributes document, which is more consistent with the rest of the results. To run the code, you need dom4j and you need either Java 6 or Java 5 plus a StAX implementation. I ran it on my MacBook under Java 5 using Sun's StAX parser.

Silverlight and Flex in the Browser

The web browser is one of the great equalizers of the world. It's why Microsoft feared Netscape. If something runs in the browser, it doesn't matter where it came from. HTML, JavaScript, CSS are agnostic of the technology used to generate them. Don't get me wrong, browsers have their "quirks" and certain technologies make use of these quirks more readily than others, but these things aren't coupled. I can create an XHTML compliant application using ASP.NET and C# just as easily as I can create an app that uses lots of IE-only HTML and JavaScript using PHP.

There is an exception to this uniformity and that comes from browser extensions/plug-ins. These are capable of doing more proprietary communication with back-end servers. In a world where a new rich internet application framework is being introduced by some multi-billion dollar software company each month, one could easily imagine a tight coupling between such frameworks and the server technologies that feed them.

Of course the mother of these new frameworks is Flex, Adobe's application platform built on top of Flash. One of the common companions to Flex is Flex Data Services. This is actually an Enterprise Java application for accessing enterprise resources (like databases) and serving up data to Flex clients. One would guess that you could do the same thing on your own, and not just in Java. Your Flex client makes gets/posts to a URL and parses the response for a data model. You could even use SOAP for all this, if you were a masochist.

The design behind Silverlight seems very similar. The quick start tutorials from Microsoft show a Silverlight client connecting to a web service. Thus it should not be too hard to build a Silverlight application that talks to a Java or PHP server. On a side note, I had one interesting realization from reading through some of the Silverlight tutorials. They make a big deal distinguishing between client-side Silverlight code written in managed CLR (i.e. C# or VB.NET) as opposed to code written in a scripting language such as JavaScript or Iron Python. My understanding of the CLR was that everything was compiled into Intermediate Language (IL.) It sounds like if you use C# for your Silverlight project, then this is the case, but not if you use Python. This seems ... odd. One approach I thought they might try was to compile everything into JavaScript and let IE's runtime handle it ... but then I remembered that they are providing Silverlight for Firefox and Safari.

So my plan now is to take the Stocks application I wrote for the GWT tutorial (part is out next week, by the way) and create a Flex and Silverlight version of the same thing. I might cheat and re-use the servlet that GWT creates, or I might create a REST servlet. Too bad there are JSR 311 implementations yet.

Oh yeah, and then there's JavaFX. There is a fair amount of JavaFX documentation and examples. However, I'm not really sure if JFX will use a similar mechanism as Flex and Silverlight. It seems like it has to. The example I've seen usually create all the JFX on the server and then ship it to the client for rendering. That approach seems kind of primitive and something that would be difficult for an interactive application (like the the stock application.) Maybe by the time I'm done with the Flex and Silverlight versions of things, it will be more obvious how to do the same thing with JFX.

Web APIs: Flickr vs. GMaps

I was doing a little research on web APIs. Two of the better ones (or at least well known and used) out there are Flickr and Google's Map (GMap.) They present two very different ways to enable third party developers to leverage powerful web services. So I thought I'd do a little compare and contrast.

Flickr's API is a classic procedural library. There are calls for almost any action you could possibly do with all things Flickr : photos, account, tags, sets, etc. You can upload photos, access photo streams, search by tags ... pretty much anything you can do on Flickr's site. Each call is a different HTTP request. You can send the package of your request in a variety of formats: REST, XML-RPC, and SOAP. The REST and SOAP follow the usual patterns for these formats. The REST requests are "pure" HTTP requests. Flickr's XML-RPC is very true to the RPC mode. It uses simple XML to specify a procedure to call along with it's parameters.

You can also specify the format of the response you get back from Flickr. Since they support REST, XML-RPC, and SOAP for requests, it's not surprising they support all these for responses. They recently added JSON and PHP as response formats. I was pleased to see JSON. I can imagine that if I was going to use Flickr's API, I would probably choose to use REST+JSON. Make a pure HTTP request and get back a JavaScript object. Seems like the lean-mean approach to me. I was surprised to see PHP as a response type. In this case, they are referring to serialized PHP objects. The structure of these objects is identical to the JSON structures.

GMaps is different in many ways to Flickr. Instead of supporting procedural calls to Google, everything is object oriented JavaScript. You include a library from Google and then use their objects. Many of their objects provide methods for making calls similar to what you see in Flickr. For example, you can geo-code a location, calculate directions, etc. But you don't make the HTTP request and you don't parse a response. Google's JavaScript objects do these for you.

The differences in these web APIs reflect the differences in these web services. Flickr is more of a pure data service. You can modify data (photos) and query that data (search for photos, etc.) Flickr wants to be your photo database. As such, they give you a number of ways to access your data. What you do with the data is up to you. Show your pics on a website, provide tools for uploading, print the pics, make aprons, whatever...

GMaps wants to draw maps for you. They don't want to give you mapping data for you to do whatever for it. They want to draw. They'll take your data and draw maps with it. They always draw the map, so they give your users a familiar interface that also integrates into Google. All roads lead back to Google.

Thus the APIs to these services are very appropriate for the services. I don't know for sure, but I'd wager they also reflect the programming design behind the services. It seems pretty obvious that Flickr is written in PHP and that Google Maps is written in Java (maybe the last one is less obvious, but I do have a little inside information on that one.) So it's not really surprising that a PHP site would have a very flexible, procedural API, and that a Java site would have more closed, object-oriented API.