《系统架构设计师教程（第2版）》第12章-信息系统架构设计理论与实践-05-信息系统架构案例分析

🕗 发布于 2024-07-26 06:55 系统架构软考架构师教材系统架构设计师第2版新版

文章目录

1. 价值驱动的体系结构——连接产品策略与体系结构
2 Web服务在HL7上的应用——Web服务基础实现框架
3. 以服务为中心的企业整合

1. 价值驱动的体系结构——连接产品策略与体系结构

1.1 价值模型

1）概述

价值模型的作用
- 有助于了解和传达关于价值来源的重要信息
解决的问题，如：
- 价值如何流动
- 期望值和外部因素中存在的相似性和区别
- 系统要实现这些价值有哪些子集
优点：
- 使用顺序推理和分类逻辑，易于教授和讲解
- 结果易于验证

2）价值驱动因素

价值期望值
- 概念：表示对某一特定功能的需求
  - 包括：内容(功能)、满意度(质量)、不同级别质量的实用性
- 如，汽车驾驶员对刹车的快慢、安全性的价值期望值
反作用力
- 概念：通常期望值越高难度越大
变革催化剂
- 概念：环境中导致价值期望值发生变化的事件，或导致不同结果的限制因素

反作用力和变革催化剂称为限制因素

3）传统方法识别价值模型的缺陷（了解即可）

对参与者的行为模型关注较多，对目标关注较少。
将参与者固定化分成几种角色
忽略限制因素之间的差别
结果简单

要求得到满足/未满足，用例成功完成/未成功完成

1.2 体系结构策略（挑战）

体系结构策略要点
- 能够被所有利益相关者所理解
- 在系统的整个生存期内保持相对稳定
体系结构具有挑战性的原因：
- 各种限制因素使得实现各个期望值变得困难
识别体系结构挑战的评估：
- 哪些限制因素影响一个或多个期望值
- 这些影响对满足期望值是积极的还是消极的
- 其影响程度如何（高中低三个等级）
限制因素对期望值的影响不能跨背景考虑
确定体系结构挑战的步骤
- 确定优先级
- 确定处理最高优先级挑战的方法

1）优先级的确定

制定系统体系结构的切入点
- 识别合适的价值背景，并对其优先化
- 在每一背景中定义效用曲线，优先化期望值
- 识别和分析每一背景中的反作用力和变革催化剂
- 检测“限制因素使满足期望值变难”的领域
优先化体系结构的权衡点
- 重要性
  - 受挑战影响的期望值的优先级有多高
  - 这些期望值的特定的背景相对优先级如何
- 程度
  - 限制因素对期望值产生了多大影响
- 后果
  - 有多少方案可供选择
  - 这些方案的难度或有效性如何
- 隔离
  - 最现实的方案的隔离情况

2）确定处理最高优先级挑战的方法

在以下领域，分析“应对最高优先级挑战的方法”的指导原则：

组织

如何系统性地组织子系统和组件?它们的组成和职责是什么?系统如何部署在网络上?都有哪些类型的用户和外部系统?它们位于何处?是如何连接的?

操作

组件如何交互?在哪些情况下通信是同步的?在哪些情况下是异步的?组件的各种操作是如何协调的?何时可以配置组件或在其上运行诊断?如何检测、诊断和纠正错误条件?

可变性

系统的哪些重要功能可以随部署环境的变化而变化?对于每一功能，哪些方案得到支持?何时可以做出选择(例如，编译、链接、安装、启动或在运行时)?各个分歧点之间有什么相关性?

演变

为了支持变更同时保持其稳定性，系统是如何设计的?哪些特定类型的重大变革已在预料之中，应对这些变更有哪些可取的方法?

1.3 价值模型和体系结构策略的联系

软件和系统的存在是为了提供价值
体系结构提供了价值的模型的折中方案

价值是一个标量，它融合了对边际效用理解和诸多不同目标之间的相对重要性。目标折中是一个极其重要的问题。

价值模型包含了软件体系结构的主要驱动因素

价值存在于多个层面，其中某些层面包含了目标系统，并将其作为一个价值提供者。用于这些领域的价值模型包含了软件体系结构的主要驱动因素。

价值模型的变化是系统演化的一个重要依据

