views:

445

answers:

2

We have been provided with a wsdl and xsd schema by a company we are working with via email. The web-services we are interfacing with are accessed through a IPsec tunnel. There are local references(on their end) in the published WSDL which means we cannot consume it.

1st question: Is this a common setup? I thought the point of having a WSDL was not only to define the contract but to also expose the service to consumers.

I can easily generate client/server code off of the provided WSDL using wsimport, wsconsume, etc.. I know when my generated client makes a call to my generated service it produces the correct message I need.

2nd Question: Is there an easy way to route this to a different soap address?

I just want to be able to do something like:

SalesTaxService svc = new SalesTaxService();
SalesTax tax = svc.getSalesTaxPort()
tax.getRate("NY");

But not use the soap address defined in the WSDL. I would like to avoid writing a bunch of dispatch clients for each method.

Am I missing something?

*In response to skaffman: This is what was generated. It defaulted to wsdlLocation as a name shrug

   @WebServiceClient(name = "SomeService")
   public class SomeService_Service extends Service {

    public SomeService_Service(URL wsdlLocation, QName serviceName) {
        super(wsdlLocation, serviceName);            
    }

    public SomeService_Service(URL wsdlLocation) {
        super(wsdlLocation, new QName("urn:some_service", "SomeService"));   
    }
  }
+3  A: 

I thought the point of having a WSDL was not only to define the contract but to also expose the service to consumers.

No, WSDL is purely a descriptive tool, it has no real runtime role. The web service operates completely independently of the WSDL. It's not uncommon for the WSDL to not be exposed.

Is there an easy way to route this to a different soap address?

That depends entirely on what web service implementation you're using, and you don't say, although I'm guessing JAX-WS. If that's the case, the artifacts that JAX-WS's tools generate allow you to pass in the URL to the client stub constructors, I think.

skaffman
+1 for generating stubs.
AJ
Thanks for the reply. Yes I am using JAX-WS. The problem is that the URL I would pass in is that of the WSDL which is inaccessible. I can generate my own service and point the client to my own service implementation but that won't go to the actual SOAP:Address that I want to interface with.
jgrowl
Are you sure? I thought the URL to the stub constructor was the URL of the web-service endpoint, not the URL of the WSDL. This is why I don't like JAX-WS..... well, one of the reasons....
skaffman
Not 100% sure but look above at what was generated. It named wsdlLocation specifically. Besides If I try putting in the endpoint address it simply won't work at all (when I try connecting to a local service)... But the ?wsdl address works fine.
jgrowl
+1  A: 

So I figured out why I was having a problem. I was assuming that the wsdlLocation had to be the WSDL that the actual service was publishing. This of course is not the case. The solution is to package a local WSDL with the correct SOAP:Address for the actual service into the client.

edit I found out that you can alter the endpoint address programmatically without having to alter the actual WSDL:

HelloService service = new HelloService (
  this.getClass().getResource("originalHello.wsdl"),
  new QName("http://example.org/hello", "HelloService "));

Map<String, Object> ctxt = ((BindingProvider)proxy ).getRequestContext();
ctxt.put(JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE, 8192);
ctxt.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://new/endpointaddress");

proxy.sayHello("Hello World!");

Credit goes to : Jianming Li

jgrowl