Application Servers by Jason Martino
Every major corporation now recognizes that the Internet is more than just a new marketing channel for their products and services. They see the web as the infrastructure that will provide customers, suppliers, and investors with the latest product information. It will allow information resources to be truly distributed to any place on the planet. Most importantly, the web will provide the backbone for the day to day operations because it will be the provider of the applications that drive the business. This is where the Application Server comes in. The Application Server market is for businesses that want to do more than host a virtual storefront. It is for businesses that are willing to invest in a strategic web solution.
Brief Definition
An Application Server is a piece of middleware that sits between the thin clients and the back end systems such as databases, transaction servers, mail servers, and accounting systems. More specifically, it is a web server that can link to these data sources and provide the hooks to view and modify data. However, the web pages and applications it returns are created using dynamic content technology: content that is suited for the viewer.
For example, in an airline reservation system, a web page viewed by a customer would show the latest flight information. But if the same web page were requested by a travel agent, additional information would be provided such as discounted fares and package deals. This in turn would streamline business operations by reducing customer service costs and provide the customer with current, timely, and verbose information based upon what he/she is interested in or is allowed to view.
Scalability
Application Servers allow businesses to scale quickly. Offices can be decentralized cutting real estate costs. Systems can be set up quickly. One only needs a connection to the Internet. Because the web pages are delivered to thin clients, all the client needs is a web browser. Based upon that user’s permissions, the user can access and modify critical corporate information from any place in the world. The network is basically provided for. It is the World Wide Web. It is based on the universal TCP/IP protocol. Almost every application provides some sort of hook into the web, which makes the Application Server the perfect glue to connect legacy systems to the new model.
Back to the Definition
But wait! We already know of these technologies: ASP, Java Servlets, CGI…. These all provide dynamic content and they can hook into databases and mail servers. Many applications today are sold with web enabling add-ons that allow companies to use them over the net (Domino for Notes, Web interfaces for PeopleSoft).
So what is an Application Server? It is a highly versatile and unified approach. Some Application Servers use Java Servlets and Java as the primary technology. After a request for a page comes in, re-usable business objects written in Java access back end data sources and return pages based upon the result set. These objects have common interfaces that work the same no matter if they are accessing a database or a distributed CORBA object.
More specifically, an Application Server must be able to do the following:
Applications
Applications built for an Application Server have few limitations. But they must be designed from the perspective of the web model. Here are three important considerations:
Connection speeds vary depending on the audience and application
There are two types of applications that Application Servers can deliver, pure HTML applications and client server applications based on Java Applets or ActiveX. In the ideal world, applets would provide a rich and completely customizable interface. Java developers could provide detailed and responsive views of company data. There would be few page requests and the application could talk directly to the server. But with the limited bandwidth of most consumers, applets are often not an option. Even on corporate intranets, a complex applet may take some time to download under heavy traffic. Therefore, in most cases, dynamically generated HTML is the answer most companies are turning to today.
The HTTP protocol is a stateless protocol
Most Application Servers provide the ability to store cookies on the thin client which are able to identify the client for application such as shopping carts. But a more interesting state mechanism is the Session Object. When a client connects to the web server, an object is created in memory keeping track of a user’s identity and other information such as user access or previous shopping cart selections. Once the client starts a new browser session, that particular session object is destroyed giving the client a clean start. One advantage of this approach is that there is no intrusion on the client machine. A disadvantage is that these session objects are more volatile.
The event driven model is closely tied to HTTP
There is no event model for HTML. When you click on a form, a request is sent to the web server. In the old CGI model, the clicking of a "Submit" button would fire a CGI program, a very tedious and difficult to maintainable process for a large application. In the case study, one Application Server answered this problem with Java and Java Servlets.
Case Study – SilverStream Application Server
Some Application Servers provide an entire event driven framework. SilverStream is one. The SilverStream Application Server comes with an HTML page designer that allows developers to visually design web pages. But the page is not really an HTML page at all. It is a Java Servlet. If one were to compare the HTML in the page designer and the actual HTML source code after the page is downloaded, he/she would see two very different results. Every time any text or HTML components are put on the page, Java Servlet code is automatically inserted. Stub Java methods such as "Submit_Button_Clicked(..)" are also entered into the servlet which the developer can modify. Therefore, the servlet provides a way to program the web pages with an event driven model even though HTML doesn’t support one.
When the client requests a web page, the servlet runs. As the servlet executes its code, it sees if the submit button was clicked, examines the parameters that were sent along with the request, and dynamically returns a page based upon those parameters.
Furthermore, HTML components can be bound to columns on a database table. For example, customer record #21 may have the phone number "781-238-5400". When the client clicks on a link to bring him to customer record #21, the phone number text field is already filled in. If he wishes to change the phone number, he can fill in the new phone number and hit the submit button. The "Submit_Button_Clicked(..)" event handler can make the necessary calls to insert the new information into the table.
Permissions and Security
Wouldn’t it be nice if a developer could develop a web page that looked different depending on who was using it? For example, when a customer orders a product, all he cares about is that the product is in stock. But the inventory department might want to know how many are in stock. With dynamically generated web pages and Application Servers, this can be handled quite elegantly. Depending on whom the user logged in as (or if the user logged in at all), some HTML is generated, and some may be left out. A user in the inventory department might see two extra columns, one containing the stock count and the other containing a text field and submit button saying "Order Amount." Employees and customers can use the same gateway into the business. Development time is cut down and the company’s entire operation has a consistent look and feel. Most Application Servers come with a built in security manager that helps companies deal with the complexities involved with security.
Clustering and Load Balancing
A good Application Server must have the ability to deliver pages without a glitch. By clustering servers together, information can be synchronized so if one goes down, another can pick up where it left off. Another consideration is performance. The more servers that are clustered together, the more total connections the system can handle without performance degradation.
Sample Applications
Players
Several major companies (about 40) have come out with Application Servers. Most seem to be moving towards Java as the solution of choice. Java technologies such as Servlets and Enterprise Java Beans (back end business objects) are behind this move. The object oriented approach and lower development costs associated with Java make it attractive. The buzz of EJBs and Sun's promise of simplifying and re-using complex back-end business objects is also attractive. Most companies like the distributed architecture of CORBA better than Microsoft's DCOM, and Java provides a good glue for tying together different distributed systems. Also Java applets can be deployed in web pages with no footprint on the client. Some companies are trying to please both camps and be compatible with CGI and ASP. Microsoft's plans are still foggy in this market. Please visit http://serverwatch.internet.com/reviews/app-reviews.html for full reviews and pricing.
Conclusion
The Application Server market will continue to evolve and grow into a multi-billion dollar industry. The Application Server's promise is the total integration of vital business operations and the web. They are expensive to implement and may not be a good solution for a small company. For example, a system to support both a shopping cart application and an order entry/order maintenance application might well run over $100,000. Hardware will alone cost over $10,000 considering one needs at least two high performance servers, one for the database and another as the web server. This does not take into consideration fail over servers but would probably include hot swappable hard drives for hard drive failures. Then there are the software costs. Application Server software can cost anywhere from $5000 to $25000 per server. Plus a company must pay for the server software(NT or UNIX) and the database software. There are also 3rd party applications used for solutions such as accounting and reporting that can also run above $5000. Finally there is the development costs and the constant trade-off between in-house developers and consultants. Consultants may charge anywhere from $75 to $150 an hour. A system critical application will take at least a 1000 hours which would put the development cost over $100,000.
However, as stated above, these systems are highly scalable. They can glue all the company's information resources together and provide a company with the competitive edge. They can also cut costs in the long run. Offices can be decentralized cutting real estate costs. Training costs are cut down because the interface is the universal web browser. Information can be accessed by employees anywhere in the world where there is an Internet connection allowing companies to set up shop quickly and cheaply.
* Please look at screenshots of an actual application co-written by me, Jason Martino
**All Pictures courtesy of SilverStream Corporation