⇧
❮
❯
↻
🍀系统架构设计🍀 9904字 50分钟

系统架构核心知识（3b）：软件架构设计（架构评估、构件与中间件）

作者

软件系统架构设计内容极多，故于2026年7月26日将后半部分内容（软件质量评估、中间件技术等）拆至本文。今后尽量会将热门长文（2万字以上）拆分为数篇易于查阅的短文（常在一级序数编号中附加任意形式的字母编号，以示关联）。

Hyplus目录

5 软件架构评估 ⭐️⭐️⭐️⭐️

为什么要进行架构评估？
架构评估到底评什么？
架构评估怎么评？
——依据：软件质量属性

软件系统质量属性（Quality Attribute） 是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者（Stakeholders） 需求的程度。

基于软件系统的生命周期，总体上可以将软件系统的质量属性分为两大部分：

  1. 开发期质量属性：在软件开发阶段所关注的质量属性，主要包含易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性这6个方面。
  2. 运行期质量属性：在软件运行阶段所关注的质量属性，主要包含性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性这7个方面。

5.1 软件质量属性 ⭐️⭐️⭐️⭐️⭐️☀️☀️

常见的质量属性（非功能性指标）：

  1. 性能（Performance）：系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
    • 典例：① 同时支持1000并发；② 响应时间小于1s；③显示分辨率达到4K
    • 代表参数：响应时间、吞吐量
    • 架构策略：优先级队列、资源调度
  2. 可靠性（Reliability）：软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。（详见系统架构核心知识（4）：系统可靠性分析与设计）
    • 子属性：
      1. 容错
      2. 健壮性/鲁棒性（Robustness）：在处理或环境中，系统能够承受压力或变更的能力。
  3. 可用性（Availability）：系统能够正常运行的时间比例。（可靠性的衍生；经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示）
    • 典例：① 主服务器故障，1分钟内切换至备用服务器；② 系统故障，1小时内修复；③ 系统支持7×24小时工作
    • 代表參数：故障间隔时间
    • 架构策略：主动冗余、心跳线（Ping/Echo）
  4. 安全性（Security）：系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
    • 特性（至少4种，具体实现详见系统架构设计理论与实践（7）：安全架构之安全模型）：
      1. 机密性：信息不泄露给未授权的用户
      2. 完整性：防止信息被篡改
      3. 不可否认性：不可抵赖
      4. 可控性：对信息的传播及内容具有控制的能力
    • 典例：① 可抵御SQL注入攻击；② 对计算机的操作都有完整记录；③ 用户信息数据库授权必须保证99.9%可用
    • 架构策略：限制访问、追踪审计、冗余（同可用性，但优先提高可用性）
  5. 可修改性（Modifiability）：能够快速地以较高的性能价格比对系统进行变更的能力。（修改的方便程度）
    • 子属性：
      1. 可维护性（Maintainability）：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度。
      2. 可扩展性/灵活性（Extendibility）：软件因适应需求变化而增加新功能的能力。
      3. 结构重组（Reassemble）
      4. 可移植性（Portability）/复用性/重用性（Reusability）：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度/重用软件系统或某一部分的难易程度。（详见后述“构件与中间件技术”之软件复用）
    • 典例：① 更改系统报表模块，必须在2人周内完成；② 对Web界面风格进行修改，修改必须在4人月内完成
    • 架构策略：运行时注册、接口-实现分离、信息隐蔽（可提高可修改性、可测试性、可移植性）
  6. 功能性（Functionality）：系统所能完成所期望工作的能力。
  7. 可变性（Changeability）：体系结构经扩充或变更成为新体系结构的能力。
  8. 互操作性（Inter-operation）：系统与外界或系统与系统之间的相互作用能力。

其他属性：

  1. 易用性（Usability）：衡量用户使用一个软件产品完成指定任务的难易程度。
    • 典例：①界面友好；② 新用户学习使用系统时间不超过2小时
  2. 可测试性（Testability）：软件发现故障并隔离、 定位其故障的能力特性， 以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。
    • 典例：提供远程调试接口，支持远程调试
    • 架构策略：记录-回放

