|
话说天下大事 分久必合合久必分(三国演义)软件行业是不是也一样呢? 现在的软件行业有着各种各样的技术平台体系架构但由于不同平台关注的方面不一样各有各自的特色平台之间很难沟通从而形成一个个的信息孤岛．那如何把这些信息孤岛联系在一起呢?业界提出了很多的方案一个很着名的方案就是 ServicedOriented (面向服务)那面向服务是什么呢?这是对它的定义: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()面向服务是一系列服务的集合各个服务之间可以互相通信(包括简单的数据传递和多个服务共同参与一个活动) 它通过为各个系统提供一些外部接口从而达到集成各个系统的目的．业界也有些相对应的体系架构例如: DCOMCORBAJEE但都无法彻底实现跨系统的集成个人觉得原因如下: 接口定义语言无法被不同系统所接收．无论是DCOMCOBRA 还是JEE都有各自的接口定义语言(都是二进制的)它们都无法被其他系统所接受而接口一旦被设定就很难改变而用户的需求是在不断变化的 使用的是二进制的网络协议来进行数据通信很难跨过防火墙而且各自使用的协议没有被广泛的接收这点对Internet的运用尤为关键 这时一种新的体系架构出现了它就是XML Web Services微软对它的定义是 : XML Web services 是提供特定功能元素（如应用程序逻辑）的可编程实体任何数量的可能是完全不同的系统都可以用常见的 Internet 标准（如 XML 和 HTTP）访问它它的核心特征是存在于服务的实现与使用之间的高度抽象化 Web Services正在迅速的被各个平台所接受相对于其他架构它的优势在与: 接口定义语言它使用WSDL作为接口定义语言这是一种基于XML格式的Document 而文本是可以被各种系统和平台所认识的 使用HTTPSOAPSMTP等其他被广泛接受的协议进行数据通信而HTTP是Internet的基础协议之一 那如何深入的理解Web Services呢?个人觉得应从以下几个方面入手: 一目的 它是实现SOA的一种方式是为了连接不同的系统和计算设备实现系统和数据的互操作性 简单的说是要能够访问不同的系统和计算设备中的数据而不用关心这些数据在各自系统和设备中是如何存放的也可以说成不用关心数据是如何封装的(类似OO里的黑盒) 二定义 XML Web Service顾名思义就是使用XML来提供Web服务．其实严格的说Web可以不要就是XML Service因为并不是所有的Web Service都需要WebServer的．服务就是把我有的功能提供给使用者也就是向使用者提供一个接口这就是Web Service．因此Web Service绝对不是一种新的分布式对象而DCOM CORBAJEE 本质上都是分布式的对象 三组成 一些能处理XML的组件． 首先XML Web Service(或者Web Service)要能够处理XML至于处理XML的组件是如何设计的不同语言平台有不同的方式可以是OO(面向对象)的也可以是其他方式在Net里是通过Net Framework 提供的一些类实现的 XML 文档 前面我们说过Web Service优势之一在与接口定义语言(IDL)是基于XML的文档由于Web Service 是SOA(面向服务)的一种而SOA的目标是在系统之间建立一种松散的耦合因此服务和消费服务方就不能以Object作为数据沟通的纽带或者说锲约(Contract) 就必须使用XML文档来做为锲约那为了使服务提供方和消费方都能够理解Contract的含意Web Service使用WSDL来描述XML文档即描述对外的接口．同时使用XML Schema来描述文档里的数据 XML文档的载体 有了ＸＭＬ文档就需要一个承载它的协议．Web Service使用SOAP作为载．SOAP:简单对象访问协议严格来说这个名称是错的因为它不是用来访问对象的．MS给它的定义是 SOAP 是一种基于 XML 的用于在 Web 上交换结构化和类型信息的简单的轻量协议．它以信封的方式来承载XML文档．信封分为两部分: 信封头(head) 和信封体(body)．头一般用来保存一些辅助的信息例如安全(签名和加密数据)和路由信息信封体用来保存锲约即服务的接口描述和具体的数据 服务的地址 用来告诉服务消费方从哪里可以访问服务服务位于何地对此 Microsoft提供了UDDI(通用说明发现和集成) Net 实现Web Service的方式是通过ASPNET．它封装了很多的细节使开发人员开发WebService很方便但造成的结果是使认识本质比较困难(MS的一贯作风)． l 通过Web方法的形式来调用Web Service． 前面说了Web Service之间交换的实际上是XML文档考虑到很多程序员 不习惯直接操作XML(喜欢操作对象及其方法)在Net里将接收到的 XML文档转换成对象或作为方法的参数的值同时又会将得到的值或对 象反序列化成XML文档发送回服务消费者服务消费者就可以以传统的 调用对象的方法的形式来向服务提供者发送请求从而获得希望的数 据．从消费者提出服务申请到得到相应的结果的流程如下(): 由这个流程图()可以看到客户端要调用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 对于数据(ABC……)它们即是服务提供者同时也是服务消费者．由于用户 需要能够能直接查询一些数据因此对于用户我们给每个数据做了一个网站以 方便用户查询(使用 建立) 前面我们说了服务是将已有的功能和数据通过接口公开而不需要关心功能和 数据在各自的系统中是如何实现的因此对功能和数据本身依然可以采用既有 的技术实现功能和数据部分还是采用三层架构将Web Service作为一个独立的 层(Facade层)框架图如下: Net提供了Asmx文件作为具体实现的文件在具体实施的过程中有几个问题要注意: l SOAP的格式 Soap是服务锲约的载体它本身也有一定的格式．对于SOAP中的信封有两种格式 Document |
