为面向服务的解决方案建模

级别: 初级
Simon Johnston, 架构师，Business Level Tools, IBM Software Group
2005 年 10 月 19 日
本文来自于 Rational Edge：IBM Rational Unified Process Update for Service Oriented Architecture（RUP Update for SOA）与 UML Profile for Software Services 的 Rational Software Architect 实现的结合提供了建模方法，以及一组用于面向服务体系结构模型解决方案的体系结构和设计的最佳实践。本文描述了背景、范围和此新功能背后的一些概念。
三年前，我们这些处于 Rational Software Corporation 前沿的一组人坐下来撰写了一篇有关利用面向服务的体系结构（service-oriented architecture，SOA）式样 1 来开发解决方案问题的文章，并且从那以后发生了许多事。我们所面临的一个问题是 Rational Software 有一组建模工具，但没有 IDE 来实际地开发我们所建模的服务实现。随着 IBM 对 Rational 的收购，我们现在有了一个世界级的 WebSphere Studio Application Developer（现在是 Rational Application Developer，或 RAD）形式的 IDE。我们还面临着一个问题，许多关于 SOA 的思想都不成熟，并且许多是被错误驱使的 —— 一个我们在文章中考虑的问题。既然支持 SOA 的 IBM 平台已经相当地成熟，并且我们的开发工具已经增加了按照灵活快捷的方式开发服务的功能，我们决定再次访问我们在前面文章中概括的服务设计的概念。
此讨论的结果是一个新的理解：我们的价值不是在表现 WSDL（Web 服务描述语言）和 XML 的所有三角地的模型开发，而是允许设计人员和架构师用恰当的功能指定恰当的服务并实现 SOA 式样的潜在益处。 此理解将我们引向一些长远的讨论，这些讨论是关于 1) 用来表现服务模型的恰当抽象级别，和 2) SOA 式样的开发影响 Rational Unified Process®，或 RUP® 的方式。
本文的前三分之一介绍了我们为变更所设置的范围，包括我们所关注的需求。接下来我将描述一些关键的主题，我们将这些主题用作对 RUP 的变更框架，及用于支持面向服务的解决方案开发的 Rational Software Architect（RSA）补充。最后，我将描述一些在我们的思想中使用的情境，这些情境随时间得到了改进，但还需要一些关键客户的验证。
我们决定不仅开发一个新的用于 RSA 的建模概要文件，还要开发添加到 RUP 中的指导，为帮助实践者在预想和开发面向服务的解决方案中实际地使用工具。
然而，众所周知，对于任何项目最关键的方面之一是设置恰当的范围：太小，您就会做出对任何人没有实际意义的东西（除了可能能够拿出您自己的要获得利益的目的），太大，就很可能要煮沸整个海洋。所以我们建立了以下标准：
我们开发的模型必须要处于当前实现技术和标准之上的抽象级别上（WS-* 规范，就是各种 Web 服务规范），然而，还要将 SOA 的概念作为头等的要素。
结果的模型必须是可扩展的，可以考虑到相关的额外规范，如安全性、服务质量，可管理性，等等。
模型必须在 IBM Rational Software Modeler（RSM）和 IBM Rational Software Architect（RSA）中实现，最初作为一个 UML 概要文件。
指导不得不向基础 RUP 添加具体的 SOA 概念。然而，我们想要在现有的 RUP 中利用尽可能多的东西，因此，为了使更新很容易地添加到现有的 RUP 配置中，我们最初选择不改变任何存在的东西。
我们的工作应该考虑在提供 SOA 指导中 IBM 已经完成的工作，如 IBM Global Services SOMA 技术。 2
因此我们定义了一组三个可交付使用的标准，每一个都可以从 IBM developerWorks 中得到：
描述 UML Profile for Software Services 的文档， 3 它依照的是 OMG 概要文件文档的式样。
实现 UML Profile for Software Services 的 RSM 或 RSA 插件， 4 它使模型构建于工具之中并符合上面的概要文件。
包含了所有关于 SOA 体系结构 5 和设计主题指导的 RUP 插件，它提供了关于依照上面的概要文件开发服务设计模型的具体指导。
幸亏 RSM 和 RSA 工具具有可扩展机制，我们才能够不仅交付 UML Profile for Software Services，还交付一个模板模型（当您选择 File -> New -> UML Model 时可用）和两个添加到 Sample Gallery 中的示例。
这是我们考虑的一个合理的标准集合并可以交付。所以让我们看看在 2005 年 5 月 IBM developerWorks 中实际交付的内容。


