Web服务的客户端缓冲技术的设计和实现.docVIP

Web服务的客户端缓冲技术的设计与实现 本文通过设计和实现一个网上商品查询系统，来展示如何利用缓冲管理、业务代理等设计模式加速Web服务的调用效率。概要 时至今日，SOAP(Simple Object Access Protocol)已由最初的实验性协议，走进了现实应用中。但是，当在分布式Java应用程序中引入SOAP作为底层通讯协议时，它所带来的繁重的网络开销成为令人头痛的问题。本文将通过设计和实现一个网上商品查询系统，来展示如何利用缓冲管理、业务代理等设计模式加速Web服务的调用效率。 回页首 引子 众所周知，Web服务的革命早已开始。SOAP(简单对象访问协议)，一种XML RPC消息协议成为了Web服务的底层通信协议。从它的名字就可以知道，它是一种易于定义、易于使用的轻量级协议。SOAP使发送和接收XML，并把它转化为异构语言对象变得容易。 但是，在拥有易用性和灵活性的同时也是要付出效率上的代价的。协议的设计者把效率方面的复杂性留给了应用程序开发者。一个简单的SOAP实现往往会给企业级应用程序带来无状态、运行效率低下等大量的问题。大数据量，频繁的SOAP调用甚至可能会引起网络阻塞。 解决Web服务效率问题的方法，一般分为两个层次： 容器层。Java Web服务的服务端一般都是一个Servlet应用程序，我们所说的容器层就是指运行Servlet的Web Server。例如，Apache Axis的服务端就可以运行在Tomcat这个Web Server上。应用程序层。一般是指用户自己编写的代码。这里可以是客户端的代码，也可以是服务器端提供Web服务的代码。解决的方法，一般包括缓冲数据、压缩信息量等等。下文将会介绍一种基于应用程序层的解决方案。通过缓冲模式，代理模式构造一个对商业逻辑透明的，提高Web服务效率的解决方案。本解决方案同时还支持自动同步缓冲区信息和UI自动更新。 在这里假设读者对SOAP已有一定的认识，并且懂得如何使用Apache Axis创建、发布Web服务。本文将不会描述SOAP的工作原理，但是会提供相关链接，在那里可以得到更多的信息。 回页首 Web Service在应用程序中的问题 当开发基于SOAP通信协议的胖客户端Java应用程序时，必须注意三个问题：性能、性能、还是性能。如果客户端程序会经常的访问服务端的相同信息，然而实现方法采取每次访问都要进行Web服务的调用，这样效率肯定很低。但现实是成百上千的客户端应用程序会为了这相同数据同时访问服务器，并且它们的操作仅仅限于浏览，服务器性能下降的会更加明显，甚至瘫痪。初步估计，一次SOAP调用的代价与执行一次关系型数据库的SQL操作相当甚至更大(如果考虑到网络的因素)。如下图： 但是，事实上，通常一个SOAP调用总是伴随着一次SQL操作。所以，一个现实中的SOAP调用的代价包括：网络的延时、Server端CPU操作SOAP的时间和数据库服务器的SQL操作延时。 由上图可见，一次Web服务调用如果不考虑网络的因素，就已经需要将近两倍于数据库SQL操作的时间。这样的效率是肯定无法接受的。因此，有一种解决方法就是尽量减少进行Web服务调用的次数了。正统的解决方案，就是采取缓冲机制。其中，缓冲机制还可以分为3种：在Server端缓冲，在Client端缓冲和不缓冲(有些实际应用中，数据量很小。维护缓冲区比不维护的代价更大)。下文中的例子程序将会根据缓冲管理模式，设计一个简单的应用程序。 回页首 具体问题举例--网上商品价格查询系统 回页首 简介 这是一个常见的程序，在很多的WebService开发包中，都有类似的例子。如Apache Axis、IBM的ETTK等。本例子，仅仅包括一个提供商品报价的服务类，它只提供了一些很简单的操作，如增加和删除商品信息，获取商品信息等等方法。通过WSDL描述这些操作，并且暴露给用户，使其可以方便的开发自己的客户端程序。本程序有一个特点，支持自动同步数据，准确的说应该是自动同步缓冲区数据。事实上，缓冲技术和自动同步技术并没有任何关系，可以分开使用。最后，本程序还提供了一个简单的GUI客户端程序，可以执行部分Web服务方法。 回页首 整体架构 客户端架构 通过代理模式，很好的分离了GUI层和业务层逻辑。又利用监听器模式实现了透明的缓冲机制。该实例程序客户端包括两个主面板(panel)。上方面版(panel)显示所有可用的商品信息，而下方面板让用户可以添加和更新商品的信息。当客户端开始运行，它会利用线程阻塞机制在服务端注册一个数据变更监听器，监听所有的数据更新事件。然后，调用Get All Quotes服务获取所有的商品信息。当任意一个客户机提交和更新了数据，该客户端的监视线程就会返回，于是一次SOAP调用结束。这同时使到服务器端的数据改变