Call it grid computing, cloud computing or software as a service, distributed computing is on a lot of developers minds recently. There are so many different ways in which people can use the "cloud" that there would appear to be no possibility of a single "framework" for cloud based services. This has not prevented a lot of developer discussion and fear that the "cloud" will somehow become a closed realm of proprietary protocols as opposed to an open-source utopia. (See for example the open cloud manifesto.) It seems to me that a discussion of the wide range of protocols and architecture in grid/cloud/distributed computing is in order. I am going to discuss some of them in order of increasing complexity.
Bandwidth and storage with REST
Little change in architecture is required when an enterprise uses c...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
loud facillities to supplement owned server bandwidth to handle unusual demands. As I discussed in this article, making use of cloud bandwidth simply requires redirecting requests to a cloud URL. This follows the REST principle that when you want the current state of a resource, the internal details of how you get it are unimportant. No special software beyond a HTTP server is required on the cloud server side. The high bandwidth and storage capacities combined with low cost and simple application make this the simplest way to take advantage of the cloud.
Remote Procedure Calls with XML-RPC and SOAP
The concept of a Remote Procedure Call has been around for years and forms the basic technology for much network computing. The architecure gives the programmer an interface which lets you program as if the method will actually be executed on your computer but will actually run elsewhere.
The technology known as XML-RPC was the pioneer for the idea of formatting Remote Procedure Calls in XML messages. This simple yet powerful concept for supplying variables to call a method on a remote computer is still in use. However, some developers wanted more, so we got SOAP. Originally SOAP stood for Simple Object Access Protocol but it certainly is not simple and has little requirement to use objects. The inescapable disadvantage of XML encoded messages is that they are very inefficient in terms of actual data transmission and CPU time required to parse the message.
On the plus side, by using text XML documents, developers can paper over the incompatibilities between different hardware and software in distributed systems. Furthermore everything that is transmitted is human readable and it is easy to create or read messages with a variety of techniques. As the evolution of SOAP shows, it is easy to add capabilities to XML formatted messages without seriously impacting existing applications.
Your SOAP or XML-RPC server on the cloud side will require custom programming but it will be a familiar environment, typically JAVA with an SQL server and huge huge disk capacity. Cloud vendors such as Amazon are rushing such capabilities into service.
RPC between objects with CORBA
The Common Object Requesting Broker Architecture or CORBA is an early effort at a standard to enable object interactions within a network. It uses an interface definition language (IDL) to define the face these objects present and an object request broker (ORB) to negotiate the exchange of information about objects. CORBA makes a major effort to ensure that the IDL can be supported in many languages and operating systems. The Internet Inter-Orb Protocol (IIOP) is the protocol by which ORBs communicate between heterogeneous mixes of computer systems using TCP/IP. It should not surprise you that object oriented languages like Java are easy to map to IDL. Support for IIOP has been part of the Java standard library since 1998.
In spite of the fact that there have been many cycles of popular "latest thing" buzz-words since CORBA was introduced, it continues to be used in network computing with strong and mature industry support. The Object Management Group is the non-profit industry consortium responsible for maintaining the standard. Version 1.0 was released in 1991 and we are currently at version 3.1 released in 2004 so you can see that this is a refined and mature standard. You can get quite an argument among developers as to whether CORBA and/or SOAP is too complex for the future of cloud computing and SOA.
Application specific protocols
A recent news article indicated that Microsoft's "cloud services operating system" called Azure, will eventually allow the use of the "Tabular Data Streams" protocol in communicating with SQL Data Services, the cloud version of SQL. It appears that customers really wanted to enable cloud relational database operations similar to existing in-house applications rather than translating requests to REST style. I think it is likely we will see a lot more cloud services that use application specific protocols.
Resources
REST versus SOAP - the REST story
REST versus SOAP - the SOAP story
Home page for the "open cloud manifesto"
Wikipedia history of Tabular Data Streams protocol
