官方系统架构设计师教程-ch21-案例研究

案例研究

目前，软件体系架构技术依然是工业界和学术界探讨并不断发展的学科，属于起步阶段。工业界和学术界都用自己的方式表达对体系结构的概念与思维和探索。本章选择了一些案例或文章，以便于读者分析、研究体系结构。

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

原文参见URL（http://msdn2.microsoft.com/zh-cn/library/aa480060.aspx）。

系统的存在是为了为利益相关方创造价值。然而，这种理想往往无法完全实现。当前的开发方法给利益相关方、架构师和开发人员提供的信息是不完全和不充分的。这里介绍两个概念：价值模型和体系结构策略。它们似乎在许多开发过程中被遗忘，但创造定义完善的价值模型可以为提高折衷方案的质量提供指导，特别是那些部署到不同环境中的用户众多的系统。

价值模型概述

开发有目的的系统，其目的是为其利益相关者创造价值。在大多数情况下，这种价值被认为是有利的，因为这些利益相关者在其他系统中扮演着重要角色。同样，这些其他系统也是为了为其利益相关者创造价值。系统的这种递归特性是分析和了解价值流的一个关键。下一部分（发现价值模型）将对此进行更深入的讨论。

价值模型核心的特征可以简化为三种基本形式。

（1）价值期望值：表示对某一特定功能的需求，包括内容（功能）、满意度（质量）和不同级别质量的实用性。例如，汽车驾驶员对汽车从60英里每小时的速度进行急刹车的快慢和安全性有一种价值期望值。

（2）反作用力：系统部署实际环境中，实现某种价值期望值的难度，通常期望越高难度越大，即反作用力。例如，汽车从60英里每小时的速度进行紧急刹车的结果如何取决于路面类型、路面坡度和汽车重量等。

（3）变革催化剂：表示环境中导致价值期望值发生变化的某种事件，或者是导致不同结果的限制因素。

反作用力和变革催化剂称为限制因素，把这三个统称为价值驱动因素。如果系统旨在有效满足其利益相关者的价值模型要求，那么它就需要能够识别和分析价值模型。

传统方法，如用例方案和业务/营销需求，都是通过聚焦于与系统进行交互的参与者的类型开始的。这种方法有如下几个突出的局限性。

（1）对参与者的行为模型关注较多，而对其中目标关注较少。

（2）往往将参与者固定化分成几种角色，其中每个角色所在的个体在本质上都是相同的（例如商人、投资经理或系统管理员）。

（3）往往忽略限制因素之间的差别（例如，纽约的证券交易员和伦敦的证券交易员是否相同？市场开放交易与每天交易是否相同？）。

（4）结果简单。要求得到满足或未得到满足，用例成功完成或未成功完成。

这种方法有一个非常合乎逻辑的实际原因。它使用顺序推理和分类逻辑，因此易于教授和讲解，并能生成一组易于验证的结果。

在《竞争优势》一书中，Michael Porter以公司战略规划为背景讨论了价值链概念：

“虽然价值活动是竞争优势的构造块，但价值链并不是独立活动的一个集合，而是一系列相互依赖的活动的一个系统。联系是指一个价值活动的执行方式与另一个价值活动的性价比之间的关系”，“联系不仅存在于公司的价值链中（横向联系），还存在于公司价值链与供应商和渠道商价值链之间（纵向联系）。供应商供货渠道活动会影响公司活动的性价比（反之亦然）”。

效用曲线就是一个从一种度量标准到另外一种度量标准的映射。第一种度量标准表示一个可量化的结果变量，第二种度量标准是生成的值（满意度、效用）的级别。使用Kepner和Tregoe所描述的决策分析方法，各个可选方案会与各个期望值进行对照评估。效用曲线用于将每一个可选方案所得出的定量测量值映射到其对应值。然后，值级别用期望优先级加权，并进行叠加。叠加值越高，方案越可取。在某些情况下，该方法可能比较主观。

体系结构挑战

体系结构挑战是因为一个或多个限制因素使得满足一个或多个期望值变得更困难。在任何环境中，识别体系结构挑战都涉及评估。

（1）哪些限制因素影响一个或多个期望值？

（2）如果知道了影响，它们满足期望值更容易（积极影响）还是更难（消极影响）？

（3）各种影响的影响程度如何？在这种情况下，简单的低、中和高三个等级通常就已经够用了。

