Announcement Announcement Module
Collapse
No announcement yet.
Design/Deployment Question Relating to WSDL location attribute Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Design/Deployment Question Relating to WSDL location attribute

    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:

    Code:
    <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

  • #2
    dynamic url in wsdl

    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

    Comment


    • #3
      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:

      Code:
      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:

      Code:
      <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

      Comment


      • #4
        I think your idea has merit.

        Thanks!

        Ben

        Comment


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

          Comment


          • #6
            Thanks Arjen!

            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

            Comment

            Working...
            X