5.2 系统架构设计中的非功能性需求 ☀️☀️

软件架构更关注非功能性需求：

  1. 系统性能需求（Performance Requirements）：指响应时间、吞吐量、准确性、有效性、资源利用率等与系统完成任务效率相关的指标。可靠性、可用性等属性归为此类。
  2. 安全性需求（Security Requirements）：系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。
  3. 操作性需求（Operational Requirements）：与用户操作使用系统相关的一些需求。
  4. 文化需求（Cultural Requirements）：带有文化背景因素的系统需求。

5.3 架构评估中的4个“点” ☀️☀️

以下4个“点”通常属于功能性指标：

  • 敏感点（Sensitivity Point）：为了实现某种特定的质量属性，一个或多个构件（和/或构件之间的关系）的特性。（该特性会对最终系统有影响；设计策略）
  • 权衡点（Tradeoff Point）：影响多个质量属性的特性，是多个质量属性的敏感点。（如图所示，两头属性经常朝相反趋势变动）
    权衡点
  • 风险点：架构设计中潜在的、存在问题的架构决策所带来的隐患。【可能】
  • 非风险点：不会带来隐患。一般以“xxx要求是可以实现（或接受）”的方式表达。

【例】常见情形：

  • 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计——敏感点
  • 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的——非风险点
  • 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性——风险点
  • 更改加密的级别将对安全性和性能产生影响——权衡点
  • ……

5.4 架构评估方法

常用的软件架构评估方法：

  • 基于调查问卷/检查表的方式
  • 基于度量的方式
    • 涉及3个基本活动：
      1. 首先要建立质量属性和度量之间的映射原则
      2. 然后从软件架构文档中获取度量信息
      3. 最后再根据映射原则分析推导出系统的质量属性
  • 基于场景的方式（最常用）

架构评估方法

5.4.1 质量属性场景描述

质量属性场景（Scenarios）是一个具体的质量属性需求，是风险承担者与系统交互的简短描述。

场景可从6个方面进行描述（一般采用刺激、环境、响应这3方面来对场景进行描述）：

  1. 刺激源（Source）：生成该刺激的实体（人、计算机系统或其他刺激器）
  2. 【刺激】（Stimulus）：刺激到达系统时可能产生的影响（即需要考虑和关注的情况）
    • 基于性能质量属性场景的刺激：定期事件、随机事件、偶然事件
    • 基于可用性质量属性场景的刺激：疏忽、错误、崩溃、时间
    • 基于安全性质量属性场景的刺激：试图显示数据、改变/删除数据、访问系统服务、降低系统服务的可用性
    • 基于可修改性质量属性场景的刺激：增加/删除/修改/改变——功能、质量属性、容量
    • 基于易用性质量属性场景的刺激：学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意
  3. 制品（Artifact）：系统中受刺激的部分（某个制品被刺激）
  4. 【环境】（Environment）：该刺激在某条件内发生（如系统可能正处于过载情况）
  5. 【响应】（Response）：刺激到达后所采取的行动
  6. 响应度量（Measurement）：当响应发生时，应能够以某种方式对应其度量，用于对是否满足需求的测试

性能场景示例：

性能场景示例

3种基于场景的评估方法：

  1. 软件架构分析法：最初关注可修改性，后扩充到可移植性、可扩充性等其他属性。
  2. 架构权衡分析法：在SAAM的基础上发展而来，主要针对性能、实用性（可用性，Availability）、安全性、可修改性。
  3. 成本效益分析法（Cost-Benefit Analysis Method，CBAM）：在ATAM基础上建立的、软件的“经济”模型。

5.4.2 软件架构分析法（SAAM）

软件架构分析法（Software Architecture Analysis Method，SAAM）最初用于分析架构可修改性，后扩展到其他质量属性。主要目标是通过场景技术发现潜在问题，适用于评估单个系统或多个系统的比较。

