2.5 Reference Model for Open Distributed Processing

Among the various architectural approaches, a useful international standard, the Reference Model for Open Distributed Processing (RM-ODP), defines what information systems architecture means [ISO 1996]. RM-ODP is a powerful way to think about software architecture and will be discussed in some detail for the purpose of illustrating the depth of material provided by the major architecture school of thought. The ODP model is representative of any mature software architecture practice, including the architecture schools previously mentioned.

RM-ODP defines five essential viewpoints for modeling systems architecture:

• Enterprise viewpoint

• Information viewpoint

• Computational viewpoint

• Engineering viewpoint

• Technology viewpoint

The five viewpoints provide a comprehensive model of a single information system, with each viewpoint being a perspective on a single information system (Figure 2.4). The set of viewpoints is not closed, so that additional viewpoints can be added as the needs arise. Another of their purposes is to provide information descriptions that address the questions and needs of particular stakeholders in the system. By standardizing five viewpoints, RM-ODP is claiming that these five stakeholder perspectives are sufficient for resolving both business functionality and distributed systems issues in the architecture and design of information systems. RM-ODP is an elegant model in the sense that it identifies the top priorities for architectural descriptions and provides a minimal set of traceability requirements that are adequate to ensure system integrity.

The enterprise viewpoint of the RM-ODP takes the perspective of a business model. Managers and end users in the business environment should be able to understand the enterprise models readily. The enterprise viewpoint ensures that business needs are satisfied through the architecture and provides a description that enables validation of these assertions with the end users.

The information viewpoint defines the universe of discourse in the information system. The perspective is similar to the design information generated by a database modeler. The information viewpoint is a logical representation of the data and processes on data in the information system.

Each of the five RM-ODP viewpoints is object oriented, and they provide a complete model of the system from the given perspective. The information viewpoint is an object-oriented logical model of the information assets in the business and how these assets are processed and manipulated.

The computational viewpoint partitions the system into software components that are capable of supporting distribution. It takes the perspective of a designer of application program interfaces for componentware. The computational viewpoint defines the boundaries between the software elements in the information system. Generally, these boundaries are the architectural controls that ensure that the system structure will embody the qualities of adaptability in management of complexity that are appropriate to meet changing business needs and incorporate the evolving commercial technology.

The engineering viewpoint of RM-ODP exposes the distributed nature of the system. Its perspective is similar to that of an operating system engineer who is familiar with the protocol stacks and allocation issues necessary to define the distributed processing solutions for the information system.

The technology viewpoint defines the mappings between the engineering objects and other objects designed to specific standards and technologies including product selections. The viewpoint is similar to that of a network engineer who is familiar with the commercially available protocol standards and products that are appropriate selections to configure the information system.

All five RM-ODP viewpoints are co-equal in the sense that they do not form levels of description; rather, each viewpoint provides a complete model of the information system that is object-oriented and corresponds to the other viewpoints. Each defines various constraints on the design of the information system that provide various architectural benefits for each of the system's stakeholders. The RM-ODP viewpoints enable the separation of concerns that divide the business and logical functionality of the system from the distributed computing and commercial technology decisions of the architecture.

The first three viewpoints identify informational and computational characteristics. The enterprise and information viewpoints are purely logical views of the business, represented as object-oriented models (Figure 2.5). The computational viewpoint is independent of the distribution of software modules, but it must define computational boundaries that are enabled for distribution. The CORBA IDL (Common Object Request Broker Architecture Interface Definition Language) notation for specifying computational interfaces is appropriate for this purpose. IDL provides a way to define computational interfaces that are independent of the distribution and deployment issues in enterprise development. The first four viewpoints-enterprise, information, computational, and engineering-are independent of specific implementations. In other words, the majority of the architectural design is independent of the specific product selections that configure the system. This property of RM-ODP enables the evolution of technology components without having an impact on the overall architectural constraints defined in the first four viewpoints. The engineering viewpoint defines qualities of service and distribution transparencies that evolving technology selections must support. The terminology of RM-ODP assists in providing concise descriptions of these technology requirements.

The 4+1 View Model is a viewpoint-based architectural approach supported by OO tools such as Rational Rose. The viewpoints include Use case view Logical view Process view Implementation view Deployment view The use case view models enterprise objects through a set of scenarios. The logical view includes object models of packages, classes, and relationships. The process view represents control flows and their intercommunications. The implementation view defines the modular structure of the software. The deployment view identifies the allocation of software onto hardware. An architecture defined as a 4+1 View Model covers aspects of all five RM-ODP viewpoints.

RM-ODP contains many terms that are useful concepts for software architects. Some of the key definitions in RM-ODP are the distribution transparencies. RM-ODP defines eight distribution transparencies that specify the qualities provided by a distributed computing infrastructure (Figure 2.6). Currently available commercial infrastructures provide some subset of these, such as the location, access persistence, and transaction transparencies provided in Java 2 Platform, Enterprise Edition (J2EE)-compliant application servers. Additional transparencies are sometimes available through niche-market products and custom implementations. Technologies that failed to provide access transparency, such as Microsoft COM+ and the distributed computing environment, did not adapt well to the future evolution of distributed systems.