必须在体系结构挑战自己的背景中对其加以考虑。虽然跨背景平均效用曲线是可能的，但对于限制因素对期望值的影响不能采用同样的处理方法。例如，假设Web服务器在两种情况下提供页面。一种情况是访问静态信息，如参考文献。它们要求相应时间为1～3s。另一种情况是访问动态信息，如正在进行的体育项目的个人得分表。其响应时间为3～6s。

两种情况都有CPU、内存、磁盘和网络局限性。不过，当请求量增加10或100倍时，这两种情况可能遇到大不相同的可伸缩性障碍。对于动态内容，更新和访问的同步成为重负载下的一个限制因素。对于静态内容，重负载可以通过频繁缓存读页来克服。

制定系统的体系结构策略始于：

（1）识别合适的价值背景并对其进行优先化。

（2）在每一背景中定义效用曲线和优先化期望值。

（3）识别和分析每一背景中的反作用力和变革催化剂。

（4）检测限制因素使满足期望值变难的领域。

最早的体系结构决策产生最大价值才有意义。有几个标准可用于优先化体系结构。建议对以下几点进行权衡。

●　重要性：受挑战影响的期望值的优先级有多高？如果这些期望值是特定于不多的几个背景，那么这些背景的相对优先级如何？

●　程度：限制因素对期望值产生了多大影响？

●　后果：大概多少种方案可供选择？这些方案的难度或有效性是否有很大差异？

●　隔离：对最现实的方案的隔离情况如何？影响越广，该因素的重要性越高。

一旦体系结构挑战的优先级确定之后，就要确定处理最高优先级挑战的方法。尽管体系结构样式和模式技术非常有用，不过在该领域，在问题和解决方案领域的身后经验仍具有无法估量的价值。应对的有效方法源于技能、洞察力、奋斗和辛勤的工作。这个论断千真万确，不管问题是关于外科学、行政管理还是软件体系结构。

当制定了应对高优先级的方法之后，体系结构策略就可以表达出来了。架构是会分析这组方法，并给出一组关于以下领域的指导原则。

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

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

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

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

总之，体系结构策略就是帆船的舵和龙骨，可以确定方向和稳定性。它应该是简短的高标准方向的陈述，必须能够被所有利益相关者所理解，并应在系统的整个生存期内保持相对稳定。

结论

价值模型有助于了解和传达关于价值来源的重要信息。它解决一些重要问题，如价值如何流动，期望值和外部因素中存在的相似性和区别，系统要实现这些价值有哪些子集。架构师分解系统产生一般影响的力，特定于某些背景的力和预计随着时间的推移而变化的力，以实现这些期望值。价值模型和软件体系结构的联系是明确而又合乎逻辑的，可以用以下9点来表述。

（1）软件密集型产品和系统的存在是为了提供价值。

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

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

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

（5）对于每一个价值群，价值模型都是同类的。暴露于不同环境条件的价值背景具有不同的期望值。

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

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

（8）体系结构方法试图通过首先克服最高优先级体系结构挑战来实现价值的最大化。

（9）体系结构策略是通过总结共同规则、政策和组织原则、操作、变化和演变从最高优先级体系结构方法综合得出的。

使用RUP和UML开发联邦企业体系结构框架

原文参见URL（http://www.ibm.com/developerworks/cn/rational/r-feaf/）。

对于贯彻联邦企业体系结构框架（Federal Enterprise Architecture Framework，FEAF）方针的团体和机构而言，IBM Rational Unified Process（RUP）是足以支持其企业体系结构（Enterprise Architecture，EA）计划的一种选择。本文探讨如何使用RUP和UML构建和管理企业体系结构。具体而言，将分析FEAF的4层矩阵结构（level IV matrix），并讨论如何用RUP促进捕获各种FEAF模型。

1996年的克林格—科恩法案（Clinger-Cohen Act）授权联邦机构开发和维护一种企业IT体系结构，以便促进联邦机构间的信息共享和组织。1999年，联邦首席信息官负责根据这一授权建立FEAF，具体内容参阅http://www.cio.gov/documents/fedarch1.pdf。FEAF的目的是建立机构范围内的路线图，通过在有效的信息技术环境中优化其核心业务过程的性能来履行机构的使命。企业体系结构可以帮助机构实现这一目标，简单地讲，它们系统而完整地定义了组织的当前（基准）环境和期望（目标）环境的蓝图。对于信息系统的演进以及开发优化其职能价值的新系统而言，EA是必不可少的。企业体系结构是从逻辑或业务（如职能、业务职责、信息流和系统环境）以及技术（如软件、硬件、通信）两方面来定义的，并且包括从基准环境转换到目标环境的顺序规划（Sequencing Plan）。