方法：

  • 主要输入：问题描述、需求说明、架构描述
  • 分析过程：场景开发、架构描述、单个场景评估、场景交互评估（单个架构评估）、总体评估（比较多个架构）

SAAM

5.4.3 架构权衡分析法（ATAM）

架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）：在SAAM的基础上发展而来，评估时关注的是【架构说明】。主要针对性能、实用性（可用性，Availability）、安全性、可修改性。在系统开发之前，对这些质量属性进行评价和折中，整个评估过程强调以【属性】作为架构评估的核心概念。。ATAM需要对软件质量属性进行优先级排序。

各种架构评估方法（如ATAM）不是一种精确的评估工具。

与SAAM不同的是，ATAM分为4个阶段（行动计划），如图所示：

  • 第一阶段：场景和需求收集（该阶段与SAAM相同）
    1. 收集场景
    2. 收集需求/约束/环境
  • 第二阶段：架构视图和场景实现
    1. 描述架构视图
    2. 实现场景
  • 第三阶段：属性模型构造和分析
    1. 特定属性分析（优秀的单一理论）
  • 第四阶段：折中
    1. 标志敏感度
    2. 标志折中

ATAM

5.5 质量效用树 ☀️☀️

质量效用树（Utility Tree）是ATAM进行架构评估的工具之一，是对质量属性进行分类、权衡、分析的架构分析工具，主要关注系统的性能、可修改性、可用性、安全性四个方面，可以直观地展现出项目中一系列关键场景中的因素。

其树形结构从根部到叶子节点依次为树根、质量属性、属性【分类】、质量属性场景。

质量效用树

修剪这棵树【拓展】：保留重要场景（不超过50个），再对场景按重要性给定优先级（用H/M/L的形式），再按场景实现的难易度来确定优先级（用H/M/L的形式），可对所选定的每个场景确定一个优先级对(重要度, 难易度)，如(H, L)表示该场景重要且易实现。

实为本章全部内容的综合表示。

【例】某网上购物电子商务公司拟升级正在使用的在线交易系统，以提高用户网上购物在线支付环节的效率和安全性。在系统的需求分析与架构设计阶段，公司提出的需求和关键质量属性场景如下：
（a）正常负载情况下，系统必须在0.5秒内对用户的交易请求进行响应；
（b）信用卡支付必须保证99.999%的安全性；
（c）对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计；
（d）网络失效后，系统需要在1.5分钟内发现错误并启用备用系统；
（e）需要在20人月内为系统添加一个新的CORBA中间件；
（f）交易过程中涉及到的产品介绍视频传输必须保证画面具有600*480的分辨率，20帧/秒的速率；
（g） 更改加密的级别将对安全性和性能产生影响；
（h）主站点断电后，需要在3秒内将访问请求重定向到备用站点；
（i）假设每秒用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的；
（j）用户信息数据库授权必须保证99.999%可用；
（k）目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；
（I）更改Web界面接口必须在4人周内完成；
（m）系统需要提供远程调试接口，并支持系统的远程调试。
在对系统需求和质量属性场景进行分析的基础上，系统的架构师给出了三个候选的架构设计方案。公司目前正在组织系统开发的相关人员对系统架构进行评估。
问题1：在架构评估过程中，质量属性效用树（Utility Tree）是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性，填入下图中（1）、（2）空白处；并选择题干描述的（a）～（m），填入（3）～（6）空白处，完成该系统的效用树。
质量属性效用树
问题2：在架构评估过程中，需要正确识别系统的架构风险、敏感点和权衡点，并进行合理的架构决策。请用300字以内的文字给出系统架构风险、敏感点和权衡点的定义，并从题干（a）～（m）中各选出1个对系统架构风险、敏感点和权衡点最为恰当的描述。
【解】
问题1：由（e）、（d）分别可得（1）为可修改性，（2）为可用性。（3）为（f），（4）为（j），（5）为（h），（6）为（b）。
问题2：系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

6 软件产品线 ⭐️⭐️⭐️

