开发人员的一种新思维模式

我们正处于转向网络中心平台的转换过程的最初阶段，这个过程漫长而又不可避免。在如何构建应用程序和分配支持业务需求所需的开发劳工这两个方面，企业应用程序架构师和开发人员都必须采用新的思维模式。

　　面向服务架构（ SOA ， Service-Oriented Architecture ）是创建灵活、可适应和分布式计算环境的一种应用程序设计风格。为了将应用程序功能设计为共享的、通用的服务， SOA 定义了一组规则、模式和实践。最佳实践使得开发人员意识到 SOA 对最大限度地提高服务共享、重用、灵活性和互操作性都有好处。服务设计实践使得公司能够创建更灵活的架构，这些架构可更容易适应变化的业务需求，同时缩减开销。有 5 个主要设计主题是开发人员和架构师必须采用的：共享和重用、具体化（ externalization ）、松耦合、互操作服务合同和复合应用程序。

　　SOA 更多时候与思维模式有关，而不是与技术有关。首先，开发人员必须接受这样的看法，即重用现有服务要比从头构建这些功能好。在没有事前存在的服务可用的情况下，开发人员应该实现该服务，这样其他开发人员才可能重用它。开发人员必须经常考虑可重用性和互操作性。

构建业务流程

　　客户 / 服务器架构与 SOA 之间的真正区别在于如何分解组件相互依赖关系。在客户 / 服务器架构中，焦点是构建一个特定应用程序，并将该应用程序分解成逻辑组件。在大多数环境下，开发人员完全期望实现整个应用程序。在 SOA 中 ，焦点是构建可重用服务，然后组合这些服务来实现业务流程。一个给定服务也许可以用在任意数量的应用程序中。在 SOA 中，开发人员期望重用尽可能多的现有服务，并且只实现编制业务流程所必需的代码。

　　每个服务都应该实现一项特殊的业务任务，并相对自治地进行运作。开发人员可将这些服务组合或重新组合成编制好的应用程序，实现各种业务流程。通过与适当的基础架构结合， SOA 使得 IT 系统能够对变化的业务条件作出迅速响应。核心开发人员将把业务逻辑和基础架构服务作为可重用组件来构建，与此同时，开发人员的工作将更像是构建承包商，通过使用标准化服务作为构建材料来组装（然后重新建模）面向过程的系统。

　　通用服务的理念是可以由多个应用程序重用，而不是为每个应用程序实例重新创建一个通用服务，这也正是 SOA 的本性，但也带来了一些挑战。一个特定服务实现可能在安全性、可靠性或事务等方面要求不同的操作语义，比如，根据使用的应用程序上下文来要求语义。在传统应用程序架构中，开发人员通常在应用程序代码内实现这些操作语义，这降低了（如果说没有消除的话）服务的可重用性。

　　SOA 通过具体化操作语义解决这类问题。而不是将安全语义（诸如身份和权利管理）直接应用到服务中，比如，开发人员根据指定特殊服务在特定应用程序上下文中所需的安全语义的说明性策略，依赖于增强身份验证和授权规则的外部通用安全框架使用语义。同样，开发人员没有将自己的事务语义构建到服务中，而是依赖通用事务框架，而这些又再一次取决于说明属性。

　　因此，重用服务的能力成指数增长。随着新用案的增加——这可能要求不同的安全和事务语义——外部事务和安全框架很容易适应新的用例，无需改变服务代码。

　　以这种方式， SOA 通过分隔业务改变了开发人员之间的劳动分工。它还减少了开发工作量，并产生更加健壮的应用程序。基础架构编程需要许多不同于业务逻辑开发的技巧。业务开发人员没有必要是安全性、可靠性和事务方面的专家。考虑到这些技术的复杂性，业务开发人员犯错误的可能性极其高。类似地，安全专家也没有必要是清单控制或工资单处理方面的专家。

　　通过将业务开发职责从基础架构开发中分离出来，每一类开发人员可专注于他们最擅长的工作。面向业务的开发人员可以充分利用那些懂得如何实现复杂基础架构服务的编程人员更技巧化的系统级工作。

实现分离