该层次结构中高于上述层面的价值模型可以导致其下层价值模型发生变化。这是制定系统演化原则的一个重要依据。

不同价值背景，其体系结构挑战优先级不同

对于满足不同价值背景需要，系统的开发赞助商有着不同的优先级。

体系结构挑战是不同价值背景的期望值引起的

体系结构挑战是由环境因素自某一背景中对期望的影响引起的

体系结构方法通过首先克服“最高优先级体系结构挑战”来实现价值的最大化
体系结构策略是通过总结共同规则、政策和组织原则、操作、变化和演变从最高优先级体系结构方法综合得出的。（该点似乎与价值模型无关）
对于每一个价值群，价值模型都是同类的。暴露于不同环境条件的价值背景具有不同的期望值。（该点似乎与体系结构无关）

2 Web服务在HL7上的应用——Web服务基础实现框架

HL7的概念
- Health Level 7
- 是一个国际标准组织，专注于医疗领域的信息交换标准

HL73.0版本扩展到了各种卫生保健行业，如制药业、医疗设备及成像设备。

将HL7软件应用在 Web Services 上
- 设计一个正确的体系结构
- 提供一个可执行且满足 Web Services 的环境
HL7

2.1 HL7模型

领域：卫生保健领域
概念：
- 为协同工作而创建的基层结构
- 它使用参考信息模型 (RIM)来获得具体领域的信息模型
- 并将这些信息模型精炼到HL7 说明书中
- 结合具体的消息类型自动产生XML表单定义 (XSD)

2.1.1 参考信息模型

概念：
- 是一个静态的卫生保健信息模型
- 它代覆盖了HL7 涉及领域的各个方面。

HL73.0版本标准开发过程定义了一些规则，这些规则用于从参考信息模型中获取一些具体领域信息模型，从而在 HL7 规格说明书中使这些模型更精确，最后产生 XML表单定义 (XSD) 与一个具体的消息类型联合起来。

2.2.1 消息结构

wrappers
- 指HL7 消息的封装
- 被用来支持消息的传输

2.1.3 交互

时间触发消息转移

此处教材原文吧啦吧啦说了一堆口水话，没有说出任何和其他类型软件的区别。

2.1.4 应用程序角色

HL7 里的每一个应用属于一个具体的应用程序角色，体现了应用程序的职责。

上边是截取的教材原文，说了好像没说

2.1.5 Storyboard

概念：
- 由一段简短的描述所构成
- 这段描述记叙了它自身的目的以及与应用程序角色间相互作用的方式和层级
- 通过交互作用图表在应用层面上展示出来
交互作用的图表指明了
- 相应交互作用的职责(即，应用程序角色)
- 交换信息的类型
- 期望的信息交换的顺序

2.2 体系结构

2.2.1 HL7应用

定义：基于HL7概念模型，我们可以更精确地定义HL7应用
作用：旨在支持应用程序角色软件组件的设计与实现

2.2.2 发送者和接收者

概述：
- 由各应用程序角色担任
- 利用Web服务通信基础设施作为底层支撑，确保信息在不同角色间的顺畅传递和处理
内部的两组核心功能：
- 商业逻辑
- Web服务适配器

2.2.3 商业逻辑的任务

发送端
- 负责创建HL7消息的XML描述
  - 包括：消息体、Transmission Wrapper、Control Wrapper
- 将这一消息传递给Web服务适配器
- 适配器负责将消息传送至接收端
接收端
- 接收Web服务适配器传来的 HL7 消息
- 验证HL7消息是否满足商业规则和约束
- 核实发送应用端是否需要确认信息，若需要，则发送确认消息

2.2.4 Web服务适配器

功能：处理消息的分发和确认信息
主要内容如下：

1）发送端

读取接收到的HL7消息的Transmission Wrapper
- 以确定消息如何到达Web服务基础设施
- 进而配置SOAP以适应传输需求
基于 HL7消息类型、应用配置、规则来准备一个 SOAP 消息
把SOAP消息传递到Web服务代理，通过网络进行传输
准备接收并存储来自接收端相应确认消息

2）接收端

