Cloud Computing Economics - There Is No Free Service

Cloudonomics Journal

Subscribe to Cloudonomics Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Cloudonomics Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


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.

More Stories By Keith Swenson

Keith Swenson is Vice President of Research and Development at Fujitsu America Incorporated and is the Chief Software Architect for the Interstage family of products. He is known for having been a pioneer in Web services, collaborative planning, workflow, and business process management, having participated in the formation of a number of standards in these fields, including receiving the 2004 "Mannheim Award for Outstanding Contribution in the Field of Workflow." He has led projects at Fujitsu, Netscape, MS2 and Ashton-Tate on group collaboration spaces. His most recent project is a cloud-based offering of Interstage BPM that will offer process modeling, forms development, rules development, Web service integration and execution of completed BPM applications in a 100% hosted cloud environment. See his blog on Collaborative Planning at http://kswenson.wordpress.com/.

More Stories By Jacques Durand

Jacques Durand is a technical director at Fujitsu America Incorporated, with more than 20 years of experience in various areas of software. He evaluates and promotes XML-related and eBusiness standards and advises on their use in the enterprise software products at Fujitsu, while representing the company in various standards organizations such as OASIS, W3C, WS-I and other vertical standards consortia. He has a long-time interest in testing and has led several conformance and interoperability testing initiatives in OASIS: the Test Assertions Guideline standards, the Testing and Monitoring Internet Exchanges (TaMIE) committee, and ebXML testing. He is also active on the OASIS technical advisory board. In WS-I, he is currently co-editor of the Reliable Secure Profile and is leading the development of the new generation of testing tools for WS-I profiles. He has also been product architect in a BPM start-up company and an R&D engineer in a telecommunications company. His initial background is in rule engines.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.