Cloud Computing Portability and Interoperability – Portability and Interoperability Interfaces

 

This chapter discusses the interfaces of the Distributed Computing Reference Model (DCRM), describing the standardization work that is needed for cloud computing portability and interoperability, and concludes with a summary.

Data Models

Data models describe the structure of data and are used by applications. They enable the applications to interpret and process the data. They apply to data that is held in store and accessed by applications, and also to data in messages passed between applications.

A data model may exist as:

  • An undocumented shared understanding between programmers
  • A human-readable description, possibly a standard
  • A machine-readable description

While there are some standard data models, such as that defined by the ITU-T X.500 standards for directories, most data models are application-specific. There is, however, value in standardizing how these specific data models are described. This is important for data portability and for interoperability between applications and software services.

Relational database schema are the most commonly-encountered data models. They are based on the relational database table paradigm. A schema typically exists in human-readable and machine-readable form. The machine-readable form is used by the Database Management System (DBMS) that is the application that directly accesses the data. Applications that use the DBMS to access the data indirectly do not often use the machine-readable form of the schema; they work because their programmers read the human-readable form. The Structured Query Language (SQL) standard [SQL] applies to relational databases.

XML [XML] schemas and Document Type Definitions (DTDs) form another kind of data model. This is based on a different paradigm, of nested data components. Again, they exist in human-readable and machine-readable forms, with the machine-readable forms used by software that directly accesses the data, and software that accesses the data working because their programmers read the human-readable forms.

The semantic web standards can be used to define data and data models in machine-readable form. They are based on yet another paradigm, in which data and metadata exists as subject-verb-object triples. They include the Resource Description Framework (RDF) [RDF] and the Web Ontology Language (OWL) [OWL]. With these standards, all applications use the machine-readable form, and there is less reliance on understanding of the human-readable form by programmers.

Another, very simple, data model paradigm is emerging in web services and cloud computing. In this paradigm, data exists as a set of name-value pairs. This paradigm is assumed by many web service messages, and is the basis of some cloud SaaS “NoSQL” data stores.

The Universal Data Element Framework (UDEF) [UDEF] is a standard index that can be used in conjunction with data models of different kinds and facilitates integrated processing of the data.

Application-Application Interfaces

These are interfaces between applications. Increasingly, applications are web-based and intercommunicate using web service APIs. Other means of communication, such as message queuing or shared data, are and will continue to be widely used, for performance and other reasons, particularly between distributed components of a single application. However, APIs to loosely-coupled services form the best approach for interoperability. Other approaches are not considered in this Guide.

Some cloud service providers make client libraries available to make it easier to write programs that use their APIs. These client libraries may be available in one or more of the currently popular programming languages.

A service provider may go further, and make available complete applications that run on client devices and use its service (“client apps”). This is a growing phenomenon for mobile client devices such as tablets and smartphones. For example, many airlines supply “apps” that passengers can use to manage their bookings and check in to flights.

If a service provider publishes and guarantees to support an API then it can be regarded as an interoperability interface. Use of a library or client app can enable the service provider to change the underlying HTTP or SOAP interface without disrupting use of the service. In such a case a stable library interface may still enable interoperability. A service that is available only through client apps is unlikely to be interoperable.

A web service API is a protocol interface with four layers.

Web Service APIs

Applications are concerned with the highest layer, which is the message content layer. This provides transfer of information about the state of the client and the state of the service, including the values of data elements maintained by the service.

An application-application API specification defines the message content, the syntax in which it is expressed, and the envelopes in which it is transported.

The platforms supporting the applications handle the Internet, HTTP, and message envelope layers of a web service interface, and enable a service to send and receive arbitrary message contents. These layers are discussed under Platform-Platform Interfaces below.

Message content is application-specific, but:

  • Some standardization may be appropriate within particular applications (for example, the Open Travel Alliance (OTA) [OTA] defines standard APIs to services such as hotel reservation, to enable collaboration between hotels and booking agents).
  • The amount of application-specific processing required can be reduced by using standards for message syntax and semantics.

The W3C Extensible Markup Language (XML) [XML] is a generic syntax standard that is used in cloud service messages. Javascript Object Notation (JSON) [JSON] is an alternative that is increasingly gaining ground.

The Cloud Data Management Interface (CDMI) [CDMI] defined by the Storage Networking Industry Association (SNIA) is a standard application-specific interface for a generic data storage and retrieval application. (It is a direct HTTP interface, follows REST principles, and uses JSON to encode data elements.) It also provides some management capabilities.

Message contents are essentially data. Standards for describing data models can be applied to service functional interface message contents and improve service interoperability.

Application Management Interfaces

These are web service APIs, like Application-Application Interfaces, but are presented by applications to expose management capabilities rather than functional capabilities.

