ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
We’ve already talked about what a Web server can do. But what about an application server? The distinction used to be quite clear. A Web server only served up HTML and images for viewing on a browser. And while an application could exist on the Web server, that application was typically restricted to just generating HTML and image data.
When discussing how a Web server works, it is not enough to simply outline a diagram of how low-level network packets go in and out of a Web server.
Likewise, in the beginning, the definition of an application serverwas fairly concrete. An application server merely contained raw business/application logic of an application and did not contain database or user interface code.
In many cases, the application server served as the middle-tier of three-tier programming. The figure below contains an illustration of the three-tier programming model.
In other words, an application server sits in the middle of other programs and serves to process data for those other programs. Usually, in the case of three-tier programming, the two layers that are separated by the application server is the User Interface layer and the Database/Data Storage layer.
Note that the concept of an application server should not be confused with Web applications sitting on a Web server itself. Web applications generally also contain application logic, but since they primarily serve to generate HTML for a Web browser, they are also user interface related and generally do not ever reside on a pure application server.
|
Data Marshalling Data marshalling is a term used to refer to the way applications talk to each other. Similar to how Web servers wrap human-readable content in HTML to make it palatable to the eye, application servers wrap application-readable content inside other tags to allow the data to be interpreted by the receiving application. These “tags” formed the standards around which application servers were formed. For example, CORBA servers use a protocol called IIOP (Internet Inter-Orb Protocol) to transfer data between application objects. More recently, XML extensiblee Markup Language) has made data marshalling as easy as making up your own tags that are similar in syntax to HTML except that they describe data rather than how content should be displayed in a browser. More information about XML can be found in Selena Sol’s XML tutorial. |
In the past, most such application servers talked the language of data marshalling protocols such as IIOP for CORBA, Java’s object serialization for RMI, and DCOM for remotely activating Microsoft ActiveX objects. However, the rise of XML (extensible markup language)as an internet friendly data marshalling language has blurred the boundaries.
Web Servers are turning into application servers that serve XML data alongside HTML data. Likewise, application servers are being marketed as being able to add value by having the capability of acting as a simple Web server while still delivering on it’s core application server functionality.
Nearly all Java Enterprise Bean servers market the capability to simultaneously serve Java Servlets and Java Server Pages — traditionally the realm of Web servers. Likewise, new data marshalling languages such as the Microsoft endorsed SOAP (Simple Object Access Protocol)XML standard have implementations that run in conjunction with existing Web servers.
So what should you use now that the distinction has become blurred? Web Server or Application Server?
The reality is that one size does not fit all. Typically, application servers are tuned for processing data using objects or code that represents application logic. Likewise, Web servers tend to be tuned to sending out data.
Web sitesic rule of thumb is that if you think of your Web site as, well, a Web site, then you should probably be using a Web server. Even if the data you are serving is dynamic, the fact that your site is Web centric means that all the configuration parameters of your Web server are best served tuning how you display information to other people’s browsers.
For example, although it is easy to find an application server that can serve Web pages, you will be hard-pressed to provide one that supports Server-Side Includes (SSI) which is a feature nearly every Web server supports out of the box. Of course, you can still add application server components to a Web server if part of the data will be related to applications.
However, If you find that you are using application server components as the primary reason for your Web site, or that the Web server itself is being dragged down by all the resources that the application components may be using, then you should consider moving the application components to their own application server.
One thing we should mention is that breaking out application components of a Web site into a separate application server can help you in several ways. In some cases, breaking out the application components can increase both performance and stability of an application. However, you should be wary of doing this too early because the addition of yet another server in your environment can also add quite a bit of complexity to managing your infrastructure.
As we just mentioned, breaking out application components in this way also usually aids in performance. For example, Web servers are usually highly tuned to serve data from disk such as HTML pages and images very efficiently. Such a server is tuned to speed up IO operations. On the other hand, application objects are usually operating on pure logic alone — they take data in from a stream, process it, and send new data back out again. This is a CPU rather than IO intensive activity. Thus, the application server is best served when it is tuned for CPU usage.
In addition, breaking out components usually adds to the stability of an application. Application servers are tested by their respective vendors to work in the context of executing application logic and so they are thoroughly debugged in that context. Likewise, Web servers are heavily tested within the context of serving documents either dynamically or statically. Mixing the two into one server can cause unexpected bugs that neither vendor has tested for.
Note that I use the word vendor loosely here since Apache has no “vendor” but rather is a community of open source developers who have arguably tested Apache beyond the scope that many other Web server vendors test their own products. However, even an Open Source community may have limits to the mix of environments that their products have been tested in.
Of course, these benefits should be tempered by what we mentioned earlier. If your Web site is mostly serving document data, it probably doesn’t make much sense to rush out and purchase an application server. Indeed, if your environment is simple, you could be adding unnecessary complexity to the overall solution, thus maikng it harder to maintain and administrate — unless you have devoted human resources to such an endeavor. As a rule of thumb, the more servers there, the more that must be maintained.