　　在 SOA 中，实现应用程序不同功能部分的服务之间的联系是松耦合的——这意味着一个特定服务对环境中另一个特定服务没有强烈依赖，松耦合通过一致化以下设计实践来实现：无状态交互、抽象服务合同以及粗粒度（ coarse-grained ）服务接口。

　　通常，服务交互是无状态的和非事务性的。开发人员必须使用不同的技术（比如可靠的异步消息传递）来管理松耦合架构中的状态和事务。

　　松耦合服务可以将服务外部接口的外部接口与其内部实现分离。在松耦合环境中，服务之间的交互是通过虚拟边界发生的，虚拟边界是由像 Web 服务描述语言（ WSDL ， Web Services Description Language ）这样的服务合同定义的。这些服务合同只公开该服务愿意授权给其他服务的那些行为、逻辑和上下文参数，而保持服务内部实现其他所有方面的不透明。分离允许改变平台各种功能的内部实现，同时最大限度地减少修订相应外部接口的需要。通过在中间件中实现数据映射和转换层可以完成这一分离。

　　抽象服务是通过使用以下设计开发方法来创建的：按业务流程粒度定义服务；通过标准、面向文档的方法，特别是简单对象访问协议（ SOAP ， Simple Object Access Protocol ） Document/Literal 风格接口，来暴露服务功能；通过用于输入和输出文档的标准的、意见一致的模式，来实现服务间的端到端语义互操作性。

　　粗粒度接口涉及到定义一些服务合同，这些服务合同从大量功能中抽象本地对象模型和接口。通常，服务之间的粗粒度接口涉及“ chunky ”会谈，它们将几种功能调用和响应打包成更少却更大的消息。与之对比，细粒度服务接口通常使用“ chatty ”会谈，它们涉及客户与服务之间的更多更小的消息（参见图 1 ）。

图 1. hunky 或 Chatty

　　服务之间的粗粒度交互涉及一些“ hunky ”会谈，该会谈将几种功能调用和响应打包成更少却更大的消息；然而，细粒度服务接口通常产生“ Chatty ”会谈，该会谈涉及客户与服务之间更多更小的消息。

　　另一个最佳实践是定义 Web 服务——因此，还要定义相关的 WSDL ——以便与业务流程中的活动和子流程的粒度相一致。开发人员应将 Web 服务设计为粗粒度的、离散的任务或编制，它们中的每一个都拥有一个业务流程或重要子流程。用这种方法，架构师可以进化平台底层的那些服务，而无需更新相应的 WSDL 服务合同。

　　因为 SOA 的一个关键目标是建立一个统一所有应用程序组合资产的完整架构，因此 Web 服务开发人员必须小心不要映射平台的本地对象模型、组件、 API 以及它们的 WSDL 中的其他工件。当开发人员从特定于平台的对象模型中自动生成服务定义时，他们不经意地在公开的 WSDL portTypes 中构建了平台的本地对象模型和方法。

　　相反，互操作 Web 服务一开始就应从头开发 WSDL ，并按以下的方式来定义 WSDL ，即其元素不必一对一地对应于底层服务平台的对象模型、方法和其他工件。根据外部互操作合约， WSDL 必须通过更改底层应用程序和平台来保持稳定。

复合应用程序

　　在 SOA 中，应用程序并不真正由层组成——至少与客户 / 服务器应用程序架构对它们的定义不太一样。应用程序由一组松耦合的服务组成。每个服务作为另一个服务的完全对等实体来运作，服务由通信部件连接。

　　服务可以自己完成整个任务，或者它可以调用其他服务来执行各种子任务。调用其他服务的服务成为了其子任务的控制器。复合应用程序由一个控制器组件组成，该控制器调用一组适当的服务来完成期望的业务流程。

　　向面向服务的思维模式转换不可能一蹴而就。各团队应该建立以共享、可重用性和互操作性为中心的设计开发准则。这些准则应该将重点放在定义与应用程序分解相关的策略、模式和 WSDL 的定义和设计模式方面。此外，应该部署开发过程和相应的工具，以确保与架构原则的一致性。

关于作者

　　Chris Haddad 是 Burton Group 的实习经理和高级顾问。您可以通过 chaddad@burtongroup.com 与 Chris 联系。

原文出处

http://www.fawcette.com/weblogicpro/2005_01/magazine/columns/soapbox/