联邦企业体系结构框架概述

联邦企业体系结构框架作为一种组织机制，用于管理体系结构描述的开发和维护。FEAF也提供了组织联邦资源、描述和管理联邦企业体系结构活动的结构。框架是通过把企业信息组织到不同的层次或参考结构中来实现这一目标的。最上面的第一层是企业的最高层视图，最下面的第4层包含最详细的企业信息。它把企业体系结构划分为4部分：业务、数据、应用程序和技术。FEAF还考虑了Zachman Framework的元素以及Spewak EA规划方法学的应用。

FEAF确定了开发和维护联邦企业体系结构所需的8种构件。这8种构件的分解进一步细化了FEAF的4个层次。前三层阐述了这8种构件逐步细化的过程，最终在第四层形成了分类和组织联邦企业描述性表示的结构。

第一层是联邦企业体系结构框架的最高层，它引入了开发和维护联邦企业体系结构所需要的8种构件。

●　体系结构推动者（Architecture Drivers）：代表推动联邦企业体系结构变更的外部激励因素。

●　战略方向（Strategic Direction）：确保变更和政府的总体方向一致。

●　当前体系结构（Current Architecture）：表示企业或机构的当前状态。完整描述可能非常重要，应该小心维护。

●　目标体系结构（Target Architecture）：表示战略方向环境中企业的目标状态。

●　转换过程（Transitional Processes）：这些过程按照体系结构标准施行从当前体系结构到目标体系结构的变更，如不同的决策或管理过程、迁移规划、预算、配置管理和变更控制。

●　体系结构片段（Architectural Segments）：关注整个企业中的某个子集或较小的企业。

●　体系结构模型（Architectural Models）：提供在企业中管理和实现变更的文档和基础。

●　标准（Standards）：机构所采用的标准（无论是强制采用还是自愿采用的），包括最佳实践和各种开放标准，所有标准都是为了提高互操作性。

第二层在更详细的层次上说明了联邦企业体系结构的业务和设计方面以及两者之间的关联。业务体系结构和设计体系结构之间的关系是推/拉关系——业务推动设计以满足自身的需要，设计（即新开发的数据、应用程序和技术）通过支持业务运作来拉动业务到新的服务交付水平。

第一层所描述的8种元素在第二层中进一步细化，在更小的粒度上描述业务和设计。例如，在第二层中观察当前体系结构（Current Architecture）构件时，将关注当前业务体系结构（Current Business Architecture），它确定了当前设计所支持的当前业务需求。以及当前设计体系结构（Current Design Architectures），它定义了用于支持当前业务需求的当前实现的数据、应用程序和技术。对于第二层中的其他构件也可从类似的视角来观察。

第三层展开了框架的设计部分，显示三种设计体系结构：数据、应用程序和技术。设计体系结构进一步细化了第二层中列出的设计细节。下面是第三层中进一步细化的6种构件中的三种。

●　当前设计体系结构（Current Design Architectures）：用于支持当前业务需求已实现的设计。当前设计体系结构由数据体系结构、应用程序体系结构和技术体系结构组成。

●　目标设计体系结构（Target Design Architectures）：用于支持未来业务需求的未来设计。目标设计体系结构由目标数据体系结构、目标应用程序体系结构和目标技术体系结构组成。

●　设计模型（Design Models）：用于定义企业的模型。有数据模型、应用程序模型和技术模型三种类型。

第三层还提供了体系结构片段（Architectural Segment）、转换过程（Transitional Processes）和标准（Standards）这三种构件的更多细节。

第四层（最详细的视图）确定了描述业务体系结构和三种设计体系结构（数据、应用程序和技术）的模型种类。它还定义了企业体系结构规划。在第四层上，三种设计体系结构如何支持业务体系结构开始逐渐明确起来。在这一层上，FEAF确定了两种机制：FEAF矩阵和企业体系结构规划（Enterprise Architecture Planning，EAP）方法学。FEAF矩阵用于组织体系结构信息，EAP帮助定义什么样的体系结构适合特定的企业。

