In the world of distributed computing, the industry has latched on to another snazzy, buzzword-compliant, omnipotent entity, the Application Server, also known affectionately as the App Server. Here's the sales pitch. You want a robust system? Fault tolerance? Load balancing? Multithreaded transaction support? Well, don't reinvent the wheel. If you're developing an application that solves a particular business problem, concentrate on solving that problem and on developing that application. Don't waste precious resources trying to focus on solving a problem that's outside your area of expertise. After all, if you were in the business of writing compilers, that should have been the highlight of your job description. Similarly, if creating a framework for load balancing, fault tolerance and the like is not your job, let someone else do it.

When I look at the stages of my career thus far, I fondly remember the days when I designed and deployed my first commercial product, an electronic private branch exchange (EPABX) with the logic written entirely in -dare I say it? -Z80 assembly. If I mention assembly now, people say, "You must be older than you look." I don't program in assembly anymore, of course; we Java programmers frown on such low-level programming, don't we? Why would you want to deal with those tedious, low-level, limited instruction sets when Java compilers are more than willing to do all that work for you? If your application doesn't need low-level programming, the only reason you'd indulge in such activity is because you think you can do a better job of writing compiler-type code than companies that specialize in it.

This month in e-Java we'll take a look at the role played by application servers in multitier computing as well as the impact they'll have in the world of Java-based e-commerce. We'll also examine the categories of application servers that exist today and the facilities offered by these servers. Finally, we'll look at the build versus buy issue vis-a-vis application servers and discuss how one should plan to migrate from the former to the latter.

Evolution of Multitiered Architectures
Application servers are a part of the evolution of computer topologies from the mainframe to the n-tier distributed computer model. The earliest computing model was the single computer mainframe. This evolved into the client/server model. Client/server refers to a topology that emerged in the 1980s in which the computer processing tasks were separated into two types of computers connected to each other over a network. Typically, this involved the client, which was the PC, and a server, which was a mainframe. The client was responsible for requesting services from the server and displaying it to the user after applying the appropriate business rules and presentation logic. The services requested were typically served up via a database management system.

The next stage in evolution was the three-tier model. This model split the responsibilities of the client into two tiers, one responsible for the presentation, the other for applying the business rules used to serve up the data to the user. The new tier of computing was given the name middle tier. The decoupling of business rules from the presentation logic abstracted the user interface from changes in the mechanism of interpreting data served up by the database servers.

The middle tier thus acted as a broker between the data source and the data presentation. It was responsible for several functions - transaction processing, business rule validation, data transport between the presentation tier and the database server, security across the tiers, and so forth. The middle tier achieved these functions through various mechanisms such as transaction processing monitors, messaging systems, message servers and ORB (CORBA/DCOM) architectures. As the three-tier model became popular, it became obvious that it wasn't feasible for one organization to manage all the complexities of the middle tier and focus simultaneously on the business problems it was striving to solve. As a result, the industry saw the emergence of companies that started providing the middle-tier services packaged as reusable third-party tools that could be applied across various industries. These packaged services were offered via a new class of computer servers called application servers.

Figure 1 illustrates the topologies discussed above.

Figure 1:

Application Server in the Middle Tier
Application servers represent typical middleware. An application server may be defined as a server program residing in a middle-tier machine that provides the business logic and services for an application program. The middle-tier machine is part of a distributed network topology, and the application program resides on a client machine that presents the data to the user. In today's world application servers are closely tied to Internet technologies and the client is typically an Internet client. Enterprise-level Java application servers are used to offer Java and browser-based applications, thus supporting the thin-client paradigm. In the n-tiered distributed topology, application servers enable modularity and componentization of critical applications by spreading the functionality across various hardware tiers.

The data served by application servers is typically served over the Web. Application servers today are almost always used in conjunction with a Web server, forming the combination called a Web Application Server. The Web server is responsible for forwarding requests from the client to the application server and returning HTML content back to the Web client. The Web server uses several alternative approaches to achieve this, including CGI, ASP (Active Server Pages), Java Servlets and JSPs (Java Server Pages). The app servers may also use distributed service protocols such as CORBA, RMI and MTS to achieve object-based communication. If we look at the distributed n-tier computing model from the perspective of application servers, the Web application server defines the following divisions of a distributed application:

• A front-end Web browser-based GUI, which may be at a PC or network computer or in end-tier devices such as the Palm Pilot, Windows CE or Webtop machines in the emerging consumer device market
• A business logic application suite that resides in the middle tier, usually housed in an intranet or a middle-tier server farm
• A back-end database tier and transaction server, which is also responsible for interacting with legacy systems

Web Application Server Services
What services are typically encapsulated by an application server? I've mentioned business logic several times. Implementing and executing business logic is certainly the main reason for the existence of application servers. In addition, the application servers' main function is to make sure that developed and deployed applications are scalable, reliable and accessible. Application servers ensure this by offering some or all of the following:

• Improvement in performance and reliability of Web-enabled state and session management, including support for connection pooling
• Database transaction management, ensuring database integrity
• Framework for supporting component development programming models
• Multiplatform and multilanguage support
• Powerful management tools
• Support for security across the multiple tiers of a distributed application
• High performance and scalability support, including resource pooling, load balancing and connection pooling
• Fault tolerance in order to guarantee the availability of application services, including support for clustering for failover recovery
• Directory services for user roles and access permissions
• Workflow tools for defining business process workflows

Splitting the Middle Tier in E-Commerce Applications
Application servers may be classified into different categories based on the services they offer and the role they play in the application architecture. In an enterprise-level application sometimes more than one application server will coexist and interact to provide the services needed by the application.

One emerging trend in such distributed applications is splitting the responsibility into a front-end Web application server and a middle-tier business logic application server. The front-end application server -an example is ColdFusion from Allaire -is responsible for managing the C2B (customer-to-business) interaction. Such servers offer the functionality typically needed for creating virtual storefronts. In addition to the core services, other modules supported by these servers are payment modules, credit authorizations and user profiles. The middle-tier server is responsible for interacting with back-end systems and for executing business logic. Examples are BEA's WebLogic application server and Netscape Application Server. These servers aren't typically concerned with the end customer, but rather with B2B (business-to-business) applications. Figure 2 shows an architecture that uses this division of labor between the two levels of application servers.

Java and Application Servers
Java middleware has gained a lot of ground in the past year. Since the announcement of J2EE, the definition of what the API standards for Java-based middleware are going to look like is much clearer. This has helped solidify the ground for Java application servers. Typically, application servers implement a messaging layer, transaction services, business logic and security. The APIs for this are defined by JMS, JTS, EJBs and Java's security model. The good news is that Java standards will help bring ubiquity to the world of application servers in the marketplace. The bad news is that sometimes it takes more time for the standards to solidify and the app server vendors are forced to provide their own implementations to meet the needs of the market.

Build vs Buy
Several companies specialize in building app servers that provide generic services for distributed business applications. It really doesn't make sense for firms to waste developer resources by trying to create these services in-house, chiefly because it's not their area of expertise. However, cost and time to market are considerations that force companies to build their own services. In addition, if the requirements for the applications under development aren't satisfied by third-party application servers, developers have no choice but to build the functionality in-house. Still, the modules and services should be developed with the understanding that they'll be replaced by a stable third-party server whenever it becomes available.