This best practice applies to the following product, version, and platform:
- WebSphere Application Server - Base, versions 4.0 and 4.0.1, OS/390 and zSeries
Although some of the items listed here may seem obvious, they are included for the sake of completeness.
1. Establish a preliminary test environment in which to experiment and gain experience.
Before constructing the webapp environment for production use, invest some time experimenting with a "sandbox" configuration. Establishing a separate J2EE application server in which a test webapp can run is relatively simple, and configuring the Transport Handler to service that application server is even more straightforward. Setting up a test HTTP Server with the plugin is a bit more complicated, but not unduly so.
You can gain valuable insights into how this system works by experimenting before committing a design to production. It is time and effort well spent. The sandbox environment can be quickly dismantled later without affecting the larger WebSphere environment.
Having both the Plugin and the Transport Handler configured at the same time is a perfectly acceptable thing to do. However, it can be somewhat confusing at first because of the way applications are bound to the virtual hosts (see next item). With both configured, it's possible a URL issued from a browser will result in a "Virtual Host or Web Application Not Found" message. This results because, for example, the webapp is bound to the Transport Handler's virtual host but the URL was pointed to the Plugin's virtual host.
It's possible to bind applications to both virtual hosts. Unless you have more advanced knowledge of how this works, configuring only one listener is best. After you gain the understanding of how this works, you will be better positioned to configure a more complex environment.
To help you understand the pros and cons of each listener, the following summary chart is offered:
Listener Pros and Cons
This concept is outlined in fair detail in the white paper referenced in the Resources section of this document. Understanding this concept is important because a webapp not properly bound cannot be executed. And understanding the concept allows you to validate that the webapp was in fact bound successfully.
Several sub-points are noteworthy:
- You must bind your Web applications to virtual hosts whether you are using the Plugin or the Transport Handler. The act of binding applications is largely independent on which HTTP listening agent is being used out front.
- Any time you deploy a new application into a WebSphere Application Server Version 4.x J2EE server, you should validate that the webapp is bound to the virtual host you intended. You can verify this by inspecting the SYSPRINT of the server region (not the control region) and reviewing the report of bound applications to virtual hosts. Again, the white paper outlines what this report looks like and how to verify proper binding.
Common Mistakes:
- The
host.[name].alias=value coded doesn't match the host value found on the received URL.It's easy to think that the virtual host value you code must be equal to the value coded during the ISPF customization dialogs, and that may be the right value to use. But it also may not. The rule of thumb is this: code the
alias=value equal to whatever host value you expect to be on the URL received by your server. Many things in the network can cause a URL to flow to your server (such as DNS configuration, HOSTS file updates on PCs). - The
host.[name].alias=value is coded in uppercase, or in mixed case.WebSphere Application Server will take a received URL and convert the host value to lowercase before it compares it to the
alias=value. Therefore, thealias=value should be coded in lower case. - Two
host.[name].contextroots=statements are coded using the same string value.This is typically done in an attempt to bind an application to two virtual hosts. While this is possible, coding two
contextroots=statements is not the way to do this. Instead, code onecontextroots=statement pointing back to onealias=statement, and provide two (or more) virtual host values on thealias=statement, separating each with a comma.If two
contextroots=are coded, the WebSphere Application Server will only bind to one of them
This pitfall comes about when someone tries to deploy the same application into two different J2EE application servers. Without going into too much detail here (because it gets somewhat complicated to explain), the best practice is to deploy the application into different J2EE application servers using different "virtual host / context root" pairs.
Of the two (virtual host or context root), the virtual host is the easiest to change. The context root is set during application assembly, and the value for the context root resides in the application.xml file of the assembled EAR file. The virtual host, however, is set in the webcontainer.conf file and is open to changing any way you want. Another point to remember is that the port designation is part of the virtual host, so a value of www.mycompany.com is a different virtual host from www.mycompany.com:8080 . If you need to perform load balancing across two or more different J2EE servers, consider using replicated servers (separate instances of the same server) which support unique "virtual host / context root" pairs by design.
5. Have in place some basic validation mechanisms so you can quickly test the pieces of your system.
The objective here is to have some quick tests in your back pocket so you can determine the health of the various components of your system without having to dig through trace files:
- If you're using the WebSphere Application Server 4.x Plugin, have a
Passstatement coded in the HTTP Server'shttpd.conffile that will resolve to a simple HTML page you know is on the server. You can then point your browser at that simple HTML file, and if the file is served to you (beware of browser cache), you know that the HTTP Server is at least up and functioning. - If you're using the Plugin, leave the
/webapp/examplessample application intact that comes with the supplied samplewas.conffile. This serves two valuable functions:- It provides a way of validating that a URL request can be mapped into the Plugin environment with a
Servicestatement, proving that the Plugin has initialized and is operational. - The "Application Dispatching Information" function of the "showCfg" servlet will tell you about the webapps it sees as deployed and available back in the J2EE application servers.
If you're concerned about exposing that function to the world, Protect the
/webapp/examplesresource.- If you're using the Transport Handler, issue the
TSO NETSTAToption to make certain your J2EE application server control region is listening on the port you expect it to. - Consider deploying a simple webapp in each J2EE application server that consists of nothing more than a static HTML page packaged in a WAR file. Have the name of the HTML file match the name of your J2EE application server instance, and set the context root to indicate the server instance in which the dummy application is deployed. You may then point your browser at this static HTML page and if the page gets served out (beware of browser cache, please), you validate that the pieces of the system allow your test request to flow all the way to the web container and allow at least a static page to be served out. That allows you to rule out as the cause of error many of the other pieces and focus just on that piece of the puzzle when a URL hits the web container. This test works equally well whether the Plugin or the Transport Handler is being used.
- It provides a way of validating that a URL request can be mapped into the Plugin environment with a
AThe essential message here is to start slow, get some experience under your belt, then progress to the more complicated configurations. As you configure your runtime environment, you will find that there are multiple choices available. In some cases, configuring both HTTP Listeners could be very problematic. This is especially true if you are just getting started with the WebSphere Application Server for z/OS and OS/390. Throughout the Recommendation section above, several alternatives and their implications are presented.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
