Cloud Computing on Ulitzer

In this article, we take a look at the basic interoperability requirements when communicating with the Cloud, and in particular at techniques and standards used to express and enforce wire-level contracts between communicating parties, as these parties are increasingly also contracting parties in a Cloud environment. Many standards already developed for Web services and service-oriented architectures provide to the communicating parties a good understanding and control of the expected quality of service at the most basic level of the interaction.

Using Web Services in Cloud Computing is not a new idea. Some vendors of Cloud platforms, which provide services necessary to run Cloud applications, supply these as Web services, especially for management functions of the Cloud (on the provider side) and for storage, versioning, upgrades, migrating and data transfer on the user side. But the Cloud will gradually bring the spotlights onto the "contractual features" of Web services, while the focus so far has been on the connectivity features of this technology.

Cloud Expo New York to attract 5,000 delegates and over 100 sponsors

One View of the Cloud
The term "The Cloud" brings forward images of billowy whiteness floating in the sky with a nebulous shape and without any clear border or structure. The term has long been associated with networks, because the complexity of the routing of messages makes it hard to map out the real structure of the Internet, which is constantly changing. Calling the network a Cloud is useful when you don't really care if you know how a message gets from point A to point B; you care only that it gets there reliably and quickly. But when you extend computational capability into the network, the concept of a white billowy Cloud becomes less apt.

The Cloud is not a single amorphous blob; it is just as complex as data centers that exist today, except that this complexity is somehow opaque (hidden). (In fact, instead of a Cloud, we might envision a jellyfish - it is squishy and compliant, expanding and contracting when needed, and yet it still has a definite resilient structure - as well as a sting if you don't get it right.)

Communication with the Cloud is not going to be magically simplified compared to typical interactions today - it still has to resolve the same issues as conventional business-to-business activity, such as management and maintenance of distributed systems in a multi-owner environment, interoperability between different platforms, security and access control.

Clear partitioning of the Cloud is necessary, isolating one domain of control from another; interfaces will be needed to allow software in one domain to access another, along with business-to-business protocols for making calls or transferring data from one domain to another, just as it happens today. What is different from what we know today is that the boundaries are stretchable to allow the expansion of additional computing resources on demand. Plus, the barrier to entry is extremely low, since the cost of a small domain is very low, and that domain can stretch quickly to handle any load if needed. Thus, usage of such protocols and remote interfaces in the future is likely to be much greater than today, resulting in "federated" processes and deep integration of multiple levels of service.

It is safe to say that the complexity that follows results in increased challenges around issues of security, interoperability, availability, discovery, etc. This is on top of the challenges of distributed functionality and remote access, which are inherent in Cloud computing, not to mention the issues around user interfaces - human interactions with the Cloud - and workflow systems. Web services are increasingly employed in addressing these challenges.

Contracting with the Cloud at Wire Level
While one is used to thinking of contracts in business terms, it is clear that these terms also have to get defined at wire level when it comes to Cloud interactions. Such wire-level contracts will concern the quality of service of the Web-based interaction, accepted delays, tolerance to protocol variations (e.g., when using different versions of a messaging protocol standard), security features to be used, conditions under which interoperability must be guaranteed.

Wire-level contracts both at definition level (how to describe these) and execution level (how to enforce these) have already been used in such areas as B2B messaging and Web services. We investigate here how Web services help interfacing with the Cloud, and in particular how its contractual features will become increasingly valuable, while often overlooked today.

First, let's define our terms. A Web service can be described as a Web-accessible interface that is exposed and invoked using platform-independent technology. A Web service passes information between applications or processes using open, standards-based protocols regardless of applications' programming languages or platforms, using a machine-readable contract to describe how to pass and receive information.

To understand more about how Web services are relevant to the Cloud, it is important to realize that Web services are more than Web-mediated remote procedure calls. Web services define contracts that cover various aspects of a Web interaction between different parties that are actual contracting business partners. These contractual aspects are in turn supported by various Web services standards:

• The service interface definition covers the basic data transfer protocol. This is typically covered by a Web Service Definition File (WSDL W3C standard), which defines in turn the operations to be invoked and their binding to messaging protocol details. A simpler notion of interface also popular for Cloud interaction today may just reuse a generic resource identification scheme (URIs) and standard protocol operations (such as HTTP verbs "GET", "PUT", "POST"). Such minimal interfacing is assumed by the REST interaction style (representational state transfer). A hybrid approach that defines a resource identification scheme combined with the use of WSDL-style interface is described in the Web Services Resource Framework (WSRF) OASIS standard, as well as in the DMTF standard Web Services for Management (WS-Management).
• The security requirements are described by policies (WS-Policy standard) that in turn relate to digital security-enabling standards that control access, integrity, authentication and confidentiality such as XML signature and encryption, SAML, XACML. Such policies can be attached to the Web service endpoint. They govern at runtime the message content or protocol aspect of security, in turn covered by such standards as WS-Security SOAP headers, WS-SecureConversation and WS-Trust.
• Reliability requirements are also covered by policy assertions (WS-Policy) attached to the Web service definition. They define the level of delivery assurance (message acknowledgements and resending rules, duplicate elimination, ordering) as covered by the WS-ReliableMessaging standard.

• Other aspects of the Web services contract, such as where to send errors, where to send responses and how to make use of the underlying messaging protocol, are also described using established standards (WS-Addressing, SOAP bindings).

Such contracts can be defined as "technical contracts," as they focus on the communication infrastructure. As such, they can be seen as low level, down to the wire translation of SLAs or QoS agreements defined in higher-level business contracts. The above Web service standards are understood by most recent Web server platforms.

These contractual features become critical in a multi-owner environment such as the Cloud, where ensuring data interaction alone is not sufficient. Web services technology covers the various aspects of associated contract information: artifacts representing these contracts (XML schemas and document templates, policies, interface definitions) are themselves subject to exchange protocols specified by standards like WS-MetadataExchange and WS-ResourceAccess.