软件产品线（Software Product Line）是指具有一组可管理的公共特性的软件密集性系统的合集。如下图所示，其中红圈部分即为软件产品线：

软件产品线

特点：

  • 核心资源
  • 产品集合
  • 过程驱动
  • 特定领域
  • 技术支持
  • 以架构为中心

软件产品线的双生命周期模型如下图所示：

双生命周期模型

软件产品线的建立方式：跨度上有演化式和革命式，建立过程中还应考虑基于现有产品还是全新产品线

  • 将现有产品演化为产品线
  • 用软件产品线替代现有产品集
  • 全新软件产品线的演化
  • 全新软件产品线的开发
软件产品线建立方式 演化方式 革命方式
基于现有产品 基于现有产品架构设计产品线的架构，经演化现有构件，开发产品线构件 核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线 产品线核心资源随产品新成员的需求而演化 开发满足所有预期产品线成员的需求的核心资源

组织结构类型：

  1. 设立独立的核心资源小组
  2. 不设立独立的核心资源小组
  3. 动态的组织结构

要成功实施产品线，主要取决于以下因素：

  1. 对该领域具备长期和深厚的经验
  2. 一个用于构建产品的好的核心资源库
  3. 好的产品线架构
  4. 好的管理（软件资源、人员组织、过程）支持

7 构件与中间件技术 ⭐️⭐️⭐️

构件化思想：系统架构核心知识（2a）：软件工程（过程模型、开发方法、需求工程）之“软件过程模型-构件组装模型、CBSE”

7.1 构件基本概念

构件（Component）是一个自包容、可复用的程序集，外界通过接口访问其提供的服务，更多相关概念可见系统架构核心知识（2a）：软件工程（过程模型、开发方法、需求工程）之CBSE。

构件是一组通常需要同时部署的原子构件（Atomic Component）。构件和原子构件之间的区别在于，大多数原子构件永远不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。原子构件是部署、版本控制和替换的基本单位。一个原子构件包含一个模块（Module）和一组资源，其中模块是不带单独资源的原子构件，可以是一组类和可能的非面向对象的结构体，例如过程或者函数。

构件的特性：

  1. 独立部署单元
  2. 作为第三方的组装单元
  3. 没有（外部的）可见状态：可以利用容器管理自身对外的可见状态（例如Spring框架中的IOC容器）

一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。

原子构件通常成组地部署，但是它也能够被单独部署。

在上述严格定义下，Java包不是模块一一在Java中部署的原子单元是类文件。一个单独的包被编译成多个单独的类文件——每个公共类都有一个。

【辨析】对象的特性：

  1. 一个实例单元，具有唯一的标志
  2. 可能具有状态，此状态外部可见
  3. 封装了自己的状态和行为

如果把软件系统看成是构件的集合，那么从构件的外部形态来看，构成一个系统的构件可分为5类：

  1. 独立而成熟的构件：该类构件得到了实际运行环境的多次检验；隐藏了所有接口，用户只需用规定好的命令进行使用。例如数据库管理系统和操作系统等。
  2. 有限制的构件：该类构件提供了接口，指出了使用的条件和前提；在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如各种面向对象程序设计语言中的基础类库等。
  3. 适应性构件：该类构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用；这种构件可以不加修改地使用在各种环境中。例如ActiveX等。
  4. 装配的构件：装配（Assemble）的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，使用胶水代码（Glue Code）即可进行连接使用。目前一些软件商提供的大多数软件产品都属这一类。
  5. 可修改的构件：该类构件可以进行版本替换。如果对原构件修改错误、增加新功能，可以利用重新“包装”或写接口来实现构件的替换。这种构件在应用系统开发中使用得比较多。

接口（Interface）是一个已命名的一组操作的集合。构件的客户（通常是其他构件）通过这些访问点来使用构件提供的服务。通常来说，构件在不同的访问点有多个不同的接口。每一个访问点会提供不同的服务，以迎合不同的客户需求。强调构件接口规范的合约性非常重要，因为构件和它的客户是在互不知情的情况下分别独立开发的，是合约提供了保证两者成功交互的公共中间层。

