Cross Domain Comet

Dietrich Kappe, Thursday, July 27, 2006 @ 10:19 am

I hate to be a blog echo chamber, but there's a post from Alex Russell of Dojo Toolkit that is worth spreading around a bit more.

First, some background. There are two technologies that Alex and Co. have been working on. One is called JSONP, which stands for JSON with Padding. The essential idea is that you can insert a script tag dynamically in a document and have it pull a script from a server in a different domain. This URL for this script takes a parameter that is prepended to the JSON which is also wrapped in parentheses. In the case where the prefix is null, we have just a JSON object. Otherwise, it's a function call. This gives us the ability to do a callback when the script loads; you want to do a callback, otherwise, how will you know that the thing loaded? Obviously, this requires some cooperation from the server -- you can't just do this with any old JSON service. A discussion by Alex of this technology can be found here. Dan Theurer has a somewhat clearer explanation, IMHO, of a similar technology used by Yahoo.

The other technology is Cometd. What is Comet? Without getting too technical, when a web application is to update a browser using AJAX, the browser "polls" the client, i.e. it keeps opening up connections to the server to ask "is it ready?" With Comet, the browser opens up a connection to the server and keeps it open until the server has something to say. There are all sorts of issues in doing this, from limitations of the HTTP protocol, to the Servlet specification, to the consumption of resources on servers and network appliances that are expecting short connections. Cometd is a server that tries to solve some of the issues.

What Alex has done is combine Cometd and JSONP to allow cross domain Comet. You can read Alex's post here...

Is Cross Domain AJAX/Comet a 'Good Thing?'

There's a school of thought that AJAX apps should really be the SOA orchestrator of various backend services from various domains -- a little Amazon S3 here, a little Google maps there, a little Yahoo mail there -- and voila!, the ultimate mashup. While it is seductive to think you can assemble applications in this way, it makes me nervous for some reason that I can't quite articulate. Having been the victim of bad SOA governance within companies, I have to think that these types of applications will be very brittle at the least, and vulnerable to security exploits at the worst.

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I am very much in line with “Is Cross Domain AJAX/Comet a ‘Good Thing?’” except for the conclusion.

   In my experience, I built a Portal where a Portlet offered an end-user a choice to choose the source of financial information out of the list of providers like Morningstar or Lipper Ltd (A Reuters Company). At the back, I provided corresponding services.

   Now, getting into the SOA age of business-centric architecture, I share some concerns about brittleness and vulnerability. However, if one follows the SOA RM standard and avoids ‘bold’ Web Services (initially provided by Amazon, Google and Yahoo!) but, instead, relies on the business execution contexts and Service Contracts that include business responsibilities of the service providers (including security and QoS), the compound application might be not that bad at all.

   This means, there should be an intermediary responsible for the quality of offered services and their compatibility. In other words, an orchestration/composition of the services, performed by the user, only looks ‘ad-hock’ while it is very well prepared by the intermediary.

   What is about an end-user just composing different services in the Web site? It is absolutely fine; it is called a ‘freedom of choice’. Such end-user becomes the author of the thing we can call a ‘custom application’, s/he is the master and the owner of it. And all problems and concerns are on her/his hands. Exactly as it is in real business life (“it is a simple SOA, stupid”)

   - Michael Poulin

   Comment by Michael Poulin, Monday, December 11, 2006 @ 9:00 am

Leave a comment