java 将动态客户端与 JAX-WS 结合使用的优势

Advantages of using a Dynamic Client with JAX-WS

提问by jconlin

What are the advantages of using a dynamic client with JAX-WS services as opposed to just using generated client classes? What are the disadvantages?

与仅使用生成的客户端类相比，将动态客户端与 JAX-WS 服务一起使用有哪些优势？有什么缺点？

**For my particular case I am using Apache CXF, I'm not sure what other libraries allow "dynamic" clients.

**对于我使用 Apache CXF 的特殊情况，我不确定其他库允许“动态”客户端。

-I thought I didn't need to add this, but... I'm looking for non-obvious(I know...subjective) advantages. I don't need someone else to tell me that an advantage of not using generated classes is that I don't need to generate classes.

- 我以为我不需要添加这个，但是......我正在寻找不明显（我知道......主观）的优势。我不需要其他人告诉我不使用生成的类的优点是我不需要生成类。

回答by Pascal Thivent

Well, the CXF documentation is pretty clear about the advantages of Dynamic Clients:

嗯，CXF 文档非常清楚动态客户端的优势：

CXF supports several alternatives to allow an application to communicate with a service without the SEI and data classes. JAX-WS specified the JAX-WS Dispatch API, as well as the Provider interface for reading and writing XML. This page, however, describes the dynamic client facility of CXF. With dynamic clients, CXF generates SEI and bean classes at runtime, and allows you to invoke operations via APIs that take Objects, or by using reflection to call into full proxies.

CXF 支持多种替代方案，以允许应用程序与服务进行通信，而无需 SEI 和数据类。JAX-WS 指定了 JAX-WS Dispatch API，以及用于读写 XML 的 Provider 接口。但是，此页面描述了 CXF 的动态客户端工具。对于动态客户端，CXF 在运行时生成 SEI 和 bean 类，并允许您通过采用对象的 API 调用操作，或使用反射调用完整代理。

In other words, you don't need the definitions of classes as shown in the documentation sample below:

换句话说，您不需要如下文档示例中所示的类定义：

JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
Client client = dcf.createClient("echo.wsdl");

Object[] res = client.invoke("echo", "test echo");
System.out.println("Echo response: " + res[0]);

Regarding the disadvantages, they are pretty obvious (and this is the price to pay): you are manipulating strings, you lost strong typing.

关于缺点，它们非常明显（这是要付出的代价）：您正在操作字符串，您失去了强类型。

回答by bmargulies

The advantage is avoiding generating and including code. In some environments, that's a problem. If there's no barrier in your environment to including generated code, then the dynamic client is a bad idea, being slower and more cumbersome.

优点是避免生成和包含代码。在某些环境中，这是一个问题。如果您的环境中没有包含生成代码的障碍，那么动态客户端是一个坏主意，它更慢且更麻烦。

The dynamic client is slower because the code (of which I wrote some) must:

动态客户端较慢，因为代码（我写了一些）必须：

1. parse the wsdl and schema
2. generate code
3. compile the code

1. 解析 wsdl 和架构
2. 生成代码
3. 编译代码

It is more cumbersome because you don't have bean classes for any complex objects in your data model. You need to use reflection.

它更麻烦，因为您的数据模型中没有用于任何复杂对象的 bean 类。您需要使用反射。

Keep in mind that the dynamic client is different from the invocation interface.

请记住，动态客户端不同于调用接口。

回答by Kevin

The advantage to using a dynamic client is that you don't need to have generated the stubs before run time. This allows you to generically invoke services that you may not know about at run time.

使用动态客户端的优点是您不需要在运行前生成存根。这允许您一般调用您在运行时可能不知道的服务。

回答by Kevin

The generated client classes are great if you know precisely what web-service your client code is going to call and that it isn't going to change over the lifetime of your client.

如果您确切地知道您的客户端代码将调用什么 Web 服务并且它不会在您的客户端的生命周期内改变，那么生成的客户端类就非常棒。

If either of these isn't the case then you will need to think about how your client will handle these situations. The Dispatch API gives you the flexibility to generate the web-service call on the fly without having an apriori knowledge of the service being accessed. This obviously comes at the cost of your code needing to support the configuration options required to build that call.