Standardization of some message content is appropriate for these and other management interfaces. This is an active area of cloud standardization, and there are a number of emerging standards. Some are generic, while others are specific to applications, platform, or infrastructure management. None, however, appear to be widely adopted yet.

The SNIA CDMI [CDMI] is specific to data management applications. It can be used by administrative and management applications to manage data containers, accounts, security access, and monitoring/billing information.

There are two generic standards, TOSCA and OCCI, which apply to application management.

The OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) [TOSCA] is an XML standard language for descriptions of service-based applications and their operation and management regimes. It can apply to complex services implemented on multiple interacting servers.

The Open Cloud Computing Interface (OCCI) [OCCI] of the Open Grid Forum is a standard interface for all kinds of cloud management tasks. OCCI was originally initiated to create a remote management API for IaaS model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling, and monitoring. The current release is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.

Platform Management Interfaces

These are web service APIs, like Application-Application Interfaces, that are presented by platforms to expose management capabilities.

The Cloud Application Management for Platforms (CAMP) [CAMP] is a PaaS management specification that is to be submitted to OASIS for development as an industry standard. It defines an API using REST and JSON for packaging and controlling PaaS workloads.

The generic application description standard TOSCA and the generic management standard OCCI apply to platform management also.

Infrastructure Management Interfaces

These are web service APIs, like Application-Application Interfaces, that are presented by infrastructure services to expose management capabilities.

There are some standard frameworks that make it possible to write generic management systems that interoperate with vendor-specific products.

  • The IETF Simple Network Management Protocol (SNMP) [SNMP] is the basis for such a framework. It is designed for Internet devices.
  • The Common Management Information Service (CMIS) [CMIS] and the Common Management Information Protocol (CMIP) [CMIP] are the basis for another such framework. They are designed for telecommunication devices.
  • The Distributed Management Task Force (DMTF) [DMTF] has defined a Common Information Model (CIM) [CIM] that provides a common definition of management information for systems of all kinds.

The DMTF is also defining the Cloud Infrastructure Management Interface (CIMI) model, with a REST interface and XML schema. It is working on a representation of this model using its generic management metamodel (CIMI-CIM).

The Virtualization Management (VMAN) standards [VMAN] of the DMTF extend DMTF standards for management of real resources to cover management of virtual resources. They include the Open Virtualization Format (OVF) [OVF], which is a standard for machine image formats that may be loaded into IaaS services by management systems, and a key standard for platform portability.

The generic standards TOSCA and OCCI apply to infrastructure management also.

The Openstack Foundation has emerged as a major open source initiative to deliver software for building private and public clouds [OPENSTACK]. The formation of the Openstack Foundation in September 2012 gives the initiative a formal home, and it has significant support from major IT industry players. The OpenStack cloud operating system enables enterprises and service providers to offer on-demand computing, storage, and network resources, by provisioning and managing large networks of virtual machines. Resources are accessible via APIs for developers building cloud applications and via web interfaces for administrators and users. While Openstack is not a standards initiative, its administration APIs are likely to become de facto standards for cloud infrastructure management.

Publication Interfaces

These are interfaces between platforms and marketplaces that enable provider organizations to publish products and information about them into marketplaces.

Publication interfaces vary between marketplaces. A level of standardization is desirable for some aspects of product descriptions and especially for cloud service descriptions. These should cover three areas: functionality, quality of service, and conditions of contract.

The W3C standard for web service descriptions, the Web Service Description Language (WSDL) [WSDL], is a mature, proven standard. WSDL descriptions are, however, designed for interpretation by software programs rather than for being read by people. They are appropriate in an SOA that includes automated service discovery and selection, but need human-friendly presentation in a cloud computing marketplace where the choice is made by people.

Standard contractual clauses, and standard service-level descriptions, would be beneficial. There is some work in these areas.

The Open Data Center Alliance (ODCA) [ODCA] is developing a systematized approach to cloud procurement based on the identification of common usage models. This could result in the development or identification of standardized descriptions of quality-of-service parameters and conditions of contract.

The SLA@SOI Consortium [SLASOI] is developing a standard framework for Service-Level Agreements (SLAs), with a supporting toolkit.

The OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) [TOSCA] is intended to enhance the portability of cloud applications and the IT services that comprise them by enabling the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown) independent of the supplier creating the service, and any particular cloud provider or hosting technology. It specifies a language for service template descriptions.

In addition to standards for the description of particular products, there is potentially a role for a marketplace catalog interface standard to define a common framework for product descriptions.

The concept of a marketplace as a system component is relatively new. It is too soon to expect mature standards for the publication and acquisition interfaces, but standards in this area will be beneficial, and their development should be encouraged.

Acquisition Interfaces

These are interfaces between platforms and marketplaces that enable consumer organizations to find out about products, and download them from marketplaces.

