Understanding Proxies

Even though WebLogic Server can operate as a full-featured HTTP 1.1 server, its real power lies in its ability to serve dynamic content through servlets and JSPs. A number of companies have adopted commercial web servers to host their corporate web sites. WebLogic provides integration with these web servers in the form of a web server proxy plug-in. This plug-in allows the web server to communicate with the WebLogic Server (or cluster). You then can have the web server serving up the usual static content, while it passes requests for JSPs and servlets to WebLogic. A proxy plug-in offloads the task of serving static content to a commercial web server.

Here are the various architectural scenarios you should consider:

• You could use WebLogic's built-in web server as your primary HTTP server, eliminating the need for other web servers.
• You can have WebLogic Server act as the primary HTTP server and servlet engine; additionally it proxies through certain requests for static requests to a commercial web server.
• You can have a commercial web server acting as your primary HTTP server; additionally it transparently proxies requests for servlets and JSPs through to WebLogic.

The choice of which configuration you adopt is largely dependent on the type of content being served up, the performance of the various HTTP servers, and other deployment parameters. For instance, if you are serving up mostly dynamic content (using JSPs and servlets), a pure WebLogic solution should be sufficient. If you are integrating with an existing framework, proxying to WebLogic Server may work better.

We have already seen how to establish WebLogic as your primary web server, including the configuration of virtual hosts. The following section shows how you can extend this by configuring WebLogic to proxy to a secondary web server. For more information on how to set up a web tier, refer to Chapter 14.

3.4.1 Proxying to a Secondary Web Server

WebLogic Server can be configured so that its built-in web server services requests for servlets and JSPs, while other requests for static web resources are redirected to a secondary server. This approach ensures WebLogic primarily handles all dynamic requests, while requests for static files are handled by some other web server. In order to implement this scenario, you need to configure an HttpProxyServlet for the web application and then map one or more URL patterns to the Proxy servlet. This way, whenever WebLogic Server receives a request that matches one of the URL patterns, the HttpProxyServlet gets invoked and simply redirects the request to the value of the redirectURL parameter.

To set up the proxy, register the class weblogic.t3.srvr.HttpProxyServlet, and set up a redirectURL initialization parameter. Here is a snippet from a web.xml deployment descriptor that illustrates how you should declare the Proxy servlet:

ProxyServlet weblogic.t3.srvr.HttpProxyServlet redirectURL http://someserver:port/

Now you need to simply map a series of URL patterns to the servlet. You can have any number of these; again, these go in the web.xml descriptor file. Here is an example that shows how you can map all files ending in .jpg to the Proxy servlet:

ProxyServlet *.jpg

Now, any request for a resource ending in .jpg will invoke the Proxy servlet, which then redirects the request to the configured URL.