The first thing to understand about receiving the request from our Palm OS device is that it won't really be coming from the Palm OS device itself. Instead, all Web Clipping devices make use of a proxied architecture like the one shown in Figure 4.

This is important, because it means that you cannot test your Web Clipping applications by pointing them at localhost. The reason for this is that the proxy servers attempting to reference localhost would be pointing back at themselves, rather than your own machine. So in order to receive the request on your own instance of Tomcat, you must change the HTML shown in Listing 1 to reference your own machine (either by DNS or IP) and then recreate and reinstall the PQA.

The proper URL will probably be something like: http://yourIP:8080/examples/servlet/StartListener

Once you have set this and reinstalled, you are ready to retry your Web Clipping application. If everything is set properly, you should see something similar to Figure 5.

Figure 5.

You try!

When we finished our previous code listing, the PQA's request had been received and interpreted by the Java Application Server. In Listing 3 below, we modify our servlet to start the Oracle listener, then inform the client of our success.

Overwrite the existing StartListener.java file with the code in the listing above, recompile it, and then re-deploy its class file to your JAS. You are now ready to restart an Oracle listener from a wireless Palm OS client! Simply click your PQA application to start it up, and then click the button labeled "Start the Listener." In a matter of seconds, if you indeed have an Oracle listener in the appropriate path on the same box as Tomcat, you should see a success message.

So close, and yet so far

Solving some of the more glaring shortcomings in this approach has been the focus of much proprietary Expand Beyond Corporations' Pocket DBA technology. To begin with, the server's response tells you nothing of the output of the command or its specific status. It merely tells you whether or not the servlet generated an error. Using the streamed output features of the Process class, it should be possible to grab the command output and return it to the client.

On the other hand, this is potentially dangerous, because the command is executing on the servlet's main thread. This means that, in the case of a long running command, the system could become completely frozen and inaccessible to other clients while waiting for the command to finish.

Finally, by running this servlet, you make an easy entry point for any hacker who wants to run random commands on your server. In this particular case, all they could do is restart your Oracle listener. However, with a real product like PocketDBA, virtually any command that the user can imagine can be run in a similar fashion. For this reason, any such servlet should be carefully secured with a password and encryption of data coming and going.