A download interface typically consists of an HTTP request that retrieves a file in the response. The format of the file is specific to the device platform and in some cases also to the component provider. There is, however, an emerging standard, the DMTF OVF, for machine image files [OVF].

Acquisition interfaces, other than for simple download, vary between marketplaces. As for publication interfaces, a level of standardization is desirable for some aspects of product descriptions and especially for cloud service descriptions, and standards for these could apply both to publication and acquisition interfaces.

Application Platform Interfaces

These are interfaces between applications and their supporting platforms. They are found in traditional solution stacks, in the resource environments of cloud and enterprise services, and in user devices. They are programmatic interfaces, for which standardization is needed to enable application portability.

As noted earlier, platforms today should do much more than traditional operating systems. The application-platform interface should enable applications to use the platform capabilities listed under Platforms.

A cloud application typically executes in a context that includes hardware, virtualization, operating system, programming language, and software libraries. The operating system provides an opaque layer that hides the hardware and (if present) virtualization from the application. Lower-level programming languages, such as C [C] expose the operating system to the application, but some applications use a higher-level language, such as Java [JAVA], that hides the operating system too. The software libraries are programming-language specific. For commonly required functions, it may be possible to obtain parallel libraries in the popular programming languages.

Operating Systems

Servers and workstations today mostly run operating systems that are versions of the UNIX operating system [UNIX], its derivative Linux [LINUX], or Microsoft Windows [MSWIN]. Web browsers on client devices provide an operating system for client applications; it does not have a name, but is quite well standardized across common browsers. Devices such as cellphones and tablets have device operating systems; these are today mostly versions of Android [ANDROID] or iOS [IOS].

The UNIX operating system and Linux are quite similar, and there is good portability between them. Microsoft Windows is different, and applications written in low-level programming languages are not readily portable between it and UNIX systems or Linux. Web browsers and device operating systems are not directly compatible with the server/workstation operating systems, or with each other (although Android is to some extent based on Linux, and iOS is to some extent based on the UNIX operating system) but they do in some cases enable portability at the programming-language level.

Programming Languages

It is the programming language that is the key to applications portability today. Java provides good portability between UNIX systems, Linux, and Microsoft Windows, and some portability between these operating systems, web browsers, and Android. For web applications, PhP [PHP] provides portability between UNIX systems, Linux, and Microsoft Windows. Other languages such as Python [PYTHON] also provide portability between these operating systems, but are less widely used.

Web browsers support Java applets, rather than Java applications. Java applets are very similar to applications, and most code is directly re-usable between them. However, applets are not widely used. Programs to execute on web browsers are mostly written in Javascript [JAVASCRIPT] which, in spite of the name, is not at all the same as Java. A version of Javascript has been standardized as ECMAScript [ECMA262]. There is reasonable commonality of support for Javascript by major browsers, but this is not necessarily reflected in the official standard. The latest revision of HTML [HTML5] has recently gained significant traction in browser-based applications, both on the desktop and on mobile devices, and is now a de facto standard supported by all major browser vendors. This means that HTML/Javascript-based applications have a far more standardized platform than before.

Android supports a variant of Java that has some differences with the official version. The biggest difference is that special-purpose user interface libraries are supported in place of those supported by the official version.

iOS supports its own language – Objective-C – which is a higher-level language that is based on C but not compatible with Java.

Standard Libraries

There are two standard libraries that provide a significant part of the desired application-platform interface functionality: J2EE and .NET.

Java 2 Platform, Enterprise Edition (J2EE) is now officially known as Java Platform, Enterprise Edition [Java EE]. It is Oracle's enterprise Java computing platform. It includes Java classes that provide many aspects of server platform functionality, including:

  • Data storage and retrieval, including data management and search
  • Process scheduling, including management of tasks and threads
  • Inter-process communication, including session as well as transport capabilities
  • Platform-platform communication, either using SOAP or raw HTTP
  • Human-computer interface, including via web pages
  • Transactionality

The .NET Framework [.NET] is a software framework developed by Microsoft that runs primarily on Microsoft Windows. It runs on servers and also includes versions for mobile or embedded device use. It has a common language infrastructure, whose purpose is to provide a language-neutral platform for application development and execution. In practice it is mainly associated with C# and other programming languages commonly used in Microsoft environments. It supports platform functionality broadly similar to that supported by J2EE.

Platform-Specific Libraries

Cloud PaaS platforms often have platform-specific software libraries that provide access to platform-specific functionality, and may even have platform-specific programming languages. Clearly, applications that use these libraries, or are written in these languages, will not be portable.

Resource Management

While the operating system provides an opaque layer that hides the hardware and (if present) virtualization from the application, there are some applications that take advantage of cloud on-demand self-service and rapid elasticity to configure and manage the underlying resources. Cloud platforms should give the ability to do this. The APIs of the Openstack open source cloud operating system [OPENSTACK] could become de facto standards for this.

