« Web Application Authentication | Main | A pain relief for Cross-Domain Scripting? »
7 July 2006
Let the loose coupling take place in the cloud
Posted by Richard Wallis at July 7, 2006 05:55 PM
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: SOA, Web Services, Amason S3, Talis, Talis Platform
Trackback Pings
TrackBack URL for this entry:
http://blogs.talis.com/mt/mt-tb.r280.cgi/448