Open distributed processing and its reference model are the result of ten years of formal standardization work at ISO. The reference model for open distributed processing is object oriented. RM-ODP provides a reference model that addresses three fundamental goals: (1) to provide a standard framework for further work and additional detailed standards under the open distributed processing initiative, (2) to provide a set of common terminology and concepts that could be applied for the development of product and application systems for open distributed processing, and (3) to provide a guideline for object-oriented architects to specify software systems. This third purpose is directly relevant to the day-to-day practices of systems architects.

Open distributed processing includes several other standards that are significant. In particular, it has adopted the interface definition language from CORBA as a notation for a specified computational architecture. It also has a standard for the trader service, which is the key directory service supporting the discovery of application functions in distributed systems. The trader service has subsequently been adopted as a commercial standard through the object management group. The group's object management architecture is a commercial specialization of open distributed processing.

All together, the consensus standards of the object management group (OMG) and the ISO open distributed processing form a set of software architecture standards that are useful intellectual tools for most software architects and developers.

RM-ODP has four completed standards documents (X.901 Overview, X.902 Foundations, X.903 Architecture, X.904 Architectural Semantics). Part one of the standards (X.901) is a non-normative overview and summary of the overall concepts and terminology. All four parts of the adopted standard are cosponsored by the International Telecommunications Union ITU-T through their X.900 series. The cosponsorship of both ISO and ITU-T represents a broad international consensus on this guideline for object-oriented architecture. Part two of the standard is the foundations document, comprising a glossary of standard terminology for object-oriented distributed systems. Part three of the standards is the architecture document. It defines the various viewpoints for object-oriented architecture along with their structuring rules and various ODP functions that enable distributed computing.

Altogether, these four standards documents comprise fewer than 200 pages of documentation-with the normative parts, part two and part three, comprising about 100 pages. Even though this is a relatively short standard, it provides a great deal of valuable information. Many ISO standards are relatively inscrutable to the practicing software engineer; this standard is no exception. However, the effort to understand it is very worthwhile, given the challenges of distributed computing in business process change that need to be resolved.

Who supports RM-ODP? RM-ODP is the product of formal standards bodies including ISO and the Institute of Electrical and Electronics Engineers (IEEE). The IEEE is an accredited standards organization reporting to ISO; therefore, the IEEE is a voting participant and joint supporter of RM-ODP as well. RM-ODP is the formal standards basis for OMG's object management architecture and all of the resulting technologies that the group has adopted that form the basis for distributed object computing and technologies that are available commercially. RM-ODP is also accurately used in several mission-critical industries that depend upon information technology for their income. In particular, RM-ODP is applied across the telecommunications industry through the telecommunications information network architecture consortium, and RM-ODP is actively used by telecommunication companies such as AT&T, Lucent, and Nortel. In the telecommunications industry, information technology is their business, and distributed information systems success is essential to maintaining their competitive advantage.

Also applying ODP actively is the financial services industry. Companies such as Merrill Lynch, Morgan Stanley, and various mortgage lending organizations are applying RM-ODP to define new information systems concepts. The deployment of new information technologies is becoming one of the key competitive advantages that these companies have for creating new market channels to distribute and transact new financial instruments and securities, and to perform other financial services. For these industries, failure of information systems directly affects bottom-line profitability and is usually not an option. If these influential companies accept this architectural approach and apply it actively, can all other organizations afford not to consider its benefits?

RM-ODP provides standard definitions for distributed infrastructure objects that enable abstract descriptions of engineering constraints. Figure 2.7 is an example of the engineering objects that RM-ODP defines. These engineering objects are capable of defining the characteristics of all forms of distributed infrastructure, including remote procedure calls, screening data interfaces, and asynchronous interfaces for signaling. Among the most important features of RM-ODP are its definitions supporting conformance assessment. After all, what is the purpose of architectural documentation unless conformance can be assessed (i.e., unless implementation of the system corresponds to the written and intended architectural plans)?

RM-ODP defines four categories of conformance and proceeds to specify how conformance is represented in an architectural plan. The first category is called programmatic conformance. This is the usual notion of behavioral testing of software interfaces. Many of the programmatic conformance points will occur in the computational viewpoint specification of RM-ODP-based architectures.

Perceptual conformance includes testing at user interfaces in communications ports that represent external boundaries to the system. Usability and user interface testing can be defined through perceptual conformance assessment. Interworking conformance involves testing between systems implementations. It is not sufficient for individual systems to have programmatic conformance in order to guarantee interoperability. Interworking conformance includes interoperability testing between working implementations (i.e., an additional requirement beyond programmatic conformance).

Interchange conformance involves testing the exchange of external media, such as disks and tapes. It ensures that information that is stored on external media can be interpreted and assimilated in other systems that conform to the same standards. RM-ODP also defines correspondence requirements between the various viewpoints of application architecture. In general, the objects defined in each of the viewpoints do not have to correspond explicitly because they represent an independent description of the system representing various levels of granularity of descriptions and constraints.

For a more comprehensive explanation of RM-ODP including details necessary for applying it to software development and enterprise architecture efforts, see Architecting with RM-ODP [Putman 2000]. Specifically, it provides a best-practice approach to creating architectural specifications using RM-ODP and current best practices. It also identifies industry tools, current and under development, that can facilitate the creation and maintenance of RM-ODP specifications and diagrams.