7.2 面向构件的编程（COP）

面向构件的编程（Component Oriented Programming，COP）关注于如何支持建立面向构件的解决方案。一个基于一般OOP风格的COP定义如下（Szyperski，1995）：

面向构件的编程需要下列基本的支持：

  1. 多态性（可替代性）
  2. 模块封装性（高层次信息的隐藏）
  3. 后期的绑定和装载（部署独立性）
  4. 安全性（类型和模块安全性）

在基于构件的开发中，构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系统模型中包的思想，它是系统设计、实现和维护的基础。构件是通过接口访问服务的一个独立可交付的功能单元。

构件组装（Component Composition）是指构件相互直接集成或是用“胶水代码”将其整合在一起来创造一个系统或另一个构件的过程。常见的方式包括：顺序组装、层次组装、叠加组装（详细技术见后述“构件的复用”之“组装构件”一条）。同时，构件组装中经常会面临接口不兼容的问题，如果一个构件的提供接口是另一个构件请求接口的一个子集，则属于操作不完备的情况。构件组装成软件系统的过程可分为3个不同的层次：

  1. 定制（Customization）：根据特定需求对构件进行个性化的调整或修改。
  2. 集成（Integration）：将多个定制好的构件组合成一个完整的软件系统。
  3. 扩展（Extension）：在现有软件系统的基础上增加新的功能或构件。

7.3 构件的复用

编写基于构建的开发方法相关案例分析/论文时可参考以下构件复用步骤：

检索与提取构件

  1. 检索与提取构件
    • 检索方法：
      1. 基于关键字的检索
        • 特点：树形或有向无回路图结构（如上图所示）
      2. 刻面检索法
        • 特点：利用刻面（Facet）描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征
        • 刻面示例：应用领域、使用环境、功能
      3. 超文本检索法
        • 特点：按照人类的联想思维方式任意跳转到包含相关概念或构件的文档
  2. 理解与评价构件
    • 要点：
      • 要复用构件，准确地理解构件至关重要。特别是对构件修改使用时。
      • 为达到目的，必须要求构件的开发过程遵循公共标准。
      • 一般构件库的文档中全面而准确地说明以下内容：
        • 构件的功能与行为
        • 相关的领域知识
        • 可适应性约束条件与例外情形
        • 可以预见的修改部分及修改方法
  3. 修改构件
    • 要点：
      • 理想状态是直接复用构件库中现成的构件，但大多数情况下，必须对构件进行或多或少的修改，以应对新需求。
      • 为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。
      • 构件库中若无可修改使用的构件，则按新需求开发构件，并存入构件库。
  4. 组装构件
    • 通常选用以下3种构件组装技术：
      1. 基于功能的构件组装技术：采用子程序调用和参数传递的方式将构件组装起来。
      2. 基于数据的构件组装技术：仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法。
      3. 面向对象的构件组装技术：如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。
    • 构件组装失配问题：失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设（assumption）与实际状况不同而导致的冲突。有如下几类——
      1. 由构件引起的失配：包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。
      2. 由连接子引起的失配：包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。
      3. 由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

7.4 构件标准

常见的3个构件标准：

  1. CORBA
  2. J2EE中的EJB
  3. DNA 2000

7.4.1 EJB（J2EE）

J2EE（Java 2 Platform Enterprise Edition）是一个为企业级应用提供的基于Java的开发、构建和部署应用的平台，由Sun Microsystems（现属于Oracle）开发，并广泛用于构建复杂的、多层次的、分布式的、基于Web的应用。J2EE提供了一个丰富的API和工具集，用于简化企业级应用的开发。核心内容如下——

容器：Applet Container、Application Container、Web Container、EJB Container

组件：Applet、Application、JSP/Servlet、EJB（Enterprise Java Beans）

EJB的分类：

  1. 会话Bean：实现业务逻辑，负责完成服务端与客户端的交互
  2. 实体Bean：实现O/R映射（对象关系映射，Object-Relational Mapping），简化数据库开发工作
  3. 消息驱动Bean：处理并发与异常访问

