Web传输范文（精选4篇）
Web传输 第1篇
文件的上传与下载是WEB应用开发中的一个基本需求。本文以示例简述PB的WEBFROM下文件上传与下载的实现，内容涉及如何使用PowerBuilder建立WEB应用、使用PowerBuilder开发COM组件、PowerBuilder虚拟文件系统，以及WEB方式下文件的上传与下载。
1 PowerBuilder建立WEB应用[2]
PowerBuilder的WEB应用构建前提是分布式应用体系。PowerBuilder的客户端应用分布到WEB服务器上，可将Web.PB看作为客户端应用。当客户端应用Web.PB被WEB服务器激活后，调PowerBuilder的服务器应用，执行在服务器应用中定义的方法，实现业务逻辑，如下图所示：
基于上述原理，本文实现简单的文件上传下载WEB应用，如图2所示：
上传按钮代码：
下载按钮代码：
2 PowerBuilder虚拟文件系统
网页部署后，打开浏览器，输入URL:http://localhost/pb_myweb/进行测试。单击上传按钮后出现的文件上传页面：
选择文件，单击Upload按钮进行上传，上传成功后显示如下, 可以在文件列表中看到刚上传的文件信息:
在文件列表中选择要下载的文件，单击下载按钮，出现下面的文件下载保存窗口，选择要保存的路径即可：
经过刚才的测试，上传与下载的需求似乎已经完成了，接下来我们打开一个新的页面，同样输入URL:http://localhost/pb_myweb/继续进行测试，文件列表为空，再次点刷新按钮也是一样。文件没有传上去吗?问题出在哪呢?
这里需要先解释一下PowerBuilder的虚拟文件系统：当我们部署一个PB的WEB应用后, IIS虚拟目录下将生成两个目录, 如果WEB应用的名称为pb_myweb, 则产生的对应目录为pb_myweb与pb_myweb_root, pb_myweb目录内存储的是网页脚本及所需第三方dll之类, pb_myweb_root目录提供文件系统、邮件系统、打印系统服务等服务, 而PB的虚拟文件系统目录对应的就是pb_myweb_rootFileCommon, Common目录下的所有子目录及文件都是针对web用户共享的, 第一级子目录是根据要部署的WEB应用相关引用文件所在的盘生成的, 一般都会存在两个基本的目录, 一个为pb_myweb_rootFileCommonctemp, 另外一个为当前程序文件所在的目录, 比如我们的程序放在d:2010web下, 则在IIS下的目录结构为pb_myweb_rootFileCommond2010web。
虚拟文件系统中有两种文件处理模式：共享模式与复制模式，可以通过设置WEB应用的PBWEbFileProcessModel属性进行切换，默认为共享模式。用户打开浏览器进行页面访问时, WEB应用会根据每一次新的访问分配唯一的会话id, 并在pb_myweb_rootfilesession目录将创建该会话的临时交互目录, 如果会话id为1234567, 则交互目录为pb_myweb_rootfilesession1234567, 实际的会话id为由数字与字母组成的25个字节的字符串:
共享模式下，系统将根据需要将common目录中的文件复制到当前会话产生的临时交互目录中，复制模式下，当发生第一个对文件相关操作时，common目录下的所有子目录及文件都会一次性复制到当前会话产生的临时交互目录中;系统还提供了一种兼容机制，如果common目录下的文件与当前会话中的文件重名的时候，只会显示、处理当前会话目录中的文件。
用户的浏览器完全关闭后，当前会话结束，IIS中有关该会话的临时交互目录及所有子目录、文件都将自动清除[3]。
由上述虚拟文件系统的介绍可以得知，每个用户打开浏览器后看到的文件都是基于各自会话对应的目录，上传与下载的目录也是在各自的会话目录中进行，且会话结束后，上传的文件也会被删除，由Sybase提供的文档我们也可以得知，web下的filecopy与filemove之类的文件操作函数调用也是基于其虚拟文件系统，所有的文件操作也只会在当前会话目录中，有什么办法能使文件存储到实际的桌面文件系统中指定的目录吗?
3 使用PowerBuilder开发COM组件
经过一段时间的摸索，笔者找到了一种比较好的办法:通过com去实现虚拟文件系统与桌面文件系统的文件互操作, 大致的流程是这样的：通过web提供的MapVirtualPath函数到得虚拟文件系统中的文件对应于实际的桌面文件系统中的路径，再通过com组件来实现文件在虚拟文件系统与桌面文件系统中的复制与移动操作。这里我们采用PowerBuilder来编写所需的com组件，主要设计界面及代码如下:
com组件的一些参数:
文件复制代码:
文件移动代码:
目录创建代码：
com组件部署时选择编译成功后自动注册选项就可以了, 如下图:
Web应用中的主页面增加两个函数:of_getname与of_move:Of_getname函数用于从指定路径中取文件名, 代码如下:
Of_move函数用于将一组文件转移到指定的目录中，代码如下：
原来的myuploadfiles_callback修改如下:
按照原来的方式上传三个文件, 结果如下:
可以看到通过com组件已经把文件中虚拟目录中转移到桌面文件系统中的指定目录，编程人员可以利用com组件扩充其他的文件操作，以满足实际WEB应用的需要。
4 结束语
文件的上传与下载是WEB应用开发中的一个基本需求，本文以示例简述使用PB实现文件上传与下载。随着计算机网络技术和数据库技术以及Powerbuilder开发平台技术的发展，基于WEB的应用已是大势所趋。因此，掌握新技术、利用新术，才能开发出满足用户需求、适应潮流发展的应用程序。
参考文献
[1]肖兵.PowerBuilder Internet技术详解[M].北京:电子工业出版社, 2002.
[2]戴小波.PowerBuilder开发WEB应用实例[J].河北软件职业技术学院学报, 2005, 7 (3) :61-63.
Web传输 第2篇
1 实现平台技术及工具
1.1 Cent OS操作系统
Cent OS是一个企业级的Linux发行版本, 是基于北美的企业级Linux厂商的源代码的二次编译版本。现行最新的版本为Cent OS-6.6, 同时提供了i386与x86_64两种架构的版本。Cent OS主要面向那些需要企业级操作系统的稳定性, 但是又需要考虑部署成本的组织与企业。
1.2 Apache Web软件
Apache的HTTP软件自1994年4月问世以来, 是各类操作系统中最为流行的Web服务器开源软件, Apache Web软件的目的是在基于HTTP标准的前提下, 提供一个安全、高效并且可扩展的http服务。HTTP软件采用C语言编写, 具有许多优点, 例如:支持HTTP/1.1协议、支持CGI和Fast CGI、支持HTTP认证、支持虚拟主机、支持安全Socket层 (SSL) 、支持多进程等。软件发布采用Apache License Version 2.0, 可以运行在Unix、Windows、Mac OS/X和Netware等操作系统中。用户可以在官网上自行下载所需的版本。
1.3 SSL/TLS协议
现行的网络通信中, 主要采用SSL (Secure Socket Layer安全套接层) 及SSL的继任者TLS (Transport Layer Security传输层安全) 实现安全传输。SSL与TLS都在传输层对网络连接进行加密。SSL协议建立在TCP/IP协议的基础上, 位于TCP协议与各应用层协议之间。可以为高层的应用协议提供数据封装、加密等功能。在RFC5246中, 对SSL进行了标准化, 新的名称为TLS。TLS为应用程序之间的通信提供保密性和数据完整性。
1.4 Open SSL工具
Open SSL自1995年问世以来, 经过多年的更新, 目前的稳定版本为1.0.0, 支持大多数的加密算法。因其采用C语言开发, 由于C语言的跨平台性极好, 在多种平台下都有Open SSL工具。软件包主要可以分为三个功能部分:密码算法库、SSL协议库、应用程序。Open SSL工具在全球使用的范围极其广泛, 但软件是人类的智力设计的产品, 总会存在各类Bug, Open SSL工具也爆发了威胁了整个互联网的安全的“Heartbleed”漏洞, 但是通过安装官方发布补丁后可以修复该漏洞。
2 测试平台简介
文中将采用于2014年10月发布的Cent OS-6.6操作系统为测试平台, Cent OS-6.6改进了许多地方, 增强了虚拟化方面的支持。内核版本为2.6.32-504, Apache服务器程序的版本为2.2.15-39, Open SSL工具的版本为1.0.1e-30。
3 实现过程
在以下的配置过程中, 需要使用管理员的权限, 因此下面的操作都是以root用户的身份执行。
3.1 安装Apache软件与Open SSL工具
管理员登录Cent OS后, 可以执行rpm–qa|grep httpd和rpm–qa|grep openssl指令, 查询Apache软件和Open SSL软件的安装情况, 如果没有安装, 可以将光盘挂载至系统中, 执行手动安装方式执行或者通过yum的方式安装。
3.2 执行Open SSL工具生成私钥和公钥文件
安装相应的软件后, 即可执行Open SSL工具, 生成服务器使用的密钥文件。通常按照下面的步骤生成私钥文件和公钥文件。
生成2048位长度的RSA私钥文件, 输出文件为“abc.com.key”, 参考下面的指令:
openssl genrsa–out abc.com.key 2048
通过上述生成的私钥文件, 生成对应的公钥文件, 生成的过程中会要求设置相关的国家代码、城市代码、单位和组织的名称等参数, 并可以设定授权给哪台服务器使用, 管理员可以根据实际的需要进行签名, 参考下面的指令:
openssl req–new–x509–key abc.com.key–out abc.com.crt
3.3 将生成的私钥和公钥文件拷贝至系统默认的密钥文件存储目录
生成文件后, 管理员可以将生成的密钥文件存储在自定义的目录中, 但是建议将其存储在Cent OS操作系统中的默认存放密钥文件的目录:/etc/pki/tls。通常, 公钥文件存储在该目录的certs子目录中, 私钥文件存储在private子目录中。管理员按文件的类别, 分别拷贝至对应目录即可。
3.4 修改SSL相关的配置
在Cent OS中, 安装Apache软件后, 相关的核心配置文件为:httpd.conf, 一般存放在/etc/httpd/conf目录中, 相关的附属配置文件存放在/etc/httpd/conf.d目录中。SSL相关的配置文件名称为:ssl.conf。管理员修改该文件中的内容, 即可使用自定义的密钥文件。
定义私钥文件:
SSLCertificate Key File/etc/pki/tls/private/abc.com.key
定义公钥文件:
SSLCertificate File/etc/pki/tls/certs/abc.com.crt
3.5 重启Web服务, 测试设置效果
完成上述的配置后, 执行“service httpd restart”, 重启Web服务, 然后通过https访问Web服务器。注意开放操作系统中防火墙关于HTTPS服务的443端口。
4 结语
随着互联网的深入应用, Web服务已经成为Internet中最重要的服务之一, Web服务器相关的安全问题已经成为网络技术安全的核心。通过使用Open SSL工具生成相关的密钥, 实现基于SSL的https传输, 对网络中传递的信息进行加密, 使得数据在网络通信中传输的安全可靠, 保障Web服务器和网络通信的安全。
摘要：随着Internet技术的成熟与广泛应用, Web服务已经成为Internet中最重要的服务之一, 因此, Web服务器相关的安全问题已经成为网络安全的核心。Internet中最流行的Web服务软件是Apache。本文将结合Cent OS操作系统, 使用Apache软件实现Web安全传输的过程, 改进HTTP协议中存在的缺陷, 保障Web服务器的安全。
关键词：Apache,CentOS,SSL/TLS
参考文献
[1]曹自刚, 熊刚, 赵咏, 等.基于X.509证书测量的隐私泄露分析[J].计算机学报, 2014, 37 (1) :151-164.
Web传输 第3篇
网络的出现, 方便了信息的流动, 降低了人与人之间, 以及企业之间信息流动的成本。为了充分发挥网络在信息交互过程中的作用, 就需要在网络基础架构之上, 构建各式各样的网络服务, 以支撑日常的应用。目前各式各样的网络应用随处可见, 但是多为封闭的系统, 而为了更好的支持各种应用场景, 经常需要对多个系统进行集成, 在多个服务之间进行数据交换, 协作完成共同的任务。Web Service正是为了处理这一问题而提出的构建在现有网络标准之上的、松耦合、跨平台、跨语言的数据交换和通信的标准方法[1]。
Web Service系统利用互联网为用户提供服务, 但是其关注与构建系统之间通信的协议, 专注于数据描述 (XML) 和交换 (SOAP) , 以及服务的描述 (WSDL) 与发布 (UDDI) , 而对安全性的支持较为欠缺, 使软件处于巨大的风险之中, 需要在应用中加以解决。
1. Web Service安全问题描述
在日常应用中, Web Service的安全威胁主要来自以下几方面:
(1) 数据的保密性无法保证
在网络安全中, 要求信息不能够泄漏给未经授权的用户及恶意访问者, 而Web Service运行在Internet之上, 利用XML定义数据交换的格式, 并利用SOAP进行数据交换, 整个过程都是通过网络明文进行传输, 容易被恶意用户监听和窃取。另外, 由于Web Service的接口描述暴露在网络之上, 也存在被恶意用户恶意调用的可能[2]。
(2) 数据的完整性无法保证
信息的完整性, 要确保信息不会被未被授权用户修改, 确保信息在存储、传输过程中不被修改、伪造和丢弃。而Web Service数据交换过程采用明文传输, 该特性使得数据的完整性无法保证, 能够被恶意用户修改, 或伪造[3]。
另外, 在Web Service中没有提供相关的方法, 对用户的身份进行必要的校验, 也缺乏必要的权限控制, 容易造成未授权操作, 从而泄漏系统的信息, 甚至危及系统的安全。
(3) 缺乏必要的身份验证机制
Web Services并未定义相关的方法, 对调用方以及服务提供方的身份进行必要的确认, 从而无法保证Web服务的合法性, 危及系统的安全。
(4) 缺乏可扩展可灵活部署的加密方法
在日常的应用中, 通常采用SSL协议, 对Web Service数据传输过程进行加密和保护, 但是利用SSL进行加密操作时, 会频繁的进行加密解密操作, 从而影响系统的通信性能, 降低系统的性能。该问题在PDM系统中表现尤为突出。PDM系统中传输的多为体积庞大的工程设计文件, 采用SSL的方法, 会对系统的性能带来极大的影响。而在处理用户登录信息、密钥传输等问题时, SSL又是一个成熟的方法。因此在应用中需要更具实际情况, 灵活的选择加密方法。
针对以上问题, 在综合考虑了可使用性、性能、私密性等因素后, 设计和实现了一套传输层加密方法, 根据PDM系统的特点, 针对不同的需要, 采用不同的方法对数据进行加密操作, 并应用在了实际的PDM系统中。
2. 传输层加密方法
2.1 概述
在PDM (Product Data Management, 产品数据管理) 系统中, 主要需要面对两种数据。一种是设计的文档、图纸等二进制数据信息[4], 这些数据数据量大, 变化较快, 并且这些数据往往具有一定的时间效应, 只需要保证一定的时效范围内不被破解, 无法获取即可, 因此, 针对这部分数据, 可以采用简单的加密方式, 确保在可容忍的时间范围内, 无法被破解即可。因此在传送大数量信息时, 采用了RC2加密算法进行加密操作, 其特点是加解密速度快, 而且形成的加密文件体积并不会增大。在加密的过程中, 如果传输的是比较大的图纸类文件, 要先进行压缩。如果是数据库的表文件, 则转换成XML文件, 然后再进行加密。
除文档数据外, 主要为系统内部的通信协作及信息交换, 相比设计文档数据, 这部分数据数据量小, 但经常包含较为敏感的用户信息, 如密钥信息、权限信息等, 针对这部分数据, 需要进行较为严格的加密, 确保访问时经过授权, 且无法被监听与破解。兼顾到身份验证的需要, 这部分基于开源的CA中心, 对用户证书进行发放和管理。在数据通信过程中, 利用证书对交换的信息进行加密操作, 从而保证数据的完整性。
传输层加密的体系结构如图1所示。
图中, 业务逻辑为实际的应用逻辑, 在传输过程中, 会调用下层的安全服务, 对传输数据进行处理, 确保服务的安全性。
安全服务模块为系统提供加密解密服务及数字签名的校验, 向应用的业务逻辑提供安全服务。安全模块具备RSA、RC2和M123三套数据加解密方法组。其中, M123加解密方法是一个自定义的对称密钥加密算法, 该算法利用三个数字 (m1, m2, m3) 作为密钥, 利用自定义的加密算法, 根据 (m1, m2, m3) 生成相应的密文, 同时在每次加密后, 利用Feistel结构, 对密钥进行混淆和轮替。M123加密方法主要用于对交换的密钥进行加密, 增加密钥交换的安全性。
密钥及证书管理模块主要负责处理证书的请求, 密钥交换。对称密钥管理模块主要用于对称密钥的生成及管理, 证书文件主要用于获取本身私钥及向CA请求上层安全模块需要的证书信息。
2.2 服务器端密钥生成及交换
服务端在服务启动后, 会随机生成RC2加密密钥和M123加密密钥。在密钥生成过程中, 为了避免伪随机带来的问题, 会利用随机数、机器码、机器时钟、加密算法的名称及当前时间综合生成源串, 对该源串利用MD5算法生成摘要后, 作为密钥。
在每个用户登录后, 服务端向证书中心请求该用户的证书信息, 利用证书对RC2加密密钥和M123加密密钥进行加密, 并对加密后的数据进行签名, 后发送给用户, 用于用户的密钥交换。
服务器端的密钥生成及交换过程如图2所示。
为了提高系统的安全性, 对于服务器端的对称加密密钥均设置了超时时间, 当超时后, 服务器端会重新生成新的密钥。
2.3 客户端密钥请求及交换流程
客户端在登录后, 会接收服务器端发送的RC2密钥和M123密钥, 同时在每次请求是, 随机生成RC2密钥。客户端随机数生成的过程中的源码, 除了与服务器端相同的因素外, 还增加了用户名、用户密码的md5值及客户端ip等信息, 以增大随机性及源码的复杂度。
客户端密钥交换的过程中, 会利用服务端的RC2密钥和M123密钥对生成的RC2密钥进行加密, 并做数字签名后, 附加在请求中, 发送给服务端。在此过程中, 并未利用服务端证书对加密后的密钥信息进行再次加密, 是为了避免频繁的密钥交换给服务器带来过大的压力。客户端的密钥生成及交换过程如图3所示。
同样, 为了保证安全性, 客户端的密钥也规定了一定的有效时间, 会定时进行更新。客户端的密钥用于加密客户端与服务器间的每次请求。
2.4 整体流程分析
下面将对本方法的整体流程其进行详细描述。
(1) 服务端生成加密密钥
服务端启动服务的时, 会自动生成RC2密钥及M123密钥。
(2) 客户登录并获取服务器端加密密钥
客户在登录时, 会对登录密码进行摘要操作, 并利用服务器端证书文件加密密钥信息, 传输给服务端, 服务端对解密并验证密码通过后, 服务端将获取该用户的证书文件, 加密密钥传递给客户方。
(3) 客户端请求业务处理
当客户在一段时间内, 第一次发起请求时, 客户端生成随机的RC2密钥, 利用该RC2密钥对请求进行加密, 同时利用服务端的RC2密钥及M123密钥对客户端的RC2密钥进行加密, 附加在请求信息中发送给服务方。此过程中, 需要对信息整体添加数字签名。
(4) 服务端响应请求
服务方收到请求后, 利用自身保留的RC2密钥及M123密钥, 解密报文中的密钥信息, 获取客户端的RC2密钥, 利用客户端的RC2密钥解密请求内容, 并进行处理。完成处理逻辑后, 服务端利用客户端的RC2密钥加密结果, 并添加签名信息后, 将数据返回客户端。
3. 总结
利用该方案, 减少了加密及解密过程中的数据交换, 同时确保了关键信息的保密性、完整性, 确保了web Service整个请求过程中的安全性。选取该方案的主要优势在于[5]:
(1) 性能好:在用户登录时, 以及小数据量的交换时, 使用RSA加密, 整体速度不受影响, 经测试能达到客户要求。
(2) 安全性好:由于密钥具有一定的时效性, 攻击者即使截获了一个文件并成功解密, 也无法利用一直的密钥, 解密以后数据。
(3) 加密流程是自定义:如果不了解具体项目传输层加密的思想, 即使截获了数据, 也很难利用通常的思维进行解密, 加大了解密的难度。
参考文献
[1]加尔布雷斯等著, 吴旭超等译.Web服务安全性高级编程[M].北京:清华大学出版社, 2003:5-10.
[2]苟光磊, 成卫, 倪伟.网络与信息安全的风险评估及管理[J].重庆工学院学报 (自然科学版) , 2007, 21 (9) :133-137.
[3]Scambray J, Shema M, Sima C.黑客大曝光——Web应用安全机密与解决方案[M].北京:电子工业出版社, 2008:212-216.
[4]张小平, 罗学科, 侯立华等.PDM技术的研究和应用[J].计算机工程与设计, 2008, 29 (19) :4960-4962, 4971.
Web传输 第4篇
在开发交管车辆收费管理系统过程中,需要将各下属单位的车辆收费信息数据整合到一台服务器上,供车主和工作人员方便地查询缴费信息,并实现在任意交费地点都能够顺利交费,考虑到现有网络和软件使用情况,必须采用Web服务方式实现。由于数据量比较大,传输时间长,可能出现连接超时,所以必须采用异步传输Web服务才能够很好地实现这种工作。
Web 服务调用的特性由消息交换模式、传输协议以及客户端 API 的同步和/或异步行为决定。实现一个异步XML Web服务方法允许线程在返回线程池的时候执行其他的代码,提高了Web 服务整体性能和系统的可伸缩性。.NET2.0和Axis2都能在传输级别和客户端调用级别实现异步行为,根据现有软件和平台使用情况我们选择使用Axis2来实现。
1 Axis2的传输调用模式
Axis2支持三种不同的消息交换模式:In-Only、Robust-In和In-Out。In-Only消息交换模式只有SOAP请求,而不需要应答;Robust-In消息交换模式发送SOAP请求,只有在出错的情况下才返回应答;In-Out消息交换模式总是存在SOAP请求和应答。Axis2提供阻塞和非阻塞客户端 API,支持服务的同步和异步调用。在调用 In-Out操作时,在 API 级别和传输级别提供异步行为。API 级别异步是通过回滚获得的,它使用一个传输连接来同时传输请求和响应。在传输级别异步中,使用不同的传输连接分别发送请求和接收响应。通过这两方面的结合,可以很好地解决大数据长时间传输问题。
根据消息交换模式和调用方法的不同结合方式,Axis2具有四种数据传输模式:
·阻塞单传输模式和非阻塞单传输模式 使用一个传输连接来发送和接收消息,不适合长时间运行的事务。原因是在响应可用之前,传输连接可能会超时。
·阻塞双传输模式 适用于服务操作在本质上是 In-Out,但传输是单向的(如 SMTP)或服务执行需要很长时间且 HTTP 连接超时。
·非阻塞双传输模式 非阻塞API在客户端发出消息后不等待消息返回就继续执行下面的代码。返回消息的处理在回调函数中进行。使用非阻塞的调用,需要在调用之前设置回调函数。
交管车辆收费系统需要长时间双向传输较大数据,必须采用非阻塞双传输模式,使用两个不同的连接来分别发送请求和接收响应,在 API 级别和传输级别实现异步行为。
2 系统实现
基于Axis2开发Web Service一般采用两种方法实现业务逻辑:第一种方法是直接实现,通常包括提供服务实现类、编写服务描述文件services.xml、将服务实现类和描述文件打成aar (Axis ARchive) 包、部署服务四个步骤;第二种方法使用WSDL2Java Tool工具,通过WSDL生成代码框架,然后在框架中填写业务逻辑。本文将采用第一种方法。
实现非阻塞双传输模式的异步Web服务,要注意以下几点:
(1) 编写服务实现类时,将实现方法的参数和返回值定义为OMElement。
(2) 在描述文件services.xml中,指定消息接收器为RawXMLINOutMessageReceiver。
(3) 在客户端调用程序中使用非阻塞模式,调用前设置回调函数,使用ServiceClient类的sendReceiveNonBlocking方法进行调用。
2.1 编写服务实现类
交管收费的服务实现类TrafficService中主要有query和updata两个方法,分别实现信息查询和数据上传两种服务。因为要采用双传输模式,所以两个方法的参数和返回值类型都是OMElement。在query方法的业务逻辑中,首先解析请求消息,获取需要查询的车辆ID和月份;然后在数据库中查询车辆的收费起止月份和收费金额。最后,生成返回消息。updata方法是将传入的数据写入数据库,实现方法和query类似。下面是query方法的实现:
public OMElement query(OMElement in){
Iterator iter = in.getChildElements();
String carid = ((OMElement) iter.next()).getText();
String strMonth = ((OMElement) iter.next()).getText();
String info=…; //在数据库中查询车辆的数据
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs =
fac.createOMNamespace("http://Traffic.com","Traffic");
OMElement res = fac.createOMElement("getInfo",omNs);
res.setText(info);
return resp;
}
2.2 服务部署
首先在服务描述文件services.xml中配置Web服务信息。包括定义Web服务名,指定服务实现类,并对该类中的每一个方法指定一个消息接收器。Axis2提供了两个消息接收器:用于 In-Only 操作的RawXMLINOnlyMessageReceiver和用于In-Out操作的RawXMLINOutMessageReceiver。这些RawXML消息接收器将传入SOAP 消息中的 <Body> 元素作为 OMElement传递给服务实现类的方法。同样,当方法返回OMElement时,其内容将被转换为SOAP 消息中的<Body> 元素返回。由于要实现双传输操作,所以指定query和updata方法的消息接收器为RawXMLINOutMessageReceiver。下面是services.xml的片段:
<service name="TrafficService">
<parameter name="ServiceClass" locked="false">
traffic.TrafficService</parameter>
<operation name="query">
<messageReceiver class=
"org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
<actionMapping>urn:query</actionMapping>
</operation>
…
</service>
然后,在classes目录下建立与包traffic同级的目录META-INF,将services.xml置于此目录下,打成Axis2可部署包aar文件作为服务的部署单元。
部署服务,将aar文件复制到Axis2应用中的WEB-INF/services目录下即可。可在Axis2管理控制台中的"System Components-> Available Services"查看到已部署的服务。
2.3 客户端调用
Axis2提供专门的客户端接口实现对Web服务的调用,调用方法封装在ServiceClient类中,分为阻塞和非阻塞模式,在此采用非阻塞模式调用In-Out服务,即非阻塞双传输模式:在客户端发出消息后不等待消息返回就继续执行下面的代码,返回消息的处理在回调函数中进行。
实现非阻塞调用,需要在调用之前设置回调函数,然后将要发送的消息构造OMElement,和回调函数一起作为参数,传递给ServiceClient实例的sendReceiveNonBlocking方法。主要代码:
ServiceClient sender = new ServiceClient();
sender.setOptions(options);
OMElement query = …; // 要发送的消息
Callback callback = new Callback() {
public void onComplete(AsyncResult result) {…}
public void onError(Exception e) {…}
};
sender.sendReceiveNonBlocking(query,callback);
while (!callback.isComplete()) Thread.sleep(1000);
CallBack 有两个抽象方法 onComplete(AsynchResult) 和 reportError(Exception),如果响应来自服务,则将触发此对象。在服务调用正常完成后,Axis2 引擎调用 onComplete() 方法。在从服务器获得错误消息后,调用 Callback 的 reportError() 方法。Callback.isComplete() 将指出操作调用是否完成。
3 结束语
Axis2是Web 服务和面向服务的体系结构的优秀平台,能够支持在客户端和服务器端同时支持异步调用,具有很高的易用性和可扩展性。本文通过一个交管收费数据传输服务,实现了基于Axis2的异步Web Service应用的开发过程,解决了大数据长时间传输问题,体现了Axis2在实现Web服务上的强大能力。
摘要：Axis2支持WSDL2.0定义的In-Out消息交换模式,可以在API级别和传输级别提供异步行为,能够很好地解决Web服务中大数据长时间传输问题。研究Axis2异步Web服务实现较大数据的传输方法,并以车辆收费数据传输服务为例,给出具体实现方法。
关键词：Web服务,Axis2技术,异步传输,数据整合
参考文献
[1] Apache Organization. Axis2 v1.0 User's Guide [M].2006.
[2]World Wide Web Consortium.Web Services Description Language(WS-DL2.0)[M].2007.
[3] Apache Organization.AXIOM Tutorial [M].2006.