I am sure all of you have heard the buzz about WEB 2.0 APIs. Like most people I watched in the early days with mild amusement as the brainiacs of this concept worked to figure out just what it was they were inventing. Now that the message is clear, I must admit that I am on board with it.
In theory, these APIs, based on web services constructs, should make the creation of new applications much easier. Eventually, building a call application can be as simple as dragging and dropping icons off a dashboard such as some of the cloud computing tools in development today are touting for IT management.
The challenge it seems is creating a set of web-services APIs which can represent the various call methods and media types that will be required to build a telephony application. While functions such as video transcoding have applications that may go well beyond telephony, we will restrict our conversation (for today) to the telephony world.
One of the things that enable cloud computing architectures to manage data between distributed applications is REST. REST means Representational State Transfer and defines, within an HTTP context how resources are defined and addressed, generally through stateless transactions. In short, we find that REST is merely a programming style or methodology, more like a database protocol with an SNMP-like "PUT/GET" nomenclature. While many web-2.0 APIs are categorized as RESTful, REST is not in fact a defined API. RESTful APIs make system and resource distribution much easier to manage (thus their logical application to cloud computing). However, to paraphrase Alan Quayle in a conversation I had with him about trying to apply RESTful constructs to telephony applications; 'how do you manage call state with a stateless API methodology?'
Well, one logical approach would be to emulate web services on top of XML schema. While as intuitive as this may seem, it raises the question of whether telephony applications in a cloud computing environment will be able to take advantage of its inherent distribution. Is there any value in it? Well, I feel that the Cloud approach is well-suited for emerging or fast growing applications and nearly ideal for applications that require peak loads which are much greater than their mean. Of-course, all such applications would have to be IP-based and hosted on general purpose servers (as opposed to dedicated switched TDM equipment). I also think that such an approach would be well-suited in a revenue-sharing scheme where the equipment provider takes the risk of the application being short-lived. Yet to do it right requires a scalable distribution across the resources.
I admit that I have been on-board with cloud computing far longer than I have been on board with Web 2.0, but this issue of state has always plagued me. There are ways to solve it in hardware and the networks that interconnect servers, but this gets expensive. In the end, we may have to be content with knowing that WEB 2.0 applications are far easier to develop and can run 'in a cloud' environment, even if we are not taking full advantage of the distributed nature of the Cloud.