Deploying WebObjects Applications With Direct Connect
WebObjects 4's Direct Connect option allows you to develop and test a WebObjects application without a separate web server. This is the default when you start an application from the command line. This option is useful for developers, because it eliminates the need to run a web server on your development system.
The URL for a DirectConnect application will look something like this:
http://localhost:33543/cgi-bin/WebObjects/HelloWorld
The Hypertext Protocol
The first part of the URL:
http://localhost:33543/cgi-bin/WebObjects/HelloWorld
represents the protocol you are using to communicate. The http prefix represents the hypertext transfer protocol and means that you are expecting a response in html format. For a deployed WebObjects application this response will come from a web server; for a direct connect application, it comes from a WebObjects application. If you had misspelled this part of the URL, for example:
htpp://localhost:33543/...
you would get an error message from your web browser such as:
The protocol specified in this address is not valid. Please make sure the address is correct and try again!
The browser will raise an error of this kind whenever it doesn't recognize the protocol you request. This error message will vary according to your browser and version.
The Hostname
The next part of the URL:
http://localhost:33543/cgi-bin/WebObjects/HelloWorld
is the hostname of the machine you are connecting to and the port number to which you're trying to connect. In this case, it is an alias for your local machine. If you mistype the hostname, the Domain Name Lookup performed by your web browser will fail, and you will get an error message something like this:
Internet Explorer could not open the Internet site
A connection with the server could not be established
or this:
Netscape is unable to locate the server
Please check the server name and try again
This message is generated by the browser and will vary according to your browser and version.
The Port Number
The hostname for a DirectConnect application is always followed by a port number:
http://localhost:33543/cgi-bin/WebObjects/HelloWorld
When a WebObjects application is started at the command line, the port number can be specified with the -WOPort option.
If there is no WebObjects application running on the port you specify, you will get an error message something like this:
Internet Explorer could not open the Internet site
A connection with the server could not be established
or this:
There was no response. The server could be down or is not responding.
If you are unable to connect again later, contact the server's administrator
This error message comes from the browser and will vary according to your browser and version. This error message may be the same as the error message for an incorrect hostname, above.
Communicating with the DirectConnect Application
If there were a WebObjects application running on port 33543 of your local system, the URL:
http://localhost:33543/
would connect to it successfully. Since each Direct Connect application will be using a unique port, nothing after the port number is significant when making the initial connection. However, the rest of the URL is very important when you deploy your application on a web server.
The Web Server URL
Deploying WebObjects Applications With a Web Server
While DirectConnect provides a quick way for developers to work with their WebObjects applications, once development is finished the application should be deployed on a web server. The URL of a WebObjects application running on a web server will look something like this:
http://webserver.domain.com/cgi-bin/WebObjects/HelloWorld
The Protocol And Host
The first part of this URL:
http://webserver.domain.com/cgi-bin/WebObjects/HelloWorld
is the same as for the direct connect URL above. The difference is that here the hostname will be either the numerical or named IP address of the web server:
http://www.apple.com/...
or
http://17.254.0.91/...
In addition, no port number is given. This means that the web browser will try to connect to the default http port, port 80. If the protocol, hostname or port number is incorrect, you will see the same errors as given above for the direct connect URL.
The cgi-bin Directory
The next part of the URL:
http://webserver.domain.com/cgi-bin/WebObjects/HelloWorld
represents the web server's cgi-bin directory. The web server should recognize this as a signal that the next part of the URL is an executable to be run. You can run executables from any path if your web server is configured to do so. Microsoft's IIS web server normally uses the path "scripts" instead of "cgi-bin":
http://webserver.domain.com/scripts/WebObjects.exe/HelloWorld
If the web server does not have the cgi-bin path configured to run executables or does not exist you will get an error message such as:
Not Found
The requested object does not exist on this server. The link you followed is
either outdated, inaccurate, or the server has been instructed not to let
you have it.
This error message is generated by the web server and is usually displayed as a page in the web browser. If you receive this error, check that the server is configured to run executables from the path cgi-bin. The specific steps required will depend on your web server. The web server error log files will help you to debug this.
The WebObjects Adaptor
The next part of the URL is the name of the executable to run, in this case the WebObjects adaptor:
http://webserver.domain.com/cgi-bin/WebObjects/HelloWorld
On Windows NT this may be "WebObjects.exe". The error messages you get from the adaptor will vary depending on the specific adaptor module you are using; cgi-bin, NSAPI, ISAPI, or Apache. If you send a URL with the adaptor and no other arguments, you might get a response from the adaptor or an error message from the web server. Instead, to test the adaptor, send a URL with some characters after the adaptor name:
http://webserver.domain.com/cgi-bin/WebObjects/someJunktext
You will get an error message like:
The requested application was not found on this server
This message comes from the WebObjects adaptor. Since the adaptor is now running, you can debug adaptor error messages by turning on adaptor logging. This is normally
done by creating a file named logWebObjects in your system's $TEMP folder. On Solaris, for example, you must create the file /tmp/logWebObjects as the root user. The adaptor will then start logging information into the file /tmp/WebObjects.log.
The WebObjects Application
The last part of the URL:
http://webserver.domain.com/cgi-bin/WebObjects/HelloWorld
is the name of your WebObjects application. The WebObjects adaptor will check the public webobjects.conf file to find instances of an application with this name. If it finds one, it will forward the request to that application. If it does not, it will check the private webobjects.conf file. If no instance with the appropriate application name is found in either file, you will see the same error message as when you typed in garbage above:
The requested application was not found on this server
This error message is generated by the WebObjects adaptor.
If you have the HelloWorld application configured and running, you will see the page generated by the application in your web browser. Once you have connected to the application, you may see additional information at the end of the URL:
http://webserver.domain.com/cgi-bin/WebObjects/HelloWorld.woa/wo/3HGN10gz64bjuvic1/0.2
This is added to the URL by the WebObjects application and should not be edited by the user.
Conclusion
The web browser, web server, and WebObjects adaptor parse the URL from left to right, only proceeding when there are no errors. Recognizing where the error messages you see in the browser come from can give you valuable clues to where problems exist in your WebObjects deployment.