将SOA实现的技术与业务方面相结合(3)

　　治理

　　尽管治理在分布式体系结构的构造和管理中并不是新概念，但从失败到成功实现或遵循治理的经验使其在 SOA 中的重要性得到越来越多的重视。

　　早期一些使用共享库(如 Microsoft® Windows® 动态链接库)造成的混乱局面就是此领域缺乏治理的结果的一个例子。Windows 构建于大量 DLL 之上，DLL 是系统级别的公用功能库，在运行时供很多使用者动态地访问。桌面应用程序也可以使用这些 DLL，而且根据操作系统的当前路径级别等因素，可以在安装应用程序时引入这些系统 DLL 的新版本。

　　您需要仔细分析更新共享 DLL 的版本的影响，因为所造成的错误的影响将非常广，而且难于定量。您需要保留接口，弃用所建议的退役 API，向相关受众发布关于功能更改的信息，并在发布前使用新版本测试依赖于库的当前版本的应用程序和 DLL。

　　如果没有进行这些必要的工作，则很容易发现陷入循环依赖关系的网中，发布一个 DLL 可能会修复一个问题，但最终会带来两个新问题。

　　SOA 尝试通过将培训与管理技术结合来处理治理共享服务的类似问题，通过 SOA 卓越中心(Centre of Excellence，CoE)概念提供流程、模板和最佳实践。CoE 提供治理中央机制，控制 SOA 生命周期的所有方面，包括以下内容：

• 开发过程
• 运营问题
• 服务所有权

　　这以传统的基于项目的设计权威角色为基础，但将其提升到了企业级别，提倡跨所有 SOA 项目的重用、一致性和标准化。

　　客户案例研究

　　虽然 SOA 肯定可以应用于新项目开发，但可能在再工程领域才是它发挥自己最大效力的地方。下面的案例研究给出了很多现有 IBM 客户面临的一个业务问题，这同时也是迅速发展的组织所经历的典型问题。这通常会导致业务需求通过涉及调配具体系统的战术 IT 活动实现，而非战略企业级的计划。SOA 的引入提供了在经历了这样的发展之后将 IT 与业务相结合的机会。

　　问题

　　客户的业务非常依赖于自定义的现成产品来进行电信运营。客户的基础设施中的每个应用程序在彼此独立的情况下都能正常工作，但由于缺乏企业视角而导致这些产品之间集成情况糟糕，从而出现竖井 (silo) 情况极为严重的局面。从 IT 角度而言，这并不一定是个大问题;每个系统都正常工作，似乎都在管理着一个业务流程。不过，这些流程实际上只是子流程，均参与到跨多个业务部门的较大事务中。

　　由于这样，会给用户带来以下影响：

• 多次身份验证：用户需要维护多个运营系统的多个登录凭据。
• 集成情况不理想：相关处理系统之间没有或仅有很少的自动化;在存在集成的情况下，也是使用不灵活的专用 API，而这意味着要进行更改非常困难。
• 手工处理：由于缺乏集成，因此存在大量的手工活动，导致出现数据重复，而且需要手动进行协调。
• 数据不一致：手动干预不可避免地会导致生产系统间出现不准确的数据表示形式。
• 可见性差：缺乏整套业务流程，意味着很难生成准确的 MIS 信息。

　　此案例研究的重点在于上面问题中重点涉及的以下三个运营系统间的集成：

• 订单管理系统：用于记录和管理客户订单
• CRM：作为客户信息的主要来源
• 供应系统：用于激活客户所需的网络服务(即漫游、3G 等)

　　每个系统都包含应用程序特定的业务逻辑，这些业务逻辑均以相对独立的方式运行，如图 3 中所示。此逻辑经常与表示信息交织在一起，即体系结构内没有清楚的关注分离，从而进一步限制了灵活性。在系统彼此通信的情况下，由于使用了专用 API，因而存在紧密依赖关系，这种方式不可靠，而且会降低可见性。

　　图 3. 业务子流程

　　这些系统的用户群实际上有重叠，有些用户最终需要按顺序访问所有三个系统，以收集必要的信息。这就要求他们进行多次登录，以不同的表示样式进行交互、进行重复任务并手动对每个系统的信息进行协调。

　　解决方案

　　引入 SOA，以在分层参考体系结构中统一这些异类系统，如图 4 中所示。

　　图 4. SOA 分层体系结构

　　每个层次提供不同的好处(如下所示)，这些层次一起提供了一个灵活的可自定义的业务驱动体系结构。接下来让我们详细讨论一下这些层次：

