Benefits of Using a Dynamic Client with JAX-WS

What are the benefits of using a dynamic client with JAX-WS services, and not just using generated client classes? What are the disadvantages?

** In my particular case I use Apache CXF, I'm not sure if other libraries allow "dynamic" clients.

-I thought I didn’t need to add this, but ... I am looking for non-obvious (I know ... subjective) advantages. I do not need someone else to tell me that the advantage of using the generated classes is that I do not need to create classes.

+6
java web-services jax-ws cxf
source share
6 answers

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

CXF supports several alternatives that allow an application to interact with a service without SEI classes and data. JAX-WS specified the JAX-WS Dispatch API, as well as a provider interface for reading and writing XML. However, this page describes the CXF dynamic client tool. With dynamic clients, CXF generates SEI and bean classes at runtime, and allows you to invoke operations using APIs that take objects, or using reflection to invoke full proxies .

In other words, you do not need class definitions, as shown in the following documentation example:

JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance(); Client client = dcf.createClient("echo.wsdl"); Object[] res = client.invoke("echo", "test echo"); System.out.println("Echo response: " + res[0]); 

As for the flaws, they are pretty obvious (and this is the price to pay): you are manipulating strings, you have lost strong typing.

+7
source share

The advantage is not to generate or include code. In some environments this is a problem. If your environment has no obstacles to including the generated code, then a dynamic client is a bad idea, slower and more cumbersome.

The dynamic client is slower because the code (from which I wrote a few) should:

  • parse wsdl and circuit
  • generate code
  • compile code

This is more cumbersome because you do not have bean classes for any complex objects in your data model. You need to use reflection.

Keep in mind that a dynamic client is different from a call interface.

+2
source share

The advantage of using a dynamic client is that you do not need to generate stubs before runtime. This allows you to broadly invoke services that you cannot know about at runtime.

+1
source share

The generated client classes are great if you know exactly which web service will call the client code, and that it will not change throughout the life of your client.

If this is not the case, you need to think about how your client will handle these situations. The Dispatch API gives you the flexibility to generate a web service call on the fly without prior knowledge of the service being served. This is obviously due to the fact that your code must support the configuration parameters necessary to create this call.

With all this, it is said that a certain responsibility lies with the developer / supporter of the interface on the server side, so as not to introduce changes that violate the client code.

+1
source share

I had a similar conversation with a colleague the other day. He used the Spring client, which requires using an interface to compile the client, but then Spring introduces the actual code for the interface to work. It basically came down to the oldest of the saws between us, things like dynamic proxies usually introduce some kind of performance tax, it’s okay with that, I started writing device drivers for writing, and therefore I’m completely predetermined in favor of speed . Faster / less wins, as far as I know, and since I'm not limited to such limited environments ... hell, my Droid phone makes all the systems I worked on, including mainframes, look professional sloppy in my first 10 years, I’ll go down on the side of speed. The common reason for this is that there are many other bottlenecks that are a "real" problem, and this problem is insignificant for them ... and this may be true ... but every bit helps. If you read the material from Steve Souders and his compatriots ... users can notice a change in just 400 milliseconds ... they put on Be sure to register that everything is slower, but their reaction is different. Therefore, since I cannot do anything about network speed, database-based overhead, etc., I can at least do the very best work that I can influence. Phew! Sorry for! Get out of the soap box now!;)

+1
source share

DII ( D ynamic I nvocation I nterface) Client: In DII, a client can invoke a remote procedure, even if the signature of the remote procedure or service name is not known before execution time.

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

  • <strong> Benefits

    • Here we must create a simple java interface describing the operations supported by the web service for access. Therefore, there is no need to automatically create stubs to access the service.
    • Using the endpoint, it generates WSDL and Stubs on the fly ie at runtime.
  • disadvantages

    • Even in this style, we need to know the web service in front of the creating client.
    • Compared to the Generated Stub (GS), it is slow because WSDL and stubs are generated at runtime.
0
source share

All Articles