从Web服务器接收SOAP 消息
验证接收到的 SOAP 消息满足应用配置和一些约束条件(如安全性)
在内存中保存这些消息
有选择性地从 SOAP消息里打开 HL7 XML消息，并核对是否与期望值相符
验证是否需要返回确认信息
传递HL7消息给接收应用端

2.3 开发HL7 Web服务适配器

其开发步骤如下：

2.3.1 消息和数据类型的设计

必须的设计：
- 可交换的消息
- 已用的数据类型
- XSD表单里它们的说明书

2.3.2 适配器模式的选择

由第一步中的消息类型来制定

2.3.3 HL7Web服务契约开发

WSDL
- Web Services Description Language
- 一种标准化的可用计算机处理的语言
Web服务契约
- 使用WSDL来开发

2.3.4 产生Web服务 Stub和代理的实现

Stub：充当远程服务的一个本地代理，允许客户端应用程序以本地调用的方式访问远程服务

2.3.5 开发适配器业务逻辑

WSDL 契约都详细说明了一个 Web服务的名字和端口
端口的作用
- Web服务器通过这些端口和客户端通信
- 端口指定了：
  - 网络中服务生效的位置
  - 端口上的操作
  - 通信的协议
端口类型：代表了暴露在Web 服务上的各种接口
操作：
- 是接口的方法
- 定义了客户端请求服务端的输入信息
- 服务器用于应答客户的输出信息
消息的格式也是基于WSDL契约中所定义的类型的格式 (XML表单)。

2.4 案例研究

两个相互交互的系统：
- 医疗信息系统 (Hospital Information System,HIS)
- 实验室信息系统 (Laboratory Information System,LIS)
两个服务的信息如下
1. HIS是由两个 Sub-systems组成：排序、报告
2. LIS是由Web服务和业务逻辑组成的
  - Web 服务：从 HIS排序系统接收命令，
  - 业务逻辑：将确认信息返回到HIS排序或报告系统
3. 消息的交互，与前文所述一致
4. 两个服务各自有一个客户端

在这里插入图片描述

上图流程说明：

当用户接口从HIS 客户机那里收到信号时， HIS 业务逻辑就会产生一个序号标识符，同时通过创建一个 XML文件以及在HL7负载里加入一个序号 I D来构造POLB_IN2120 信息。
业务逻辑发送一个 POLB_IN2120 信息 (Send Order) 给适配器，通过它的代理服务(POLB_AR002942 服务代理)来调用 LIS服务。
在 Laboratory端， POLB_AR002942 Service Stub 接收到SOAP信息，同时使它对于LIS Web服务适配器是可用的。
LIS适配器从 SOAP信息里得到HL7信息 (Order), 同时依据 HL7信息类型表单来验证从 SOAP 那得到的被封装的HL7 负载。
LIS 适配器从 SOAP信息里得到 HL7信息 (Order), 同时依据HL7信息类型表单来验证从 SOAP 那得到的被封装的 HL7 负载。
如果需要，它会准备确认序列，这个确认序列是通过构造一个XML 文件同时在文件里附上一个预先定义的应答确认来实现的。
当一个新的信息到达时， LIS业务逻辑重新从顺序队列里得到 HL7信息，并且将信息发送给 LIS客户端。

3. 以服务为中心的企业整合

以一个经过简化的实际案例为例，介绍了以服务为中心的企业集成的基本步骤，从业务分析到服务建模，到架构设计，到系统开发的整个生命周期。以服务为中心的企业集成涉及的主要技术被穿插在各个步骤中进行了详细的讲解。

3.1 案例背景

