认清SOA的本来面目.docxVIP

PAGE 1 PAGE 1 认清SOA的本来面目  SOA架构的提出，就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。  　　软件业从最初的面向过程、面向对象，到后来的面向组件、面向集成，直到现在的面向服务，走过了一条螺旋上升的曲线。其实，自从上世纪70年月提出“软件危机”，诞生软件工程学科以来，为了彻底摆脱软件系统开发泥潭，一直也没有放弃努力。  　　在经典软件工程理论中，不管是瀑布方法还是原型方法，都是从需求分析做起，一步一步构建起形形色色的软件系统。但是，需求变更像一个挥之不去的阴影，时刻伴随着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段，甚至上线阶段遭遇应接不暇的需求变更的极端苦痛。客户将变更的需求视为bug(错误)是测试上线阶段的主要问题。  　　如何解决这一问题?能否来一场软件开发和架构的革命?SOA架构的提出，就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。  　　1.定义  　　SOA并不是一个新概念，有人就将CORBA和DCOM等组件模型看成SOA架构的前身。早在1996年，GartnerGroup就已经提出了SOA的预言，不过那个时候仅仅是一个“预言”，当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年，SOA的技术实现手段慢慢成熟了。在BEA、IBM等软件巨头的极力推动下，才得以渐渐风行起来。Gartner为SOA描述的愿景目标是实现实时企业(Real-TimeEnterprise)。  　　关于SOA，目前尚未有一个统一的、业界广泛接受的定义。一般认为:SOA，面向服务的架构是一个组件模型，它将应用程序的不同功能单元服务(service)，通过服务间定义良好的接口和契约(contract)联系起来。接口采用中立的方式定义，独立于详细实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。  　　从这个定义中，我们看到下面两点:  　　·软件系统架构:SOA不是一种语言，也不是一种详细的技术，更不是一种产品，而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它其实更像一种架构模式(Pattern)，是一种理念架构，是人们面向应用服务的解决方案框架。  　　·服务(service)是整个SOA实现的核心。SOA架构的基本元素是服务，SOA指定一组实体(服务供应者、服务消费者、服务注册表、服务条款、服务代理和服务契约)，这些实体具体说明白如何供应和消费服务。遵循SOA观点的系统必需要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。  　　2.SOA三种角色的关系  　　服务是一个自包含的、无状态(stateless)的实体，可以由多个组件组成。它通过事先定义的界面响应服务恳求。它也可以执行诸如编辑和处理事务(transaction)等离散性任务。服务本身并不依靠于其他函数和过程的状态。用什么技术实现服务，并不在其定义中加以限制。  　　服务供应者(serviceprovider)供应符合契约(contract)的服务，并将它们发布到服务代理。  　　服务恳求者(serviceconsumer)也叫服务使用者，它发觉并调用其他的软件服务来供应商业解决方案。从概念上来说，SOA本质上是将网络、传输协议和安全细节留给特定的实现来处理。服务恳求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。  　　服务代理者(servicebroker)作为储存库、电话黄页或票据交换所，产生由服务供应者发布的软件接口。  　　这三种SOA参与者:服务供应者、服务代理者以及服务恳求者通过3个基本操作:发布(publish)、查找(find)、绑定(bind)相互作用。服务供应者向服务代理者发布服务。服务恳求者通过服务代理者查找所需的服务，并绑定到这些服务上。服务供应者和服务恳求者之间可以交互。  　　所谓服务的无状态，是指服务不依靠于任何事先设定的条件，是状态无关的(state-free)。在SOA架构中，一个服务不会依靠于其他服务的状态。它们从客户端接受服务恳求。因为服务是无状态的，它们可以被编排(orchestrated)和序列化(sequenced)成多个序列(有时还采用流水线机制)，以执行商业规律。编排指的是序列化服务并供应数据处理规律。但不包括数据的呈现功能。