【IT168 信息化】简介

　　如果您加入IT行业已经有一段时间了，那么当您听说供应商们推出新的技术时，您会有似曾相识的感觉。如果您对于大量有关面向服务架构的宣传感到晕眩，那么您并不是惟一的一个。在最近的会议上，一个习惯于使用COBOL编码的与会者问道，SOA和他所使用的COBOL copybook之间的区别在哪里。我从未使用过COBOL copybook，但是曾见过大量的技术出现又消失，所以我可以理解这个问题。在本文中，我将说明隐藏在SOA背后的主要驱动力，以及如何改进技术以支持SOA。

　　重用所面临的障碍

　　重用一直是软件开发的首要目标之一。这很明显：如果您编写了一段代码来实现某种功能，如果无需在其他很多地方再重新编写或维护它，那么无疑会提高生产率。然而，重用实现起来并不轻松，也并非自动化的。首先，必须以一种可重用的方式来组织或编写代码。然后，必须知道存在一段可以被重用的代码。在组织代码方面，不同的编程语言以不同的方式为重用提供内置支持。过程和函数是大多数程序员所熟悉的基本单元。面向对象的语言，比如C++和Java，还提供了定义和扩展自定义的类型或类的手段。这些特性背后的基本理念就是封装(也就是说，只需通过一些定义良好的接口来访问其中的功能，实现对于您而言是一个黑盒子)。这些特性有其用途和优点，但是当涉及到支持更大规模的重用时，它们也存在一些局限性。

　　首先，这些编程语言工件是非常低级的，只有特别熟悉它们的程序员才能进行有效的重用。

　　其次，即便是在同一个项目团队中，要发现可重用的资产也不是一件容易的事情，更不用说在企业范围内了。

　　最后，这个层面上的代码并不支持网络，这意味着无法跨机器调用这些代码，也无法在另一种编程语言中透明地重用它们。例如，假定我已经使用C++编写了一个定价模块，那么不费一番工夫，我是无法在Java中调用这个模块的。

　　在这里我想表达的是，这些特性肯定有其用处，但是这个层面上的重用实际上就是剪切和粘贴代码，这易于出错而且不可扩展。

　　面向重用

　　“服务”这个概念的出现就是为了解决这些重用问题中的一部分。CORBA是对象管理组(Object Management Group，OMG)提出的一个标准，这或许也是使用基于标准的分布式计算模型来解决重用问题的首次全面努力。

　　其思路是，通过一个抽象接口正式实施封装的概念，并提供一组可由这些服务(或CORBA技术中的对象)使用的基础性服务。接口是使用一种叫做IDL(Interface Definition Language，接口定义语言)的语言定义的，而且为各种编程语言定义了映射。服务可以使用这种语言来描述。要使用某个特定的服务，只需使用IDL即可，而无需了解实现该服务的实际细节。这些服务还支持网络。这提供了一种跨硬件、语言和网络的便利途径。

　　CORBA还定义了一套丰富的基础性服务，比如用于注册和发现对象的目录服务(称为命名(naming))、基于公开属性发现对象的交易(trader)服务、用于异步通信的通知服务、事务服务，等等。所以，现在可以快速构建服务，因为可以利用这些基础性服务。还可以跨越多种边界轻松重用这些服务。其他的分布式组件模型，比如微软的DCOM和J2EE，都以一种或多或少类似的方式来构建和使用服务。

　　SOA到底是什么?

　　现在，我们已经准备给出面向服务架构(即SOA)的定义了。遗憾的是，关于SOA，存在多种定义，有时它们还相互冲突。很多定义都结合了一种特定的技术(特别是Web services)，或者在定义中包含一种特定的特性(例如调用类型)。我将给出一些我认为抓住了SOA本质、而不是将其与特定的技术相关联的现有定义。但是，首先让我们看一看面向服务架构中的术语“服务”。

　　定义SOA中的服务

　　服务是一个被过度使用的术语，但是却没什么好的定义。服务就是一种能够以分布式方式调用的功能，它是定义良好的、自包含的，并且不依赖于上下文或其他服务的状态。让我们看一看构成服务定义的一些特征：

　　能够以分布式方式被调用。这很重要，因为我们不能假定某个功能是处在客户端环境中。

　　定义良好。正如早先讨论的那样，重用在编程语言层面上面临的一大难题就是难于发现可重用的资产并跨越各种技术使用它们。一个服务应该能够在一个众所周知的目录中描述和注册自身，而希望调用服务的客户端则应该能够完全基于已注册的信息来调用服务。

　　自包含。一项操作的语义应该由即将进行的操作中的信息和服务状态所决定，而不应该依赖于其他某个服务的状态或上下文。这种隔离使得理解服务提供的功能和对其进行重用变得更加容易。

　　定义SOA

