Reference Model for Open Distributed Processing (ISO/IEC DIS 10746-1:1995, or RM-ODP) provides a framework to understand and develop distributed processing in heterogeneous environments. It identifies the important properties of open distributed systems as openness, integration, flexibility, modularity, federation, manageability, provision of quality of service, security and transparency (from the point of view of the application).

That isn't the clearest definition, but it is pretty accurate. RM-ODP is a dense concept, like Object Orientation. To get more detailed accounts of what RM-ODP is about, you can check out these resources:

Web Sites

• The Distributed Systems Technology Centre RM-ODP Information Service

• SINTEF's ISO RM ODP overview

• communityUML's ODP Dictionary

Books

• Architecting with RM-ODP

• Software Architect Bootcamp

RM-ODP defines five viewpoints as necessary for fully defining ODP systems. You can think about these viewpoints like those old anatomy books with the picture of the body's different systems printed on plastic layers. The bottom page was an outline of the body; then you can lay on the skeleton, organs, the nervous system, the circulatory system, then the muscles. No layer is more important than the others, all are necessary. The muscles need the skeleton for a foundation, but the skeleton needs the muscles to stay together.

For a while, you could look at each layer separately. Soon you discovered that you could look at a couple of systems together for highly complimentary views: nervous and circulatory systems, skeleton and muscles, etc.

The RM-ODP viewpoints are the same. Each one is necessary and brings a complimentary set of concerns, requirements, objectives, and perspectives to the table:

ENTERPRISE: also called the Global viewpoint takes the perspective of a business model. This viewpoint should be understandable by the stakeholders of the system. In UML terms, this viewpoint correlates to use cases; explaining what a system should be able to do, what it will be used for, who will use it, etc.

INFORMATION: refers to the information in the system and the the information about the system, or its behavior. This viewpoint explains the data model in the system: what the system needs to know and to remember. It also explains the rules to be followed by the system: policies specified by the stakeholders, how things work together, rules for allowable change in state, things that must always be true (invariants), and quality attributes.

COMPUTATIONAL: viewpoint partitions the systems into functional modules. This viewpoint is concerened with how the system assembles from an Object Oriented standpoint, taking the perspective of a designer of application components and program interfaces. This viewpoint corresponds to the UML logical model.

ENGINEERING: exposes the distributed nature of the system. This viewpoint contains information on how the components from the computational viewpoint are implemented.

TECHNOLOGICAL: viewpoint describes the where to apply technologies to implement the system, and the technologies of choice. This viewpoint maps the components described in the computational viewpoint (interfaces, api's, objects) to the technologies to implement the engineering viewpoint. The viewpoint is responsible for insuring that the choices conform with the requirements of the system.

In design pattern terms, these viewpoints help deal with the forces of a Open Distributed Processing system. ODP system have opperate in a different set of environments and constraints than traditional systems:

• Local: Traditional systems know where they are located, where they are installed. An ODP system can be distributed across a single machine, a cluster, a LAN, or across the whole Intranet. It can make no assumptions about its location.

• Mobility: A component might not even be located where it started. ODP components may migrate machines during its lifetime.

• Global State: Traditional systems can count on having a global state, like a single system clock. ODP system don't have a similar guarantee.

• Concurrency: The lack of global state, also means that there is a lack of concurrency in ODP systems. ODP systems require some sort of coordination to control simultaneous events that require concurrency.

• Quality of Service/Failure: Traditional systems are usually built in reliable systems. A server is either up or down. But an ODP system could utilize resources spread across systems. One file server may be down while its redundant unit may be up. ODP systems may experience a lesser service level when components fail or become unreliable, but they should not simply go down. Think of a RAID system.

• Heterogeneity: And ODP system may be made up of many different technologies that are joined using standard protocols.

• Evolution: During the life time of a system, components may migrate machines, sub-systems may fail, technologies may be replaced by different technologies, machines added or upgraded. Large systems are rarely fully replaced. Usually pieces are upgraded on at a time. Like a city. It would be unfeasible to replace an entire city at once. Instead new pieces are added while older parts are renovated.

• Scale: Traditional systems scale along with their host machine. ODP systems can scale along many different paths and reach literally the scale of the Intranet.