首先，什么是 SOA？流行着许多定义，但让我们以一个软件工程师的角度去看，简单地说 SOA 是一个“体系结构式样”的实例。这又引出一个问题，什么是体系结构式样？这里有一个来自 Roy Thomas Fielding 的很好的定义：
体系结构式样等同于限制体系结构要素的作用或特性及任何体系结构中符合该式样的那些要素之间的容许关系的体系结构约束。 6
举个例子，一个已编制的体系结构式样是管道和过滤器样式，它包含了将管道作为连接器来关联过滤器的独立的要素。在管道连接的两个过滤器之间存在着数据类型必须遵照的具体的约束，且存在着一些令式样适应于某些环境的特征。
知道了这些，我们可以开始列举 SOA 的体系结构要素，以及具体到其式样的关系和约束。有了这个有用的体系结构式样的定义，Fielding 还提供了一个非常及时的建议：
设计这个强意词是普遍发生的。至少软件行业中的某些此种行为还缺乏对为什么已知的体系结构约束集合是有用的的理解。换句话说，在选择复用那些体系结构时，好的软件体系结构背后的原因对设计人员不是显然的。 7
我们希望通过提供 RUP 中的具体附加内容集的简明及时的指导来缓和此精确的行为。此指导描述了体系结构的式样、要素和关系，以及在整个开发生命周期中他们是如何被识别、指定和管理的。同事还要注意，通常体系结构的目标，特别是体系结构建模，提供了一个适当的抽象级别，在此级别上，可以容易地识别体系结构的要素，并且在不隐藏那些应该添加到针对实现更低层细化级别的细节的情况下，对要素进行控制。
在下面几个部分中，我们将讨论针对 SOA 的 RUP 更新中的一些关键主题 —— 特别是，要素、关系和每个主题引入的约束。
我们的标准规定，关键的 SOA 概念必须作为头等要素通过模型表现出来，因此这些关键的概念是什么？如您所预想的，其中一个概念就是服务本身，然而，与其作为模型建立的中心，还不如实际地成为次要的要素（不是重要的，但作为模型的要素，因为它不能独立存在）。要构建一个表现 WSDL 所定义服务的服务模型，我们必须首先开发服务规范以及服务供应商。
服务规范有三个规范要素，所有都同样重要，虽然在某种情况下，根据服务的建模类型可对它们进行选择：
结构规范。它可以用标准的 UML 或 Java 接口考虑。其定义了可以调用的操作和由这些操作销毁或创造出的消息。
行为规范。它表示出服务客户和所指定服务之间的任意预期的有意义的协议或会话。例如，服务也许要求您在调用另一个操作之前先登录，这称为伪对话服务。服务也许还要求客户实现特殊的接口，以便接口可以被回调，且协议可以展示这点。
策略规范。它表示服务的策略主张和约束。策略主张可能包括安全性、可管理性等等。
那么，例如，如果我们设想一个订单管理服务，我们也许期望看到列出“下订单”、“取消订单”和“更新订单”作为可用操作的结构规范。此订购服务的行为规范可能会说明，您如何不能更新或取消没有订购的订单，或者在您取消订单之后就不能再对其更新。最后，策略规范可能要求加密订单的某些要素，指示要使用的加密技术、要使用的证书等等。
我们在 RUP 中已经交付的指导的一个方面是一组技术（新的行为识别服务中进行了描述），用来从业务过程模型、用例或现有的各种清单资产中确定服务。这种行为和这些技术集允许架构师和设计人员制造出候选服务模型，这些模型是经常用于描述用来实现过程或需求集的“理想化”服务的服务规范。
我们介绍术语“候选服务”，因为许多这些服务经常不得不被重构来 1) 符合现有服务，2) 适应现有功能体系结构的框架，或者 3) 被分开以考虑更细致或并行的开发。
SOA 式样解决方案的开发的一个主要优点是在开发一个应用程序时（收集需求、设计并实现解决方案，且管理项目），不用将应用程序作为一个固定的边界考虑。在 SOA 中，我们看到的应用程序是一个动态的实体，一个满足特殊业务需求集的服务配置。要达到这种状态，我们显然需要在企业中设计、实现并管理作为可用功能组合的服务集。
该需求就是为什么我们指定前面提到的新的识别服务行为的原因。我们不仅是在识别候选服务时考虑组合，我们还由服务的原始形式进行重构以适应组合中服务的形式。该级别的复用不仅应该得到设计工具的支持，不仅应该得到关于服务组合的信息存储库的支持，还应该 —— 最重要的 —— 得到以恰当的方式开发恰当的服务时指导参与者的过程支持。
这确实导致了一个特别的问题，在传统情况下，我们关注软件开发生命周期，视其为一个由项目限制时间的过程，项目受到解决方案的某些离散部分的开发时间的限制。就服务组合本身而言（关于已安装的服务的元数据和考虑复用的设计模型的组合），我们看到这样一个生命周期，它横切了使用它并对它做出贡献的单个项目，如图 1 所示。

