Solving Web Development Battles
by Ed Sawicki
Accelerated Learning Center
Tailored Computers
October 14, 2007
It's rare that IT staffs within sizable organizations have not had battles over platforms and tools for developing their Web site. Unless IT staffs have been carefully selected or trained to be enthusiastic about the same products and technologies, programmers, developers, and system analysts will have their favorite platforms, languages, and development tools. How does an organization choose between Windows and Linux, Apache and IIS, PHP and Java, etc.?
Management decides based on criteria that some see as arbitrary and a subset of employees are disappointed. Some view the decision as so very wrong that they become disenfranchised, unproductive, and uncooperative with the other side. Can this be avoided?
Yes, it can. The trick is not to decide on only one Web server platform, one language, and one development tool. Allow more than one! Make all or most people happy.
If you're thinking that this would be a support nightmare, you're probably not aware of a technology that makes this easy to manage. The technology is the HTTP reverse proxy. I'll refer to it simply as a proxy for the remainder of this article but be aware that there are many different types of proxies and we're talking about a specific type.
Let's assume that one group in your company wants to run the Apache Web server on Linux using the PHP language and the MySQL database. We call this LAMP (Linux, Apache, MySQL, and PHP). Another group wants to run Java servlets using Tomcat running on Linux to take orders online. The Sales department wants to run IIS on Windows and use Microsoft Web development tools. With a proxy, each group can have what they need. Let's assume that they'll have their own server hardware.
The proxy sits between the Internet and the Web servers as this diagram shows. All requests from the Internet must pass through the proxy.
The proxy is configured to direct incoming requests to a specific Web server based on the URL. The following diagram shows that the Java/Tomcat server handles all requests where the path portion of the URL begins with /orders. The Windows server handles all requests where the path portion of the URL begins with /sales. The LAMP server handles everything else.
The next diagram gives examples of how URLs are handled. The proxy directs the http://example.com/orders/order.jsp URL to the Java/Tomcat server because it has /orders following the Web server name (example.com). It directs the http://example.com/sales/default.asp URL to the Windows server because it has /sales following the Web server name. Any URLs whose path does not begin with /orders or /sales are directed to the LAMP server.
The explanation so far has been simplistic to get the concept across. There's much more functionality available. The proxy can direct requests to certain Web servers based on other criteria, such as:
- The IP address of the requester. There are numerous practical examples for this. Requests from internal and external clients can be handled by different servers. Requests from different parts of the world can be handled by different servers.
- The current load on the Web servers. This allows the proxy to do load balancing.
- Whether the protocol is HTTP or HTTPS. Instead of purchasing a SSL certificate for each of your Web servers, you can purchase only one for your proxy. The proxy speaks HTTPS with the outside world and uses HTTP to communicate with the Web servers.
Many reverse proxies can also behave as caching proxies, reducing the load on the Web servers for requests that have already been serviced recently.
There are many reverse proxies to choose from. My favorite are open source proxies because I can tweak them to suit my precise needs. The most popular open source reverse proxy is probably Apache. Although Apache is best known as a Web server it can also be configured to be a caching reverse proxy. There are many other open source reverse proxies to choose from.
Deploy a HTTP reverse proxy and keep everyone happy!