服务：【拓展】

  • HTTP（Hyper Text Transfer Protocol）：超文本传输协议。
  • RMI-IIOP（Remote Method Invocation over the Internet Inter-ORB Protocol）：远程方法调用，融合了Java RM和CORBA，在使用Application或Web端访问EJB端组件时使用。
  • Java IDL（idltojava）：一个ORB（对象请求代理），可用于在Java语言中定义、实现和访问CORBA对象。Java IDL支持瞬间的CORBA对象，即在对象服务器处理过程中有效。实际上Java IDL的ORB仅是一个类库，并非完整的平台软件，但其对Java IDL应用系统和其他CORBA应用系统之间提供了良好的底层通信支持，实现了OMG（对象管理组织）定义的ORB基本功能。（CORBA相关概念见后述）
  • JTA（Java Transaction API）：用于进行事务处理操作的API。
  • JDBC（Java Data Base Connectivity，Java数据库连接）：一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，由一组用Java语言编写的类和接口组成。JDBC提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序。
  • JMS（Java Message Service，Java消息服务）：Java消息系统访问机制，但其本身并不实现消息。JMS支持点对点模式分发的消息队列，也支持发布-订阅模式的多个目标订阅的消息主题——消息会发送给一个主题，但与点对点模式不同的是消息不再只被投递给一个接收者，而是所有此主题的订阅者都会收到该消息。JMS支持各种消息类型（二进制、流、名-值表、序列化的对象和文本）。通过声明与SQL的WHERE相近的句段，可以建立消息的过滤器。
  • JavaMail：用于发送邮件。
  • JAF（Java Activation Framework）：用于封装传递的邮件数据。
  • JNDI（Java Naming and Directory Interface）：一个应用程序设计API，为开发人员提供了查找和访问各种命名和目录服务的通用、统一的接口。
  • JAXP（Java API for XML Processing）：专门用于XML解析操作的API。
  • JCA（Java Connector Architecture，J2EE连接器架构）：由J2EE 1.3首先提出，是对J2EE标准集的重要补充。它位于J2EE应用服务器和企业信息系统（EIS）之间，例如数据库管理、企业资源规划（ERP）、企业资产管理（EAM）和客户关系管理（CRM）系统。不使用Java开发的企业应用或者在J2EE框架内的应用都可通过JCA连接。JCA在javax.resource包及其子包 （cci、spi、spi.security）中定义。（企业信息化体系相关概念见系统架构核心知识（1）：系统工程与信息系统基础）
  • JAAS（Java Authentication and Authorization Service）：Java认证和授权服务。
  • JSF（Java Server Faces）：一种用于构建Web应用程序的新标准Java框架。
  • JSTL（JSP Standarded Tag Library）：JSP标准标签库，一个不断完善的开放源代码的JSP标签库。
  • SAAJ（SOAP with Attachments API for JAVA）：在松散耦合软件系统中利用SOAP协议实现的基于XML消息传递的API规范。
  • JAXR（Java Apl for XML Registries）：一种Java客户机API，用于访问UDDI（仅限V2）和ebXML注册中心。

“JCA”亦为Java Cryptography API的缩写。

基于JavaEE平台的基础功能服务构建应用系统时，【JDBC、JCA、Java IDL】可用来集成遗产系统。

7.4.2 CORBA

CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）是由OMG（Object Management Group，对象管理组织）制定的一种面向对象的构件重用标准，旨在提高软件构件的重用性和互操作性。

CORBA解决了远程调用问题（例如客户端与服务器不在同一局域网），在本地设置对象引用，使得能够像调用本地资源般调用远程资源（逻辑上），而底层实现均交予COBRA实现。

CORBA