图 1：服务组合生命周期
图 1 所示的服务组合管理过程是一个不断进展的活动。注意单个项目与服务组合交互的方式，在项目的细化阶段从单个的项目中提取需要组合的服务，在项目的构造阶段组合的服务被实现。
不管多大规模的模型（或实际上是要素的任意集合）都存在的一个问题就是如何管理模型，如何对要素分类，以及如何以任何检查模型的不同涉众都可以理解的方式来组织要素。
服务模型的此种结构在服务的识别和服务的管理过程中变得重要起来。让我们暂时考虑 UML 1.x 中的模型管理 —— 包 —— 的典型方法。关于包的问题是它们通过所有权或聚合来管理模型要素，换句话说，一旦将一个要素放入单个的包中，不同包中的要素可以对其访问但不能将其“放置”在一个以上的包中。此刻，对于我们这些具有程序设计语言背景的人来说，这似乎不是主要问题，它反映出包、模块或命名空间在语言中工作的方式。
然而，我们真正需要表示的是模型的视图，因为对业务所有者有用的结构集合不同于软件架构师、设计人员、开发人员、操作人员等所需要的集合。出于该原因，我们推荐不要将包作为管理模型视图的主要机制（不是说包中不出现服务，只是说包应该用于模型的更平凡结构）。取而代之，我们指望 UML 2.0 规范的复合结构概念，其提供了表示使用“部件”和“连接器”的分类器的内部结构功能。
我们利用这些技术划分所管理的服务，换句话说，根据逻辑分类方案进行组织，不需要让服务所属于任何一个分区。例如，我们可能有两个不同的组合视图：一个表示不同的业务线，另一个表示提供服务的应用程序“类型”，如图 2 所以。

图 2：根据逻辑分类方案利用分区进行组织，不需要让服务所属于任何一个分区
注意，相同的服务（较小的方框）出现在一个以上的分区中（较大的方框），顶部的三个分区表示业务线，且底部的三个表示应用程序类型。从此处我们可以看到，虽然业务的供应链拥有并管理着 Shipping、Validation，和 Warehouse 服务，但我们可以看到 Shipping 服务由 ERP 包提供而 Warehouse 和 Validation 服务是定制开发的。
该技术不仅在管理已开发的服务集方面体现价值，还在服务的识别过程中体现价值。分区可以用于表示服务分组，并作为服务规范进行开发，可以将服务放置于不同的分区中以可视化关系和它们之间的依赖。


对 SOA 的 RUP 更新已经在许多（和谐的）地方得到扩展，以提供关于体系结构开发和面向服务解决方案的设计模型的具体指导。但 RUP 的许多领域仍旧不受到该更新的影响。例如，我们在早期决定的更新的开发，尽管一些行业作家已经引入了支持 SOA 的新开发角色，但我们相信当前 RUP 的Software Architect 和Designer 角色对于我们所需要的更新是足够的。
在更新 RUP 以引入对于 SOA 解决方案构建的指导的过程中，我们只添加了以下两个新活动：
识别服务。由 Analysis & Design 和 Refine the Architecture 工作流中的 Software Architect执行。
服务设计。由 Analysis & Design 和 Design Services 工作流中的 Designer 执行。
识别服务活动是软件架构师在概括解决方案的体系结构时所执行的一个活动，活动的输出是服务模型。该服务模型中包含一组已识别的，已经是候选的服务，这些服务要作为服务设计活动的一部分由设计人员进一步细化。
更新将整个服务模型（表示 UML Profile for Software Services）和其附属的要素引入到 RUP 中。模型表示面向服务解决方案的体系结构抽象，该抽象使软件架构师和设计人员在这样一种环境下开发模型，在这种环境下，服务的概念和对 SOA 的具体关注是头等的模型要素。模型不直接表示任何实现技术，如 WSDL。