FEAF矩阵概述

FEAF提供了开发、维护和实现高层操作环境并支持IT系统实现的结构。这种结构根据Zachman框架来分类和组织企业的重要模型。Zachman Framework是1987年由John Zachman提出的，是企业根据总体信息需求评估软件开发过程模型完整性的一种方法。该框架为完整的体系结构提供了多种视角，并对体系结构产品进行了分类。Zachman Framework实际上是一个包括36个单元的矩阵，涵盖了企业中的谁（who）、什么（what）、何处（where）、何时（when）、为何（why）以及如何（how）。该框架把企业分解成6个视角（perspective），从最高层的业务抽象开始直到实现。该框架可以包含全局规划，也可以包含技术细节、列表和图表。任何适当的步骤、标准、角色、方法或技术都可以放进去。

FEAF关注Zachman Framework中的三个方面：数据（什么）、过程或应用程序（如何）和位置或技术（何处）。如图所示，把FEAF图形化表示为一个3×5的矩阵，体系结构类型（数据、应用程序和技术）是矩阵的一个轴，视角（规划者（Planner）、所有者（Owner）、设计者（Designer）、构建者（Builder）和转包者（Subcontractor））在另一个轴上。相应的EA产品列在矩阵的单元中。

图21-1提供了FEAF矩阵的综览，在第四层上描述了FEAF。该矩阵结合了5个视角行（即视图）：规划者、所有者、设计者、构建者和转包者，以及Zachman Framework中的前三个体系结构工件或产品抽象列（即什么、如何和何处）。FEAF矩阵也把视角或行称为视图，表示不同的抽象层次。此外，视角和焦点（列）的相交称为FEAF的“模型”。IBM Rational Unified Process也结合最佳实践为不同的项目干系人和需求提供不同的抽象层次。在RUP中，体系结构通过不同的视图来定义，每个视图都依赖于特定项目干系人所需要的详细程度。关键体系结构决策在每个视图中表示。RUP中的模型记录了所有做出的决策，包括体系结构上的重要决策。例如，用例模型可能包括25个用例，其中只有10个对体系结构非常重要。用例视图就仅仅表示对体系结构至关重要的那些用例。对于本文而言，FEAF模型和RUP体系结构视图是等价的。此外，RUP提供了一组一致的模型，把不同视图中的体系结构元素关联在一起。

图21-1　HL7消息发展体系（引自HL7 V3 Ballot7）

规划者和所有者这两行关注的是业务体系结构的定义和编档。这两行一旦完成，就明确了企业的业务是什么，以及用什么样的信息来控制它（即业务模型）。这两行被认为是基础，要开发能够共同理解并跨联邦企业集成的体系结构描述必须要完成这两行。

第三、四、五行（即设计者、构建者和转包者）定义了支持业务体系结构的设计体系结构（即数据、应用程序和技术）。根据特定体系结构的用途和目标开发这几行的适当模型。

每个视角和设计体系结构的相交（Intersection）所定义的模型，是及时管理和实现企业变更的基础。对于那些支持系统管理和开发至关重要的企业模型，该框架提供了分类和组织这种企业模型的逻辑结构。

使用RUP支持FEAF

Rational Unified Process主要强调的是软件系统。企业体系结构包括软件，但是还涉及到硬件、人员和信息。从FEAF强调数据、应用程序和技术设计体系结构可以看出这一点。本质上，企业组织可以看作一个包含其他系统的系统。虽然RUP确实讨论了如何表示软件应用程序的硬件、人员和信息，但是在解决系统问题时还有待于改进。为满足这种需要，RUP for System Engineering出现了，它是一个RUP插件，提供了新的和改进的活动和工件，增强了RUP的功能。它还提供了一组技术用于减少功能分解的必要性，从而使系统和子系统规格说明满足整个开发团队的需要。本文不再深入探讨如何在EA开发中使用RUP SE技术，但是讨论了构建EA时使用的RUP和RUP for System Engineering工作流的详细情况。

表21-1说明了构造FEAF矩阵中各种模型（或者RUP体系结构视图）时应该使用RUP和RUP for System Engineering的哪一部分。下面的矩阵简要定义了要捕获的体系结构视图，如何使用RUP和UML捕获这些视图，以及有关使用RUP的更多信息的RUP工作流和活动参考。体系结构视图不是互相独立的，而是一组一致且可实现的模型视图。

