1. SOA综述
1.1 SOA的含义
SOA是一个基于特定标准的组织和设计方法,SOA在传统的业务层和技术层之间增加了一个服务层,通过连接能完成特定服务的独立功能实体来实现软件系统架构。它将业务层和技术层之间的信息有效地进行沟通,让企业应用层可以彻底摆脱技术的束缚。将注意力放在服务上,使得应用程序能够集中起来提供更加丰富、更加灵活、目的性更强的商业流程,使得基于SOA的企业应用系统能够更加真实地反映出与业务模型的结合。
SOA是一种架构模型,它可以根据需求通过网络对松散藕合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。
SOA的关键是“服务”的概念,W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化,但也可能使提供者的状态改变,或者双方都产生变化”。
Gartner则将SOA描述为:“客户端/服务器的软件设计方法,一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处,在于它着重强调软件组件的松散祸合,并使用独立的标准接口。”
虽然不同厂商或个人对SOA有着不同的理解,但是我们仍然可以从上述的定义中看到SOA的几个关键特性:一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。
1.2 SOA的特征
(1)松散藕合
服务请求者到服务提供者的绑定与服务之间是松藕合的。松散藕合旨在将服务提供者如何实现服务和服务使用者如何使用服务方面隔离开来。服务接口作为与服务实现分离的实体而存在,服务请求者不知道提供者实现的技术细节,比如程序设计语言、部署平台,等等。服务请求者往往通过消息调用操作请求消息和响应,而不是通过使用API和文件格式。服务实现的修改完全不会影响到服务的使用者。
(2)粗粒度服务
服务粒度(service granularity)指的是服务所公开功能的范围,一般分为:细粒度和粗粒度。其中,细粒度服务是那些能够提供少量商业流程可用性的服务。粗粒度服务是那些能够提供高层商业逻辑的可用性服务。粗粒度服务可以灵活组合稳定性强、重用性高的细粒度服务,而快速形成新的业务逻辑。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构(SOA)不要求使用粗粒度接口,但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。
(3)标准化的接口
服务描述的重点在于与几部分交互所用的操作: 服务、调用操作的消息、构造这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息的信息。SOA通过服务接口的标准化描述,从而使得该服务可以提供给在任何异构平台和任何用户接口使用。该接口隐藏了实现服务的细节,允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。
(4)无状态服务
服务应该是独立的、自包含的请求,在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时,它们最好定义成通用业务流程、函数和数据模型,而不是实现构件(比如会话密钥)。
1.3 SOA的基本架构
1.展现层(Presentation):通过portal (门户)等技术建立展现平台,方便用户在这个界面上提出服务请求。
2. 业务处理建模(business process modeling): SOA元模型从模型驱动架构MDA(Model Driven Architecture)中继承了平台无关模型来对业务处理过程建模。这一部分独立于服务设计和部署层。MDA的主要缺陷是在模型设计阶段就对需求有完整的描述,而且没有需求变更的反馈机制。SOA通过添加敏捷方法(AM)来应对需求变更的情况。
3. 服务层(Services):整个SOA的核心层,它承上启下,对上响应业务模型,对下调用相关组件群完成业务需求,形成“业务驱动服务、服务驱动技术”的SOA事务处理格局。服务可以根据粒度分层。虽然细粒度提供了更多的灵活性,但同时也意味着交互的模式可能更为复杂。粗粒度降低了交互复杂性,但敏捷性却下降。
4. 企业组件层(enterprise components):这里是相关组件发挥作用的场所。这些组件是平台相关的。因为到了这一层,许多底层软硬件平台的特性已经不再透明了。
5.系统软件层(Operational System):这一层包括操作系统、数据库管理系统、CRM、ERP、商业智能(BI)等异构系统,是一个集成的平台。
除此之外,诸如QoS、安全性等也是SOA架构的组成部分。
1.4 SOA的体系结构
SOA的体系结构包括三个部分:
1. 服务提供者:一个可通过网络寻址的实体,它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心,以便服务使用者可以发现和访问该服务。
2. 服务使用者:一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询,通过传输绑定服务,并且执行服务功能。服务使用者根据接口契约来执行服务。
3. 服务注册中心:服务发现的支持者。它包含一个可用服务的存储库,并允许感兴趣的服务使用者查找服务提供者接口。
2. 基于Web服务的SOA应用基本协议
Web服务是建立可以互操作的分布式应用程序的平台,同时也是一套标准,定义了基于web的互操作的规范。根据这个规范,可以使用任何语言,可以在任何平台上,只要基于web service标准,就可以实现互操作。从表面上看,Web Service就是一个应用程序,它向外界暴露出可以调用的API接口,而其他的应用程序可以远程调用这个接口,我们称提供接口的一端为服务端,而调用接口的一端成为客户端。从这个意义上说,web服务不过是通过提供调用标准,实现了接口的远程调用。但是实际情况并非如此简单,首先提供了分布式调用后,可以分离出服务提供方和服务消费方,这样便于开发的时间实现协作,而且彼此松散耦合,给开发带来了方便;第二正是因为服务提供方和消费方的分离,这样恰恰符合SOA的理念,因此是实现SOA的一个比较好的技术;第三由于要实现远程调用,那么面临新的问题,就是网络通信和本地调用不一样,它存在网络调用中出现调用失败的问题,同时也决定了不能频繁的调用,那么这样就出现了如何划分服务粒度的问题,这些问题又恰恰需要利用SOA的思想进行解决。
尽管 Web Service是一种比较好的SOA实现,但是SOA和Web Service之间有着根本的区别。首先SOA是一个体系架构,强调系统的逻辑层面的设计,而 Web Service则是一种实现方法,属于技术层面的内容;其次基于SOA思想的实现未必只有Web Service,同样,基于 Web Service实现的应用也未必符合SOA思想。但是目前它们的结合则具有广阔的应用前景,因此这个部分具有重要的意义。下面从开发的角度来认识Web Service的基本协议。
2.1 XML
XML即为可扩展的标记语言(eXtensible Markup Language),XML是一套定义语义标记的规则,这些标记将文档分成许多部件并对这些部件加以标识。
XML是标记语言。理解XML,首先要理解标记,可以从熟悉的HTML的标记(Markup)来讨论,通俗地讲,它就是一种用来给文本添加标记的语言。在HTML里每个标志都是有确切含义的。例如,在HTML中,标签<B>的含义是要求HTML浏览器将一段文本加粗表示,而标签<CENTER>的含义是告诉浏览器将这段文本在一行的中间显示。而XML并非象HTML那样,提供了一组事先已经定义好了的标签,而是提供了一个标准,利用这个标准,可以根据实际需要定义自己的新的置标语言,并为你的这个置标语言规定它特有的一套标签。准确的说,XML是一种源置标语言,它允许你根据它所提供的规则,制定各种各样的置标语言。从这个意义上说XML是比HTML更抽象的一个语言,利用XML可以定义出类似HTML一样的语言来,所要做的工作就是对XML的部分进行定义。
XML具有如下的优点:
(1)XML允许各种不同的专业(如音乐、化学、数学等)开发与自己的特定领域有关的标记语言。比较早而且比较典型的是下面两个实例:化学置标语言 CML(Chemistry Markup Language)、数学置标语言 MathML(Mathematical Markup Language)。这就使得该领域中的人们可以交换笔记、数据和信息,而不用担心接收端的人是否有特定的软件来创建数据。
(2)XML具有较好的保值性.过去40年来的大多数计算机数据都丢失了,不是因为自然损害或是备份介质的磨损,而只是因为没有人来写出如何读取这些数据介质和格式的文档。以不常用的格式保存的二进制数据,数据也许会永远地消失了。XML在基本水平上使用的是非常简单的数据格式。可以用100%的纯ASCII文本来书写,也可以用几种其他定义好的格式来书写。
(3)应用间交换数据.由于XML是非专有的并易于阅读和编写,就使得它成为在不同的应用间交换数据的理想格式.XML使用的是非专有的格式,不受版权、专利、商业秘密或是其他种类的知识产权的限制。XML的功能是非常强大的,同时对于人类或是计算机程序来说,都容易阅读和编写。因而成为交换语言的首选。
(4)XML还具备简单数据库的功能,可以用来保存和检索数据,可以作为一个小型的数据库使用,这个可以说超出了一般语言的范畴。
2.2 SOAP
SOAP (simple object Access protocol) 简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议,是一个基于XML的协议。它包括四个部分:
1. SOAP封装(envelop): 封装定义了一个描述消息中的内容是什么,是谁发送的,谁应当接受并处理以及如何处理它们的框架。
2. SOAP编码规则(encoding rules): 用于表示应用程序需要使用的数据类型的实例。
3. SOAP RPC表示(RPC representation): 表示远程过程调用和应答的协定。
4. SOAP绑定(binding): 使用底层协议交换信息。
SOAP采用了已经广泛使用的两个协议:HTTP和XML。其中HTTP用于实现SOAP的RPC风格的传输,而XML是它的编码模式。一个SOAP请求实际上就是一个HTTP POST请求。
2.3 WSDL
己经有了SOAP协议,就解决了如何进行通信的问题。因此下一步就是要解决通信内容的问题,其实也就是如何描述Web服务,这就是WSDL(Web Services Description Language),包括参数的传递和结果的返回等内容,而它本身是由XML定义的,是一种XML文件。目前WSDL 2.0已经成为标准,并获得了广泛的支持。
WSDL就是描述Web服务的标准XML格式,它用一种和具体语言无关的抽象方式定义了给定Web服务收发的有关操作和消息。业务之间将通过交换WSDL文件来理解对方的服务,可以将服务看作是通过SOAP访问的对象。
WSDL文档将服务定义为网络端点或端口的集合。在WSDL中,由于端点和消息的抽象定义已从具体的网络部署或数据格式绑定中分离出来,因此可以对抽象定义进行再次使用: 消息,指对交换数据的抽象描述; 而端口类型,指操作的抽象集合。用于特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将网络地址与可再次使用的绑定相关联,可以定义一个端口,而端口的集合则定义为服务。因此,WSDL文档在网络服务的定义中使用下列元素:
1. Types:数据类型定义的容器,它使用某种类型系统(如XSD)。
2. Message:通信数据的抽象类型化定义。
3. Operation:对服务所支持的操作的抽象描述。
4. Port Type:操作的抽象集合,这些操作由一个或多个端口支持。
5. Binding:特定端口类型的具体协议和数据格式规范。
6. Port:定义为绑定和网络地址组合的单个端点。
7. Service:相关端口的集合。
可以说Web服务的开发就是围绕WSDL进行的,因此充分理解和使用WSDL是进行Web服务开发的基础。而编写WSDL的过程就是填写以上七个部分。应该注意的是,WSDL并没有引入新的类型定义语言。虽然WSDL知道,要描述消息格式需要丰富的类型系统,并且它也支持“XML架构规范(XSD)”作为其标准类型系统,但是,由于不可能只用一种类型系统语法来描述现在和将来的所有消息格式,因此WSDL允许通过扩展来使用其它类型定义语言。
此外WSDL还定义了通用的绑定机制。通过该机制可使特定的协议、数据格式或结构与抽象的消息、操作或端点相关联。该机制还允许对抽象定义进行再次使用。
2.4 UDDI
统一描述、发现和集成协议(UDDI,Universal Description Discovery and Integration)是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范,同时也包含一组能够使其他企业发现所需web 服务的访问协议的实现标准。
UDDI解决了企业遇到的大量问题。首先,它能帮助拓展商家到商家(B2B)交互的范围并能简化交互的过程。对于那些需要与不同顾客建立许多种关系的厂家来说,每家都有自己的一套标准与协议,UDDI支持一种适应性极强的服务描述,几乎可以使用任何接口。规范允许企业在注册中心中发布它所提供的服务,这样发现企业及服务就变得高效而且简单了。对于B2B交易场所提供者,他们需要获得这一行业内的供应商的分类数据,以及它们与计费服务、包装商、运输商、保险公司等之间的关系,UDDI允许动态发现相关的Web服务并将其集成到聚合的业务过程中。UDDI提供一站式搜索有关企业和电子化服务的信息。在UDDI中发布企业与服务信息使其它企业能大范围的访问到这些信息。
UDDI包含于完整的Web服务协议栈之内,而且是协议栈基础的主要部件之一,支持创建、说明、发现和调用M范b服务。UDDI构建于网络传输层和基于SOAP的XML消息传输层之上。诸如Web服务描述语言提供了统一的XML词汇,供描述Web服务及其接口使用。