某航空公司的信息系统已有好几十年的历史。该航空公司的主要业务系统构建于20世纪七八十年代，以IBM的主机系统为主，包括运行于TPF上的订票系统和运行在IMS上的航班调度系统等。在这些核心系统周围也不乏基于UNIX 的非核心作业系统，和基于.Net 的简单应用。这些形形色色的应用，有的用汇编或COBOL编写，运行于主机和 IMS之上；有的以PRO*C编写，运行在 UNIX 和 Oracle上。这些应用虽然以基于主机终端的界面，但是基于Web和 GUI 的应用也为数众多。
近年来，该公司在企业集成方面也是煞费苦心——已经在几个主要的核心系统之间构建了用于信息集成的信息 Hub(Information Hub), 其他应用间也有不少点到点的集成。尽管这些企业集成技术在一定程度上增进了系统间的信息共享，但是面对如此异构的系统，技术人员依然觉得企业集成困难重重。
(1)因为大部分核心应用构建在主机之上，所以Information Hub是基于主机技术开发，很难被开放系统使用。
(2)Information Hub对 Event 支持不强，被集成的系统间的事件以点到点流转为主，被集成系统间耦合性强。
(3)牵扯到多个系统间的业务协作以硬编码为主，将业务活动自动化的成本高，周期长，被开发的业务活动模块重用性差。
为了解决这些企业集成中的问题，该公司决定以Ramp Control 系统为例探索一条以服务为中心的企业集成道路。本文将以Ramp Control系统中的Ramp Coordination流程为例，说明如何用以服务为中心的企业集成技术一步步解决该公司 IT技术人员面临的企业集成问题。

3.2 业务环境分析

在航空业中， Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。通常，每个航班都有一个人负责 Ramp Coordination, 这人通常称为RampCoordinator。由Ramp Coordinator协调的业务活动有：检查机位环境是否安全，以及卸货、装货和补充燃料是否方便和安全等。
实际上， Ramp Coordination的流程因航班类型的不同，机型的不同有很大差异。图12-14所示的流程主要针对降落后不久就起飞的航班，这种类型的航班称为short turn around航班。除了short turn around航班外，还有其他两种类型的航班。 Arrival Only航班指降落后需要隔夜才起飞的，Departure Only航班是指每天一早第一班飞机。这些航班的Ramp Coordination的流程和Short Tum
Around类型的流程大部分的业务活动是相似的。这三种类型的航班根据长途/短途，国内/国外
等因素还可以进一步细分。每种细分的航班类型的Ramp Coordination的流程都是略有不同。

在这里插入图片描述
很明显，如此多的流程之间共享着一个业务活动的集合，如此多种类型的流程都是这些业务活动的不同组装方式。以服务为中心的企业集成中流程服务就是通过将这些流程间共享的业务活动抽象为可重用的服务，并通过流程服务提供的流程编排的能力将它们组成各种大同小异的流程类型，来降低流程集成成本，加快流程集成开发效率的。以服务为中心的企业集成，通过服务建模过程发现这些可重用的服务，并通过流程模型将这些服务组装在一起。

3.3 服务建模

IBM推荐使用组件业务建模 (Component Business Model) 和面向服务的建模和架构(Service-Oriented Model and Architecture) 两种方法建立业务的组件模型、服务模型和流程模型。
服务模型是服务建模的主要结果。 Ramp Coordination相关的服务模型和Ramp Coordination流程相关的有两个业务组件：①Ramp Control 负责Ramp Control相关各种业务活动的组件；
②Flight Management负责航班相关信息的管理，包括航班日程，乘客信息等
这两个业务组件分别输出如下服务。
(1)Retrieve Flight BO: 由Flight Management输出，主要用于提取和航班相关的数据信息。
(2)Ramp Coordination: 由Ramp Control输出，主要用于Ramp Coordination流程的编排。
(3)Check Spot: 由Ramp Control输出，用于检测机位安全信息。
(4)Check Unloading: 由Ramp Control输出，用于检查卸货状况。
(5)Check Loading: 由Ramp Control输出，用于检查装货状况。
(6)Check Push Back: 由Ramp Control输出，用于检查关门动作。
在服务建模确定系统相关的服务输出后，还需要确定服务在当前环境下的实现方式。在我们的案例中， Retrieve Flight BO被实现为信息服务， Ramp Coordination被实现为流程服务，通过 BPEL4WS方式实现。其他4个服务都是 Staff Service。需要注意的是，因为环境的不同和随着系统的演化，我们可能会改变服务的实现方式，如 Check Push Back现在通过 Staff Service即人工服务实现。将来随着自动化程度的增强， Check Push Back完全可能通过自动化的系统实现。到那时，只需重新实现这个服务，而无需改变整个流程。这是服务的可替换性的一个典型实例。

3.4 IT环境分析

