Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
🏛️ BS ISO/IEC 10746 是国际标准化组织(ISO)与国际电工委员会(IEC)联合制定、英国标准协会(BSI)采纳为英国国家标准的开放分布式处理(Open Distributed Processing,ODP)参考模型(RM-ODP)标准。本批收录 ISO/IEC 10746-2:2009(基础,Foundations)与 ISO/IEC 10746-3:2009(体系结构,Architecture)两个分部,两者共同为构建可互操作、可移植、可演化的分布式系统提供了概念框架与体系结构规则。英国在该标准制定过程中的参与由技术委员会 IST/15(软件与系统工程)负责,该委员会召集了来自工业界、学术界与标准化机构的广泛代表,其秘书处可提供委员会成员名单。
RM-ODP 诞生于 20 世纪 90 年代初分布式计算蓬勃发展之际:当时 CORBA、DCE、分布式数据库等异构技术并存,系统之间互操作困难,”开放”成为一个可望而不可及的目标。ISO/IEC 与 ITU-T 联合开展研究,最终形成了以多视点抽象为核心、跨厂商跨平台通用的参考模型体系。本系列英文标题中的法文副题 “Traitement réparti ouvert — Modèle de référence” 保留了双语文档的传统,也反映出该标准从一开始就定位为国际通用的元标准(meta-standard)。
开放分布式处理参考模型(RM-ODP)由多部分组成:第 1 部分给出总体概念与框架(Overview),第 2 部分定义基础(Foundations)——即支撑各视点建模的基本概念与形式化定义,第 3 部分规定体系结构(Architecture)——即各视点语言及其相互关系的规则,此外还有导论性文本与一致性声明方面的配套内容。本批收录的第 2、3 分部是 RM-ODP 的核心主体,也是工程应用中最常被引用的部分。
| 标准号 | 中文标题 | 发布年份 | 核心内容 |
|---|---|---|---|
| BS ISO/IEC 10746-2:2009 | 参考模型:基础(Foundations) | 2009 | 基本概念、对象建模、行为与状态、分布透明性定义、绑定与互操作、形式化语义 |
| BS ISO/IEC 10746-3:2009 | 参考模型:体系结构(Architecture) | 2009 | 企业、信息、计算、工程、技术五个视点语言,计算模型与工程模型,规范与一致性规则 |
从标准体系的外部关系看,RM-ODP 处于”元层”:它不直接规定某个具体协议,而是为其他标准与实现提供描述语言与一致性框架。例如,面向对象的分布式中间件、Web 服务、微服务架构等实现都可以用 ODP 的视点语言来描述与对比;ISO/IEC 19500(CORBA)等标准在制定过程中也大量借鉴了 ODP 的概念。理解这一点,有助于读者在浩如烟海的具体技术标准中把握 RM-ODP 的独特地位。
Part 2 定义了 RM-ODP 的基础概念,为体系结构部分提供统一的词汇与形式化基础。它并非一份简单的术语表,而是从对象建模出发、逐层构建的严密概念体系:
基础部分以对象(object)作为第一类概念:对象封装状态与行为,通过接口(interface)与外界交互。对象可以同时持有多类接口,接口之间通过绑定(binding)建立通信关系。动作(action)是对象行为的最小单位,行为(behavior)则由按时间顺序发生的动作序列刻画,状态(state)表示对象在某一时刻的信息状况。这套术语为后续视点语言提供了统一的”语法起点”。
分布透明性(distribution transparency)是 ODP 最为人称道的质量属性清单。标准系统性地定义了八类透明性:
基础部分定义了绑定(binding)关系与互操作规则,说明多个接口如何组合为一次端到端通信。此外,Part 2 还给出了各核心概念的形式化定义,使描述可以被精确推理与一致性验证。对于追求严谨性的架构评审与安全分析而言,形式化语义层提供了可机器检查的基础。
Part 3 规定了 ODP 体系结构的核心——五个视点(viewpoints)及各自对应的语言/模型。五个视点的划分并非随意,而是针对分布式系统生命周期中不同利益相关方的关注点逐步演化而来:
| 视点 | 关注内容 | 典型问题 | 主要产出物 |
|---|---|---|---|
| 企业视点(Enterprise) | 系统目的、组织角色、政策 | 系统为谁服务、有何业务约束 | 社区对象、角色、政策与义务 |
| 信息视点(Information) | 信息、数据与处理语义 | 系统需维护哪些信息、如何保证一致性 | 信息对象、不变式、动态方案 |
| 计算视点(Computational) | 功能分解、接口与绑定 | 系统如何分解为计算对象 | 计算对象、操作签名、绑定对象 |
| 工程视点(Engineering) | 机制、透明性支持、资源 | 如何实现透明性与容错 | 节点、通道、协议对象、透明性机制 |
| 技术视点(Technology) | 具体平台、实现技术 | 在何种平台上实现 | 构件清单、实现约束、测试安排 |
除视点语言外,Part 3 还规定了两个配套模型:计算模型(Computational Model)以接口与操作定义功能分解的抽象表达,计算对象之间通过操作调用(operation invocation)与信号交互(signal interaction)通信,强调接口签名清晰、绑定可验证;工程模型(Engineering Model)则描述如何用工程机制(如通道 channel、桩 stub、绑定器 binder、协议对象 protocol object)支撑分布透明性,是中间件内部结构的通用蓝图。
最后,Part 3 给出了规范与一致性(conformance)的表述与检查规则:系统声称遵循某视点规范时,必须能以标准规定的方式证明其满足了相应的行为与接口要求。一致性声明通常与实现的互操作测试配套,构成采购与验收的基础。
RM-ODP 并不是孤立的参考模型,它与其周边标准形成了完整的生态:
理解这些关联,读者可以把 RM-ODP 视为一张”分布式系统解剖图”:任何具体技术的落脚点都能在这张图上标注出来,这也正是参考模型类标准的价值所在。
从工程可操作性角度,应用 RM-ODP 时通常应遵循以下要求: