🏛️ BS ISO/IEC 10746 is the Open Distributed Processing (ODP) reference model (RM-ODP) standard jointly developed by ISO and IEC and adopted by the British Standards Institution (BSI) as a UK national standard. This batch includes ISO/IEC 10746-2:2009 (Foundations) and ISO/IEC 10746-3:2009 (Architecture), providing the conceptual framework and architectural rules for building interoperable, portable, and evolvable distributed systems.
💡 The core idea of RM-ODP is “describe the same system from multiple viewpoints”: characterising the system from the enterprise, information, computational, engineering, and technology viewpoints, thereby decomposing a complex distributed system into manageable, reason-able facets.
1. Series Overview and Positioning 📌
The Open Distributed Processing reference model (RM-ODP) comprises several parts: Part 1 gives the general concepts and framework, Part 2 defines the Foundations — the basic concepts and formal definitions supporting viewpoint modelling — and Part 3 specifies the Architecture — the rules for the viewpoints and their interrelationships. The Parts 2 and 3 in this batch are the core of RM-ODP.
| Standard | Title | Year | Core Content |
| BS ISO/IEC 10746-2:2009 | Reference model: Foundations | 2009 | Basic concepts, object modelling, distribution transparency definitions, formal semantics |
| BS ISO/IEC 10746-3:2009 | Reference model: Architecture | 2009 | Five viewpoints, computational and engineering models, specification and conformance rules |
⚠️ This series supersedes and withdraws the earlier BS ISO/IEC 10746-2:1996 and BS ISO/IEC 10746-3:1996. Use the 2009 second edition when citing.
2. Foundations (Part 2) — Concepts and Definitions 🔧
Part 2 defines the foundational concepts of RM-ODP, providing a common vocabulary and formal basis for the architecture part:
- Object modelling: centred on “object-interface-behaviour”, defining basic concepts of object, interface, action, behaviour, and state.
- Distribution transparency: defines access, failure, location, migration, relocation, replication, and persistence transparency as quality goals for distributed-system design.
- Binding and interoperability: defines binding relationships and interoperability rules.
- Formal semantics: provides formal definitions of concepts for precise reasoning and consistency verification.
💡 Distribution transparency is the soul of ODP: users need not perceive the physical location, failures, or replication of objects; the system automatically shields these distribution details, achieving true “openness” and “portability”.
3. Architecture (Part 3) — Viewpoints and Models 🏗️
Part 3 specifies the core of the ODP architecture — the five viewpoints and their corresponding languages/models:
| Viewpoint | Focus | Typical Questions |
| Enterprise | System purpose, organisational roles, policy | Who is the system for; what business constraints apply |
| Information | Information, data, and processing semantics | What information must the system maintain |
| Computational | Functional decomposition, interfaces, binding | How is the system decomposed into computational objects |
| Engineering | Mechanisms, transparency support, resources | How are transparency and fault tolerance implemented |
| Technology | Concrete platform, implementation technology | On which platform is it implemented |
In addition, Part 3 defines the computational model (interfaces, operations, and binding of computational objects) and the engineering model (supporting distribution transparency through engineering mechanisms), plus the rules for expressing and checking specification and conformance.
4. Key Technical Requirements ⚙️
- A distributed system should be modelled separately from each of the five viewpoints, with consistent mapping between viewpoints to avoid information loss.
- The system should satisfy the declared distribution transparency requirements, such as access, location, and failure transparency.
- Computational objects communicate through interfaces; interface binding relationships should be explicit and verifiable.
- The engineering model should provide mechanisms supporting transparency (e.g. binders, migrators, replicators).
⚠️ RM-ODP is a reference model, not an executable specification: it provides a conceptual and rule framework and does not prescribe specific protocols or APIs. Real systems must still be realised with concrete technologies such as CORBA, web services, or microservices.
5. Engineering Practice 🛠️
- Distributed-system design: decompose a complex system into five viewpoints, clarifying each stakeholder’s concerns.
- Architecture review: use the viewpoint model to review the completeness and consistency of a system architecture.
- Middleware design: use the computational/engineering models to guide distributed middleware and communication-framework design.
- Interoperability and migration: exploit distribution transparency for interoperability across heterogeneous platforms and smooth system migration.
6. Frequently Asked Questions ❓
❓ Q: What are the five viewpoints of RM-ODP and why are multiple viewpoints needed?
A: Enterprise, information, computational, engineering, and technology. Because a distributed system spans business, data, function, mechanism, and platform layers, a single view cannot fully describe it; multiple viewpoints enable collaboration among different stakeholders.
❓ Q: What is distribution transparency?
A: Distribution transparency is a system’s ability to shield distribution details from users — location, failure, migration, replication, etc. It is the key quality attribute for ODP “openness” and “portability”.
❓ Q: How do Part 2 (Foundations) and Part 3 (Architecture) relate?
A: Part 2 defines the basic concepts and formal definitions supporting viewpoint modelling; Part 3 specifies the architectural rules for the viewpoints and their interrelationships. The former is the conceptual basis of the latter.
🔍 Q: Does RM-ODP prescribe concrete implementation technologies?
A: No. It is a reference model providing a conceptual and rule framework; the specific protocols, APIs, or platforms are decided by implementers through technology selection.