异步Web服务,JAX-WS要求:使用的wsimport支持异步或推出自己的? [英] Asynchronous web services calls with JAX-WS: Use wsimport support for asynchrony or roll my own?

查看:158
本文介绍了异步Web服务,JAX-WS要求:使用的wsimport支持异步或推出自己的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有一个是的由杨杨,解释了如何使用的wsimport创建具有异步Web服务调用Web服务客户端工件优秀的文章。异步要求WSDL有标签

There is an excellent article by Young Yang that explains how to use wsimport to create web service client artifacts that have asynchronous web service calls. Asynchrony requires that the WSDL has the tag

< enableAsyncMapping>真< / enableAsyncMapping>

在其绑定部分。如果您使用的JAX-WS注解的Java类的自下而上的方法不能直接在WSDL,因为WSDL是Web服务器上生成的神器做到这一点。相反,你使用像构建Ant或Maven工具,包括当在WSDL执行的wsimport此绑定。

in its bindings section. If you are using the bottom-up approach with JAX-WS annotated Java classes you can't do this directly in the WSDL because the WSDL is a generated artifact on the web server. Instead you use build tools like Ant or Maven to include this binding when wsimport is executed on the WSDL.

生成的客户端工件具有异步方法调用返回一个

The generated client artifacts have asynchronous method calls that return a

Future<?>

Response

这是一个未来。

我的阅读杨的文章后的问题是为什么不只是推出自己的异步Web服务调用使用Executors及期货。不要用的wsimport创建的工件提供一些优势,我看不出在一个滚你自己的方法?

My question after reading Yang's article is why not just roll my own asynchronous web service calls using Executors and Futures. Do the artifacts created by wsimport offer some advantage that I can't see over a roll-your-own approach?

如果任何人有两种方法的经验或见解我会AP preciate您的反馈意见。

If anyone has experience or insight with both approaches I would appreciate your feedback.

推荐答案

在理论上,产生异步客户端就不需要阻塞线程。通过传递AsyncHandler,该系统可以使用NIO的一个事件注册的web服务调用完成时,它可以调用的处理程序。没有线程需要在所有阻止。

In theory, the generated asynchronous clients wouldn't need to block threads. By passing an AsyncHandler, the system can use NIO to register for an event when the web service call is complete, and it can call that handler. No threads need to block at all.

如果你把你的同步的Web服务调用到一个执行者,它仍然会结束阻塞线程,直到结果到来,但至少有这种阻塞仅限于执行程序中的线程池。

If you put your synchronous web service call into an executor, it will still end up blocking a thread until the result arrives, although at least this blocking is limited to the thread pool in the executor.

只要你有数百个线程左右浮动,您的系统性能会降低,由于上下文切换。

As soon as you have many hundreds of threads floating around, your system performance will degrade due to context switching.

无论是引擎盖下的Web服务库实际使用NIO是另一回事。它似乎没有由JAX-WS规范是需要的。使用JDK 1.6和设置一个破发点服务器端,我设置100个客户端关闭调用服务器。使用JVisualVM我连接到客户端,可以看到,它创造了每次调用一新线程服务器。垃圾!

Whether the web service library under the hood actually uses NIO is another matter. It doesn't appear to be required by the JAX-WS specification. Using JDK 1.6 and setting a break point server side, I set 100 clients off to call the server. Using JVisualVM I attached to the client and could see that it had created one new thread per call to the server. Rubbish!

环顾四周,我发现的Apache CXF支持限制异步调用中使用线程池在网络上。果然,使用带有CXF生成的客户端,并把正确的库在classpath中所讨论的这里,复验结果显示,正在使用的只有25个线程。

Looking around on the web I found that Apache CXF supports limiting the pool of threads used in async calls. Sure enough, using a client generated with CXF and putting the right libraries on the classpath as discussed here, a retest showed that only 25 threads were being used.

那么为什么要使用JAX-WS API,而不是建立自己的?由于构建自己需​​要更多的工作; - )

So why use the jax-ws API rather than build your own? Because building your own takes more work ;-)

这篇关于异步Web服务,JAX-WS要求:使用的wsimport支持异步或推出自己的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