如果其中任何一个都不是，那么您需要考虑您的客户将如何处理这些情况。Dispatch API 使您可以灵活地动态生成 W​​eb 服务调用，而无需事先了解所访问的服务。这显然是以您的代码需要支持构建该调用所需的配置选项为代价的。

With all this said, a certain amount of responsibility does lie with the developer/maintainer of the server side interface to not introduce changes that will break client code.

尽管如此，服务器端接口的开发人员/维护人员确实有一定的责任不引入会破坏客户端代码的更改。

回答by mezmo

I had a similar conversation with a co-worker the other day. He was using the Spring client, that requires the use of an Interface to compile the client against, but then Spring injects the actual code to make the interface work. It basically boiled down to the oldest of saws between us, things like dynamic proxies usually introduce some sort of performance tax, he's ok with that, I started out life writing device drivers, and so am thoroughly prejudiced in favor of speed. Faster/smaller wins as far as I'm concerned, and since I'm not constrained to such limited environments...heck my Droid phone makes all the systems I worked on, including mainframes, in my first 10 years professionally look puny, I'll come down on the side of speed. The common rejoinder for this is that there are many other bottlenecks that are the "real" problem, and that this issue is insignificant against them....and it may be true...but every little bit helps. If you read the stuff from Steve Soudersand his compatriots...users can notice a change of as little as 400 milliseconds...they don't necessarily register that things are slower, but their reaction is different. So since I can't do anything about network speed, database index overhead, etc, then I can at least do the best job I can with the things that I can influence. Whew! Sorry 'bout that!! Stepping off the soapbox now! ;)

前几天我和一个同事有过类似的谈话。他使用的是 Spring 客户端，这需要使用接口来编译客户端，但随后 Spring 注入了实际代码以使接口工作。它基本上归结为我们之间最古老的锯子，动态代理之类的东西通常会引入某种性能税，他对此表示同意，我开始编写设备驱动程序，因此我完全偏向于速度。就我而言，更快/更小的胜利，而且由于我不受限于如此有限的环境......哎呀，我的 Droid 手机让我工作的所有系统，包括大型机，在我职业生涯的前 10 年里看起来都很微不足道，我会站在速度一边。对此的共同反驳是，还有许多其他瓶颈是“Steve Souders和他的同胞们……用户可以注意到只有 400 毫秒的变化……他们不一定认为事情变慢了，但他们的反应是不同的。所以既然我对网络速度、数据库索引开销等无能为力，那么我至少可以在我可以影响的事情上做我能做的最好的工作。哇！对不起！现在离开肥皂盒！;)

回答by Premraj

DII(Dynamic Invocation Interface) Client:With the DII, a client can call a remote procedure even if the signature of the remote procedure or the name of the service are unknown until runtime.

DII（dynamic我nvocation我覆盖整个院落）客户端：随着DII，客户可以调用即使远程程序或服务的名称的签名是未知的，直到运行时的远程过程。

Because of its flexibility, a DII client can be used in a service broker that dynamically discovers services, configures the remote calls, and executes the calls.

由于其灵活性，DII 客户端可用于动态发现服务、配置远程调用和执行调用的服务代理。

• Advantages

  • Here we have to create simple java interface describing the operations supported by the web service to access. So no need auto generated stubs to access the service.
  • Using endpoint it generates WSDL and Stubs on the fly i.e. at run-time.

• Disadvantages

  • Even in this style we have to know the web service before the creating client.
  • Comparing to Generated Stub(GS)it works slowly because of WSDL and stubs generates at run-time.

• 好处

  • 这里我们要创建一个简单的java接口来描述web服务支持的操作来访问。所以不需要自动生成的存根来访问服务。
  • 它使用端点即时生成 WSDL 和存根，即在运行时生成。

• 缺点

  • 即使在这种风格中，我们也必须在创建客户端之前了解 Web 服务。
  • 与生成存根 (GS)相比，它运行缓慢，因为 WSDL 和存根在运行时生成。