随着 Web Services 在业界的应用越来越广泛,其安全性和可靠性也日益受到人们关注。WS-Security 规范保证了消息的完整性和机密性。WS-Security 规范也描述了如何利用安全令牌来进行身份认证。WS-Reliable Messaging 规范使得分布式的应用程序在系统,网络失败时仍然可以进行可靠的消息传输。本系列文章介绍了如何利用 WebSphere Application Server V6.1 和 feature pack for web service 实现 WS-Security 和 WS-Reliable Messaging。
本系列的文章分为三个部分来介绍如何开发安全可靠的 web service:
第一部分:基于 JAX-WS 的 web service 的开发。
第二部分:实现可靠的消息传递。
第三部分:实现安全的 web service。
JAX-RPC 和 JAX-WS
JAX-RPC 是 Java 社区的工作成果,为客户端端和服务器端的 Web 服务实现提供一个众所周知的 API。通过采用一个面向 Web 服务的标准 API,JAX-RPC 旨在帮助服务用户(客户端)和服务实现者获得最大程度的灵活性,方法是通过把服务互操作性的重担转移到运行时的基础架构。通过采用标准组织提供的全局标准、使用定义明确的概要文件(例如 WS-I)以及创建 IDE 和其他开发工具来与这些标准相匹配,运行时框架可以提供连接级别的互操作性。就其本质而言,JAX-RPC 定义并使用了一种基于 XML 的远程过程调用机制。它使服务器(即服务提供者)能够用标准的 API 定义其服务并且能够用 WSDL 描述其服务;它使客户端(即服务消费者)能够用标准的 API 与服务器进行通信。
JAX-WS 是 JAX-RPC 的后续版本,简化了使用 Java 技术开发 web service 的工作。 JAX-WS 使用 JAXB 提供数据绑定服务,并支持通过定制来控制生成的服务端点接口。通过使用 J2SE 1.5 的 annotations 特性,JAX-WS 简化了 Web 服务开发,并缩小了运行时 JAR 文件的大小。
WebSphere Application Server(WAS) V6.1 和 feature pack for web service 同时支持 JAX-RPC 和 JAX-WS 两种编程模式。目前 WS-Reliable Messaging 只支持符合 JAX-WS 规范的 Web Services,所以在本例中我们将介绍如何使用 Application Server Toolkit V6.1 开发基于 JAX-WS 的 web service。生产环境则使用安装过 feature pack for web service 的 WAS V6.1。
基于 JAX-WS 规范的 WS-Security 和 WS-Reliable Messaging 的实现通过将符合需求的策略集(policy set)绑定到服务提供者或服务客户端应用程序上即可。
开发基于 JAX-WS 的 Web Services
既可以通过已有的 WSDL 文件自顶向下,也可以根据实现类自底向上的开发基于 JAX-WS 的 Web Services。在本文中仅以自顶向下的方法为例介绍如何开发一个 Calculator 服务,实现简单的加法功能。开发的步骤有三步:
1.根据 WSDL,使用 wsimport 命令生成服务提供者和服务请求者需要的各种类文件
2.实现服务提供者
3.实现服务请求者
第一步:根据 WSDL 生成相关的服务端和客户端类
Calculator 服务的 wsdl 文件 Cal.wsdl 如下:
……
……
将 Cal.wsdl 文件复制到 {WAS_INSTALL_ROOT}bin 目录,在 cmd 中运行 wsimport 命令:
wsimport –keep –verbose –Cal.wsdl
使用 wsimport 命令生成模板文件后,将生成下列文件:
comibmwsservicesAdd.java
comibmwsservicesAddResponse.java
comibmwsservicesCal.java
comibmwsservicesCalService.java
comibmwsservicesObjectFactory.java
comibmwsservicespackage-info.java
ObjectFactory.java 文件包含 com.ibm.ws.services 包中生成的每个 Java 内容接口和 Java 元素接口的工厂方法。package-info.java 文件接收 targetNamespace 值并创建目录结构。Cal.java 文件是生成的服务端点接口(SEI)类,包含 ping 方法定义。Add.java 和 AddResponse.java 文件包含由 JAXB 生成的类型值,这些值是从 XML 模式类型映射的 Java 类。CalService.java 文件是生成的服务提供者类文件,供 JAX-WS 客户端使用。
第二步:实现服务提供者
打开 Application Server Toolkit V6.1 建立企业应用程序项目 ServiceEAR,该项目包含一个动态 Web 项目 Services。
在 Serivces 动态 Web 项目中创建 com.ibm.ws.services 包,然后拷贝以下 java 文件:
comibmwsservicesAdd.java
comibmwsservicesAddResponse.java
comibmwsservicesObjectFactory.java
comibmwsservicespackage-info.java
comibmwsservicesCal.java
添加 Cal.java 接口的实现类 CalImpl.java
在该实现类 CalImpl.java 中加入注释行:
@WebService(endpointInterface=”com.ibm.ws.services.Cal”,targetNamespace =
”http://services.ws.ibm.com”,serviceName=”CalService”,portName=”Cal”,
wsdlLocation=”WEB-INF/wsdl/Cal.wsdl”)
可以看到此处添加的 web service 注释中,服务名为 CalService,服务端口为 Cal,这都与我们在 Cal.wsdl 中看到的一致。
接着在 Srvices 项目的 WEB-INFwsdl 路径下添加 Cal.wsdl 文件。
最后打包生成 ServiceEAR.ear 即可。
第三步:实现服务请求者
建立企业应用程序项目 ClientEAR,该项目包含一个动态 Web 项目 Client。
在 Client 动态 Web 项目中创建 com.ibm.ws.services 包,然后拷贝以下 java 文件:
comibmwsservicesCal.java
comibmwsservicesCalService.java
然后打开 CalService.java 文件进行修改,我们将注释 @WebServiceClient 中 wsdlLocation 属性的值设置为 WEB-INF/wsdl/Cal.wsdl
此外我们需要确保服务请求者能够访问到 wsdl 文件。可以通过以下两种方式进行设置:
1. 如上图所示,将路径写入到 CalService 类静态代码中,例如:
url=new URL(“file:/C:/AST_workspace/Aircrafts/Cal.wsdl”);
此时,wsdl 文件位于 C:/AST_workspace/Aircrafts/ 下
2. 使用 CalService 类带参数的构造函数
public CalService(URL wsdlLocation, QName serviceName) {
super(wsdlLocation, serviceName);
}
向参数 wsdlLocation 中传入正确的 wsdl 文件的位置即可。
在本例中,我们采用第一种方法保证 wsdl 文件可被正确的访问。
然后在项目的 WEB-INFwsdl 路径下添加 Cal.wsdl 文件。
然后添加客户端的欢迎页面 index.html 和 servlet:CalServiceServlet.java,并在 doPost 方法中调用 web service。从前面的 wsdl 中可以看到我们的 web service 需要向其中传入两个参数 a,b,方法 add 会进行简单的加法并返回两个数的和。我们在欢迎页面和 servlet 中实现参数 a,b 的传入,调用 web service 的示例代码如下:
Cal cal = (new CalService()).getCal(); // 调用构造函数创建 web service
cal.add(a, b); // 调用 web service
最后打包生成 ClientEAR.ear 即可。
第四步:报文监测
最后检查开发的 web service 是否能够正确运行。首先,我们打开 C:/AST_workspace/Artifacts/ 目录下的 Cal.wsdl 文件进行编辑,以使我们能在 TCP/IP 监视器中察看收发双方的报文。
将服务地址改为 http://localhost:9090/Services/CalService
……
……
打开 Application Server Toolkit V6.1 中的 TCP/IP 监视器,添加监视器,在本地监视端口中输入 9090,在主机栏中填写服务提供方所在的服务器的地址,本例中服务提供方就部署在本地,因此填写 localhost,填写服务器监听端口,点击确定并启动监视器。
然后将 ServiceEAR 和 ClientEAR 两个项目部署到 WAS V6.1 服务器上。
在浏览器中输入 http://localhost:9082/Client/,进入客户端的欢迎页面,输入参数并点击 Add 后,在 TCP/IP 监视器中可以看到请求报文如下:
12
24
响应报文如下:
到此,就完成了符合 JAX-WS 的 web service 的服务提供者和客户端所有的开发工作。
结束语
本文通过示例展示了 Web services 的新编程模型 JAX-WS 的开发过程。通过本文,您可以对 JAX-WS 有一个初步的了解,并懂得如何通过 WebSphere 提供的工具开发简单的符合 JAX-WS 标准的 Web services。您可以通过本文提供的参考资源获得更多关于 JAX-WS 的信息。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
Java Web服务:WS-SecurityPolicy建模与验证
WS-SecurityPolicy的一个缺点是在编写一个策略时很容易出现错误,如断言位置使用不当,或者在文档中混合使用断言版本等。许多web servicess协议会……
-
WS-I闭关 这对WS-*意味着什么?
互操作性真的通过WS-I组织由WS-*系列规范所实现,并通过由今天所开发出来的规范和标准得以改善了吗?还是真正的互操作性的挑战转移到别处,仍然有待解决?
-
Java Web服务:通过CXF使用WS-Security
Apache CXF支持使用WS-Security SOAP扩展技术提供一整套用于消息交换的与安全相关的功能。CXF也使用WS-SecurityPolicy配置WS-Security,具体是怎么操作的呢?
-
.NET vs. Web Service的平台之争
当微软发布.Net的时候,比尔盖茨宣称这是公司一项很大的赌注。然而在.Net的发展与微软当初期望渐行渐远时,它却远超出了CIO的想象……