图 3：UML Profile for Software Services
除了在服务模型中描述工件的具体内容，更新还包括与上面描述的主题相关的概念以及在开发 SOA 模型时反映对重要性所关注的额外的指导方针。这些关注包括：
消息设计和消息附件。设计消息，管理可复用的消息目录和消息方案的一致性。
服务数据封装。围绕服务中数据管理的服务设计特性和数据方案与服务边界之间的关系。
服务仲裁。有关一般作为 SOA 式样一部分（特别是 Enterprise Service Bus，或 ESB 视野）的仲裁组件的概念的具体指导。
状态管理。对有状态和无状态服务的优点的讨论，包括对于规范的技术和管理资源状态的服务设计。
我们还提供了指导方针 Going from Services to Service Components（从服务到服务组件），其论证了从服务设计模型到传统的设计或实现模型的一种可能的变换。
更新还包含两个报告描述，描述创建服务模型的 RSA 工具指导者，和表现服务模型开发的相当完整的实例。


IBM Rational Software Modeler 和 IBM Rational Software Architect 的新插件（今后称为 RSM 或 RSA 插件）提供了 UML Profile for Software Services，一个您可以使用的模板模型，和一对论证概要文件使用的示例模型。该插件可以在 IBM developerWorks 下载，并可以利用标准的软件更新机制将其添加到工具中（注意下载的压缩文件表示一个存档更新站点）。
在 RSM 或 RSA 中，在软件服务的插件安装完之后可以很容易地创建新的服务模型。以下的步骤是必要的（注意是在 Modeling Perspective 中）：
如果在您的工作区中已经有了一个 UML 建模工程，您可以将服务模型添加到该工程中或创建新工程（参见步骤 2）。
右键单击工程并选择 New -> UML Model 或者在 File 菜单中选择 New -> UML Model。
当您看到 New UML Model 向导时，如图 4，转到步骤 3。
要创建新的 UML 建模工程，到 File 菜单中并选择 New -> Project，UML Project 处在 Modeling 目录下面。
在结果向导中，给出工程的名称并选择 Next。
在 New UML Model 向导中，如图 4 所示，确保正确设置了目标文件夹，从模板列表中选择 Service Design Model，并给模型命名。

图 4：New UML model 向导
这将创建并打开带有 UML Profile for Software Services 的 UML 模型和一个模板结构，您可能由该模板结构开始为 SOA 解决方案建模。模型还包含一组可以在创建一些复合要素时有用的可复用模型要素，至少使用这些要素要比手动创建更简单。


