Geographic Translator

The interesting challenge with Geographic Translator has nothing to do with portlet technologies. This application is in dire need of someone with Graphical User Interface skills.

There are very cryptic parameter strings that have to be composed and passed in to the service to produce the desired transformation. Wanting to provide a capability to support transformations between 36 different coordinate systems and 230 different datums, while leaving the SOAP parameters as close as possible to the parameters of the underlying legacy application, has led to a very confusing set of instructions.

It was much easier to use the code completion feature of NetBeans after building the web service client to figure out exactly what data was needed by each of the service options. But then, not being very adept at designing web page forms, I was left to struggle with figuring out the best way to present the instructions to users for the many different use cases.

I was starting to get the hang of using the HTML div tag and the onClick javascript function to dynamically present the user with the form fields needed for input based on which type of transformation was being performed. Then suddenly the WSDL was no longer accessible over the network. So what was going on this time?

After a number of email exchanges (what exactly does "they changed something on the external firewall to prevent me natting" mean?) I found out that the IP address of the 6 WSDLs I was using in the NetBeans project that has the 6 SOAP Web Service clients had been changed. So now, how difficult is it to get the code working again?

I remembered the little trick of doing a "Refresh Client" to point the services to the new WSDL location. I also did a clean and build. The build was now working but if I tried to run the project and access one of the services I would continue to get an exception stating that the WSDL could not be found because it was looking at the old IP address. The solution was to delete each of the web service clients and then recreate them with the new WSDL. Not really that time consuming once I knew what had to be done, but, of course, the whole day was wasted trying to figure out what was going on.

The developer of the SOAP Web Services was kind enough to provide me with his code solution that uses a configuration file to make a Web Service client configurable after deployment. That will definitely bear looking into since this environment is proving to be somewhat less than stable.