简要介绍下soa及个人对webservice的理解.就一个具体的项目介绍下实施过程中一些需要注意的问题
引用文章:
(1) http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
(2) ms-help://ms.vscc.2003/ms.msdnqtr.2003feb.2052/cpguide/html/cpconanatomyofsoapwebservicelifetime.htm
(3) ms- help://ms.vscc.2003/ms.msdnqtr.2003feb.2052/cpguide/html/cpconcustomizingsoapinaspnetwebserviceswebserviceclients.htm
“话说天下大事, 分久必合,合久必分.”(三国演义)----软件行业是不是也一样呢?
现在的软件行业有着各种各样的技术平台,体系架构,但由于不同平台关注的方面不一样,各有各自的特色,平台之间很难沟通,从而形成一个个的信息孤岛．那如何把这些信息孤岛联系在一起呢.?业界提出了很多的方案,一个很著名的方案就是 serviced-oriented (面向服务).那面向服务是什么呢?这是对它的定义:“soa is an architectural style whose goal is to achieve loose coupling among interacting software agents. a service is a unit of work done by a service provider to achieve desired end results for a service consumer. both provider and consumer are roles played by software agents on behalf of their owners.”(1).面向服务是一系列服务的集合.各个服务之间可以互相通信(包括简单的数据传递和多个服务共同参与一个活动) ,它通过为各个系统提供一些外部接口,从而达到集成各个系统的目的．业界也有些相对应的体系架构,例如: dcom.corba.j2ee.但都无法彻底实现跨系统的集成.个人觉得原因如下:
1. 接口定义语言无法被不同系统所接收．无论是dcom.cobra 还是j2ee都有各自的接口定义语言(都是二进制的).它们都无法被其他系统所接受.而接口一旦被设定就很难改变.而用户的需求是在不断变化的.
2. 使用的是二进制的网络协议来进行数据通信.很难跨过防火墙,而且各自使用的协议没有被广泛的接收,这点对internet的运用尤为关键
这时一种新的体系架构出现了,它就是xml web services,微软对它的定义是 : “xml web services 是提供特定功能元素（如应用程序逻辑）的可编程实体，任何数量的、可能是完全不同的系统都可以用常见的 internet 标准（如 xml 和 http）访问它。它的核心特征是存在于服务的实现与使用之间的高度抽象化。” web services正在迅速的被各个平台所接受.相对于其他架构,它的优势在与:
1. 接口定义语言.它使用wsdl作为接口定义语言.这是一种基于xml格式的document ,而文本是可以被各种系统和平台所认识的.
2. 使用http,soap,smtp等其他被广泛接受的协议进行数据通信.而http是internet的基础协议之一
那如何深入的理解web services呢?个人觉得应从以下几个方面入手:
一. 目的
它是实现soa的一种方式,是为了连接不同的系统和计算设备.实现系统和数据的互操作性
简单的说是要能够访问不同的系统和计算设备中的数据.而不用关心这些数据在各自系统和设备中是如何存放的.也可以说成不用关心数据是如何封装的(类似oo里的黑盒)
二. 定义
xml web service顾名思义就是使用xml来提供web服务．其实严格的说web可以不要,就是xml service,因为并不是所有的web service都需要webserver的．服务就是把我有的功能提供给使用者,也就是向使用者提供一个接口,这就是web service．因此web service绝对不是一种新的分布式对象.而dcom , corba,j2ee 本质上都是分布式的对象.
三. 组成
1. 一些能处理xml的组件．
首先xml web service(或者web service)要能够处理xml,至于处理xml的组件是如何设计的.不同语言,平台有不同的方式.可以是oo(面向对象)的.也可以是其他方式.在.net里是通过.net framework 提供的一些类实现的
2. xml 文档
前面我们说过web service优势之一在与接口定义语言(idl)是基于xml的文档,由于web service 是soa(面向服务)的一种,而soa的目标是在系统之间建立一种松散的耦合,因此服务和消费服务方就不能以object作为数据沟通的纽带或者说锲约(contract) ,就必须使用xml文档来做为锲约.那为了使服务提供方和消费方都能够理解contract的含意.web service使用wsdl来描述xml文档.即描述对外的接口．同时使用xml schema来描述文档里的数据
3. xml文档的载体
有了ｘｍｌ文档就需要一个承载它的协议．web service使用soap作为载．soap:简单对象访问协议,严格来说这个名称是错的,因为它不是用来访问对象的．ms给它的定义是” soap 是一种基于 xml 的、用于在 web 上交换结构化和类型信息的简单的轻量协议”．它以信封的方式来承载xml文档．信封分为两部分: 信封头(head) 和信封体(body)．头一般用来保存一些辅助的信息,例如安全(签名和加密数据)和路由信息,信封体用来保存锲约即服务的接口描述和具体的数据
4. 服务的地址
用来告诉服务消费方从哪里可以访问服务,服务位于何地,对此
microsoft提供了uddi(通用说明、发现和集成).
net 实现web service的方式是通过asp.net．它封装了很多的细节,使开发人员开发webservice很方便,但造成的结果是使认识本质比较困难.(ms的一贯作风)．
l 通过web方法的形式来调用web service．
前面说了web service之间交换的实际上是xml文档,考虑到很多程序员
不习惯直接操作xml(喜欢操作对象及其方法),在.net里将接收到的
xml文档转换成对象或作为方法的参数的值,同时又会将得到的值或对
象反序列化成xml文档发送回服务消费者,服务消费者就可以以传统的
调用对象的方法的形式来向服务提供者发送请求从而获得希望的数
据．从消费者提出服务申请到得到相应的结果的流程如下(2)-:
由这个流程图(2)可以看到.客户端要调用web service首先要发送消息.
而服务端是通过消息知道有消费者要调用它．因此从某种意义上说.web
service是一种基于消息的体系架构,只不过消息是基于xml的文档
l 代理类的产生
代理类的作用是用来方便和web服务进行通信的.在.net 里可以以自动和手
动的方式产生,两者都是根据服务的wsdl文件产生的.正如前面所说为了方便
程序员的习惯用法,.net会将xml文档反序列化成对象,在代理类里也是同样的.
这样就会给我们一种错觉,好像在客户端重新生成了服务端的对象.例如: 一个
web方法 test向客户返回一个objecta
public class objecta
{
public string fielda
public string fieldb
}
那么在代理类同样会生成一个objecta.它的结构和服务端的objecta是一模一
样的.但实际上这只是.net为了方便我们使用web service而人为生成的(这也是
很多人认为webservice是用来进行远程对象访问的原因之一).对web服务客户
端而言,接收到永远只有xml文档,文档里的数据是以xml schema描述的.至于
怎么使用是各个web客户端各自的特点,对.net而言它会将一些复杂的自定义
的xml schema类型转换成object.其他的一些客户端就不会转换成object.例如
soap tookit.它会转换成一个xml 节点(node)对象
下面就结合一个实际的项目来说明如何实施web service.
一. 项目概况
某公司有个现有产品producta.(pa) ,它需要获得一些数据来进行业务处理．这些数据按地区和时间是会变化的,同时数据是由相应的政府机构定的,不同地区的政府机构的数据是不同的,每变动一次都需要以公函的形式通知产品用户,或者由公司自己整理然后告诉用户去更新．这样就造成不同地区有不同版本,用户升级困难,同时政府机构之间的数据很难沟通和对比
二. 解决方案
利用web service的功能,将所有政府机构的数据都公开(当然要权限的 j)．产品(pa)作为webservice的客户端可以实时访问不同的数据,这样产品和数据之间,数据和数据之间,用户和数据之间都无缝的联系在一起了
三. 具体实施
有了服务就有服务的两个参与者：服务的提供者和服务的消费者
对于产品(pa)它是服务的消费者．因此它只是个web service client.可以是任
何类型的程序．现有的pa是个vb版的程序,可以通过代理类来访问不同
的 service.
对于数据(a.b.c…….).它们即是服务提供者同时也是服务消费者．由于用户
需要能够能直接查询一些数据,因此对于用户,我们给每个数据做了一个网站以
方便用户查询(使用asp.net 建立)
前面我们说了服务是将已有的功能和数据通过接口公开而不需要关心功能和
数据在各自的系统中是如何实现的,因此对功能和数据本身依然可以采用既有
的技术.实现功能和数据部分还是采用三层架构,将web service作为一个独立的
层(facade层).框架图如下:
.net提供了asmx文件作为具体实现的文件.在具体实施的过程中有几个问题要注意:
l soap的格式
soap是服务锲约的载体,它本身也有一定的格式．对于soap中的信封.有两种格式 document和rpc．对于soap请求和响应中的数据有两种格式: encoded 和literal.
document 样式是指将 body 元素格式化为 body 元素下的一个或多个连续的消息部分(3).是使用xsd schema的
rpc 样式是指根据 soap 规范中对 rpc 使用 soap 的内容（也就是通常所说的 soap 规范的第 7 节）对 body 元素进行格式设置(3).它是将所有的元素封装在一个xml元素中,不需要使用xsd schema
literal样式是将参数驻留在 body 元素中并编码为自包含的 xml 文档.使用xsd schema
encoded样式是使用 soap 规范中编码规则进行格式设置的.它不需要xsd schema
在asp.net中document/ literal是默认的设置．literal只能在document下才
能使用,而encoded可以同时在document和rpc下使用．我们可以自定义
soap的样式．.net提供了属性来完成这个功能:
soapdocumentmethod
soapdocumentservice
soaprpcmethod
soaprpcservice
具体的使用请参考msdn
l 实体(entity)的设计
项目中我没有用dataset.用了自定义的类.主要的考虑是
a. 操作起来方便
b. dataset是个粗粒度的对象.包括一些我们不需要的属性和对象.增加了访问时间
如果web方法将实体作为参数时,需要对实体的有效性进行判断．例如.实体中属性内容是否为空,值的长度等等．由于.net会自动将接收到的xml消息反序列化成对象,而对象的值是客户端设置的,我们无法控制.那这时就有必要进行数据有效性的判断了．一般有三种办法.
a. 在商业逻辑层进行验证.
这样的缺点时代码量比较多,尤其时当属性比较多的时候,改动不方便
b. 通过实体对应的xsd文件来进行验证
c. 通过设置在实体属性上的attribute来进行验证
b和c都利用了反射技术来实现,优点是减少了代码量,改动比较方便,推荐使用．我在项目里用了attribute的方法.
l webservice的安全
安全性是web service 一个很重要的方面.
安全主要包括授权和签名这两方面．microsoft和其他公司共同提出了一
个工具包来解 决这个问题：web service enhancment(wse)- .现在最新
的版本是2.0. 实现了很多重要的service规范..
l exception的实现
web service里通常会将异常以soap错误的形式发布．在soap消息中有个fault元素是专门用来保存这些信息的．在用asp.net创建的web service中是先将异常序列化然后放到fault元素中的．一般会将错误封装成soapexception向客户端抛出,但如果遇到了soap中header部分的错误就会抛出一个soapheaderexception．对于soapexception,错误信息是放在detail属性里的,里面包含错误的详细信息．在实际应用过程中这些详细信息对客户是不友好的,这时就需要我们重新封装下soapexception了．方法是在抛出异常的服务端给detail属性(序列化成detail元素)增加一个子元素用来存放一些友好的错误信息,然后在接收端就向用户显示出在这个子元素下的错误信息
