[架构模式] 企业计算中的面向服务

萧闫子

摘要：有关面向服务的体系结构的各种讨论经常在缺乏足够交流的情况下进行。对于 SOA，至少已形成两个截然不同的角度：构建企业解决方案的开发人员的角度和跟踪组织 IT 资产有效性的资产组合管理人员的角度。本短文尝试明确这些角度，以使开发和操作能够更有效地协同工作。

本页内容

登录/注册后可看大图	引言
登录/注册后可看大图	SO 与 SOE
登录/注册后可看大图	商业效益
登录/注册后可看大图	服务设计
登录/注册后可看大图	服务支持
登录/注册后可看大图	结论

引言假设您是一位面包师，正在与焙烤食品经销商交谈。对您而言，做面包就是合理搭配原料、跟踪发酵时间和确保产品质量的稳定。而经销商将所有这些都看作理所当然的事；她只关心包装、发货计划和货品上架。你们用相同的语言交谈，但“面包”一词对您和她却有着不同的含义。
讨论面向服务的体系结构 (SOA) 时也要落入个令人遗憾的模式。这取决于您所处的角度：开发人员或者技术资产组合管理人员：这两类人员对 SOA 都有着大体一致的概念，但又有些分歧。你们都同意可以用它做面包，但您所说的面包以实用性为评判依据，而经销商则以其在产品线中的作用为判断准绳。

                               
登录/注册后可看大图

返回页首
SO 与 SOE为消除这种交流不畅的倾向，我们将资产组合管理人员的角度称为面向服务的企业 (SOE)，而将开发角度称为面向服务 (SO)。
技术专家们对术语“SOA”有一些怀疑。有时它的描述几乎可用来表示任何概念，因而失去了任何实际意义。这个术语已被某些设法搭上流行快车的供应商肆意滥用，但抵制使用此术语的主要原因还是 SO 与 SOE 之间的混淆不清。
我们用术语服务模型描述这两个角度的交汇点。服务模型是一组标准和原则，规定在技术资产之间传送消息的方式，以形成获得商业效益的解决方案。接口符合此模型的资产称为服务。尽管服务可通过多种服务模型提供和使用，但通用技术社区在 XML、SOAP 及相关 Web 服务标准中的近期投入显示，应极力优先使用建立在该基础之上的模型。
从解决方案角度看，SO 是一组模式和实践惯例，用于开发单个服务和解决方案，它们利用了服务模型，因而能够在不同系统之间集成。服务封装其操作系统和专用协议的特性，允许使用标准协议和极传统的接口访问其业务逻辑和信息。在稳定的接口背后，可以持续升级和改进实现，而不会对使用该服务的解决方案产生负面影响。
从资产组合角度看，面向服务的企业是分解、集成和管理组织的技术资产组合的一条途径，它将服务模型用作开发和操作分布式业务系统的基础。它使用一套组织标准扩展“通用”服务模型，这些标准着眼于可重用性、一致消息的处理以及组织的服务和解决方案资产组合的运营（也称为非功能性）需求的传递。组织逐个服务、逐个解决方案地建立其技术资产组合。有效的 SOE 工作会引导此循序渐进式开发过程创建一个独立于平台的解决方案框架，从而提高后续开发的速度，并保证管理上的一致性。
Microsoft 谨记开发人员与投资管理人员双方的要求，针对使用 Web 服务开发跨平台的面向服务解决方案时的需求，全力以赴开发了相应的标准、指南、工具和技术。

                               
登录/注册后可看大图

返回页首
商业效益SO 的商业效益首先得自于更有效的集成：业务系统之间的集成、工作组之间的集成、跨地域的分公司之间的集成以及价值链之间的集成。SO 允许在受管理的条件下合理访问关键任务信息和功能，无需安排监视人员及工作人员手工保护和代理这些资源。SO 为开发更动态的解决方案铺平了道路：将业务过程中的执行者更完整地链接到一起的解决方案和更有效地响应业务过程实例上下文的解决方案。
面向服务的企业能产生合理化组织技术资产组合的额外商业效益。分解业务过程和为业务过程建模可以发现业务自动化支持方面的冗余和缺口。利用这种业务功能清理能够做出明智的供应源决策，例如将库存管理方面的工作交由后勤服务提供商去做。由此形成的服务与业务功能之间的配合能够清晰界定技术资产的商业所有权，逐渐促成更好的资产组合维护。
组织的服务体系结构的范围由业务需要定义，并且在需要发展时可扩展此范围。多数组织能够确定一些关键业务过程，如果沿袭 SO 原则重新设计改造这些过程，会具有很好的经济意义（尤其是能在复杂的价值链之间实现更好的集成）。多数组织将选择 SO 作为新开发的基础，并使用 façade 服务按需访问现有系统。少数组织会看到大张旗鼓地重新构建其整个技术资产组合的商业价值，但还有更循序渐进的方法，也是更典型的做法。

                               
登录/注册后可看大图

