WebService实现分布式服务的基本原理

简单的说， 就是客户端根据WSDL 生成 SOAP 的请求消息， 通过 HTTP 传输方式（也可以是其它传输方式， 如 FTP 或STMP 等，目前 HTTP 传输方式已经成为 J2EE Web Service 的标准）传给对方， 服务方实现服务请求， 将结果以 SOAP 的消息格式返回给客户端。 

 

如果人工去创建和解析基于 XML 格式的 SOAP 消息还是一个非常复杂的过程， 这样 JAX-RPC 应时而生， 他实现了J2EE Web Sercive  的远程分布式调用。 

 

JAX - RPC ：Java APIs for XML-Based Remote Procedure Call. 它本质上是另一种RMI。 只是 JAX-RPC 以 SOAP 作为通信协议， RMI 以 RMI- IIOP或者 RMI - JRMP为通信协议。 

 

         

 

客户端需要根据 WSDL 创建客户端 Java 程序， 其中包括 Stub 程序。 客户端调用相应的Stub 程序， 进一步调用JAX- RPC 运行环境创建 SOAP 请求消息， 通过 HTTP 传输给服务器端。

 

Web 服务器端的JAX-RPC 运行环境在收到 SOAP 请求消息后， 对 SOAP 的 XML 内容进行解析， 再通过 Tie 来调用服务接口实现类。（无状态会话 Bean 或者 Java  对象） ，得到结果后， 创建SOAP 响应消息返回给客户端。 

 

  

客户端基于JAX- RPC 实现远程分布式调用的基本原理

 

（1）通过 JAX-RPC 创建 SOAP 请求消息

（2）通过 JAX- RPC 将 SOAP 请求消息送到服务地址

（3）通过 JAX- RPC 解析 SOAP 请求消息

 

服务器端基于 JAX-RPC 实现远程分布式调用的基本原理

 

服务器端的 JAX-RPC 的运行环境在收到了基于 XML 格式的SOAP 请求消息后， 会调用服务器端的 JAX-RPC Tie 对象的相应服务接口方法checkUserLogin, 将上面的基于 XML 格式的 SOAP 请求消息中的参数值映射为 Java 对象类传给 Tie 对象的接口方法， 将 loginName 和 password 都转化为 Java 的String 类型。 这是前述的 WSDL 中所定义的类型。 

 

 

 

利用设计模式

设计模式在设计Webservice的时候显然可以起到相当大的作用。设计模式的主要目的就是为解决某些在类似环境下的相像问题提供已有的较为成熟的设计方案。在这里，只简单的提及一些很常用的模式，让我们了解到模式在Webservice中可以起到的作用。

Adapter ：为内部系统提供一个不同的接口

Fa?ade： 封装复杂的内部实现，提供一系列简单的接口

Proxy： 作为其他对象的代理，代替它提供服务

 

Adapter模式用于将一个组件的接口转化成客户所需要的样子，这里的客户就是Webservice。一个常见的情况就是将原有的老的系统包装成一个Webservice。比如现在使用的是J2EE的平台，而原来有一个C++的系统实现了某些功能，现在需要将它发布成Webservice，那么就需要利用JNI技术做一个Adapter，为原来的C++组件提供一个Java的接口，然后再转化为Webservice。

 

Fa?ade模式用于构建粗粒度的服务，它包装了细粒度的服务，从而为复杂的系统提供了一个简单的接口。在J2EE中，Session Bean就象是一个Fa?ade，而Entity Bean则是细粒度的服务。在Webservice中也一样，使用Fa?ade模式可以将已有的组件的功能发挥殆尽。

 

Proxy 模式用于充当其他对象的代理，类似于中间人的作用，将处理工作从一个对象传递到另一个对象。在Webservice中，它主要用于隐藏Soap消息构造的过程。也可以用于模拟对象（Mock Object）的创建。

 

以上仅仅是一些可以用于Webservice开发的模式，如果你熟练的将这些模式应用于Webservice开发，你将会发现开发Webservice应用，将好像做一种特殊的面向对象设计。

 

l         安全

Webservice为作为方便的服务被用广大领域使用的同时，也成为了黑客们的美食。在这里，本文将就目前对Webservice安全所能做的改进做简单介绍。

在Webservice中的安全主要分为以下三个方面。

传输      SSL/HTTPS 对连接加密，而不是传输数据

消息      数据加密(XML Encryption)   数字签名(XML-DSIG)

底层架构  利用应用服务安全机制

 

传输时的安全是最容易被加入到你的Webservice应用中的，利用现有的SSL 和HTTPS协议，就可以很容易的获得连接过程中的安全。

 

然而这种安全实现方法有两个弱点。一是它只能保证数据传输的安全，而不是数据本身的安全，数据一旦到达某地，那么就可以被任何人所查看。而在Webservice中，一份数据可能到达多个地方，而这份数据却不该被所有的接受者所查看。二是它提供的是要么全有要么全无的保护，你不能选择哪部分数据要被保护，而这种可选择性也是在Webservice中所常要用到的。

 

第二层的保护是对于消息本身的保护。你可以使用已有的XML安全扩展标准，实现数字签名的功能，从而保证你的消息是来自特定方并没有被修改过。XML文件的加密技术从更大程度上加强了Webservice的安全，它能够定制数据传输到后，能否被接受者所查看，进一步完善了传输后的安全，业界也在不断的制定Webservice的安全标准，比如SAML 和 WS-Security。

 

最后一层保护就是依靠底层架构的安全，这更多的来自于操作系统和某些中间件的保护。比如在J2EE中，主持Webservice的应用服务器。目前很多的J2EE应用服务器都支持Java Authentication and Authorization Service (JAAS)，这是最近被加入到J2SE 1.4当中的。利用主持Webservice的服务器，实现一些安全机制这是很自然的做法。另一种利用底层架构的安全方法就是，做一个独立的负责安全的服务器，Webservice的使用者和创建者都需要与之取得安全信任。