Design/Deployment Question Relating to WSDL location attribute

[benethridge]

Hi, everyone.

I have a general question/problem regarding WSDL design and syntax that we have been wondering about at our company.

In WSDL, from everything we've seen and learned, the "address location" is hard-coded:

<wsdl:service name="MyService">
		<wsdl:port binding="tns:MySOAPBinding" name="MySOAPBindingPort">
			<wsdlsoap:address location="http://www.mycompany.com:8080/myApp/MyApp"/>
		</wsdl:port>
	</wsdl:service>

That being so, how do you deploy (somewhat elegantly) the same war (i.e. same source code, i.e. same app funtionality version) to multiple servers without having to manually modify the wsdl for each one of them? Is there a way to "soft-code" the location attribute in the wsld, so that it can be picked up at deploy-time from some kind of properties file?

We had also thought about writing a program to soft-populate the value by writing a simple program to modify the location, and then making that program be part of the deployment script after the war has been unpacked by tomcat.

We're thinking that most everyone in the WSDL world must have this problem, or perhaps we're missing something simple?

Ben

[farrellr]

Yes, I too have been editing wsdl manually, wishing there were a better way.

I have seen this before:

http://forum.springframework.org/sho...ht=wsdl+deploy


Arjen, any development after that?
... Rich

[breidenr]

First, let me say I have been wrestling with this in my head for the past couple of weeks. I have not implemented this yet, but I think I have a workable solution...

In my mind, this really boils down to two seperate things:

1. How to configure environment specific attributes for an application in general.
2. How to handle the WSDL service location specifially.

There are several ways to solve #1. For the sake of simplicity. let's assume that every machine on which your WAR will be deployed will have a properties file at a well known location that will contain environment specific information:

debugLevel=WARN
wsdl.location=http://mytestserver
ldapServerName=testLdapServer
someOtherProperty=someEnvSpecificValue

These can easily be loaded using a PropertiesFactoryBean.

Since your WSDL is just a file in your deployed application, you probably have it somewhere at the root of your web application and access like this: http://localhost/MyApp/MyApplcation.wsdl. Since no URL is mapped to this extension in your application, the file is simply served as-is.

However, this is no reason you could not override this behavior and map *.wsdl to a servlet or Controller, which would in turn return the WSDL file indicated in the URL. However, before returning the file, it would do some simple property placeholder replacement. So, the bundled WSDL could look like this:

<wsdl:port binding="tns:MySOAPBinding" name="MySOAPBindingPort">
    <wsdlsoap:address location="${wsdl.location}"/>
</wsdl:port>

and your servlet/Controller would take care of replacing ${wsdl.location} with the appropriate value.

If I get a chance, I will try to dummy up a simple example this evening. If you think this idea is awful, let me know and save me the trouble

[benethridge]

I think your idea has merit.

Thanks!

Ben

[Arjen Poutsma]

Check out http://opensource.atlassian.com/proj.../browse/SWS-47, which available in the nightly builds.

Hopefully, I am able to to do a 1.0M2 release soon, so that you don't have to resort to nightly builds anymore.

[farrellr]

Thanks Arjen, I've already grabbed one of the nightly releases to get the multiple xsd for validation functionalty, so I should already have this functionality as well. I'll give it a try.
...Rich