This chapter describes the Distributed Computing Reference Model (DCRM). It contains an overview, descriptions of the components of the model, and sections on performance and security. It identifies the interfaces between the components. Portability and Interoperability Interfaces describes them in more detail.
The technical components and interfaces of the DCRM are shown in Distributed Computing Reference Model.
Distributed Computing Reference Model
The Management Systems and Marketplaces are particular kinds of application, shown separately because of their particular relationships to platforms and infrastructure.
The Application Data/Applications/Platforms/Infrastructure stack is present in enterprise systems, cloud systems, and user devices.
Enterprise, Cloud, and Devices
In cloud systems:
Different human actors use different components, as shown in Human Actors.
The following sections describe the model’s components.
An application may contain data that is regarded as a component in its own right. This is particularly the case for applications such as Relational Database Management Systems (RDBMS) that serve as data repositories for use by other applications.
The application interprets the data using a data model that defines the structure of the data and may include metadata that the application can use to interpret elements of the data.
Cloud computing is changing the ways in which enterprises store and use information.
Traditionally, data was created and stored by an enterprise for its own use. RDBMS provided the accepted best practice storage paradigm. Selected data, representing the final results of operations, was exposed externally. For example, a logistics company might send a customer a delivery record and payment invoice.
It is becoming increasingly common for companies to expose internal data. For example, logistics companies now often provide tracking information so that customers can see where there consignments are on the way to delivery.
Cloud computing raises the further possibility of collaborative use of data by an ecosystem of organizations. The ownership of such data becomes a matter of secondary importance. Accessibility of the information is the primary consideration.
Cloud computing also facilitates the assembly of really large collections of information (“big data”). Such a collection might come from a vast number of Internet transactions, or from sensors collecting real-time information about the environment (e.g., in weather stations) and connected to the Internet – the “Internet of Things”. This information is often collected from, and stored in, a large number of locations, perhaps distributed globally.
An application is a deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application. (See the Definitions section of the TOGAF Standard [TOGAF].)
In the DCRM, an application may be:
In the SOA style, applications consist of collections of services. These may be explicitly programmed as service compositions; for instance, using the OASIS standard Web Services Business Process Execution Language (WS-BPEL). In this case, the WS-BPEL program is an application component, and the supporting process manager that enables this program to be created and executed is a part of the platform.
The role of applications in the DCRM is shown in Applications. (The interface to management systems is omitted from this figure for convenience.)
Online Shopping Application Example illustrates how this could apply to a specific use-case: online shopping.
Online Shopping Application Example
Applications interface to:
SaaS services and enterprise application services generally interface to application users and systems managers via web pages displayed on PCs and mobile devices. Applications running on servers may interface to application users and systems managers in this way, but often have direct user interfaces.
An application platform is the collection of technology components of hardware and software that provide the services used to support applications. (Again, see the Definitions section of the TOGAF Standard [TOGAF]. The term “service” is used in this definition in a general sense, not in the more specific sense of a software service.) It exposes an application platform interface to applications.
At the time that The Open Group was formed, the problem of application portability related to the re-use of application components across operating system platforms. The two consortia that combined to form The Open Group had made major contributions to the solution of this problem through their work on the UNIX operating system, which was then established as the de jure standard platform for application portability.
At that time, applications were typically large, monolithic software packages. This led to the problem of “information silos”, which could be addressed by the replacement of monolithic applications by groups of loosely-coupled services in a Service-Oriented Architecture (SOA).
For these reasons, the problem of application portability is very different now to what it was 20 years ago.
In the DCRM, a platform may be a PaaS service or an operating system platform on a server, PC, or mobile device.
Platforms interface to:
Platforms are used by developers to develop applications and other programs, and by systems managers to run and configure applications, either through management systems, or directly.
Today, an application platform addressing portability must include more than a server operating system. A modern cloud portability platform could provide the following capabilities:
In the future, application portability platforms may provide other capabilities, and in particular:
User identity management and access control are often particularly difficult when integrating services. Different services define different user roles, and have different ways of identifying and authorizing users. They may hold similar information about users, represented in different ways. For a good user experience, these differences must be reconciled to enable single sign-on and automatic synchronization of user information across the services. This can be hard to do.
A cloud PaaS service exposes an application platform as a cloud service.
The application platform's application platform interface is exposed as the service's functional interface. It is a programmatic interface and supports applications running on the cloud platform service. The service environment also exposes a management interface. This is a web services interface that enables the cloud platform service to be configured and managed.
Cloud services are typically exposed as web services, with the platform handling the web service interface protocols. There are two different styles: WS-I and raw HTTP.
There is a set of standards for web service interfaces – WS-I (see [WS-I]) – but it is not universally used, and its use currently appears to be shrinking rather than growing. These standards are based on the use of XML message contents [XML] in a SOAP envelope [SOAP]. They include means of assuring the integrity, confidentiality, and non-repudiation of messages, and of conveying information that can be used for authentication and access control.
In practice, WS-I does not guarantee interoperability “out of the box” between products and services from different vendors. Experience shows that significant test and integration effort may be needed to make it work.
The approach that is increasingly displacing WS-I is the use of HTTP [HTTP] (or HTTP over a secure transport protocol – HTTPS) without SOAP as an upper layer, and with JSON [JSON] and other data formats in place of XML. This approach relies on HTTPS for assurance of integrity and confidentiality. It makes no provision for non-repudiation, authentication, or access control, although the OAUTH authorization standard [OAUTH] can be used directly over HTTPS and is gaining some ground for authentication and access control.
The two styles are illustrated by the Example Use-Cases for WS-I and Raw HTTP.
In the DCRM, infrastructure includes cloud IaaS services, hardware in servers, PCs and mobile devices, and virtualized hardware resources in enterprise systems.
A cloud infrastructure service makes hardware components available as cloud resources, generally through a virtualization layer.
The functional interface in this case supports the loading and execution of machine images. There is also a management interface that enables the hardware resources to be provisioned and configured, and enables machine images to be deployed on them.
Infrastructure interfaces to:
An enterprise may use a management system to manage its cloud and enterprise IT resources. It is convenient to be able to manage multiple resources – ideally all resources – with a single management system.
Management systems interface to:
Management systems are used by systems managers to manage applications, platforms, and infrastructure.
Marketplaces interface to platforms through product publication and acquisition interfaces. These enable developers to put products into the market place, and systems managers to take them from the marketplace and put them onto their systems.
Marketplaces are used by publishers and procurers.
Publishers are people responsible for making products available to potential consumers. They post product descriptions, terms and conditions, and other information about the products. Where the products are available by purchase, rather than free-of-charge, this is a part of the sales function.
Procurers are people responsible for acquiring products for use by their enterprises, or by themselves. When acquiring a product, they typically create a contractual relationship between their enterprise (or themselves) and the product supplier.
Adequate performance is crucial to the usability of any system. Cloud computing introduces some particular performance issues. This section explains how they can be addressed in the context of the DCRM.
For an analysis of different types of workload, and their suitability for distributed processing in the context of cloud computing, refer to the discussion of Workload Allocations in the chapter on Buying Cloud Services in The Open Group Guide Cloud Computing for Business [CLOUD GUIDE].
System components that are “in the cloud” may physically reside in different places. The time taken to send a message between two cloud-based components, or between a cloud-based component and an in-house system, may be hundreds of milliseconds or seconds, rather than microseconds or milliseconds. The speed of data transfer is likely to be tens or hundreds of kilobytes per second, rather than megabytes or gigabytes. End-to-end performance may be impacted by the concatenation of services across a distributed architecture that spans multiple clouds and in-house systems.
This can lead to two big problems:
It might be possible to mitigate these problems to some extent, by positioning cloud services that communicate frequently with each other in the same data center of the same cloud supplier, but this runs counter to the principle that services should be from different suppliers and in different geographical areas for robustness and fault tolerance.
Developers of distributed computing applications are best advised to design them so that they are horizontally scalable, with components that can be replicated to meet increasing traffic, and that do not require exchange of messages that are frequent, large, or time-critical.
Where there is a requirement for application data to exist in more than one location, incremental changes should be copied as they occur, to avoid the need for bulk data transfers.
The security of a system depends on the security of all of its components and on the security of all links between them, and security should be considered at all stages of system and component design. This section is not an exhaustive analysis of security in distributed systems; it just contains an overview discussion of some of the major aspects of the DCRM that relate to security. Designers must consult other material to gain an adequate understanding of current best practice. The Open Group Security Forum and Jericho Forum are one source of such material; see under Security in [OGBOOKS]. Another excellent source is the Cloud Security Alliance (CSA) [CSA], both for providing security assurance within cloud computing, and for use of cloud computing to help secure other forms of computing.
Infrastructure, platform, and application components may be multi-tenanted, meaning that different users, possibly from different enterprises, share resources. At the infrastructure level, multi-tenancy is generally achieved by virtualization; at the platform level it is generally achieved within the context of a multi-user operating system; and at the application level it is achieved by design of the application concerned. Generally, each tenant is unaware of the others, and uses the resources as though they were dedicated to him.
It is essential that secure separation is maintained, so that no tenant can obtain information about other tenants, the operation of their systems, or the content of their data, and so that no tenant can modify the desired operation of another’s system.
Secure tenant separation is the responsibility of the operator of the multi-tenanted resource. Generally this is a cloud service provider.
In the DCRM, systems are accessed and information is exchanged between components over corporate intranets and the public Internet. It must be possible to do this in such a way that:
All interfaces that require communication over the HTTP protocol are susceptible to normal web application security risks (for more information, see the OWASP Top Ten Project web security risks [OWASP]). However, the focus for our topic is the unique security vulnerabilities introduced by interoperability techniques.
In the DCRM, it is the platform components that have the main capabilities that can be used to provide security against these threats.
Identity and access management require protocol exchanges between platform components, as a part of the platform-platform interface, and ability for applications to manage these through the application-platform interface. The WS-I style of platform-platform interface has better facilities for this than the raw HTTP style.
Security of information in transit requires secure protocols for their exchange. HTTPS is the most commonly used secure message exchange protocol. The raw HTTP style of platform-platform interface relies on it exclusively. The WS-I style includes additional secure messaging protocols (WS-Security).
Dealing with DOS attacks is inherently problematic and may require the participation of application components as well as platform components.
The WS-I and raw HTTP styles have very different security characteristics, as illustrated in Security Characteristics of WS-I and Raw HTTP. WS-Security provides many solutions for web service security-related problems. However, the exposure of application logic to the outside via web services introduces a new security risk, which cannot be mitigated by WS-Security.
Raw HTTP Style
Mainly supported by W3C and many large enterprises.
Mainly supported by developers.
SOAP has an underlying security architecture, WS-Security.
REST has no security architecture, and is primarily relying on HTTP security standards.
Susceptible to all XML-related exploitations, such as manipulation/injection.
Susceptible to all HTTP/HTTPS exploitations, such as session ID hijacking.
Denial of Service (DOS)
SOAP is more susceptible to DOS attacks.
Firewalls can be employed to combat DOS attacks.
The security standard imposed by WS-Security provides a fairly good protection for man-in-the-middle attacks. Think of source authentication and message payload integrity.
However, SOAP headers can be altered along the way, introducing new man-in-the-middle attacks (for example, references to non-existing locations).
Depends on the authentication methods used between point-to-point communications.
The WS-I style, using SOAP and WS-Security, is primarily focused on providing a security protocol for the data package itself (in this case, the encryption of a message). With the raw HTTP style, security is primarily focused on the transport of the data package, by having an encrypted connection between two points. If, for example, a new party C is introduced into a connection between two points A and B, SOAP can facilitate that the message arrives from A to B via C securely. The data package is at all times encrypted, and the authenticity of the package can be guaranteed. However, with the raw HTTP style, you would have a proper security line between A and C, and between C and B. In this case, C is able to view the package, change the contents of the package, or even delete it. This implies that the WS-I style should be used in case of a brokered architecture. Raw HTTP security is primarily relying on standard HTTP security options, such as TLS, SSL, cookies, and sessions.
The user of a cloud service, or other distributed computing service outside their control, must rely on the operator of that service not to read or modify their data or to modify the execution of their software. Ultimately, this is a question of ensuring that the service contract forbids such practices and trusting the supplier to honor it.
The infrastructure, platform, and application management interfaces must be secure, to prevent tampering with systems through their management interfaces.
The components acquired from marketplaces must operate as specified, and must not include “Trojan Horses” or other features that could compromise a system’s security.
Part of the value of a marketplace can lie in the security validation applied to products published in the marketplace, to protect the acquirers of those products.