soap协议范文1
关键词：Web Services；SOAP；签名；加密；
中图分类号：TP393文献标识码：A文章编号：1009-3044(2011)28-6850-03
大多数应用系统需要在不同组织机构的异构平台间完成数据收集、传递和处理。面向服务的架构是现代应用系统的基础， Web Services作为面向服务的核心，具有跨平台、松耦合、与实现语言无关等特点，是一种分布式模型技术，被广泛应用于现代应用系统中，不同组织采用Web Services技术对外提供服务。这样，应用系统的安全边界由Intranet扩大到Internet，给各组织机构平台的安全性和消息传递的安全带来了挑战。
1 Web Services基础和SOAP规范
1.1 Web Services基础
Web Services是一组通过标准的Web协议可编程访问的Web组件。其涉及的相关技术主要包括可扩展标记语言XML，简单对象访问协议SOAP，Web服务描述语言WSDL，通用描述、发现与集成UDDI。其中XML是Web Services平台中表示数据的基本格式；SOAP是轻量级的协议，它通过XML文档形式发送和接收消息实现异构平台上的不同系统的相互通信和共享数据；WSDL用来描述Web Services所完成的功能和Web Services所提供的服务；UDDI用来注册、已建立的Web Services [1]。
一个典型的Web Services调用和返回的消息传递模型如图1[2]，服务提供方对外提供接口，隐藏内部实现，服务请求方通过调用接口请求Web Services 服务。
Web Services中的消息基于XML格式，以SOAP协议封装，可以通过任意支持字节流的协议传送，而由于HTTP协议的通用性，目前大多都将SOAP与HTTP绑定。
1.2 SOAP 规范[3-4]
简单对象访问协议（SOAP，全称Simple Object Access Protocol）是一种标准化的通讯规范，以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。SOAP消息分为四部分：
1）SOAP信封（Envelope）：定义了一个SOAP消息表示框架，包括消息头Header和消息体Body，消息头中定义消息发送和接收者信息以及附加的特性，消息体中包含发送的数据信息。
2）SOAP编码规则：定义了一组数据序列化的编码规则，定义数据类型。
3）SOAP RPC：表示远程过程调用和响应的约定。 在SOAP RPC请求和相应中，方法调用被串行化为SOAP编码规则定义的，基于XML的数据类型。
4）SOAP 绑定：定义SOAP在传输过程中使用特定底层通信协议的约定。
Web Services使用SOAP进行消息传递，是将每个远程请求串行化为基于XML数据类型，把请求数据和应答数据序列化，附加上消息发送和请求者等信息，以HTTP等协议为底层传输协议。
2 Web Services安全
2.1 Web Services安全问题
Web Services的数据交换是在异构平台间进行，需要跨越不同平台的网络安全边界，在互联网上进行消息传送，易受到数据截取、篡改、非授权访问等威胁。所以，安全问题一直是Web Services亟需解决的，Web Services安全必须是覆盖消息传输的所有的协议层，不能仅考虑孤立的单个协议层。消息传递的安全主要包括四个方面：机密性、完整性、不可抵赖以及授权访问。
Web Services服务提供方一般使用边界防火墙处理Web Services的消息验证，对访问接口的数据包源地址进行验证，但数据包的源地址是易于伪装，而且由于Web Services在传输层采用HTTP作为传输协议，其内容大多数的防火墙并不检查或者过滤，防火墙的有效性大大降低。
消息传输层一般采用SSL来对HTTP进行加密，但是通过SSL只能是实现点对点的安全，端对端的安全无法保证[5]。 SOAP是轻量级的基于XML 的协议，本身并不处理安全，并且由于SOAP协议的独立性设计，使得本协议层的安全不能依赖已有的安全协议，例如SSL、TLS、SHTTP和S-MIME。
但是由于SOAP协议采用XML格式，支持模块化的扩展，所以可以对在SOAP消息框架中定义安全标签，对SOAP头进行扩展，将安全信息放在SOAP报头中[6]。
2.2 WS-Security[5]
WS-Security提供了如何将安全令牌证书（security tokens）与SOAP消息关联起来的通用机制，定义了如何利用XMLEncryption 和XML Signature 对SOAP进行加密和签名。WS-Security主要描述以下三种机制，通过其实现消息传输安全的不同方面：
1）通过对SOAP 签名实现完整性要求和不可抵赖性。
2）通过对SOAP加密实现机密性要求。
3）采用安全令牌确认发送者身份，只有授权用户才能进行调用Web Services服务。
WS-Security支持多种安全令牌，包括用户名安全令牌、x.509证书、Kerberos票据等，对SOAP Header进行语法细节定义，规定在SOAP Header中使用定义安全要素，包括安全令牌和签名，在SOAP Body中对数据加密。相比消息传输层的安全，WS-Security更易扩展，而且实现了端到端的安全。
3 安全SOAP实现
以典型的购物网站为例，在用户购买商品时，需要输入用户名和信用卡相关信息，购物网站在向发卡行请求扣款时，调用发卡行的Web Services。这样通过HTTP发送的SOAP消息中包括：
< Header>
< Body>
< requestPayment>
< ID>13423
4392122109980678
< expire>05/16< expire>
… … … …
信用卡信息以明文方式在网络上传送。一旦含有这些敏感信息的SOAP包被截获，信息很可能被篡改或泄漏。
根据WS-Security规范，对SOAP 信封封装的全文或敏感部分的数据进行签名和加密，也可以只进行签名或者只进行加密。消息接收者通过验证签名来检验消息的完整性和发送者的真实性，而经过加密的消息，只有被授权用户才能解密，保证消息的机密性。
经过签名和加密的消息传送处理如图2。
图中所示，消息发送者对原始SOAP包中进行签名和加密后，将安全SOAP消息经过互联网发送，接收者对安全SOAP消息进行解密并验证签名后，再进行业务处理。
本文使用常用的x.509标准的证书实现SOAP安全，在SOAP Header中下，加入以下安全令牌信息：
xmlns:wsse="/ws/2002/04/secext"
Id="myCert"
ValueType ="wsse:X509v3"
EncodingType="wsse:Base64Binary">
MIIEZzCCA … …
3.1 签名与验证
本例签名中是用x.509标准的证书，消息发送者首先取得用户证书，使用证书中的私钥，采用特定的散列算法和签名算法，对SOAP Body 中敏感数据进行签名。然后将签名信息，包括签名数reference，签名结果，密钥信息，散列和签名算法等写入SOAP Header，绑定底层协议如HTTP，通过网络传输
一个典型的SOAP签名在Header中下加入节点为：
()
接受方收到消息后，分为两步验证：首先，检查摘要值的有效性，从DigestMethod中获得摘要算法，根据Reference URI中的标识在Body中找到签名数据，算出摘要值，将算出得摘要值与下的比较是否一致。若两者一致，提取KeyInfo中的公钥信息，并从中提取签名算法，将中的值解密后，与摘要值进行比较，验证消息的完整性。
3.2 加密与解密
对SOAP进行加密时，首先从接收方的x.509证书中获得加密的公钥，再用随机或秘密产生的会话密钥对SOAP消息中敏感数据采用对称加密算法加密，而对会话密钥采用非对称加密算法。将加密后数据和密钥信息写入SOAP Body中。
一个典型的SOAP经加密后Body中含以下节点
接收方收到SOAP消息后，根据自己的私钥和消息中的解密得到会话密钥，再根据会话密钥解密中的消息数据。
消息加密后，以密文形式在网络上传送，即使被拦截，非授权用户也不能解密消息，保证了消息的机密性。
3.3 SOAP安全包结构
在对SOAP消息的签名和加密后，SOAP依然符合XML的格式规范，所有签名和加密的信息都在XML SOAP中以节点元素的方式显示，经过签名和加密的SOAP消息结构图如图3。
Security中包括安全令牌和签名信息等信息，写入SOAP报头中，加密数据在SOAP Body中。Reference 中ID属性值与 Encrypted Data中的ID关联，表示Signature是对该部分数据进行的签名。
4 SOAP安全
按照WS-Security规范，通过对XML SOAP进行签名和加密，增强了Web Services的安全，使SOAP消息具有机密性、完整性和不可抵赖性。Web服务请求者，即消息发送方要在原始SOAP包中增加安全信息，需要修改SOAP消息内容，然后通过互联网发送消息。这样，用来生成SOAP 内容的应用也需要修改，破坏了软件工程中功能内聚原则，增加了开发人员的研发和代码维护工作。
Web 服务安全的理想解决方案是对用户以及Web业务隐藏安全细节，不需要用户进行额外设置，也不需要修改Web业务的代码。在增强系统安全性时，尽可能不改变单个Web Service请求和服务的业务代码，使系统更易扩展和维护[8]。
为此，可以采用专门的安全服务器在系统内部处理SOAP的安全，即SOAP安全。SOAP安全负责SOAP包的安全方面的工作，包括对由内向外的SOAP消息进行签名和加密，以及由外向内的SOAP包进行验证和解密。安全验证与Web应用分开，这样的方式减轻了应用服务器的开销，仅专注于业务处理，使得Web服务更具扩展性，安全对业务透明。对已有系统，使用安全，不会额外增加用户和开发人员的工作量。
使用安全的SOAP传输模型如图四，消息发送方生成SOAP消息，传送给SOAP安全，SOAP安全中有一个敏感数据表，保存所有敏感数据标签，例如 表示身份证号、代表信用卡号。安全分析消息发送方传来的SOAP，对含敏感数据标签的数据项签名并加密，封装成安全SOAP包。安全SOAP包通过互联网传给Web Services 服务方，而服务方的SOAP安全接收到SOAP后，在SOAP安全上先进行解密和验证，若验证通过，则解析成其中SOAP数据，给Web Services服务器，否则丢弃SOAP包。这种方式保证了跨越不同安全边界，在互联网上传递的SOAP包是经过签名和加密的。
5 结束语
Web Services安全是目前跨平台应用系统面临的重要安全问题之一，而SOAP作为Web Services数据交换和消息传递的基础，其安全独立底层传输协议。根据WS-Security规范，可以对SOAP 进行扩展，实现SOAP数据的签名和加密，保证了SOAP消息的机密性、完整性、不可抵赖性以及授权访问。采用采用插件式安全的方式处理SOAP安全问题，将业务处理与安全分开，对用户和开发人员透明，易于集成和维护，并且安全还可以重用。
参考文献：
[1] 周劲,刘洋,蔺永政.一种基于Web Service的分布式应用系统的设计[J].计算机应用研究,2007(2).
[2] Web service[EB/OL]./wiki/Web_service.
[3] 师群群,刘晓霞,李艾功.Web Services中SOAP安全性的研究与实现[J].微计算机信息,2008(30):58-59.
[4] 张仙伟,张Z.Web服务的核心技术之一――SOAP协议[J].电子科技,2010,23(3).
[5] WS-Security[EB/OL]./wiki/WS-Security.
[6] 曹刚,李亚伟.基于XML Web Service身份认证的研究与实现[J].微电子学与计算机,2006,23(8).
[7] 景建笃，游晓黔. 安全Web Services 体系结构的研究[J].计算机工程与设计,2007,28(5).
[8] Melzer I,Jeckle M.A Signing Proxy for Web Services Security[EB/OL].2003.jeckle.de/files/signingProxy.pdf.
soap协议范文2
[关键词]XMLSOAP互操作分布式
中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)1210057-01
在企业的信息化进程中,信息资源具有多源海量性、分布异构性、时间动态性等特点,原有的异构分布式系统难以满足信息化进程快速发展的要求,如何实现企业异构系统的资源共享,应用程序的跨平台、跨语言、跨硬件的无缝集成是目前企业集成亟待解决的问题。
一、传统模式的分布式对象互操作存在问题
传统的分布式平台,如Microsoft的DCOM以及Microsoft之外的CORBA
或Java RMI都依赖于周密管理的环境。两台任何的计算机使得DCOM或CORBA在环境之外被成功调用的几率是很低的。特别是在考虑安全性的时候尤其如此。
DCOM和CORBA都依赖于高技术的运行环境。这两个协议都有复杂的规则来处理数据排列、类型信息和位操作。这增加了移植到其他平台的难度。由于存在以上问题,导致这两种系统之间很难实现互操作,而XML和SOAP技术的产生和发展使Internet上分布式对象间的互操作称为可能。
二、基于SOAP实现异构分布式对象互操作的主要任务
1.必须定义一个完整的XML文档语义,使得嵌入在SOAP报文中的XML文档能够被无二义地解析成对特定组件的调用。该定义必须适合各种主流的分布式组件协议,并且是可扩充的,以适合将来新的组件技术。
2.必须实现一个能够接受并处理SOAP报文的SOAP适配器。由于使用标准的HTTP协议,我们需要监听网络的8080端口,接收含有XML文档的SOAP报文。
3.必须实现一个可以接收服务器端返回的SOAP报文的客户端组件,该组件可以使用各种语言开发,使得用户可以容易地处理分布式组件调用的结果。
三、关键技术
(一)标准的数据格式:XML。XML(Extensible Markup Language)是W3C开发的一种可扩展的标记语言,以用于那些目前HTML无法满足要求的应用。它提供了一种新的数据交换的标准,使得为特定的应用制定特殊的数据格式,在各系统之间传递结构化数据成为可能。XML具有以下特征:
1.可扩展性强。XML的层次较高,是一种可用来“设计语言的语言”,引用范围广,并可随着人们的想象空间而无限自由的扩展。
2.异构系统兼容性好。借助XML,异构系统之间可以方便地进行信息交流。XML格式简单易读,对各种类型的数据都能加以标注。只要系统安装有XML解析器,便可解读来自其他系统的信息,进而加以利用。
3.网络应用灵活性强。XML格式的数据文件既能通过网络传送到其他应用软件、对象或中间服务器做进一步的处理,亦可由浏览器进行浏览,为灵活的分布式应用软件的开发提供了支持。
(二)简单对象存取协议SOAP。SOAP以XML形式提供了一个简单、轻量的用于在分散或分布式环境中交换结构化和类型信息的机制。它通常将HTTP作为底层的传输协议,采用XML格式来封装调用请求和回应信息。特别适合面向对象的网络应用系统。SOAP由四部分组成:
1.SOAP信封。它构造定义了一个整体的表示框架,可用于表示在消息中是什么,谁应当处理它。
2.SOAP编码规则。定义了一个数据的编序机制,通过这样一个编序机制来定义应用程序中需要使用的数据类型,并可用于交换由这些应用程序定义的数据类型所衍生的实例。
3.SOAP RPC表示。定义了一个用于表示远端过程调用和响应的约定。
4.SOAP绑定。定义了一个使用底层传输协议(如HTTP\SMTP等)来完成在节点间交换SOAP消息的约定。
四、基于XML和SOAP技术的互操作模型
(一)互操作模型体系结构。在基于Web的异种分布式对象平台的互通中,关键在于双方的异构系统与SOAP报文的转化,使得不同的分布式对象技术可以与SOAP交互通信,因此必须使不同的异构系统支持SOAP,能够与SOAP进行互相通信。为此本文提出一个基于SOAP的分布式对象远程调用系统模型,即以XML为数据表现形式,以SOAP为应用间的通讯协议,通过对服务的统一描述达到共享,实现异构分布式对象的互操作。
SOAP分布式调用系统沿用了DCOM的proxy/stub结构,在客户端和服务器端分别增加了SOAP客户和SOAP服务器一层,原有的调用机制发生了变化,本地内核接收到消息后,不直接发给远程内核,而是发往本地的SOAP客户端,由SOAP客户端发往远程的SOAP服务器。相对而言,COM和CORBA对象的服务器端对象会保持不变,而客户端应用则是千变万化的,并且客户程序与服务器端对象是完全独立的。SOAP客户端提供了相应的API函数接口供客户端调用,即客户端应用程序显示的调用SOAP客户端的API接口,将请求直接发往SOAP客户端。在服务器端,SOAP服务器接到请求后,向服务器端对象发出调用请求,请求的结果直接返回到服务器端SOAP层。
(二)互操作模型的工作原理。当客户端的应用程序需要从网络中某个节点处获得一定的数据或服务时,发现这些数据和服务可能处于一个运行着和客户端不同的操作系统的服务器上,客户端应用程序中负责查找数据的那一部分只要通过调用SOAP客户端提供的API函数,SOAP客户端将完成到网络中查找数据源或服务,并进而传输客户请求、组装应答消息,最后将结果送回应用程序的任务。
SOAP客户端完成的功能包括接收客户程序发出的调用请求,将之转化为SOAP消息格式,并将SOAP请求消息发送到服务器端,服务器端对象执行这个请求,再由SOAP服务器端将执行结果返回到客户端。即SOAP既作为一个HTTP消息,也作为一个SOAP服务器,创建和解开SOAP消息。
这个互操作模型有效的解决了不同类型的对象之间的互相调用的问题,客户只要知道提供服务的对象的URI和对象接口的XML描述,就可以自由的进行远程过程调用,而无需知道对象使用什么机制实现的,调用方和被调用方之间是透明的。
(三)基于XML和SOAP实现异构分布式对象互操作模型分析。基于XML和SOAP实现异构分布式对象互操作模型的优点:
我们在调用各种分布式组件时,可以不受限于其特定的编程框架。具体的组件协议对用户来说时透明的,简化了用户分布式组件的开发。
由于采用了标准的HTTP协议与SOAP协议,在分布对象环境中实现信息资源的重用、重构和共享,实现面向协同应用的相信共享与应用互操作是低成本的,在未来的应用中,也会产生相当大的作用。
由于这种技术可以推广到其他各种分布式组件协议上,也就是说,基于标准的XML解析,使得对各种分布式组件协议的集成成为可能。
五、结束语
随着计算机网络技术的发展,利用网络技术实现信息共享、管理和提
供信息服务的系统越来越称为研究的热点。本文提出了一个基于XML和
SOAP的异构分布式对象互操作模型,一定程度上实现了跨平台的组件通讯以及组件重用的思想,解决了DCOM和CORBA难以在Internet上互相调用、互相通信的局限性,解决了广域、异构信息的互联、互通和互操作问题,达到消除信息孤岛现象,以满足各个组织信息共享需求的目标。
参考文献:
[1]王小非、张鸿海,海上网络战[M].北京:国防工业出版社,2006.
[2]曾宇、查杰民,基于Web服务的应用程序集成的研究[J].计算机工程与设计,2006,27(2).
[3]鞠彦辉,基于Web Services技术的企业信息集成系统架构研究[J].中国管理信息化,2007,10(2).
[4]夏厚德,基于SOAP协议的分布式应用研究[J].武汉科技大学学报,2003,25(3):298-300.
soap协议范文3
电子商务应用系统的安全要素通常包括数据的机密性、完整性、用户授权、身份的可鉴别性和不可否认性等方面。将基于SOAP协议的WebServices[1]技术应用到电子商务，虽然很好地解决了电子商务的应用集成和分布式应用，但由于SOAP协议是一个基于XML的轻量级协议，其设计目标在于它的简单性和可扩展性，在制定时并没有过多考虑安全性要求，加之SOAP协议规范本身没有提供安全解决方案，因此在不安全的公用网络传输时，SOAP消息中的敏感信息很容易被人窃听、篡改或伪造，从而造成数据的泄密和数据完整性的破坏。电子商务中整个WebServices的通信，都是通过SOAP消息来实现的，若不能很好地解决SOAP消息的安全问题，则将极大阻碍WebServices在电子商务领域的应用。
2SOAP消息安全性改进
在电子商务应用中，通信双方常常通过交换商务文档来进行电子商务交易。发送方会将一个或多个文档包装在一个请求消息中，然后发送给接收方；接收方处理该消息的内容后响应发送方。当一些业务应用被调用后，一个包含业务文档的请求将从SOAP发送者发送给SOAP接收者，而位于SOAP接收者端的业务应用将处理这个请求并生成响应，这个响应被回送给发出该请求的SOAP发送者。商务文档的网络传输路径上存在许多恶意的攻击者，它们可以监视网络中传输的消息，并可能按照传输消息的协议格式发送欺骗性的假消息或者对原消息的内容进行更改。比如攻击者中途截取消息，对该消息进行处理之后再转发，这对电子商务的安全构成极大的威胁。
通过对SOAP消息安全性研究发现，所有的攻击都是对SOAP消息的修改，或者在SOAP消息的首部或实体删除一些部分以及在后面附加一些内容，或者添加一些全新的元素[2]。SOAP消息中的XML元素可能被处理而导致一些意外的修改，这会使得原SOAP消息中某些元素的前驱后继关系被改变。而且意外的修改还可能导致SOAP消息中各元素的前驱、后继以及兄弟元素的数量被改变，这样原SOAP消息元素的层次结构也被改变了。SOAP消息可以在传送的过程中被扩展，而在SOAP首部中没有包含与SOAP消息的结构相关的信息，而攻击者利用最多的恰恰是SOAP的层次化结构。所以，本文引入一个称为SOAPRECORDER的数据结构概念，它用来保存SOAP消息的动态结构信息。SOAPRECORDER的基本作用是在其中保存SOAP消息的各元素的结构（例如：首部元素的个数、签名对象的个数以及签名对象的层次信息等等）。这些信息可以在SOAP消息的发送程序创建该SOAP消息的同时进行计算，因此不会引起额外的开销。
2.1SOAPRECORDER结构
SOAPRECORDER信息的结构如图1所示。SOAPRECORDER中包括的内容有：根结构下的子元素的个数、首部元素的个数、签名元素的参考项的个数、签名对象之间的前驱、后继以及兄弟关系和扩展的部分。电子商务文档在网络传输时所受到的攻击主要是利用SOAP消息结构化语法的漏洞，所以解决这一问题的有效的手段就是在SOAP消息中添加SOAPRECORDER信息。消息的接收方在接收到SOAP消息的同时对消息的结构信息进行计算，然后与消息中的SOAPRECORDER信息进行比较，如果两者出现差异，则说明SOAP消息在传送的途中受到了篡改攻击。SOAP消息的发送者如果在消息中添加了SOAPRECORDER信息，那么在发送消息前必须对SOAPRECORDER信息也进行签名，以保证SOAPRECORDER信息在消息传送途中不被篡改。
2.2SOAP消息加密传输
由于SOAP消息在网络传输时受到威胁，所以要对其消息进行加密传输。本文采用一种加密和数字签名技术保证SOAP信息在公开网络上的安全传输[3]。SOAP消息请求者先用哈希函数从原始信息和扩展信息的组合信息中得到信息摘要SHash(M,W,Ex)，其中M为原始信息，W为需要嵌入的加密信息，Ex为扩展信息。并用自己的私密钥对信息摘要加密'()userSKSES，接着利用自己的对称密钥对三者的组合信息加密'(,,)userSSKWEMWEx，然后用服务提供者的公开密钥对请求者的对称密钥加密''()userPKserverWESSK，这样数字签名的正确性就可以由任何请求者公开密钥的人来验证；而加密后的对称只有服务提供者能够用私有密钥解开，这样就保证了SOAP信息在Internet传输过程中的安全。具体步骤如下：（l）数字签名SHash(M,W,Ex)；'()userSKSES；（2）信息加密'(,,)userSSKWEMWEx；''()userPKserverWESSK；（3）数据传输''''UserServer:{S,W,W}；（4）Server信息解密''()serveruserSKSSKDW；（5）Server签名验证（用得到的组合信息与哈希函数计算信息摘要，与解密后的信息摘要比较）''SHash(M,W,Ex)；'()userPKSDS；''?SS（比较两者是否完全一致，如果一致，说明签名正确，反之说明签名无效）；服务请求者构造SOAP消息，消息的Body部分包括上述三个方面的组合信息和服务的访问参数。为保证消息不会被网络上恶意破坏者篡改和伪造，对SOAP信息签名和加密是必需的步骤。加密按照WS-Security中的XMLEncryption规范[4]，通过扩展SOAP消息的Header的方式来实现。消息接收端在收到加密的SOAP请求后，解析SOAP消息的Header部分，得到服务请求者的X.509证书并验证其合法性。同时用私有密钥解密SOAP消息中加过密的对称密钥W，并用对称密钥解密加过密的组合信息W，然后用哈希函数和得到的组合信息重新计算信息摘要，并与解密后的信息摘要比较。在成功判断数字签名的正确性后，从消息中取出原始数据。
3SOAP消息安全性实现
本文设计一个称为SendSOAPRECORDER的模块向在Web服务间进行交互的SOAP消息中加入SOAPRECORDER信息。每一个SOAP消息的处理节点也都有一个相应的CheckSOAPRECORDER模块用来检查接收到的SOAP消息的安全性。如图2所示：当处理节点接收到SOAP消息时，先把该SOAP消息发送到本节点的CheckSOAPRECORDER模块进行检测，在经过节点的所有检测之后还要把该消息发送到本节点的SendSOAPRECORDER模块添加本处理节点的SOAPRECORDER信息。于是每经过一个处理节点，都会增加额外的两条进行SOAPRECORDER处理的消息。在一个节点传送SOAP消息前，首先计算出该消息的SOAPRECORDER信息，并在SOAP消息的首部或实体中将该信息添加到一个作为SOAP信封元素形式存在的首部下面，然后对它进行签名和加密。SOAP消息传送路径上的每个中间节点也对SOAP消息做同样的处理。SendSOAPRECORDER负责添加SOAPRECORDER信息。为了检测网络攻击，CheckSOAPRECORDER模块在接收到SOAP消息后会做一些常规的检测。一旦有SOAP消息到达，CheckSOAPRECORDER模块就会立即检测SOAP消息中是否有作为SOAP首部存在的SOAPRECORDER首部。因为在新伪造的首部下拷贝的SOAPRECORDER信息已经不再是作为一个独立的SOAP首部而存在，所以CheckSOAPRECORDER模块会立即抛出一个异常，警告消息接收者SOAPRECORDER信息已经被人攻击。如果包含该首部，CheckSOAPRECORDER模块将校验SOAPRECORDER的签名。如果SOAP消息传送途中经过了若干个中间处理节点，那么这些中间节点会在该消息中添加它们自己的SOAPRECORDER信息，这样SOAPRECORDER的签名可能出现嵌套的情况。如果签名校验不正确，就说明SOAP消息已经被恶意攻击。
soap协议范文4
1系统概述
企业服务总线的核心是由消息监听器、适配器、协议转换器、消息路由器和服务调度器五部分组成.协议转换作为企业服务总线的核心功能之一,可以为注册到企业服务总线上的服务提供者和服务请求者提供可靠的交互服务.ESB系统总体框架图如图1所示.企业服务总线的主要功能包括如下部分:1.消息监听功能:监听基于不同协议的消息.2.服务请求者与服务提供者之间的应用协议的转换:如果服务请求消息基于的协议与服务提供者所注册的协议不同或者服务提供者所提供的服务消息是服务请求者无法解析,则需要对该协议进行转换.3.服务之间的消息转发(路由):把请求消息转发到目标的服务地址.4.服务定位:查找服务的目标地址.5.服务安全:对请求消息进行认证授权.在企业服务总线中,协议转换器主要功能就是如果请求消息基于的协议与服务者所采用的协议不同,则需要对该协议进行转换.
2协议转换器的需求分析
各个系统在需要与其他系统交互的时候,要通过调用ESB来访问目标系统提供的服务接口获取数据,完成业务操作.各应用系统作为服务消费方在调用ESB的时候,需要明确每个参数代表的含义,按照参数书写格式要求来发送参数,然后ESB会自动调用消费方服务.但连接到ESB上的服务请求者和服务提供者可能采用不同的应用协议,针对不同的应用协议,ESB的监听器接收到的请求消息有不同的协议格式.如果ESB能够支持现有的各种通信协议,那么对消息的处理就完全不考虑传输细节,而直接通过消息请求和获取服务.如果没有将一种协议转换为另一种协议的工具,则服务请求者很难与给定的服务提供者进行通信.与此需求相关的需求是使用者的数据格式可能与服务提供者使用的数据格式不同.因此,需要一种能够提供此转换的工具.
关键技术
1基本定义
SOAP即简单对象访问协议,是一个轻量级的、简单的、基于XML进行信息交换的通信协议.它可以和现存的许多因特网协议进行结合使用,包括HTTP,SMTP.JMS是实现JAVA领域远程通信的一种手段和方法,是个远程通信协议,在其他的语言体系中也存在着类似JMS的东西,可以统一的将这类机制称为消息机制.XML(ExtensibleMarkupLanguage)即可扩展标记语言,它是万维网协会的XML工作小组所定义的可扩展标记语言,是一组规则与准则的集合.XML作为通用的、自解释的数据交换格式,已成为大多数应用程序所采用,XML技术可以有效地解决不同协议下的数据之间的共享与交互.
XML现在已经成为一种通用的数据交换格式,它的平台无关性,语言无关性,系统无关性,给数据集成与交互带来了极大的方便.XML是从标准通用标记语言(SGML)中简化修改出来的.XML将SGML的灵活性和强大功能与已经被广泛采用的HTML结合起来,简化了计算机对文档和数据交换的处理,使得现有的协议和软件更为协调,从而简化了数据的处理和传输.使用XML标记语言可以做到数据或数据结构在任何编程语言环境下的共享.XML最大的优势在于它能对各种编程语言编写的数据进行管理,使得在任何平台下都能通过解析器来读取XML数据.XML标记语言的语法非常简单,可以通过解析器在任何机器上解读.并可以在各种计算机平台上使用.逐渐成为一种数据交换的语言.
2协议转换思想
ESB支持广泛使用的协议(HTTP,JMS,SOAP等等).目前,我们设计的ESB系统支持的协议有:HTTP、SOAP和JMS协议,以后还将对其进行扩展.协议转换模型用于当服务的请求者与服务提供者基于不同协议时的消息转换.消息监听部分监听到消息后,对其进行适配,然后将其传递给协议转换部分,协议转换器主要负责将采用不同协议的消息转换成内部标准消息,经由消息路由器路由后将其封装成目标方要求的协议形式的消息传递到目标方.在进行协议转换时,标准消息的内容主要由以下几部分组成:用户名、角色类型、IP地址、端口号、消息的状态、消息的寻址信息和业务数据.
网络上传输的消息的内容常常分为消息头和消息体,如应用层的HTTP、SOAP、JMS消息.业务相关内容存入消息体中,消息头中包含与业务无关的管理信息,比如消息的优先级、序列号、地址信息等.因此,对消息进行解析时,可以对其消息头和消息体分别进行解析.譬如SOAP消息都使用XML形式编码.处理接收到的SOAP消息应该有两个步骤,首先,识别应用程序需要的SOAP消息的头部分;其次,识别应用程序需要的SOAP消息体部分;最后,检验该SOAP消息是否满足要求,即消息的目的地址、参数信息等是否和目标地址名称、参数等相对应.
协议转换模型设计与实现
1并行XML解析
XML在不同的语言里解析方式通常都是一样的.基本的解析方式有两种:SAX和DOM.利用SAX解析XML文档,牵涉到两个部分:解析器和事件处理器.解析器负责读取XML文档,并向事件处理器发生事件,如元素开始和元素结束事件;而事件处理器则负责对事件做出响应,对传递的XML数据进行处理.DOM是基于XML文档树结构的解析,DOM在分析XML文档时,将组成XML文档的各个部分映射为一个对象,在内存中,这些节点形成一棵文档树,整棵树是一个节点,树中的每一个节点也是一棵树,通过访问树中的节点来存取XML文档的内容.为了提高系统的效率,在这个协议解析器中,我们将采用一种并行的XML解析方式.并行XML解析可以充分利用多核计算机的优势来提高系统的性能.具体实现方式为:首先对XML文件进行预解析,根据预解析的结果将XML文件划分为多个小的XML文件,并将这些XML文件分配到不同的线程上,从而这些划分后的XML文件就可以并行地进行解析.
2协议转换模型
在不同系统或不同系统的组成部分之间传输数据时,必须考虑接口参数差异问题.不同格式的数据是难以在系统内部或者系统间传输的,因此协议转换器要解决这种异构的问题.鉴于业务相关内容通常存入消息体中,消息头中包含与业务无关的管理信息,协议转换器以分层方式进行转换,主要包括2个部分:消息头转换和消息体的转换.在进行协议转换时,要对ESB系统支持的各个协议建立模型,每当需要某种协议解析时,都要读取对应的协议模型信息.协议转换可能会出现解析失败的情况,这就要求将失败信息记录到日志文件中,方便系统查阅并进行处理.
为进行协议转换,消息或服务必须要先进行适配,在初次连接或者其协议发生变化时,要填写其协议的格式,在此设计一个表格存储在注册库中.这一表格包括字段序号(SQ),消息名称,消息序号,消息类型,字段名称,起始位,长度,字段类型,字段描述.其中,消息类型是指消息所使用的协议.协议转换示意图如图2所示。协议转换器要把收到的不同协议格式的消息转换为内部统一的消息格式即XML的格式,以方便内部消息路由器对消息的路由;消息路由器对消息路由后,由系统内向服务提供方或者服务请求方发送数据时,协议转换器实现读取XML文件,按照数据库中对应的注册的协议的要求,形成指定的消息类型,并发送到目的地.而这里的转换是需要服务请求方和服务提供方提前注册他们支持的协议的详细信息,我们将这些信息分别都保存在不同的表格里,并存入注册库.
因此,协议转换器有两个功能要实现.一个是将接收到的消息转换为内部数据格式即XML文件.另一个功能是将内部表示的XML文件转换为注册库中查找到的目标协议格式,在这一过程中,需要使用并行XML解析方式对XML文件进行解析,从而能够快速地实现协议转换.在这个转换的过程中,ESB系统首先要建立所支持的JMS、HTTP和SOAP协议的模型,从而为协议转换提供相关的信息.协议转换器过程图如图3所示,在这里以JMS和SOAP协议转换为例.若获取到对方的JMS或者SOAP消息,则在存入数据库的同时,要首先根据之前注册的JMS或者SOAP模型将JMS或者SOAP消息转换为XML的格式,统一消息格式,方便系统对数据的处理.当传输数据时,若传输的是其他形式的消息,则其消息格式 为消息描述指定的格式,协议转换器就利用消息描述表中对消息的内容的描述进行转换,将XML格式的消息转换为JMS或者SOAP消息.实质上,在协议转换器中,消息的转换包括两个层次上的协议转换:服务请求方的数据到系统内部的协议转换,系统内部的消息到服务提供方的协议转换;服务提供方的消息到系统内部的协议转换,以及系统内部的消息到服务提供方的协议转换.
3协议转换器的可扩展性
设计模式使人们可以更加简单方便地复用成功的设计和体系结构.为了实现协议转换器的可扩展性,协议转换器的实现中应用了工厂模式和适配器模式.协议转换器的类图如图4所示:在协议转换器的实现中,AbstractTransformer是所有协议转换的一个基类,并且是一个抽象类,实现了接口Transformer和Amnotatedobject.其它的转换类都实现了AbstractTransformer.
结语
soap协议范文5
关键词: Web Service；身份认证；数字签名加密；SOAP扩展
中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)10-2438-03
Web Service是一种部署在Web上的对象，它们具有对象技术所承诺的所有优点，同时，Web Service是建立在以XML为主的、开放的Web规范技术基础上，因此具有比任何现有的对象技术更好的开放性，是建立可操作的分布式应用程序的新平台。它的设计目标就是简单性和扩展性，这有助于大量异构程序和平台之间的互操作性，从而使存在的应用程序能够被广泛的用户访问。
随着移动开发热的推动，Web Service的推广迎来一轮新的高潮。但是由于设计上的不同，Web Service应用带来了新的攻击类型：黑客把恶意代码附加在正常代码上，通过在输入域中输入，从而进入系统。毋庸质疑，Web Service通信安全的研究意义重大。
1Web Service体系结构简介
Web Service体系结构是由服务提供者，服务注册中心以及服务请求者共同构建而成的。通俗的理解：服务提供者提供自定义的服务以及访问的接口；服务注册中心的主要功能则注册已经的网络服务，进行整理分类以供服务请求者的查找；服务请求者可以通过已经的接口进行服务的访问。彼此间交互着，查找以及绑定的操作。
UDDI（统一描述、发现和整合）建了一个平立、开放的框架，通过因特网来描述服务，发现业务，并且整合业务服务。它是一套基于Web分布式的、为Web服务提供的信息注册中心的实现标准规范。在Web服务被注册的同时，该标准也能帮助服务请求者找到所需求的服务。
WSDL(Web Service Description Language) Web描述语言将Web服务描述定义为一组服务访问点，客户端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问(类似远程过程调用)。WSDL首先对访问的操作和访问时使用的请求/响应消息进行抽象描述，然后将其绑定到具体的传输协议和消息格式上以最终定义具体部署的服务访问点。
SOAP(Simple Object Access Protocol)简单对象访问协议是基于XML实现互联网信息交互的协议。SOAP消息根据实现模式可以分为请求消息和响应消息，实际交互中将请求或者响应消息的参数作为XML节点可以实现跨平台的异构传输。虽然SOAP的请求消息和响应消息略有不同，但是SOAP消息通常是由一个SOAP Envelope、一个可选的SOAP Header和一个SOAP Body组成的XML文档。
2Net平台下的通信安全设计方案
2.1基于SoapHeader和来源IP实现安全认证
Header在Soap消息中提供了一种传递信息的途径，通过Header属性是可以让消息接受者知道应该处理该消息，这些信息可以是与要处理的消息相关联的信息或指示，但是它传递的信息不是应用程序的有效载荷。
Header是可以在Soap消息传递路径中的中间节点处理的。SoapHeader在缺省情况下由客户端对象发送给Web Service，我们可以通过SoapHeader来加载控制信息实现安全认证，.Net平台下实现的具体步骤如下：
1）创建继承自System.Web.WebServices.SoapHeader的自定义SoapHeader类型。
2）在WebService中创建拥有public访问权限的自定义SoapHeader字段。
3）在使用SoapHeader的WebMethod上添加SoapHeaderAttribute访问特性。
4）生成器会自动为客户端生成同名的自定义SoapHeader类型，同时还会为类型添加一个SoapheaderValue。
SoapHeader多数情形下用来传递类似于用户身份的一些控制信息，当然它的作用远不止这些，有待于实际应用中发掘。
除此之外，在服务端，我们可以通过HttpContext.Current.Request.UserHostAddress来获取客户端的IP地址，我们只允许指定的IP的服务端进行访问，保证点对点安全。
2.2通过SOAP扩展修改SOAP消息
Net平台下的SOAP扩展是是一种有效的作用于SOAP消息的拦截机制，能够在SOAP请求或响应传输之前操纵它们。也就是说，我们可以在SOAP请求消息或者响应消息传输前实现SOAP消息的修改，通过SOAP消息的修改我们可以实现报文的加密或者数字签名，增强消息的通信安全。需要注意的是：当对SOAP消息进行SOAP扩展后，必须在服务端和客户端都对消息进行相应的扩展。
.Net平台下实现使用SOAP扩展修改SOAP消息需如下步骤：
1）从SoapExtension派生一个类。
2）保存对Stream对象的引用，这些对象表示SOAP扩展前后未来的SOAP消息。
3）初始化SOAP扩展特定的数据。
4）在适当的SoapMessageStage或阶段中处理SOAP消息。
public override void ProcessMessage(SoapMessage message){
switch (message.Stage)
{
case SoapMessageStage.BeforeSerialize://在序列化之前，就是还未输出soap消息
//ToDo break;
case SoapMessageStage.AfterSerialize:/ /在序列化之后，就是将要输出soap消息
//ToDo break;
case SoapMessageStage.BeforeDeserialize://在反序列化之前，正在得到输入的soap消息
//ToDo break;
case SoapMessageStage.AfterDeserialize: //在反序列化之后，就是得到输入消息
//ToDo break;
}
2.3实现SOAP消息的XML Encryption
通过向基础结构中注入SOAP扩展，可以检查或修改每个序列化和反序列化阶段前后的SOAP消息。在此基础上，开发过程中可以将客户端的SOAP请求或者服务端的SOAP响应进行自定义的XML加密。
加密SOAP扩展可以在.NET Framework序列化客户端参数之后对SOAP消息的XML部分进行加密，而在.NET Framework反序列化该SOAP消息之前，它又可以在Web服务器上对该SOAP消息进行解密。
XML Encryption是W3C加密XML的标准。加密的过程实际上是先对XML节点的内容进行加密，然后再将替换先前节点的内容。XML的格式不受影响。加密可根据安全性级别的要求采用不同的算法，总体上分为对称加密和非对称加密。
XML Encryption允许只对文档中部分敏感数据加密，将其他的数据仍处在非加密的状态，缩短了密文的长度，提高了传输效率。
不仅如此，XML加密还可以对整个XML文件或者XML文件中的某个元素进行加密。XML Encryption体现了自包含的特质，是在原资源的位置上创建一个新的EncryptedData元素完全的替代原资源(使用CipherReference除外)。EncryptedData元素包含着一些列用于描述算法的子元素，同时也包含着密钥信息。KeyInfo元素下的EncryptedKey元素及其子元素包含着关于被保存的密钥的信息。
在安全性要求更高的项目中，可对整篇文档多重加密，当XML文档发送给多个接收者时，能够保证各个接收者根据自己的密钥读取相应的数据信息，而对其余的数据是不可见的。
2.4对SOAP消息实现数字签名
在实际的应用中还需要客户端对SOAP消息进行一次签名，并将签名连同消息一起发送；服务端接受消息后，需要对SOAP消息中的签名进行认证。通过验证才能确定消息在传输过程中没有被更改过，而验证的用户就是对消息签名的用户。
采用传统的数字签名虽然也可以保证整个XML文档或消息的不可抵赖性、身份认证和数据完整性，但在Web Service的应用环境下却是不够的。若对整个文档或消息进行数字签名，则签名后不能再对其进行修改，因而需要能实现对XML文档或消息的细粒度控制，才能适应Web Service的灵活性要求。引入XML签名，可对已签名文档继续添加签名，同时也能实现对文档选择进行细粒度的签名，根据需要选择不同的元素或元素的属性进行数字签名。
对SOAP消息的数字签名同样可以发生在.NET Framework序列化客户端参数之后，但是在.NET Framework反序列化该SOAP消息之前，必须对该消息的签名进行验证。
在.Net平台的System.Security.Cryptography的命名空间下提供了加密服务功能，包括安全的数据编码和解码，以及许多其他操作，这里我们用来实现XML数字签名：
1）在.NET序列化客户端参数之后创建CspParameters对象，并指定密钥容器的名称。
2）使用RSACryptoServiceProvider类生成一个对称密钥。将签名RSA密钥添加到SignedXml对象。
3）创建说明签名内容的Reference对象。并将XmlDsigEnvelopedSignatureTransform对象添加到Reference对象中,然后将Reference对象添加到SignedXml对象中。
4）通过调用ComputeSignature方法计算签名。
5）检索签名（一个元素）的XML表示形式，并将它保存到一个新的XmlElement对象中。
在.NET Framework反序列化该SOAP消息之前,载入SOAP报文后找到元素，并创建新的XmlNodeList对象。加载XML的第一个元素到,使用CheckSignature方法和RSA公钥检查签名。返回的是一个布尔逻辑值，若为false表示验证签名失败，随即可以抛出异常终止Web服务的调用。
3结束语
Web Service通信安全是企业级开发中的关键模块。文章从这一角度出发，采用SoapHeader加载控制信息，IP来源验证，SOAP扩展加密，SOAP报文的数字签名等方法来保证服务通信过程中消息的真实性、保密性和完整性，可行的实现了Web Service的安全访问控制。
参考文献：
[1]顾宁,刘家茂,柴晓路Web Services原理与研发实践[M].北京:机械工业出版社,2005.
[2]乔波.Web+Services安全技术研究[J].信息安全与通信保密,2007(8).
soap协议范文6
【关键词】 企业门户;企业门户网站;WSRP;WSXL;UDDI
一、企业门户(Portal)
Portal是IT领域的新技术,是企业信息化工作的发展方向之一。Portal一词是从Internet所衍生出来的,原来是“门户网站”的意思,扮演人们上网后想要拜访的第一个站台。从面向应用领域的角度看,门户可分为Internet门户和企业门户。人们对Internet门户的认识比较一致,提供面向Internet用户的服务的网站。对企业门户认识与IT业有些名词一样,不同的专业人士和机构对之有不同的理解,并有很多术语用于描述企业为其客户、合作伙伴和员工的方便而采用的“门户。根据应用的具体功能不同又把企业门户细分为信息门户、知识门户和应用门户等。
1.企业信息门户(Enterprise Information Portal,EIP )。基本作用是为人们提供企业信息。企业信息门户提供了一个了解企业的访问入口,所有访问者都可以通过这个入口获得个性化的信息和服务。
2.企业知识门户(Enterprise Knowledge Portal,EKP)。是一个平台,该平台是知识加工平台、决策平台、知识与获取平台的集成,它使企业各部门职员之间的信息共享和交流更加流畅。企业知识门户的重点是企业信息的加工与处理。
3.企业应用门户(Enterprise Application Portal,EAP )。实际上是对企业业务流程的集成。它以商业流程和企业应用为核心,把商业流程中功能不同的应用模块通过门户技术集成在一起。
以上三类门户虽然在侧重点有所不同,但随着企业信息系统复杂程度的增加,越来越多的企业需要能够将以上三类门户有机地整合在一起的通用型企业门户,把它们统一称为企业门户。企业门户能够通过超越现有分散的应用环境实现这个目标,把原来不同的内部部门的分割、不同的企业内外的分割,通过系统的集成使其相互关系连接到一起,形成广泛的,相互关联的企业应用环境,形成真正的企业合力。它不但能降低企业的运营成本,通过丰富的企业信息资源吸引新客户,密切老客户的关系,更重要的是缩短企业响应市场时间,使企业在激烈的市场竞争中占据最有利的地位。
二、构建企业门户网站的Web服务
1.企业门户网站与Web服务
随着Web服务的发展,IBM、微软、Sybase、CA、Sun等五大门户厂商推出的门户方案也开始支持XML、简单对象访问协议(SOAP:Simple Object Access Protocol)、WEB服务描述语言(WSDL: Web Services Description Language)、统一描述、发现和集成协议(UDDI:Universal Description, Discovery and Integration)等标准,还有的门户方案中整合了Portlets、PNP等组件。Portlet 是在门户中运行的为门户提供内容的组件,提供对应用程序、基于Web的内容和其它资源的访问。Web页面、Web 服务、应用程序和联合内容提供可通过Portlet来访问。
门户网站是用户访问不同来源的信息和应用程序的焦点。门户网站从本地或远程数据源(例如,从数据库、事务系统、联合内容提供者或远程Web站点)获取信息。它们加工此信息并将其聚集到复合页中,用一种简洁、容易的使用形式为用户提供信息。除了纯粹的信息之外,很多门户网站还包括一些应用程序,如电子邮件、日程、管理器、银行业务、帐单显示等。各种不同的信息和应用程序需要不同的加工和选择机制,但它们都依赖于门户网站的基础结构,并影响门户网站所拥有的数据和资源。几乎目前所有的门户网站实现都提供一种组件模型,它允许将称为 Portlet的组件插入到门户网站基础结构中。
2.用Web服务构建企业门户网站
Web服务技术是一种在Internet环境下松散耦合的Web应用之间进行互相调用和互相集成的技术框架。Web服务体验语言(Web Services Experience Language,WSXL)和Web 服务远程门户(Web Services Remote Portals,WSRP)为当Web服务的组件发生更改时,可以重新配置和调整服务提供了灵活性。WSRP目前是 WSXL 的一部分;WSRP 定义了称为远程Portlet Web服务(Remote Portlet Web services)的特殊WSXL组件。这两个规范都反映了对Web服务的人性化应用程序进行标准化时展开合作的趋势。
为了使将WSRP服务动态集成到门户网站中尽可能简单,我们需要集成一个查找和绑定功能。可以将一个UDDI注册中心当作和查找WSRP服务的注册中心。这个 UDDI 注册中心可以是一个局限在公司网络中的专用UDDI,也可以是公用UDDI目录,希望提供或使用WSRP服务的客户机应用程序可以执行(如图1所示操作)。
(1)将Portlet作为WSRP服务:Portal管理员使用函数将portlet作为 WSRP 服务到UDDI注册中心。如门户网站的管理函数可以读取门户网站的portlet 注册中心,并显示所有可用的portlet,portlet管理员就可以选择要的portlet 了。
(2)查找和绑定远程Portlet Web服务:查找和绑定管理函数让管理员可以搜索UDDI注册中心来查找WSRP服务、对于一个选定的服务,管理函数可以在portlet注册中心中自动生成一个绑定到该服务的portlet。
(3)选择代表WSRP服务的portlet:在管理员将portlet绑定到WSRP服务之后,用户就可以将portlet放在他们的一个个页面上去了。
3.Web Service 构架门户网站整个业务流程
Web Service构架门户网站业务流程(如图2)示例了用Web Service 构架门户网站整个业务流程。当Portlet接收一个需要交互式远程服务请求时,Portlet通过SOAP Proxy产生应答;Proxy包装这些参数,转换为SOAP的请求,并将请求送给远程Web Service。Web Service通过SOAP Wrapper来接收SOAP请求,还原这些参数,使用参数完成本地服务。当web Service返回结果时,SOAP Wrapper 将结果数据转换为SOAP的响应,并把它送回到SOAP Proxy,SOAP Proxy最后还原成结果数据,并以一个适当的形式返回到原先请求的portlet。
为了简化在Portlets中使用Web Service,象IBM等公司提供一个Web Service Proxy产生器工具,该工具能够从一个WSDL接口文档自动产生客户代码,并且实现可选择的服务实施文档。如果只有一个服务接口文档被用,服务产生器工具产生一个通用的服务,它能被用到存取给定的任何服务实施。如果一个服务接口和一个服务实施都被用,服务产生器工具产生一个服务只能存取服务实施。服务包含在服务接口文档里面,是一个特定的绑定的代码。如绑定的是一个SOAP绑定,然后服务将会包含用来启动服务的SOAP客户代码。
当一个访问远程Portlet页面发生请求时,Portlet使用一个Portlet来实现远程Portlet Web Service ,它是通过Remote Portlet Invocation(RPI)协议(如图3),portlet启动portlet完全和它会启动本地portlet一样,通过Portlet请求和Portlet 响应。portlet在内部实现一个SOAP,转换所有的参数作为一个SOAP的请求,并发送给远程的Portlet Web Service 主机。在Web Service 旁边的SOAP Wrapper 还原出所有的信息,这些信息是在远程Portlet上的请求和响应。
是直接通过一个入口或门(Portal),还是间接的经过Web Service接口?对于远程Portlet来说,它是透明的。在每个情况,它处理输入参数而且返回一个portlet响应。
SOAP Wrapper转换进入SOAP响应之内的响应,且把它送到SOAP,SOAP还原出这些响应,最后通过 Portlet返回原先的Portlet 响应。这个响应也是原始的通过Portlet 引擎的请求。
通过对构建企业门户网站的Web服务技术探讨,给出了Web Service构架门户网站整个业务流程简单阐述。企业门户网站从内外两个角度提供了集成的企业信息平台解决方案。一方面它为企业内部员工提供了信息交换的平台,另一方面成为企业与客户、供应商之间的信息交换、业务推广和服务的平台,使的B2B电子商务发展成为可能。
参考文献
[1]柴晓路.Web服务架构与开放互操作技术[M].北京:清华大学出版社,2002
[2]SamtaniG,Sadhwani.B2BiandWeb:Anintimidating Task.Web Services Architect,2002(1):30～32
[3]企业门户网站/省略,2003
