BEA: 展望面向服务领域

 来源：IT专家网

   BEA 宣布该公司将拓宽其在 SOA 方面的咨询实践，而且它已经开发了一个工具，其他公司可以使用该工具来学习 SOA，并弄清他们在向新架构模型的转换上准备得怎么样了。尽管 BEA 和其他主要供应商，如 IBM 和 Microsoft，不断加大对 SOA 的投资力度，而我们当中还有很多人还在努力理解 SOA 究竟是什么。

    你对 SOA 的理解到了什么程度?假设现在有人叫你对 SOA 下一个定义，会是什么样呢?始终存在的一个挑战是:如何将 SOA 与使用 Web Services 的标准分布式架构区分开来。另外一个挑战是:如何准确描述广为人知的面向服务范例包含的内容。

    为了解决这些问题，我们咨询了著名的 SOA 专家Thomas Erl，请他给出一些解释。Thomas 撰写了《Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services》。该书是去年Web Services和 SOA 领域的最畅销书。今年的晚些时间，他将出版他的第二本著作，题为:“Service-Oriented Architecture: Concepts, Technology, and Design”，全书长达700页。

    下面就是该书的部分节录，它向我们介绍了 SOA 和面向服务的基本知识。

    面向服务架构

    目前还没有对“面向服务架构”的官方定义。因为术语“面向服务(service-oriented)”已经存在了一段时间，所以它被用于不同的语境和不同的目的。尽管如此，在其存在的过程中，它代表了一种基于“分解”概念的范例，这是一直不变的。任何事物，如果能够以定义明确的相关单元集的形式处理，就可以更好地构造、执行或者管理。因此，面向服务不只是一个技术范例。黄页中全都是面向服务的企业。个体公司是面向服务的，从每个个体公司都提供可供多个客户使用的独特服务方面来说。积少成多，这些企业最终组成了一个企业社区。如果一个企业社区不是由一家单独的企业供应商来提供所有的服务，其意义将会非常深远。通过将社区分解成专门化的个体供应商，我们可以实现一种分布式供应商的环境。即使在分布式模型中，如果施加强大的依赖性，就可能抑制个体企业的潜力。尽管我们希望能允许经销商之间互相交流，并充分利用各自的服务，我们还是要避免这样一个模型，即供应商形成了紧密联系，从而导致紧缩性的相互依赖。通过准许企业自主管理其个体服务，就可以使他们发展相互之间的相对独立性。尽管鼓励企业供应商之间的独立性，我们仍然必须确保他们同意遵守某些基本约定。例如，用于交易货物和服务的共同货币、需要标记来遵循某些参数的构建代码，还可能是一种要求:所有的企业员工使用与本地客户相同的语言。这些约定从客户的利益出发，对每个企业的关键因素进行了标准化，而没有太多地影响企业实行自主管理的能力。

    当与“架构”放在一起时，面向服务就体现出了一种技术性的内涵。“面向服务架构”这个术语代表了一种模型，该模型中自动化逻辑被分解成了更小的独立逻辑单元。聚集起来，这些单元就组成了一个较大的业务自动化逻辑块。这些单元单个来看可以是分布式的。面向服务架构(SOA)鼓励单个逻辑单元遵循一组设计原则，其中一条就是要求它独立存在。这就允许各单元独立发展，而仍然保持足够的共同性。这样也会形成一个具有不同特征和利益的业务自动化环境。

　　SOA 可能非常复杂。目前的开发工具和服务器平台正不断地扩大支持创建面向服务解决方案的功能集和能力。尽管如此，在我们讨论 SOA 支持企业级自动化的几种方式之前，我们必须首先从其最基本的形式入手来了解一下 SOA。该基本模型确定了各种 SOA 变体底层的核心架构。它由三个构成一种特殊关系以实现自动化的基本组件构成。

　　服务

　　每个业务流程都包含了一系列的步骤。较大的流程往往包含一个或多个支持父流程的子流程。这些子流程也包含某个逻辑边界内的一系列步骤。边界封装了由子流程提供的独特任务或功能。