表21-1　FEAF矩阵中的各种模型描述

表21-1　FEAF矩阵中的各种模型描述-续表

结论

建立和管理企业体系结构所需要的业务模型和设计模型可以使用不同的技术和方法来完成。IBM Rational Unified Process提供了建立和维护企业体系结构的一组关联的最佳实践和方法。Rational Unified Process把不同的视角和一组实践活动，以及创建一组一致的模型所得到的工件结合在一起。模型的体系结构视图可以组织成FEAF矩阵。总之，使用RUP作为开发企业体系结构的过程框架，组织可以有效地捕获、审查、管理变更，并可在不同视角和组织之间沟通企业体系结构。

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

原文参见URL（http://msdn2.microsoft.com/zh-cn/library/ms954603.aspx）。

今天，由于商业与法律的需要，例如美国的健康保险便利和义务法案（Health Insurance Portability and Accountability Act，HIPAA）——卫生保健组织机构很清楚要与它们的商业结合起来。遗憾的是，大多数的健康信息系统一直是私人所有，而且在一个卫生保健行业它们只为一个部门服务。

Health Level Seven（HL7）是美国国家标准化协会（ANSI）认可的标准化开发组织中的一个，它正在全世界保健行业里运行着（Level Seven引用了开放系统互连模型OSI的最高层——应用层）。传统上，它从事临床建模与数据的管理工作，最近的一个版本——HL73.0版本扩展到了各种卫生保健行业，如制药业、医疗设备及成像设备。

HL7标准也指定了一些适当的信息基层组织，如Web Services，它就适合传送HL7信息，并且在应用软件之间对于如何确保这个信息的传送的交互性，提供了一个说明性的向导。将HL7应用软件应用在Web Services上，意味着首先设计一个正确的体系结构，其次是提供一个可执行的满足Web Services的环境。本文只是涉及HL7 Web Services Basic profile（HL7WSP）。

HL7模型概念

通过对HL7标准规格说明书以及本文以外的一些工具的描述，这部分将介绍一些主要的HL7模型概念和人工制品，这些都与我们的讨论相关。

参考信息模型

对于一个给定的卫生保健领域，HL73.0版本说明书是基于参考信息模型的（RIM）。这是一种公共的模型框架，包括病例模型、信息模型、交互模型、消息模型和实现信息说明书。

HL7的参考信息模型是一个静态的卫生保健信息模型，它代表了至今为止负责HL7标准发展行为的卫生保健领域的各个方面。HL73.0版本标准开发过程定义了一些规则，这些规则用于从参考信息模型中获取一些具体领域信息模型，从而在HL7规格说明书中使这些模型更精确，最后产生XML表单定义（XSD）与一个具体的消息类型联合起来。

消息结构

HL7应用软件之间的交互行为是通过消息的交换来完成的。这样，在提供envelopes支持应用程序之间的消息交换期间，这个标准就提供了一个真实的功能水准。HL7消息的封装被称为wrappers，最初是通过RIM中类的定义和关联模型化的。然后，这些说明书被用来为消息wrappers创建XML表单。接下来，在HL7消息开发框架中所列的过程在图21-2中有所描述。

图21-2　HL7消息发展体系——引自HL7 V3 Ballot7

所有的HL7消息都被放在Transmission Wrapper，Wrapper的目的是支持应用软件之间消息的传输（和确认）。Wrapper的重要部分是一些元素，如消息标志符、消息的创建时间、交互标志符、发送者和接收者标志符、确认编码和消息序列号（可选）。认为HL7消息是在合理的HL7应用软件之间进行交换这一点是很重要的。也就是说，特殊的软件应用或是组成成分（像“顺序实体”）都代表着有组织的或是可管理的实体（像西部医院登记一样）。所以，在传输层，发送者和接收者概念不会被看成是一个规格说明书的一部分。

交互

一次HL7交互就是信息特殊转移过程中的一次联合，一个触发事件就开始了消息的转移，应用软件进行接收和发送消息。在HL7里，一个触发事件是引起信息在应用软件之间进行转移的一系列精确条件，它也代表着一个真实的事件。例如，实验室顺序的安排或是一个病人的登记。

应用程序角色