返回页首
服务设计另一个需要探讨的问题是 SO 替代面向对象 (OO) 的程度。从真正意义上而言，SO 是分布式对象技术的演变，但是对于本地处理，SO 未取代（或者尚未取代）OO。事实上，多数服务提供与使用都用对象模型和 OO 最佳方法来编码。但是设计服务和服务使用时，开发人员必须突破 OO 方法，考虑服务调用的目标和成本。
服务设计应遵循“合同至上”的原则。服务提供程序应关注服务将接受和生成的消息，注意消息架构的平台独立性以及通过表面和实际 (de facto) 的标准元素构成这些消息。服务开发人员使用的对象模型应从服务合同派生，而不是从对象模型派生服务合同。服务应为使用者提供逻辑“业务”接口（如 ValidateAddress），该接口为调整调用成本（在公共 Internet 上高，但在专用网络上可能较低）提供充足的价值。服务设计指导的一个起始参考点为 Don Box 的文章（英文），其中介绍了面向服务的四个原则。
使用服务时，有几个关键问题必须在解决方案或者在中间增值服务中解决。而在这些问题中，应首先考虑服务调用成本并做出适当的供应源决策。使用远程服务执行简单的整数运算显然不是一个好选择。当多个服务为类似功能提供不同的服务粒度时，既要考虑提供的合同，又要考虑提供的服务级别协议（例如，在可以返回一个安全性当前值的服务与可以在单个调用中返回一个值列表的服务之间进行选择）。开发人员应利用异步通信支持可靠消息传送，并处理不确定的滞后时间。在编排一组人员的有序工作成果的解决方案中，滞后问题可能会极其严重。
每个设计良好的服务和面向服务的解决方案都成为组织的技术资产组合（面向服务的企业中的组件）的一部分。成功 SOE 的特点包括严格的服务分解、详尽的前瞻性集成策略、在服务和解决方案的管理与控制上保持普遍的一贯性。
应将服务分解，以供解决方案资产组合充分利用。通常这意味着达到可能的最高重用级别。分解服务的一种可取方法是使它们与组织的业务过程的组成步骤相一致：分解为任何业务过程所需的最细粒度，并提供聚合服务，以支持粗粒度的常见访问模式。如果某银行有二十二个需要为客户信用评分的应用程序，ScoreConsumerCredit 服务应设计为支持所有这二十二个程序。同一业务功能的多个实现导致业务不规范，业务规则变化时维护需求增加，从长远观点来看，还会增加贸易成本。为重新使用而进行分解可能需要一些技巧，包括考虑环境相关性（ScoreConsumerCredit 可能会因交易的地域环境而具有不同的要求）和“服务继承”，其中，一个服务扩展另一个服务的合同和业务数据。设计新服务时，可以研究现有业务组件模型以获得相关指导。希望随着时间的推移能重新分解和版本化已部署的服务。
服务体系结构的集成策略应设法提供一项支持，即支持访问最完全的合理的技术资产集合。服务模型包括的资产越多，能在该模型上构建的解决方案就越多。一种常见的实现方法是利用以商业消息总线技术表示的集成投资。消息总线通常采用一种“可插拔”方法与各种专用系统通信，而且通常提供一组此类系统中较常见的现成的连接器。
访问一致性包括配置、异常处理和统计值收集的一致方法。服务体系结构应指定一组接口和标准过程，它们必须由所有服务实现，以支持服务与（如果适用）底层业务系统的可管理性和控制。为了能够将供应商提供的服务加入到组织的服务资产组合中，组织管理标准应尽可能符合相关供应商支持的标准。

                               
登录/注册后可看大图

返回页首
服务支持有效的 SOE 需要具有一致的策略，用于此分解适当、集成正确、管理良好的服务和解决方案资产组合的运行时支持。服务体系结构的关键基础结构要求包括（但不限于）：

•	身份和角色管理：将组织和组织外部价值链参与者与可审核的身份映射，或者将这些参与者与命名角色映射，以改进授权管理。
•	消息传送管道：对在解决方案和服务之间传送的消息提供一致的支持和管理，包括实施安全策略。
•	实体模型：分解适当的 XML 架构资产组合，描述将由服务和解决方案处理的业务实体。
•	发现策略：用于服务接口与实体定义，通常由目录或索引库支持。
•	事件引擎：用于传送异常和状态消息。

服务体系结构终止于何处，解决方案资产组合从哪里开始，这一直是争论的话题。例如，对于过程编排，SO 不是说明性的：可以使用若干有效的方法创建和管理那些调用服务以实现商业价值的过程实例。