• 表示层：引入了门户，为用户提供跨业务活动范围的统一用户体验。通过其个性化功能，可以针对用户的角色对界面进行定制，从而通过基于浏览器的单点登录环境为用户提供相关内容。
• 业务流程层：尽管现有业务逻辑主要部分仍然驻留在运营系统中，但业务流程层将对这些系统限制如何协作进行编排。它可提供以业务为中心的视图，记录端到端流程，但是不考虑细节。
• ESB：可以将总线视为此方案中的粘合剂。它为服务提供者和使用者(可以为业务流程或 Portlet)提供一定程度的隔离。虽然总线中没有业务逻辑，但它可以进行动态路由(例如，基于某个服务级别协议选择一系列激活服务中的某个服务)，并进行接口映射，有效地将异类基础数据对象统一起来。
• 服务：提供了基于标准的接口，允许使用者以独立于平台的方式访问服务包含的功能，而不用考虑其实现。
• 服务组件：这包括实现服务指定的功能的软件组件。服务组件遵循服务层中定义的契约，并保证 IT 实现与服务描述的一致。
• 运营系统：运营系统大部分都没有变化。不过，其间的任何依赖关系限制都完全在业务流程层内进行了处理。其目标不是将业务逻辑从这些应用程序迁移出来，而是要保留其经过生产验证的功能，并以标准方式在整个企业内对其进行公开，从而提高其可见性。假如服务接口不变化，则基础运营系统可能会在不影响服务使用者的情况下进行变更。通过这样，就可以使用独立的实现完全替换一个运营系统(例如，使用 Siebel 替换 PeopleSoft)，让业务需求推动系统的选择，而不是让 IT 主导供应商的选择。

　　服务投资组合

　　标识服务时，可以使用一系列建模技术，如 IBM 内使用的面向服务的建模与体系结构(Service-Oriented Modeling and Architecture，SOMA)方法，本文对此将不予讨论。但抽象一点来说，所标识的服务归为两大类：

• IT 服务：这些服务通常不包括实质的业务逻辑，而用于提供对现有运营系统的基于服务的访问。通常称为原子服务(因为这些服务通常并不依赖于任何其他服务)，且由基础运营系统直接提供——不过也可以使用可用的任意接口机制自行构建。所公开的方法通常都是通用型的细粒度方法(例如，CRM 服务可能会提供 getCustomerRecord 端点)，因为这些服务主要设计为供其他服务进行重用。虽然此接口可以由 ESB 访问，但最好仅在服务接口足够通用，而且不会在使用者和提供者之间引入紧密耦合的情况下才使用。
• 业务服务：这些服务包含业务流程使用的业务逻辑，通常称为组合服务，因为这些服务可能会将处理委托给一系列其他业务服务或 IT 服务。与 IT 服务不同，所公开的方法通常是粗粒度的，且通常与特定业务活动相关(如 provisionNetworkService)。

　　经常还有第三类服务，信息服务，用于提供对数据源(通常为联合数据源)中包含的数据的直接访问。不过，在这种情况下，所有数据访问都是通过相关运营系统执行的。

　　行业遵从性

　　使用行业特定的业务流程模板和数据模型不仅可以加速在 WebSphere Business Modeler 中进行的开发工作，而且还能够提供对业务本身的结构、确定的差距和重叠区域的验证。不过，可能更为重要的是其带来的前瞻性品质认证，特别是在应用程序集成方面更是如此。

　　由于其多样化且十分复杂的技术需求，很多电信运营商都非常依赖于现成的系统，将其用于控制从开单到网络的物理运营的各个方面的事务。这些系统必须有效地进行通信才能保证企业的成功，而遵循行业标准是实现此目标的最好方法。

　　目前需要使用 ESB 来执行中介操作，在相关运营系统使用的不同数据表示形式之间进行转换。但随着整个行业对标准遵循的不断增加，这将变得越来越没有必要。采用通用数据术语是此领域的一个关键，可帮助对产品接口进行标准化，提高性能、消除特定的产品依赖性，让我们回到 SOA 的主要目标之一，即业务敏捷性。

　　解决方案堆栈

　　此解决方案基于以下运行时堆栈和开发环境：

• IBM WebSphere Process Server (including WebSphere Enterprise Service Bus) V6.0.2
• IBM WebSphere Portal Server V6.0.1
• IBM Rational® Software Architect V7.0
• IBM WebSphere Business Modeler V6.0.2
• IBM WebSphere Integration Developer V6.0.2
• IBM WebSphere Business Services Fabric V6.0

　　除了每个体系结构层提供的具体功能外，堆栈还带来了一系列非功能优势，包括固有的可伸缩性(通过作为 SOA 基础的 IBM WebSphere Application Server 提供的功能)和在堆栈所支持的操作平台内一定程度的平台独立性。

　　尽管我们在此解决方案中使用了一系列 WebSphere 品牌产品，但此方案最终代表的是一种体系结构范式，并有一定的供应商独立性。IBM 参加了各种标准组织(如 W3C、OASIS 及其 TMF、BPEL、XML 和 WS* 标准的后续实现工作)，可确保此解决方案不会成为另一个定制解决方案。

　　总结

　　本文从技术和业务的角度讨论了如何通过引入 SOA 来处理现实的业务问题。BPM 之类的补充技术的出现带来了更多的 SOA 好处，支持您的业务积极地参与到软件生命周期中来。

　　我们还了解了 SOA 一个将来的发展方向，说明了 IT 模式如何发展为行业模板，从而为整个企业提供技术和流程蓝图。任何 SOA 的一个主要目标都是将 IT 与业务需求相结合，但 SOA 现在有了进一步的发展;通过采用新兴的行业模型，我们可以看到 SOA 理念将如何帮助业务保持自身与行业的一致，通过采用标准和最佳实践来提供可靠的互操作性和未来敏捷性。