技术开发 频道

Webservice 的设计和模式

    4、文档交换vs. RPC模型

    这两种交互方式应该在应用架构的设计初始就应该详加考虑,因为它将在很大程度上决定系统的耦合程度。

    RPC(Remote Procedure Call)本质上就是远程方法的调用。尽管Webservice是基于XML的但是你仍然可以使用远程方法调用这种模式来进行Webservice的实现,尤其是在那种简单的请求相应的模型中。在这个过程中,传输中的XML文件所描述的更多是有关远程方法的信息,比如方法名,方法参数等等。

    而文档交换方式,与RPC相比较在XML文件中不是做远程方法的映射,而是一份完整的自包含的业务文档,当Service端收到这份文档后,先进行预处理(比如词汇的翻译和映射),然后再构造出返回消息。这个构造返回消息的过程中,往往不再是简简单单的一个方法调用,而是多个对象协同完成一个事务的处理,再将结果返回。

    这两种方式的区别,类似与打电话和发邮件的不同处理方法。在目前,对于第一种方法提供了很多自动化的工具使得远程方法的调用能够很容易的完成,而后一种方法缺少一系列工具的支持,需要开发者手工完成。

    尽管如此,在此还是推荐使用文档交换的方式。由于它在以下方面具有RPC所不具备的优点。

    使用文档方式,你可以充分利用XML文件的功能去描述和验证一份业务文档,而在RPC模型中XML仅仅被用于描述方法的信息。

    使用文档方式,在客户的Service的提供者之间不再需要紧密的约定,而RPC模型需要客户和Service的提供者紧密相连,一旦方法发生变化,客户端就需要做相应的改动。这不符合低耦合系统的要求,而在文档交换方式中则灵活的多。

    由于业务数据是自包含的,显然文档模型更利于采用异步处理。

    5、利用设计模式

    设计模式在设计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应用,将好像做一种特殊的面向对象设计。

    6、安全

    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的使用者和创建者都需要与之取得安全信任。

0
相关文章