Skip to main content

Varying Endpoint Address in Client

8 replies [Last post]
Joined: 2005-08-16

I've been doing some experimentation with JAX-WS 2.0 EA2. I'm attempting to generate a client that can access an existing web service. This client might be making request of a various instances of the service (i.e., same WSDL binding, but different addresses).

The generated stub is retrieving the endpoint address from the original WSDL, which I find a bit bizzare - I'm not sure why this isn't an annotation in the classes that I've already created.

That bit of strangness aside, I don't see any mechanism that would allow me to point the client at any endpoint. I'm hoping that someone will be able to point me to whatever it is that I'm missing. I couldn't find anything like this in the samples.

This seems like such a basic concept, that it must be possible somehow!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-02-17

So did you come up w/ a solution? Please paste in some code. I went down to the level of dispatcher and set the url it did not affect the call using the wsimport PortType that was created.
Agree w/ aneilson - we need to be able to modify endpoint services at any time and I should be able to make a separation between endpoint listed in the wsdl and say a database property for endpoint. And it should be easy to do this.

Joined: 2003-06-14

You can set the endpoint address using BindingProvider.ENDPOINT_ADDRESS_PROPERTY

Something like this should work for you.

BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "...");

Joined: 2005-08-16

Thanks, your suggestion for setting the ENDPOINT_ADDRESS_PROPERTY on the stub works.

I still don't see why the original WSDL file needs to be around. I would have thought that the process of importing the WSDL into annotated code would mean that the WSDL is no longer needed. If the WSDL file isn't in its original location when I use the stub, I get an exception complaining about it being missing. This doesn't make any sense to me.

Joined: 2003-06-16

The reason that accessing the WSDL at runtime is needed is because we no longer generate binding specific interfaces. So at runtime, we need to go look into the WSDL to determine the binding.

Joined: 2005-08-16

I guess I'm coming from a different perspective where the WSDL binding doesn't have the same sort of significance (i.e., always document/literal bindings, and choosing different transports is something that happens elsewhere in the stack).

I can understand why you would refer back to the original WSDL to access the binding information if it hasn't be rendered into some attributed code format for runtime. Aside from any overhead to process the WSDL again at runtime (which could be significant in some cases), it seems like there is potential for deployment problems.

I got into trouble at first because I wasn't aware that this was going on at all. Some documentation is definitely in order to ensure that people don't attempt to deploy apps with the originalWsdl pointing to some server that isn't accessible (e.g., a development server).

I can imagine needing to take special steps to have to deploy the WSDL file along with my application for a variety of reasons: the server only handles one-way or POST messages or requires security that the code fetching the WSDL doesn't implement. Am I always going to be able to deploy the WSDL file in a way that it is accessible from my client app in the local file system? Even if I can, it seems like one more deployment issue that I'd like to avoid - especially since the tool could have extracted all the binding goodness out of the WSDL file at development time.

Joined: 2003-06-10

WSDL bindings are extensible. Moreover, with WS-Policy starting to be deployed, it's going to be even more complex to capture all the details in annotations, except in simple cases. We could have designed a mix of annotations and XML-based descriptors to capture all the information, but that's error -prone and quite static anyway. Either approach would have lead us to playing catch-up with the latest WSDL extensions with no end in sight.

So we decided to take a different route and use WSDL itself as the binding description language: after all, all the required information is there by definition. The drawback is that it requires accessing the WSDL at runtime. On the plus side, if more dynamic policies start being deployed (think of what WS-MetadataExchange permits), we won't need to make changes to the basic architecture.

I should add that we are looking at using a catalog mechamism like the Apache XML Commons Resolver to make it easy to package the required WSDL documents with the application and avoid expensive remote accesses at runtime.

Joined: 2008-09-11

Is it possible now to package the required WSDL documents with the client application and thus to avoid expensive remote accesses at runtime ?

Joined: 2004-06-01