以下的部分概述了我们从与客户的讨论（不论客户认为面向服务的解决方案的开发如何适应他们的软件开发生命周期）中总结出的三个情境。我们先认明三个开发服务的方法，而它们当然不是不相容的（真实的工程使用技术的组合），它们在阐明不同方法和思想方面是有用的。
在任何可能的地方，我将把在这些情境中描述的任务与 RUP 中定义的结合起来。
在消息为中心的设计中，焦点在服务领域中。例如领域工程或面向对象分析和设计（Object-Oriented Analysis and Design，OOAD）的技术提供了许多对抽象领域模型开发的洞察，并且这些技术通常生成对应消息方案的高度可复用模型。服务设计常常是次要的活动，尽管有时候并行地完成。例如，在电子数据交换（Electronic Data Interchange，EDI）中，不存在真正的服务接口概念，因为 EDI 系统通常有一个单个的全球的消息收件箱和发件箱。
该方法的一个实例可能是在传统的B2B 环境中，以 EDI 标准化作为代表。在此种情况下，主要的设计活动涉及开发某些行业或其他范围内取得一致的消息方案，这被认为是表示一类消息的方案 —— 例如，EDI 8 Purchase Order、ACORD 9 Claim Inquiry，或者 SWIFT 10 Credit Transfer。
在许多现代标准活动中，如 SWIFT 或 RosettaNet， 11 经常存在一个用于标准的设计过程，包含了一个混合的以消息为中心并以服务为中心的方法，在该方法中使用了如用例分析的技术。
在此实例中，客户是一个大的保险供应商，开发新的应用程序以支持其中一条业务线。在该公司中业务和 IT 支持之间的结合相当的好，且严密关注通过 IT 传递到业务的价值。
此情境中的项目扩展了两个索赔处理系统，以便两个系统可以提供将要启动策略集成并使公司收回一个系统并将所有索赔处理系统移到一个单个的系统中的面向服务的接口。
业务人员希望服务能够支持一些现有的业务过程，但他们清楚地知道这些过程随时变化，所以将服务与过程结合是不切实际的。作为回应，该业务领域的软件架构师相信更加适合的方法可能会集中于过程中的业务工件，主要是索赔本身。除了这些，他们已经在 IBM IAA 中投了资， 12 这为工件提供了定义良好的且标准的模型，如索赔。
在这点上，对于主要工件的实际数据模型已经由 IAA 指定，所以主要的工作是理解在当前系统中使用这些工件的方式及围绕着不同的实现如何开发新的外观。
业务分析人员开始编制需求，还利用业务过程模型来描述系统的功能需求。非功能需求在需求数据库中进行描述，依附于业务过程模型中的任务或项。过程模型是为两个当前系统和两者的交集开发的。
软件架构师拿到了这些模型和需求并与业务分析人员一起开发集中于两个系统间一般工件的流程的更具体的过程。软件架构师还与业务分析人员一起理解当前系统的数据需求及它们到 IAA 数据模型的关系。
数据架构师与软件架构师一起描绘出针对新的过程中工件的逻辑和物理表示的方案。
软件架构师开发了一个将过程活动划分成一组服务操作的候选服务模型。该模型还包括每个服务的消息需求及这些消息到下面的数据模型的关联。
软件架构师与集成专家一起（不是通常的 RUP 角色，但对应该角色的描述是为 RUP 设计的）定义从候选模型到当前实现所需的映射（在它们存在的地方）。这些映射将在所选的中间件中实现，但不应该像引入主要性能问题那样麻烦。
在此方法中，设计人员牵扯到展示（作为服务或一组服务）预期的业务或应用程序的功能。在此种情况下，我们不必要知道服务的客户会选择什么来利用服务，但我们知道此种客户期望的交互类型。因此，与第一个情境相反，消息是次要，并且被作为对操作的需求响应被开发。
该方法的实例是由 Amazon 和 eBay 表现的 Web 服务 API（Web Services APIs presented by Amazon，AWS） 13 。此服务接口没有将业务过程强加于客户，一般地，它们甚至没有将所期望的接口强加于客户，但它们使第三方开发人员以清晰直观的方式接触到了各自的服务供应商的操作。
如前面所提到的，以服务为中心的建模通过了解参与者的需求（服务的外部客户）并提供支持那些需求的操作（浏览目录、向购物车中添加物品、付账等）有助于用例驱动的方法。
成为次要关注的消息的问题在 Amazon API 中是明显的，在 Amazon API 中肯定能够将普通的方案定义从当前设计中分析出来，这证明消息是为每个操作请求和响应而分别开发的。
此处我们的实例是一个为化学加工行业提供零件的在线供应商。商家可以提供一个 Web 门户，客户可以通过该门户购买零件，商家还可以通过电话和传真管理进一步的业务。但需要为客户提供通过比 Web 本身更程序化的方法对购买门户进行的访问。这种对核心订购功能的访问使公司成为客户供应链中的关键要素，一个可以直接与客户核心业务应用程序集成的要素。商家试图实现 EDI 购买解决方案，但初始部署的成本和必要的基础结构证实是不可行的的。执行团队相信许多客户正在向其他的能够提供此种购买门户的供应商转移，因为这些竞争者已经能够通过更自动化的过程更好地集成。
与我们的第一个情境比较，此项目由 IT 组织推动。以一个商家的观点，项目目标是简单地提供一个机制来执行同样的订购操作，不需要让客户花时间将数据输入到 Web 门户或者商家输入来自传真订购清单的类似数据。IT 组织被允许独立做出许多决定，只要能够生成比前一个 EDI 尝试花费少的解决方案。
两个重要的影响设计的观察已经由 IT 组织的高级团队做出来了。
提供的功能必须不得少于通过 Web 或人工订购提供的当前功能。
操作集不是由我们的业务过程所推动，而是由客户所使用的，作为他们过程的一部分。针对该原因，我们必须假设关于这些操作使用的可能性越少越好。
软件架构师生成了一组描述客户所期望的功能的用例文档，并且确保业务团队同意。然后用例被断成一组离散的操作，且数据需求（消息）被指定。这些操作集合成一组三个用于搜索、订购和账户管理的服务。此步骤倾向于受到经验和判断的影响比受到精确的规格影响要多，因而此步骤是迭代的。
一旦知道了服务和操作集，团队就可以更加正式地定义服务规范，包括针对每个接口的协议和服务客户所需要的任意策略信息。该步骤非常的重要：它向客户提供了在服务可用时，不能够通过简单地阅读由商家部署的 WSDL 就能够被理解的信息。
业务执行者（不是当前的 RUP 角色，但似乎我们都承认他们）传达了这样一个需要，就是当客户感觉他们的收入正在被当前提供这些功能的更大的供应商抢走时，必须向客户提供可编程访问业务服务的能力。
软件架构师打算开发一组提供 Web 订购系统的核心功能的服务。提议包括一组用例，描述了客户通过 Web 执行的活动（与来自在线业务的业务分析人员一起开发）。同时也包含了初始阶段的模型，这个模型展示了对于当前后端系统的候选服务和他们之间的关系。
软件架构师，赞成该项目，迭代候选服务模型以在后端应用程序分区（公然地展示所需的业务功能以支持服务）中识别服务。同时，软件架构师让设计人员观察当前的 Web 应用程序及如何与后端系统交互，挖掘出要由服务实现的任何所需的业务逻辑和需求。
软件架构师和业务分析人员一致同意把所需的功能集作为服务执行的操作和任意所需的约束或策略来提供。此模型的迭代显示了三个具体的服务和初始服务规范，尽管在过程的这一点上这些只指定了服务的结构方面。
软件架构师与 Web 应用程序团队的开发人员一起了解对于已识别的操作集的具体数据需求。这被交给了具有 XML 技术的数据架构师，来开发将会生成由操作销毁和生成的消息方案的消息模型。
设计人员可以开始连接服务模型和将用来描述提供业务逻辑的组件的实现模型（J2EE）并连接到现有的后端应用程序。
软件架构师和设计人员最终用细节根据服务规范细化了服务模型，主要提供可以使客户了解如何与服务交互的协议和策略细节。
我们现在有一组完整的模型：
描述客户期望的用例模型
描述客户视角（服务规范）和供应商视角（服务、分区等）的服务模型
描述实现服务规范的软件组件的实现模型
现在开发人员能够实现准备由客户使用的试验系统。
在成功部署试验工程之后，要注意的是，向客户提供的服务涉及 Web 系统特定功能的并行实现。建议建立新的工程来重新配置 Web 应用程序以复用这些服务，这项工作应该包含于 Web 应用程序的常规计划更新中。这样的重配置将某些业务逻辑从 Web 应用程序中移到服务中，因而一个单独的组件集合由基于 Web 和服务的客户使用。
为了满足 Web 应用程序团队对性能的关注，除了向合伙人提供的 SOAP/HTTP 绑定之外，服务还需要被重配置，以在 Web 应用程序中访问服务时，服务能够提供更有效的 Java 绑定，。
在协作为中心的方法中，重点是两个或多个服务的协作，这是服务的过程视角，它与传统业务建模的相关性要比与软件开发活动的相关性更大。在此方法中，服务作为协作中的实现角色，因此服务规范成为为跨一个或多个协作的角色而定义的责任。
这样一种方法将对那些涉及到 RosettaNet Partner Interchange Processes（PIPs）的开发和 OAGIS 14 标准的开发中的人是可识别的（然而，在这些情况下协作远不完全）。这样的方法在业务中对于业务过程设计或在业务集成活动（在活动中 IT 系统的组件作为服务出现）中而言是普遍的。
通常在这样的情境中，服务规范可能直接源自协作，而该方法倾向于较少关注于导致需要实现完整性的混合方法的消息内容。
此情境涉及一个已经决定通过收购而继续扩充策略的中型银行企业，这意味着对于该企业来说，IT 不只是一个必须拥有的部分，而且还是在吸收所收购操作过程中发挥竞争优势的业务的一部分。
银行已经开发了一个领先的得到谨慎管理的组合，以确保成本和功能的效率。然而，很清楚的是某些技术和文化方面的阻碍出现在视线中，在整个企业中提供应用程序的一般集合。由于这些阻碍，公司已经决定使用服务方法来提供它们的 IT 功能并以此式样开发所有的新功能。企业已经经过多年开发了一套以过程为中心的东西。这些很好理解，一般的过程使它们有效地集成所收购的企业并指导他们的 IT组织来支持这些过程。
在我们的情境中，银行将一个遗留应用程序引入了服务组合中，这给我们提供了一个机会来观察帐户统一的过程模型，即一个令企业帮助客户有效利用帐户的业务服务。此过程模型已经由许多“黑盒子”活动设计而成，意味着一个活动通常由一个没有作为服务组合的一部分而启动的系统执行或者以还没有细化的方式执行。模型将这些活动表示为“黑盒子”并不提供更多的细节。团队已经注意到特定的遗留应用程序系统参与了帐户统一过程的三个活动，且其他过程模型的分析揭示了使用同一应用程序的两个其他的过程。
在企业所依靠的方法中，过程模型是分析和需求收集的主要工件。过程本身表现出通过 IT 和相应的人员，业务功能需求的完全体现，附属的且正式定义的文档描述了非功能的需求。在配置管理之下这些过程模型得到了小心的维护，并且为每个操作过程而发布，这样它们不仅指导过程的开发还为过程中的银行职员培训提供了材料。
早期提及的服务组合是一个 RAS 15 存储库，其考虑了基于由每个资产中的 RAS 名单所定义的标准的搜索。资产是所部署的服务，而名单包含了描述服务的核心组合及描述业务信息（如所有权、策略等等）的范围。
在开发服务以提供遗留应用程序的功能过程中，包含了业务和 IT 代表的团队致力于作为业务过程实现的服务之间的协作。该方法使业务端将结果看成是传统的业务过程模型，而 IT 端将同样的模型看成是服务之间的协作。
业务分析人员要么创建新的业务过程模型，要么更新现有的业务过程模型。此模型是按照商家所展望描述的新过程，该过程更新还包括由过程活动管理、消除或产生的业务文档定义。软件架构师创建了差距分析文档，这个文档对新业务过程的需求和现有服务组合进行了比较。
业务分析人员将关键性能指示器（Key Performance Indicators，KPI) 16 定义为业务过程本身的一部分。这暗示着参与过程的服务必须支持可以查询的用来确保与 KPI 的一致性的度量。
数据架构师改进来自业务过程模型的消息定义，确保与现有方案的通用性，然后开发可以用于生成服务所需的 XML 方案的消息模型。
软件架构师用新的服务或向现有服务中添加新的规范来更新服务模型。数据架构师开发的消息模型用于（或复用于）这些服务规范。
软件架构师和业务分析人员更新早期定义的过程模型以将活动映射到新的或更新的服务上。对于服务更新，模型是完整的了，现在就可以对其进行转换并发布。
软件架构师和设计人员开发了包含协议和策略信息的具体服务规范。这样一个具体的规范作为供应商和客户之间的合约，不能由任何一方打破。
开发人员创建针对遗留应用程序的适配器和/或变换，用来实现具体的规范。
开发人员必须开发用于监控的度量生成器。这些通常是具体的操作，需要监控基础结构来查询对应一般状态和度量状态的服务。
集成专家使用新的服务来更新过程的编排 —— 在此种情况下，业务过程被转化为编排语言，业务过程执行语言（Business Process Execution Language，BPEL）。在某些情况下，在部署之前还要用一些额外的信息更新生成的编排。
业务分析人员用业务 KPI 定义和它们到具体度量的关系来更新监控中间件，以便可以监控新的服务。


IBM Rational 团队已经与许多客户一起工作，并在IBM 的内部项目中展示并使用了 RUP 和 RSM/RSA 插件。我们已经收到足够的反馈信息，通过这些信息我们得知尽管我们还有许多事情要做的，但我们已经建立了良好坚实的基础。现在我们正致力于一组具体的工程，其设计用来延伸我们所做的工作，并且了解我们可以在哪里添加更多内容，特别是在用于建模工具和额外的 RUP 指导主题的策略规范的领域。
_xyz