定义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都有其各自的优点。然而，对于每个企业来说，有效地管理这些服务都是一件伤脑筋（且开销巨大）的事情。
文章来源于领测软件测试网 https://www.ltesting.net/
