本文来自于
Rational Edge：作者介绍了通过使用 IBM Rational 和 WebSphere
工具集，如何定制 IBM 针对目标行业的行业模型（Industry Model）以支持特定的业务需求。
本文概述了使用 IBM Rational 工具和 IBM 的行业模型（Industry
Model）来开发基于面向服务的体系架构（service-oriented architecture，SOA）的解决方案。如图
1 所示，IBM 的行业模型（Industry Model）是一组相关的模型，它描述了应用于关键行业，例如，银行业（Information
Framework，IFW）和保险业（Insurance Application Architecture，IAA）的应用程序和集成解决方案在分析与设计的不同方面。
这里我们特别着重于那些与 SOA 的分析和设计相关的模型，以支持组织的运作需求。
图 1： 与面向服务的体系架构相关联的行业模型
行业模型（Industry Model）被组织成为一组基础模型，它们作为其他产品构建所依据的标准分类。详细描述了支持组织业务所需的端到端过程的分析模型是源于这些基础模型的。同时，作为组织中
SOA 项目蓝图的详细服务分析和服务设计模型也同样源于这些基础模型。
很重要的是要了解 IBM 行业模型并不提供现成的解决方案。相反，这些行业模型是在任意一个问题域内任意一个组织细节的深思熟虑的抽象，并且提供具体过程和底层服务构建所依据的蓝图和标准。
一般来说，行业模型和企业建模的目标是在企业范围内提供一致的模式和工件。此建模方法大大地提高了生成真正可复用的基于服务的基础架构的机会。然而，它没有绕过软件开发的实现阶段。IDM（接口设计模型
—— 被给定的行业模型中的子模型）中描述的模式会为那些设法，例如，将现有的客户信息控制系统（Customer
Information Control Systems，CICS）事务的功能展示为更加可复用的 XML
消息的人提供非常有价值的指导。尽管如此，仍然需要存在编写面向商业的通用语言(Common Business
Oriented Language ，COBOL) 代码来将理想的 XML 消息转换为事务调用的工作。
每个独立的金融机构，当然，也包括机构中的每个单独的项目，会遇到一组与目标运作环境相关的截然不同的挑战。这些挑战的范围从现有系统和基础架构的局限性到所选解决方案的架构的难题。所遇到的在企业范围内部署
Web 服务的挑战与在企业范围内构建 J2EE 架构相关的挑战是不同的。
不论目标环境如何，行业模型支持基于需求的解决方案的识别、分析和设计。企业集成中基于技术的挑战随着所选基础架构的不同而变化。然而，获取和表示业务需求的挑战，以及从这些需求得到服务架构的挑战没有太大的不同，模型的目的是通过特定解决方案架构无关的方式来支持系统的基于需求的分析和设计。
此外，还要提供将模型工件转换并部署到具体技术领域的能力，例如下一个部分中介绍的业务过程执行语言（Business
Process Execution Language，BPEL）/J2EE 环境。
由于行业模型是由组织来定制的，因此假设在这样做时有某种方法学作为指导是合理的。然而 IBM 并不是想要试图取代详述了基于统一建模语言（Unified
Modeling Language，UML）的分析和设计优点的许多参考，但是行业模型附有一组推荐，详细描述了他们在基于
SOA 项目中的使用方法，这些推荐的高度概括如图 2 所示。
图 2: 行业模型定制化路标
简而言之，此方法着重于详细的过程分析，目的是识别出可高度复用的业务任务，而这些任务可能被作为服务的候选进行进一步探究。这提供了对每个服务环境的完全了解，以及可能的复用的可靠探究。
高可复用的业务任务被建模成为系统用例。通过对这些服务候选的输入和输出信息需求的探究，我们可以实现大规模的
3NF（third-normal form）类模型的发现和定制，这些类模型捕获与服务候选相关联的详细数据需求。
而这些用例是用于通过组件接口上的具体操作扩展设计级服务（组件）模型的。构建设计级 UML 模型来提供每个组件内部结构的详细定义和它们所展示出的服务。将该设计模型充分地形式化，以允许生成基于特定平台的组件（举例来说，Java
模型）或服务约定，例如，Web 服务描述语言（Web Services Description Language，WSDL）。
行业模型很好地适应自顶向下（Top Down）的分析和设计，推动了基于纯业务需求的服务定义。然而，当今很少的金融机构运作于“全部淘汰，重新构建（rip
and replace）”的基础之上，实际上，大多数组织都争取保留现有系统中相当多的投资，这驱动它们通过高度可复用的业务服务来展示出现有系统的功能。
明显的是，纯粹的自顶向下的方法在此场景中也是不理想的。已知现有系统的约束条件，只考虑纯粹的业务需求很可能产生不实际或不可能实现的服务定义。如图
3 所示，这常常导致组织使用自底向上（Bottom Up）的方法，当然自底向上的方法也有它自己的挑战。偏重于基于当今系统的已知能力来定义服务当然也可以产生可行的解决方案，但是，这种服务方法会今天已经被集成的系统更好地满足业务需求吗？
行业模型以纯业务驱动的方法开始 —— 分析将要成为过程的业务，并导出分析级服务的定义。然而，到设计时，必须考虑当今系统的现实世界的约束条件。我们所分析的服务现实吗？能够实际地构建它们吗？在大多数协商中，由于遗留的特性，在设计时会引入重要的折中。
图 3: 通过行业模型考虑解决方案的约束条件
这意味着行业模型趋向于既不遵守自顶向下，也不遵循自底向上的方法。相反，自顶向下的分析能够满足着重于解决方案的设计。存在着两个完全分离（但可追溯）的模型需要维护：基于需求的详细分析模型，和考虑部署环境约束条件的形式化的服务设计。
将这两个模型映射到真实世界的工具能力会形成图 4 中例举的典型项目路标。
图 4:行业模型工具全景
图 4 中概括的步骤的更完整描述如下：
- 根据已定义的项目范围，利用 IBM Rational RequisitePro 以半结构化的形式获取最初的业务需求。行业模型第
1 层的过程定义常常用于指导此过程，并用于确保标准术语的使用。
- 然后，这些需求用来驱动 IBM WebSphere Business Modeler 中行业模型分析过程的定制。这包括分析通过每个过程的数据流，获取跨所有过程的可复用的数据集合。这些过程模型由项目得出，并在企业级进行复查。将过程分析作为活动图导入到
IBM Rational Software Architect 和 IBM Rational Software
Modeler（RSA/M）以便于形成与现有企业级过程定义的可视化比较或合并。RSA/M 也包含从过程任务到支持这些任务的系统用例的映射。这些映射是用于识别受项目所影响的现有用例模型的子集的。
- 业务对象模型（Business Object Model，BOM）在 RSA/M 中由附加的数据需求和业务规则来扩展，形成了服务候选的完整分析模型。尤其是，执行分析来识别
BOM 模型中的类的最可复用的集合。这些集合与业务过程的信息需求紧密地结合起来，并且是在设计当中将可复用的
XML 数据类型形式化时所需要的。在通过企业范围的业务模型得到验证和合并之前，这个被完成的分析将从项目中获得。
- 在 RSA/M 中，此分析用于扩展行业模型的设计层服务定义（IDM）。典型的，包括扩展模型中现有的服务接口来提供满足所表示的业务需求的服务定义，与此同时，要注意现有的系统和其他的约束条件。此服务设计可以用于生成
WSDL 定义或其他服务描述。
- 分析级所获取的过程模型现在必须用于构建设计级过程。这包括考虑最终确定的服务定义，和其他设计级工件，例如
portlet、具体化的业务规则（externalized business rules），或人员交互（staff
interactions）。这导致了在 WB Modeler 中的详细的过程规范，同时考虑了可复用软件工件的定义和现有系统的约束条件。随后，此过程模型被用作
BPEL 生成的来源。
- 来自于 WB Modeler 的 BPEL 定义和来自于 RSA/M 的 WSDL 定义都需要被导入到
WebSphere Integration Developer（WID）中，以构建最终的解决方案。WSDL
服务被绑定到调用它们的 BPEL 任务上，按照需求，生成对任意 portlet、规则，或人员活动调用的其他绑定。
IBM Rational 和 IBM WebSphere 工具已经经过了多年的演进，来支持企业业务建模。现在，世界金融机构前十名中的七家都在使用
IBM 的行业模型来支持 SOA 或其他项目计划。企业建模和健壮的建模工具一起使 SOA 成为了现实。
| 