在构建Ramp Control 系统之前，该航空公司已经有大量的信息系统。作为架构设计的重要步骤对现有IT环境调研，描绘了和Ramp Control相关的 IT系统的状况，包括周围应用和应用提供的接口，这些应用和 Ramp Control 交互的类型和数据格式。简化的IT环境视图，描绘了Ramp Coordination 流程和周围系统交互状况。目前， Ramp Coordination流程需要4种类型的外围应用交互。
(1)从乘务人员管理系统提取航班乘务员的信息。
(2)从订票系统中提取乘客信息。
(3)从机务人员管理系统中提取机务人员信息。
(4)接收来自航班调度系统的航班到达事件。
通过将主机应用中的信息集中为粗粒度的业务对象，并通过信息服务输出，为该公司的核心系统提供了更加通用的连接能力，同时为IT 系统的平滑演进提供了必要的条件。

3.5 高层架构设计

据需求和设计阶段的业务模型和现有IT环境调研结果，再结合传统的IT应用开发方法，Ramp Coordination系统的高层架构被设计了出来，如图12-15所示。
在这里插入图片描述
本案例中的主要架构元素以及它们之间的工作关系如下。

1）信息服务

Federation Service是 Ramp Coordination 流程中需要从已有系统中提取4类信息，在Service 建模阶段这4类信息被聚合为Flight BO(Business Object)。如上文所述，Retrieve Flight BO服务用于从已有系统中提取Flight BO。它实际上是一个Federation Service,将来自乘务人员管理系统、机务人员管理系统和订票系统中的信息聚合在一起。从这三个已有系统来的 Crew Info、Cockpit Info和 Passage Info 是在已有系统中已经存在的业务逻辑或业务数据，它们属于可接入服务 (on-ramp Service), 接入的协议分别为 JDBC、IMS J2C Connector和socket。乘务人员管理系统基于Oracle数据库， Crew Info可以直接通过 JDBC获得。机务人员管理系统基于 S/390上的 IMS,IBM 已经提供了 IMS的J2C Connector, 所以Cockpit Info可以通过J2C connector获得。订票系统构建在IBM TPF 之上，由于实时性的要求， socket 是比较好的接入方法。Retrieve Flight BO 被实现为一个EJB, 外部访问通过RMI/IIOP绑定访问这个服务。在Retrieve Flight BO 内部，Flight BO以 SDO来表示。

2）企业服务总线中的事件服务

Event Service是在检查机务环境安全 (Check Spot) 前，Ramp Coordiator 需要被通知航班已经到达。这个业务事件由航班调度系统激发， Flight Arrival是典型事件发现服务 (Event Detect Service), 它通过M Q将事件传递给 Message Broker, 通过JMS的Pub/Sub, 这个事件被分发给Check Spot。这里的Event Service是本例中 ESB的重要组成部分。通过 ESB上的通用事件服务，现有Information Hub的缺陷得到了克服。应用程序间的事件集成不再需要点到点的方式，而是通过 ESB 的事件服务完成订阅发布，应用程序间的耦合性得到了极大的缓解。

3）程服务

Process Service是Ramp Coordination被实现为一个Process Service, 它被WBI SF的BPEL4WS容器执行， BPEL4WS 容器提供Choreograph Service、Transaction Service和Staff Service支持。 Ramp Coordination通过RMI/IIOP协议调用，在BPEL4WS容器中 WSIF被用于通过各种协议调用服务，它成为ESB 中Transport Service 的一部分。 Ramp Coordination中的人工动作被实现为Staff Service 而集成到流程中。这里， Staff Service通过Portlet 实现，运行在Websphere Portal Server上。Portal Service 实现部分 Delivery Service支持PDA设备， RampCoordinator通过PDA设备访问系统。

4）企业服务总线中的传输服务

RCMS是即将新建系统，用于提供包括 RampCoordination在内的Ramp Control的功能。 RCMS通过由 WSIF 实现的 Transport Service 以SOAP/HTTP 调用 Ramp Coordination服务。

3.6 结论

通过一个简单的案例，讲解了以服务为中心的企业集成的主要步骤和涉及的技术。这些集成的技术，无论是方法学、体系结构还是编程模型都在不断地发展中。随着这些技术的不断完善，以服务为中心的企业集成方案的实施将更加简单高效。