HL7里的每一个应用属于一个具体的应用程序角色。根据一个应用程序提供给其他应用程序的服务或是一个应用程序为了获得特定的服务而发送给其他应用程序的消息，这样一个角色就体现了应用程序的职责。

Storyboard

像消息类型、交互作用和应用程序角色这些概念都集合在了一个HL7 Storyboard里，它是用来指定在HL7标准化行为范围内与任意卫生保健领域相关联的用例。

一个Storyboard是由一小段记叙了它本身的目的及交互作用图表的描述所组成的（在应用层）应用程序角色间相互作用的级数。就像图21-1中的那样，交互作用的图表指明了相应交互作用的职责（就是应用程序角色）、交换信息的类型以及期望的信息交换的顺序。

体系结构

基于刚刚介绍的HL7概念模型，现在我们能更精确地定义出HL7应用。这些都是在支持应用程序角色软件组成中的设计与实现，这些角色是作为交互行为中的一部分来实现发送者/接收者的职责，通过使用Web服务通信基层结构来满足HL7 Web服务的（如图21-3所示）。

图21-3　参考体系结构

在图21-3所示的结构里，能够抽象出HL7发送者/接收者内部的这两组功能：商业逻辑和Web服务适配器（需要强调的是，这里商业逻辑的范围是在HL7应用进行它们的发送者的角色和/或信息的接收者内部。也就是说，它支持一种具体的通信模式。应用层商业逻辑、消息的产生，或是为了响应需求而提供的具体服务这些都是在范围之外的）。

至于HL7消息的扩展，我们需要关注一下。商业逻辑的任务如下。

（1）发送端：创建一种具体HL7消息类型的XML描述，消息类型包含消息体、Transmission and Control Wrappers。将消息传送到Web服务适配器，适配器负责传送到接收应用端。

（2）接收端：“找回”由Web服务适配器接收的HL7消息，同时从接收到的XML消息那里打开Transmission Wrapper、Control Wrapper和消息体；验证HL7消息是否满足用来交互的商业规则和约束；核实发送应用端是否需要一个应用层的确认信息（HL7消息类型MCI）——如果是那样的话，发送那个消息。

Web服务适配器的功能主要是用来处理消息的分发和确认信息。因此，主要包括如下内容。

1）发送端

（1）读取接收到的HL7消息的Transmission Wrapper，以便决定如何到达Web服务基层结构上的发送容器（例如接收应用软件），从而配置SOAP。

（2）基于HL7消息类型、应用配置和规则（如安全性）来准备一个SOAP消息，包括作为一个SOAP消息体部分的HL7 XML消息，这个消息被发送到Web服务基层组织。

（3）把SOAP消息传递到Web服务代理，通过网络进行传输。

（4）无论发送端什么时候请求，都准备接收并存储来自接收端的相应信息或是应用层的确认消息。

2）接收端

（1）从Web服务站处接收SOAP消息。

（2）验证接收到的SOAP消息满足应用配置和一些约束条件（如安全性）。

（3）或者将这些接收到的消息在内存中以永久的形式保留。

（4）有选择性地从SOAP消息里打开HL7 XML消息，同时核对接收到的HL7消息是否与期望的HL7消息类型相符合。

（5）验证是否任意通信层的确认信息都需要被执行，在哪种情况下资金积累一个合适的消息发送到源消息发送端。

（6）传递HL7消息给接收应用端。

在适配器这层，这些情况都能够当作多个单行道方式或是请求/就答消息扩展模式来实现。在一个真正的实施过程中，适配器的结构也需要处理综合性应用和互操作能力。例如，如果一个应用业务逻辑不能直接与一个Web服务环境进行交互或是它被搭建在一个与以前实现时不同的平台上。

开发HL7 Web服务适配器

原则上，尤其是当范围被限制在只是支持HL7 Web服务时，开发HL7 Web服务就与开发普通的Web服务相类似了。事实上，RIM的标准化模型的有效性，消息类型的说明书，通信模式及Web服务都在一定程序上影响着开发过程。为了高效地开发HL7 Web服务适配器，需要按如下步骤来做。

（1）消息和数据类型的设计。在一个像HL7这样面向消息的环境里开发一个Web服务，必须首先设计可交换的消息、已用的数据类型以及XSD表单里它们的说明书。这项活动完全受益于HL7（使XSD表单自动化产生）所构造的消息和数据类型工具。

