Advantages of using a Dynamic Client with JAX-WS

Question

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?

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

-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.

Briefs

Answer 1

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

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.

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.

Hide

@Pascal - I appreciate the answer... Maybe I should have better phrased the question as what conditions would cause you to use a dynamic client over generated... – Briefs

Answer 2

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

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

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

Hulahula

@Hulahula - Any reference for dynamic clients being slower? Care to elaborate on what more "cumbersome" means? I'm not saying its not correct, just looking for a reference. – Briefs

The only real "slow" part of the dynamic client is the startup costs. We basically need to parse the wsdl, call xjc to generate some code, compile it, load the compiled classes into memory, etc.. and THEN, after that is all done, do much of the same setup as the normal generated clients. Once all generated and running, the dynamic clients aren't any slower. – Ing

Answer 3

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.

Guild

@Guild - This is the reason why I was asked to move to a "dynamic" client.. in order to create compile time dependencies... but it also introduces coupling between the client and server side code... I guess I'm still weighing the positives and negatives. – Briefs

Answer 4

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.

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.

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.

Prescind

Answer 5

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 Souders and 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! ;)

Haematoxylon

Answer 6

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.

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.

• 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.

Vulcanology