面向服务体系结构(SOA)漫谈).docVIP

面向服务体系结构（SOA）漫谈 摘要：本文简单的对于面向服务体系结构 SOA 进行了介绍，并且对SOA的特点进行了整理，以及对SOA的未来做了展望。 一 SOA定义 SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。从这个定义中我希望表达的前提有下面两点： 1 软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一 种模式 Pattern 。因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的应用场景，用来满足不同的特定需求。 2 SOA的使用范围：需求决定同时也限制功能。SOA并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业 务集成问题。在下面我们会详细讨论Internet的各种特点如何决定SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于 Intranet环境的几个特点： a 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同； b 大量、频繁的数据传输仍然速度缓慢并且不稳定； c 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。 前看来大多数软件的功能最终将作为服务来交付和使用。当然，它们可以实现为紧密耦合的系统，但从门户、 设备以及其它终端使用的观点看，它们将使用一种面向服务的接口。 我们已经注意到有人提出体系架构师和设计者应该谨慎避免将所有功能都作为服务。我们认为 这是不正确和不适当的。如果有了成熟的Web服务协议和技术，再考查是否将所有功能实现为Web服务是否有效，这可能会 更加有效，但这并不会减弱从服务的角度来设计所有功能的需求。服务是发布的主要构造成分，应该在每一重要的接口中使用。 面向服务的体系结构可以让我们按照相关的服务来管理使用（发送、接收、使用，等等）服务。这将对我们如何管理软件生命周期 产生重大影响－－从需求规格说明开始就作为服务，服务的设计，服务的获取和外包，以及服务的评估等等。 随着时间推移，功能被说明、发布或 使用的抽象级别会逐渐越来越高。我们已经经历了从模块化、对象，到现在的服务的发展过程。 然而，在许多方面，SOA的命名还是令人遗憾的。当然，SOA也和体系结构相关，不可能将讨论限制在体系结构方面，因为一些事物，如业务 设计和发送过程也是重要的考虑因素。一个更有用的命名方法可能是面向服务（Service Orientation）或SO。实际上这与面向对象（OO） 和基于组件的开发（CBD）有许多相似之处： 类似于对象和组件，服务代表了自然的建造单元块，它可以让我们按更熟悉的方式来组织功能。类似于对象和组件，服务是一个功能建造单元块，它可以组合信息和行为。隐藏内部的工作，以防外部入侵。为其它部分提供一个相对简单的接口。对象使用了抽象数据类型和数据抽象，服务可以通过方面或上下文环境提供类似级别的适应性。对象和组件可以按照类或继承行为的服务层次 来组织，服务可以单独发布和使用，或者按层次或协作方式来使用。对于许多组织来说，研究面向服务的体系结构的起点是对Web 服务的考虑。然而Web服务不是内在的面向服务的。 一种Web服务只是提供一种符合Web服务协议的功能。在本文中，我们将要标识一个结构良好的服务所具有的特征，并为系统架构师和设计者提供关于如何交付 面向服务的应用程序的指导。 基于上面的前提，下面就让我们一起看一下SOA的基本特征。 二SOA三大基本特征 1 独立的功能实体 在 Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非 常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主 Host或者Server 来存放和管理这些功能实体；当这些宿主运行结束时这些组 件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。 SOA架构中非常强 调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理 Transaction ，消息队列 Message Queue ，冗余部署 Redundant Deployment 和集群系统 Cluster 在SOA中都起到至关重要的作用。 2 大数据量低频率访问 对 于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成