Talis
Publications

Blogroll

« June 2006 | Main | September 2006 »

31 July 2006

A pain relief for Cross-Domain Scripting?

The Developers who have tried their hand at Web 2.0 AJAX, that I have spoken to, have almost without exception reported to me their journey through states of both joy, frustration, and concern around the use of that wonderful tool the XmlHTTPRequest.

The joy starts early on - "You mean it is that easy to get data from a server and dynamically insert it in to my web page without doing a refresh!".
Rapidly drops to frustration - "You mean to say that I can only get data from the server from whence the page came :-(".
Moves in to creative mode - "If I create this little php script as a proxy on my server, my requests can see the world!".
Followed by a worrying - "I wonder if my server will cope with the proxy load, what if its address becomes public knowledge?".
Then comes the blinding light of JSON - "Absolutely magic! In a script tag I can insert a call to a JSON service anywhere without any of these Cross-Domain scripting issues to worry about".
Finally the question of trust occurs - "This JSON stuff being injected in to the browser has full access to everything - do I trust the people that coded the service to only do what they say they were going to do, or will the viewers of my page become unwitting accomplices in a distributed denial of service attack?".

On the final point, trust is an issue of who you get your service from. Users of the JSON versions of the Talis Platform APIs can rest assured that our services will only do what we say they will. So there! - problem solved. Well it is until some high profile instance of a very useful JSON delivered service is found to be a front for a password capturing scam - then see all and any trust, for all and any JSON service, dissolve like mist on a hot summer's morning.

So in summary, although useful XmlHTTPRequest it is too restrictive to be really useful in orchestrating cross-domain web services together in the browser client; Although using JSON in a script tag is powerful and bypasses the limitations of XmlHTTPRequest, it is not widely supported and where it is can I trust it.

Greater minds than mine have been thinking about this. Jeff BezosBarr reports a lunchtime conversation with Peter Nixey of Web Kitchen around this subject. Peter in his posting Why XHR should become opt-in cross-domain relates the tail, of how the owner of a fictitious pub is having issues with his local council, to highlight what I have been describing.

Paul goes on to propose a solution to the XmlHTTPRequest cross-domain restriction problem, by allowing servers to opt-in to receiving cross-domain requests and then informing the browser of that opt-in with a new HTTP header.

I think this idea has much going for it. What do you think? Peter is asking for feedback. Let him know what you think.

Maybe this is something that the W3C Web APIs Working Group should consider for inclusion in to their Draft XMLHttpRequest Specification.

Update:
My thanks to my colleague Ian Davis, a member of our team who is involved with the W3C Web APIs Working Group. He has pointed me at a proposal for a cross-site XMLHttpRequest, which starts an interesting conversation on the Working Group mailing list.

Technorati Tags: , , ,

Posted by Richard Wallis at 12:11 PM | Comments (0) | TrackBack

7 July 2006

Let the loose coupling take place in the cloud

A posting over on the Amazon Web Services Blog about the Openfount Queued Server attracted my attention last week.

The Openfount Queued Server looks really interesting. It took me a little while to understand the architecture, but this was time well spent.
Just like Jeff, it took me a while to get my head around what was different about what Openfount were doing. The description on their site to be fair does describe what is happening, but the light bulb above head moment didn't really occur until Jeff's posting, supplemented by Bill Donahue's comments had been read.

So what is going on? In simple terms the Web Service client is talking to its server via a message queue. So what is radical about that then you may ask - we've had message queue based client server communication for years. Well the difference is that the message queue is hosted by an open third party, Amazon's S3 Simple Storage Service.

The client never talks to the server directly. Instead, it uses APIs from the Queued Server toolkit to write messages into a queue for processing by the server. The server processes messages and then writes return values into another queue, where the client picks them up and displays the results.
Because the server is actively polling the queue for messages, it need not have any public interface at all. No domain name, no IP address, and no vulnerability to well-known generic attacks. In fact, the server could be running behind a cable modem with a dynamic IP address and no one would be the wiser, since it simply reaches out to the world via standard HTTP requests over port 80. In this model the server never accepts incoming calls directly. It reaches out and pulls in requests, and can be very, very choosy about the requests that it accepts.
The clients and servers are isolated and protected from each other. It appears that the client need not even know the domain name or the IP address of the server!

Because everything is handled via a queue, there is no reason why multiple servers could not be used handle the load with Internet bandwidth & S3 being the choke points. Looking at the blurb on the S3 site it is a very wide choke point indeed. As Bill Donahue says in his comments, they actually want to use Amazon's SQS (Simple Queue Service) to do the actual queuing, but whilst it is in Beta they are have cross domain scripting issues which prevents them using both S3 & SQS.

Back in January 2005 I mused about the use of and reasoning behind SQS. In that posting I was equating SQS with Sun's $1 a CPU Cycle Utility Computing Service and looking back I still believe I was right to.

The SOA Operating Platform is starting to emerge. Get your CPU cycles from a supplier like Sun, get your network attached storage and queuing infrastructure from someone like Amazon, get your mapping application services from someone like Google, get your payment services from someone like PayPal, get your Library Domain specific Web Services from someone like Talis. Who, other than the core utility processing, storage, and queuing service providers, needs to invest in infrastructure anymore?

Globally distributed SOA seems to be looming out of the mist, and it is a different shape to what was envisioned a few years back. No sign of the network of UDDI servers scattered about the planet, just lots of loosely coupled applications sitting above utility core services and domain specialist platform providers.

There is one other massive benefit of what is being provided by Openfount - all the calls to the message queues from the servers and clients originate from those servers and clients.

Anyone who has tried to implement a solution requiring a client to access a service that is behind a firewall will immediately grasp the importance of this. Agreeing the security policy with a firewall administrator for access out to an external service can at times be difficult. Agreeing a security policy for requests from outside a firewall to an internal server is more often than not impossible.

Technorati Tags: , , , ,

Posted by Richard Wallis at 05:55 PM | Comments (0) | TrackBack