BS ISO IEC 10746 — Open Distributed Processing Reference Model Standard Series (Foundations and Architecture)

Information Technology — Open Distributed Processing — Reference Model: Foundations and Architecture

🏛️ 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.

StandardTitleYearCore Content
BS ISO/IEC 10746-2:2009Reference model: Foundations2009Basic concepts, object modelling, distribution transparency definitions, formal semantics
BS ISO/IEC 10746-3:2009Reference model: Architecture2009Five 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:

ViewpointFocusTypical Questions
EnterpriseSystem purpose, organisational roles, policyWho is the system for; what business constraints apply
InformationInformation, data, and processing semanticsWhat information must the system maintain
ComputationalFunctional decomposition, interfaces, bindingHow is the system decomposed into computational objects
EngineeringMechanisms, transparency support, resourcesHow are transparency and fault tolerance implemented
TechnologyConcrete platform, implementation technologyOn 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.
🔒
正在加载下载地址,请稍候 10 秒

Leave a Reply

Your email address will not be published. Required fields are marked *