　　服务代表了现实世界的行为。行为的大小和范围与被封装到服务中的任务或功能无关。有关系的是任务或功能的边界必须清晰。因此，服务可以表示流程的任何部分。这样做就使服务建立了一个到该流程的业务逻辑的标准入口点，注意到这一点很重要。

　　将这个概念扩展到一个物理实现的环境中，就建立了一种称为“自包含的处理逻辑单元”的服务。该服务也有清晰的功能边界，它被设计用来执行一个特定的任务。该任务可以是精密复杂的，也可以是有限的。例如，服务可能执行一系列牵涉到其他服务的行为。或者，服务的惟一功能可能是提供到固定资源(如一个知识库)的访问。无论如何，它最基本的特征是它是相对独立的，或者说与其他服务是松散耦合的。

　　松散耦合

　　在SOA 领域，松散耦合代表了服务之间的一个通信协议的基础。该协议由一个认知构成，即为了使服务之间相互通信，它们必须了解各自的情况。这种了解是通过使用服务描述来实现的。一个服务描述，以其最基本的格式来看，确定了如下信息:

　　服务名称

　　对服务所期望的数据的描述

　　对服务所返回的任何数据的描述

　　例如，服务 A 知道服务 B，因为服务 A 已经访问了服务 B 的服务描述。如果服务 A 可以通过某种方式与服务 B 通信，而甚至不知道服务 B 的存在，那么就不会有通信协议，这些服务也会被认为是去藕合的(decoupled)。去藕合的通信常常通过使用中间件或两个程序之间的中间组件来实现。

　　松散耦合协议的另外一部分是，服务之间的通信也应该是自包含的。这就是说，在服务之间传递的每一个通信单元都应该独立于其他单元而传输。

　　因此，如果服务 A 已经获得了服务 B 的服务描述，就可以与服务 B 进行通信了。服务 B 收到了通信(单元)，但不一定响应服务 A。更进一步说，该通信本身没有任何直接指向服务 B 的连接。如果服务 A 已经建立了一条通向 B 的直接连接，通过它来传输数据以及接受响应，那么这些服务就被视为紧密耦合的。

　　紧密耦合的另外一个特征是，处理逻辑单元之间具有依赖性。该逻辑以这样一种方式来实现，即对于某段逻辑的更改很容易影响到它引用的或引用它的其他逻辑片段。因此，如果服务 A 和 B 是紧密耦合的，那么更改其中一个就可能需要对另一个也进行更改。在一个松散耦合架构中，只要原始的通信协议(该协议由服务描述来表示)仍然保留着，那么对二者中任何一个服务的更改都不会影响到另一个。

　　那么我们如何实现松散耦合呢?我们需要一个通信框架，该框架纯粹基于前面所提到的“独立通信单元”。这就引入了消息传递。

　　消息传递

　　消息是 SOA 的基础技术。它们实现了许多面向服务的原理，并且构成服务间通信的基础。对于 SOA 概念本身来说，基于消息传递的通信并不是新内容。它已经在中间件产品中使用了多年。

　　然而，SOA中实现消息传递的首选方式是相当特别的。一旦某个服务以自己的方式发送了一条消息，此后它就失去了对该消息后续事件的控制权。这就是为什么需要用独立的通信单元来实现真正的松散耦合的原因。消息，就像服务一样，需要相对的自包含。这意味着尽可能根据需要加入足够的智能性。这包括实际的结构和消息数据的键入。

　　消息传递为 SOA 提供了同步通信或异步通信的选项。尽管SOA 完全支持同步消息交换，然而它对松散耦合性和通信独立性的强调表明它鼓励异步交互场景。最终结果是具有了支持多种通信模型的能力(“消息交换模式”)。当前的面向服务的消息传递依赖于一个复杂的架构，该架构支持大信息量消息的传输和运行时处理。消息可以装备许多可组合的功能，这些功能可用来处理从安全性和可靠发送到路由选择和策略处理等许多事件。