重要组成部分：

  • 伺服对象（Servant）：最终完成客户端请求的CORBA对象的真正实现。
  • 可移植对象适配器（Portable Object Adapter，POA）：在底层传输平台与接收调用并返回结果的对象实现之间进行协调。屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
  • 对象请求代理（Object Request Broker，ORB）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象，是因为并没有硬性规定CORBA对象的实现机制。由于独立于程序设计语言和特定ORB产品，一个CORBA对象的引用又称为可互操作的对象引用（Interoperable Object Reference，IOR）。从客户程序的角度看，IOR中包含了对象的标识、接口类型及其他信息以查找对象实现。

OMG基于CORBA基础设施定义了4种构件标准：

  1. 实体（Entity）构件：需要长期持久化并主要用于事务性行为，由容器管理其持久化。
  2. 加工（Process）构件：同样需要容器管理其持久化，但没有客户端可访问的主键。
  3. 会话（Session）构件：不需要容器管理其持久化，其状态信息必须由构件自己管理。
  4. 服务（Service）构件：是无状态的。

7.4.3 接口定义语言（IDL）

拓展

IDL（Interface Definition Language，接口定义语言）用于定义接口以及相关部分。

IDL文件包含的主要元素：接口描述、模块定义、类型定义、常量定义、异常、值类型。其中接口描述是IDL文件中最核心的内容。

由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为Java类，而该接口的操作映射为相应的成员函数。模块定义映射为Java语言中的包（Package）或C++中的Namespace。

7.4.4 服务端构件模型

拓展

关于服务端构件模型的典型解决方案包括适用于应用服务器的EJB模型（见前述EJB/J2EE）和微软公司COM+模型（将COM提升到了应用层），以及适用于Web服务器的Servlet模型（见前述EJB/J2EE）和Visual Basic及其他微软的技术（基于微软公司ASP技术）。.NET框架还引入了一种新的同时适用于客户端和服务端的基于CLI（Command Line Interface）的构件模型。

7.5 中间件基本概念

中间件（Middleware）是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。

中间件的作用：

  • 负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
  • 提供应用的负载均衡和高可用性、安全机制与管理功能，并提供交易管理机制来保证交易的一致性。
  • 提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
  • 提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。
  • 屏蔽硬件、操作系统、网络和数据库的差异。
  • 提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

在分布式系统中，中间件通常提供两种不同类型的支持：

  1. 交互支持：中间件协调系统中的不同组件之间的交互。
  2. 提供公共服务：即中间件提供对服务的可复用的实现，这些服务可能会被分布式系统中多个组件所需要。
    • 公共服务是指被不同组件需求的服务，无论这些组件的功能是什么。可将这些服务视为中间件容器所提供，可在该容器中部署组件，并且这些组件可以访问和使用这些公共服务。

【例】Kafka作为一种分布式消息中间件提供的交互支持和公共服务：支持消费者和生产者之间的交互；支持多个组件的复用功能（公共服务）；消息持久化到硬盘。

7.6 消息中间件

拓展

消息中间件是在消息的传输过程中保存信息的容器。消息中间件在将消息从它的源中继到它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递：若发送消息时接收者不可用，消息队列会保留消息，直至可以成功传递为止。消息队列保存消息存在期限。

消息中间件的特点：

  1. 采用异步处理模式。消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道（主题或队列）上，消息接收者则订阅或是监听该通道。一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
  2. 应用程序和应用程序调用关系为松耦合关系。主要体现在如下两点：发送者和接受者不必了解对方、只需确认消息；发送者和接受者不必同时在线。例如在线交易系统为了保证数据的最终一致，在支付系统处理完成后会把支付结果放到消息中间件里通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。

消息中间件的传输模式：

  1. 点对点模型：用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发送到由某个名字标识的特定消费者。该标识实际对应于消费服务中的一个队列（Queue），在消息传递给消费者前存储于该队列中。队列消息可以放在内存中，亦可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。
  2. 发布-订阅模型（Pub/Sub）：支持向一个特定的消息主题生产消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下，发布者和订阅者彼此不知道对方。这种模式类似于匿名公告板，多个消费者可以获得消息，在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅（Subscription）供消费者订阅。订阅者必须保持持续的活动状态及接收消息，除非订阅者建立了持久的订阅。

发表评论