（2）适配器模式的选择。创建Web服务适配器的下一步是选择哪一个适配器结构模式能够最好地适合HL7通信模式，这个通信模式是由步骤（1）中所获得的消息类型来指定的。这一步要定义，比如说，一个（仅仅一个）代理/Stub组成成分是必要的。

（3）HL7 Web服务契约开发。从一个普通的角度考虑，在创建一个面向消息的Web服务的下一步就能够定义它的契约了，用一种标准化的可用计算机处理的语言称作Web服务描述语言，或者在支持Web服务标准的编程语言里实现它的开发。

（4）产生Web服务Stub和代理的实现。一旦WSDL契约完成，它就可能创建使用一些工具的Web服务Stub和代理服务器，这些工具是由像WSDL.exe这样的开发平台所提供的。

（5）开发适配器业务逻辑。这一步是建立在前一步代码生成的基础上的，添加了必要的逻辑来支持适配器的功能，这些功能在Architecture一节里已描述过了。

一个普通的WSDL契约都详细说明了一个Web服务的名字和端口，通过这些端口，Web服务器可以和客户端应用程序进行通信。一个端口指定了网络中服务生效的位置。每个端口也指定了端口上的一群有用的操作（portTypes），和客户与服务器在那个端口上进行通信的协议间的一个绑定。端口类型代表了暴露在Web服务上的各种接口。操作是接口的方法，它们定义了客户端请求服务端的输入信息，以及定义了服务器用于应答客户的输出信息。消息的格式也是基于WSDL契约中所定义的类型的格式（XML表单）。

案例研究

一个参考实现案例已经构建了，包括两个系统之间的交互：医疗信息系统（Hospital Information System，HIS）和实验室信息系统（Laboratory Information System，LIS）。

（1）HIS是由两个Sub-systems排序和报告组成的，为此应用程序和Web服务已经被开发。

（2）类似地，LIS是由Web服务和业务逻辑组成的，Web服务从HIS排序系统接收命令，业务逻辑是将确认信息返回到HIS排序或报告系统。

（3）这里，设想中用到的通信模式交换与前面所描述的“发送消息负载——附有确认信息——立即”是相符的。

（4）为了保持业务逻辑的简单实施，当允许一些用户与样品应用程序进行交互时，两个Windows客户应用程序必须被开发。

HIS客户应用程序发送命令请求给HIS Web服务器，并且显示发送命令的接收确认信息。它的用户界面允许用户发送一个命令（发送按钮），因为全球唯一的标识符（GUID）是由客户应用程序自动产生的。当HIS系统接收确认、信息确认和通信结果时，HIS客户用户界面也会通过LIS系统（用三个验证框：OrderAck、ActiveConf和Result）显示出来。

下面是用来交换HL7信息的逐步流程，这些信息存在于提前设想的模板的上下文里。

（1）当用户接口从HIS客户机那里收到信号时，HIS业务逻辑就会产生一个序号标识符，同时通过创建一个XML文件以及在HL7负载里加入一个序号ID来构造POLB 1N2120信息。

（2）业务逻辑发送一个POLB IN2120信息（Send Order）给适配器，通过它的代理服务（POLB AR002942服务代理）来调用LIS服务。

（3）在Laboratory端，POLB_AR002942 Service Stub接收到SOAP信息，同时使它对于LIS Web服务适配器是可用的。

（4）LIS适配器从SOAP信息里得到HL7信息（Order），同时依据HL7信息类型表单来验证从SOAP那得到的被封装的HL7负载。

（5）LIS适配器从SOAP信息里得到HL7信息（Order），同时依据HL7信息类型表单来验证从SOAP那得到的被封装的HL7负载。

（6）如果需要，它会准备确认序列，这个确认序列是通过构造一个XML文件同时在文件里附上一个预先定义的应答确认来实现的。

（7）当一个新的信息到达时，LIS业务逻辑重新从顺序队列里得到HL7信息，并且将信息发送给LIS客户端。

事实上，对于给定的应用程序角色和交互活动，可以构造一个能自动产生代码的工具，用这个工具来创建需求信息队列和存储引入的信息。这是一种用来构建Web服务适配器代码的方法（代码案例见原文）。

结论