　　请注意我们刚刚讨论了基本 SOA 模型的组件，而没有引用 Web Services、WSDL 或SOAP 。当然，这些技术已经成为了交付面向服务解决方案的最成功的方法。在如今的 SOA 领域，服务是以 Web Services 的形式存在的，服务描述主要是通过 WSDL 定义实现的，而消息传递是通过 SOAP 格式来标准化的。但是一定要记住，基本的SOA 是技术不可知的(technology-agnostic)。这一点同样适用于面向服务原理。

　　面向服务原理

　　到目前为止，我们已经确定基本的 SOA 由一组服务组成，这些服务使用服务描述来保持松散耦合，并且以消息传递作为其通信方法。这些核心特征由面向服务原理塑造和支持，它构成了服务级设计的基础。

　　在前面，我们已经确定 SOA 没有正式的定义。也没有一个处于统治地位的标准机构来定义面向服务背后的原理。相反，有很多种关于什么构成了面向服务的看法，它们有的来自于公共的 IT 机构，有的来自供应商和咨询公司。(参考www.serviceorientation.org/以获得更多信息)

　　据说，面向服务根植于一个称为“分离关注点”的软件工程理论。这个理论表明，将一个问题分解为一系列的单个关注点是非常有用的。这样做可以降低复杂性，并且能够提高全体关注点的整体质量。该理论已经在不同的开发平台上以不同的方式实现了。例如，面向对象编程和基于组件编程的方法通过使用对象、类和组件成功地实现了关注点的分离。

　　面向服务可以视为一种实现关注点分离的独特方式。面向服务原理提供了一种支持该理论的方法，同时为一种独特的架构模型，即 SOA 构建了基础范例。

　　正如前面所提到的，没有正式的面向服务原理。然而却有一套与面向服务相关的常见原理集。本书详细讨论了这些原理，现列举如下:

• 服务是可重用的——不管是否存在立即重用的可能性，服务都要设计为支持潜在的重用。
• 服务共享一份正式协议——为了使服务能够交互，它们只需要共享一个定义了信息交换术语和其他服务描述信息的正式协议协议。
• 服务是松散耦合的——服务必须设计为在松散耦合的基础上进行交互，并且它们必须维护该松散耦合状态。
• 服务将底层逻辑抽象化——服务唯一对外可见的部分是通过服务描述所公开的内容。在该描述中没有表示的底层逻辑是不可见的，并且与服务请求方没有关系。
• 服务是可组合的——服务可以组成其他服务。这允许逻辑以不同的粒度级别表示，并促进了抽象层的可重用性和创建。
• 服务是自治的——由服务管理的逻辑驻留在一个显式边界中。服务在该边界内具有完全的自治权，而不依赖于其他服务来执行这种管理。
• 服务是无状态的——不应该要求服务来管理状态信息，因为那样就会妨碍它们保持松散耦合的能力。服务的设计应该在最大程度上实现无状态性，即使这样做就意味着在其它地方拖延状态管理。
• 服务是可发现的——服务应该使它们的描述可以被人们和服务请求方发现和理解，以便服务请求方可以利用它们的逻辑。

　　这八条当中，自治性、松散耦合、抽象和需要正式协议可以视为构建 SOA 基准基础的核心原理。

　　当代SOA

　　这段介绍仅仅抓住了这个广泛主题的表层部分。面向服务背后的这些原理和由 SOA 确定的架构范例可以应用于整个企业。当与开放的 Web Services技术框架结合使用时，它就形成了一种巨大的潜能，可以提高机构的灵活性，改善贯穿先前不同的环境的通信线路。一旦提升到这个层次，面向服务的架构就发展为我们所划分的“当代 SOA”。实现这个综合而又复杂的模型可以极大地影响一个机构。可能受到影响的方面包括业务建模、资源分配和技术基础架构。该书的其余部分都用来研究当代 SOA的各个方面。

　　这是从Thomas Erl撰写的《Service-Oriented Architecture: Concepts and Technology》一书中节选出来的，全书约700页，ISBN为:0131858580，由Prentice Hall/PearsonPTR 联合出版，Copyright 2005。