Choosing the service URI at install time..?

[Bret Waldow]

A web service consists of a client talking with a server. A WSDL file provides details about the service, including the address of the machine the service is deployed on, which is the server URI.

Thus, this URI is in the WSDL file, hard coded into the server code, and written into the client used to contact the service.

That's fine for a company publishing a service of it's own - they decide the URI. We have a different problem.

We are providing a service for other companies to license and deploy on their own system. We give it to them to install on their system, so we don't know the URI of their server - they choose that when they install our service.

But we provide everything else. Currently, the server URI is in the WSDL, and in the .class files in the .jar which provides the service. We expect them to create their clients from the WSDL, but we need to find a way around the hard-coded URI in the WSDL and server-side .jar we provide. We don't especially want to give them our source code to make the revision themselves...and even if we did, we can't be sure they will be ready to recompile java files - they might be a .NET shop.

Any suggestions? Regrettably, it's urgent, (isn't it always?)

We are deploying in Axis 1.1 in Tomcat 5.0.25 currently.

Thanks in advance,
Bret

[Balaji Loganathan]

Originally posted by Bret Waldow:
A web service consists of a client talking with a server. A WSDL file provides details about the service, including the address of the machine the service is deployed on, which is the server URI.

Thus, this URI is in the WSDL file, hard coded into the server code, and written into the client used to contact the service.

Bret

The service URI in WSDL is dynamic and not hardcoded(atleast in Axis). its takes the host name of where its deployed.

[Bret Waldow]

AFTER the service is deployed, the dynamic WSDL provided by the service will indeed show the URI of the server it's deployed on.

I said, we are providing a WSDL file and .jar which our clients must deploy on their server. The .jar contains obfuscated, proprietary compiled .class files. These server-side SOA implementation class files must reference the URI of the server they are deployed on (at least the files generated by wsdl2java reference it - in the files named <servicename>Locator.java).

We will not release the .java source for them to modify. Instead, the question is, how can these compiled, jar'ed .class files get the server ort information at install time, or at run time? All of this happens before anyone can ask the service what it's dynamic WSDL is at runtime.

I'm getting some ideas, and I'll put our solution here once I've worked it out.