在卫生保健领域，HL7是用来为协同工作而创建的基层结构。HL7使用参考信息模型（RIM）来获得具体领域的信息模型，同时把它们精炼到HL7说明书中，结合具体的消息类型自动产生XML表单定义（XSD）。因为能够被设计所公用，因此这些概念就对它们进行建模，而不是只集中在关于互操作能力的一些技术问题上。我们能够考虑说明书，同时知道如何构建一个应用程序软件，包括角色、协作模式和消息。

从理论到实践，HL7并没有告诉我们怎么构建和设计一些方案，而是当Web服务被用时，本文提到的参考体系结构就是一个相应的出发点。

以服务为中心的企业整合——案例分析

原文参见URL（http://www.ibm.com/developerworks/cn/webservices/ws-soi2/）。

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

案例背景

某航空公司的IT系统已有好几十年的历史。该航空公司的主要业务系统构建于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技术人员面临的企业集成问题。

业务环境分析

在航空业中，Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程，其流程图如图21-4所示。通常，每个航班都有一个人负责Ramp Coordination，这人通常称为Ramp Coordinator。由Ramp Coordinator协调的业务活动有：检查机位环境是否安全、卸货、装货和补充燃料等。

图21-4　设想的体系结构的模板

实际上，Ramp Coordination的流程因航班类型的不同，机型的不同有很大差异。图21-5所示的流程主要针对降落后不久就起飞的航班，这种类型的航班称为short turn around航班。除了short turn around航班外，还有其他两种类型的航班，如图所示。Arrival Only航班指降落后需要隔夜才起飞的，Departure Only航班是指每天一早第一班飞机。这些航班的Ramp Coordination的流程和Short Turn Around类型的流程大部分的业务活动是相似的。这三种类型的航班根据长途/短途，国内/国外等因素还可以进一步细分。每种细分的航班类型的Ramp Coordination的流程都是略有不同。

图21-5　Ramp Coordination流程图

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

服务建模

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完全可能通过自动化的系统实现。到那时，只需重新实现这个服务，而无需改变整个流程。这是服务的可替换性的一个典型实例。

IT环境分析

在构建Ramp Control系统之前，该航空公司已经有大量的IT系统。作为架构设计的重要步骤的现有IT环境调研，描绘了和Ramp Control相关的IT系统的状况，包括周围应用和应用提供的接口，这些应用和Ramp Control交互的类型和数据格式。简化的IT环境视图，描绘了Ramp Coordination流程和周围系统交互状况。目前，Ramp Coordination流程需要4种类型的外围应用交互。

（1）从乘务人员管理系统提取航班乘务员的信息。

（2）从订票系统中提取乘客信息。

（3）从机务人员管理系统中提取机务人员信息。

（4）接收来自航班调度系统的航班到达事件。

通过将主机应用中的信息集中为粗粒度的业务对象，并通过信息服务输出，为该公司的核心系统提供了更加通用的连接能力，同时为IT系统的平滑演进提供了必需的条件。

高层架构设计

据需求和设计阶段的业务模型和现有IT环境调研结果，再结合传统的IT应用开发方法，Ramp Coordination系统的高层架构被设计了出来，如图21-6所示。

图21-6　Ramp Coordination系统架构

如下4点简要介绍了本案例中的主要架构元素以及它们之间的工作关系。

（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），它通过MQ将事件传递给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设备，Ramp Coordinator通过PDA设备访问系统。

（4）企业服务总线中的传输服务。RCMS是即将新建系统，用于提供包括Ramp Coordination在内的Ramp Control的功能。RCMS通过由WSIF实现的Transport Service以SOAP/HTTP调用Ramp Coordination服务。

结论

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

网课

考点分析
做好准备工作
论文写作格式
如何解答试题
如何写好摘要
如何写好正文
常见问题及解决办法
论文评分标准
论文写作实战

论文写作注意事项

会出现的问题
- 方法
- 技巧
- 实践
- 缺乏理论和组织
- 偏题
- 缺乏实践
不要猜题

考试大纲

系统建模
软件架构设计
系统设计
分布式系统设计
系统可靠性分析与设计
系统安全性和保密性设计

图片详情

做好准备工作

检查考生是否具有参加系统架构设计工作的实践经验
检查考生 $\color{green}{\text{分析问题}}$ 与 $\color{green}{\text{解决问题}}$ 的能力，特别是考生的独立工作能力
- 讲清楚为什么这样做：如何分析问题、分析了哪些因素，做了什么决定，再去讲怎么去做的
检查考生的表达能力