Overall Standard

There are in fact a number of commercial and open source products that deliver various capabilities that should be provided by a modern distributed computing platform, but there is no overall service platform interface standard.

Platform-Platform Interfaces

These are protocol interfaces between platforms supporting applications. They include the lower three web services interface layers: Internet, HTTP, and message envelope, as explained under Application-Application Interfaces. They also include interfaces for service discovery.

Standardization of these interfaces is needed to enable interoperability between platforms (which is a precondition for interoperability between applications).

The lowest web services interface layer is the Internet layer, at which information is exchanged using the Internet Protocol (IP) [IP], the Transmission Control Protocol (TCP) [TCP], and associated protocols from the Internet protocol suite. It provides basic information transport between Internet endpoints.

At the next layer is the HyperText Transfer Protocol (HTTP) [HTTP] of the World Wide Web, possibly used over a secure transport protocol (HTTPS). It provides information transport between web servers and their clients, with optional confidentiality and guaranteed integrity (by using secure transport).

Above this is the message envelope layer. This may be implemented using HTTP header fields, parameters and cookies, or using the message envelope parts of messages of SOAP [SOAP], layered on top of HTTP, as defined in the OASIS WS-I profile standards [WS-I]. Its functions include the maintenance of user sessions and user authentication. They may also (with SOAP) include additional security and identity management functions. Some services have parallel raw HTTP and SOAP APIs.

Users and managers can often interact directly with cloud services over the Internet or intranets using HTTP. The user browses and inputs to a set of web pages. Many cloud services have parallel human and programmatic interfaces; they have APIs that duplicate the function of their human-interface web pages. In these cases, the Internet and HTTP layers are the same for the human-computer interfaces and the APIs. Use of the raw HTTP style of interface may enable the envelope layer to be the same in these cases also.

The OASIS Universal Description Discovery and Integration (UDDI) standard [UDDI] applies to service discovery using web-based registries that expose information about a business or other entity and its technical interfaces. In conjunction with the WSDL described in Publication Interfaces, it covers the technical interfaces to product functionality, but it is not a complete standard for the procurement interface and is not generally used by cloud marketplaces.

There is a proposal to standardize an XML language to describe HTTP-based web applications. This is the Web Application Description Language (WADL) [WADL]. It has been described as the REST equivalent of WSDL (which can also be used to describe REST web services).

Platform-Infrastructure Interfaces

Platform-infrastructure interfaces include hardware/software interfaces, used by low-level software components such as device drivers. It is desirable to allow for a wide variety of hardware devices, with different features, and there is no generic standard device interface. They also include interfaces to processors and memory provided by machine instruction sets. Again, a generic standard is not appropriate.

The OpenStack open source cloud infrastructure implementation [OPENSTACK] may provide a de facto standard for the interface to the cloud infrastructure. This would enable the portability of platform source code between cloud infrastructure implementations.

Summary

Summary of Interfaces lists the interfaces described in this section. It shows which components expose and use each interface, why standardization might be beneficial, and which standards or emerging standards might apply.

Interface

Exposed By

Used By

Type

Reason for Standardization

Standards

Data Model

Data

Applications

Description or Shared Understanding

Data Portability

Application Interoperability

SQL
XML
RDF
OWL
UDEF

Application-Application Interfaces

Applications

Applications

Web Service API Content

Application Interoperability

N/A (but principles of arrangement are important)

Application Management Interfaces

Applications

Management Systems

Web Service API

Management Interoperability

CDMI
TOSCA
OCCI

Platform Management Interfaces

Platforms

Management Systems

Web Service API

Management Interoperability

CAMP
TOSCA
OCCI

Infrastructure Management Interfaces

Infrastructure

Management Systems

Web Service API

Management Interoperability

Platform Portability (machine image)

CIMI-CIM
VMAN
OVF
TOSCA
OCCI
Openstack

Publication Interfaces

Marketplaces

Platforms

Web Service API

Publication and Acquisition

ODCA
SLA@SOI
TOSCA

Acquisition Interfaces

Marketplaces

Platforms

Web Service API

Publication and Acquisition

HTTP
OVF
ODCA
SLA@SOI
TOSCA

Application-Platform Interfaces

Platforms

Applications

Programmatic

Application Portability

UNIX
Linux
MS Windows
Android
iOS
Openstack

Platform-Platform Interfaces

Platforms

Platforms

Web Service API Envelope, HTTP and Internet

Service Discovery

Platform Interoperability

TCP/IP
HTTP
SOAP
WSDL
WADL
WS-I
UDDI
JSON

Platform-Infrastructure Interfaces

Infrastructure

Platforms

Various

Platform Portability (platform source)

Openstack

Summary of Interfaces