　　现在，让我们看一看一些SOA的不同定义。W3C把SOA定义为“一组可调用的组件，其接口描述可以被公开和发现”。我个人不太喜欢该定义中使用的组件这个词，因为组件是一个被过度使用的术语，会让人联想起特定的内容，比如ActiveX、EJB等等。然而，如果我们使用服务来代替组件这个词，那么这种定义是合理的。

　　ZapThink是一家行业分析公司，它把SOA定义为“一种架构准则，其中心内容是把IT资产描述和公开为服务。然后可以把这些服务以松散耦合的方式作为高级业务流程的一部分，从而在面临IT异构性时提供业务灵活性”。我较为喜欢这个定义，因为它使用了IT资产这个术语来定义SOA，范围更为广泛。此外，它还指出了SOA的一个重要特性——松散耦合(稍后将进行详细说明)，并提及了SOA的优点。

　　最后一个定义来自于BEA的dev2dev站点的SOA技术中心，在这个定义中，SOA被定义为“一种设计方法，其目标是重用应用中立的服务，从而提高IT适应性和效能”。这是SOA在业务层的一个优秀定义。它强调了一个事实：SOA不仅仅是一个技术工件(像接口和协议一样)，它其实是一种设计方法，具有最大化重用的明确目标。我想为这个定义添加一些内容：它不仅是设计方法(这只是前端部分)，还是涉及到服务的整个生命周期——服务的设计、部署、维护和最后的停止使用——的方法。

　　希望这3个定义能够让您了解什么是SOA及其目标。在进入下一节内容之前，我想谈谈SOA的一个重要特性——松散耦合。耦合即组件相互依赖的程度。可以将服务设计在一起，即紧密耦合;也可以动态发现和使用服务。松散耦合是我们想要实现的目标，因为它可以降低服务或组件之间的相互依赖性，并让您可以轻松替换或更新服务。

　　SOA和分布式技术

　　从有关CORBA和J2EE的讨论中，您可以看到，这两种技术都提供了构建SOA的方法。这些技术已经跨不同行业进行过几次成功的部署。然而，如果要在企业级评估重用，那么即便是在已经部署这些技术的企业中，重用也没有达到应有的水平。在某些企业中，从业务的角度看，大量“服务”实际上都在执行同样的任务，比如验证信用卡、查找雇员等等，这种情况并非罕见。

　　为什么会存在这种重复呢?主要有如下两个原因：

　　异构性或多中间件问题：一家典型的企业通常使用多种应用程序、工具和技术。同样的情况也适用于中间件：Java领域可能使用J2EE，而Microsoft领域则使用DCOM，诸如此类。从构建服务的角度看，这意味着可以通过多种方式描述接口(IDL用于CORBA，MDL用于DCOM，Java用于J2EE)。此外，由于每项技术都定义了自己的传输协议，所以有多种使用这些服务的方式。尽管人们曾经尝试搭建“桥梁”来连通这些技术之间的不同编程模型和传输协议，但实际的用户体验还是很糟糕：无法理解的映射(试试从Java到IDL的映射就知道了)，这类“桥梁”的糟糕性能，供应商由于互操作性问题而相互责怪。简而言之，无论是定义还是使用服务的方式都不是通用的，从而影响了互操作性，而使重用难以实现。

　　这些技术的复杂性：这些技术都相当复杂，难于学习，需要了解一个新的API和一个新的编程模型才能使用这些技术。使用这些技术构建服务需要编写大量的代码，尤其是对于CORBA来说。在这方面，J2EE做得要稍好一些，因为它支持使用更为声明式的方法来构建服务。然而，即使是J2EE也无法让人满意，因为程序员要掌握数十个API才能达到一定的效率。复杂性的另一方面体现在管理这些服务的生命周期上，例如，部署服务、对服务进行版本控制、停止使用服务。这些技术在这方面的支持很差，只有J2EE稍好一些，而CORBA和DCOM都有其各自的优点。然而，对于每个企业来说，有效地管理这些服务都是一件伤脑筋(且开销巨大)的事情。

　　所以，尽管分布式组件技术为构建SOA提供了明确支持，并且基于行业认可的标准，但上述两个因素在企业层面上妨碍了重用的实现。注意，实际的情况还要更糟，因为要使用这些基于标准的技术，企业需要让系统基于专用的中间件技术，比如MQ和TIBCO。所有这些系统，无论是基于标准的还是基于专用技术的，都应该被认为是企业的IT资产，因为在构建这些系统的过程中企业进行了大量的投资。这些现有系统中已经存在的功能必须被公开为可重用的服务，从而使用它们轻松构建新的系统。使用CORBA和J2EE的经验告诉我们，引入另一组API或另一种传输协议无法解决这个问题。我们需要做的是对消息格式进行标准化，并使用已经在企业中普遍应用的传输协议，比如MQ和IIOP。在下一节中，您将会看到Web services是如何满足这种需求的。