any applications server checklist: reducing implementation cost, ease of development, and integration into the existing network environment.
No single solution is a perfect fit for every company, and legacy systems mean that few IS managers have the luxury of launching applications servers from a clean slate. Choosing the right solution for any particular operation still requires you to sift through confusing and often contradictory information. In this report, we'll examine the spectrum of applications server solutions from x86-based PCs to high-end RISC systems and from server operating systems to applications server suite
s.
What, exactly, is an applications server? The definition often depends more on who's doing the defining than on the underlying technology. Vendors of mainframe and midrange computers define their systems as applications servers because these systems run core business programs such as billing, inventory control, sales analysis, general ledger, and payroll.
Vendors of increasingly powerful PC servers also define their systems as applications servers. After all, these systems now incorporate many high-end management and development features and can also run core business applications. But unlike their high-end cousins, PC system vendors tend to be more egalitarian in their definition of an applications server: They broaden the category to include, in addition to traditional business applications, productivity tools such as Lotus Notes.
So who's right? Both can be right. And both can be wrong. Applications servers sit somewhere between the data, which resides in a repository like a database, and th
e client, which is on the user's desk. In other words, applications servers are part of a client/server architecture.
Not every activity performed by a server can be called an application. And not every distributed application can be called client/server. A file server, for example, doesn't qualify because the client isn't aware the server's there. The client talks to a redirector that sends client requests to the file server.
Client/server operation is a logical concept and doesn't depend on physical topology. In a true client/server system, significant processing occurs in both the client and the server processes -- regardless of where those processes are executing. Interaction between client and server is cooperative. Typically, a client sends a request to a server. The server, in turn, responds to that request. Both the client and the server portions of a distributed application are aware of each other and communicate as peers. Unlike the case with a file server, neither portion of a distributed a
pplication performs useful work without the other. The client and the server typically implement a cooperative balance of work that trades off the computing power available on each platform against network traffic.
In a two-tier architecture, desktop clients connect to a server on a LAN. Such an architecture enables users to access one set of data. There's a problem, though: The server is responsible for retrieving data and often for applying business rules on that data. For example, a client requests some data, and the database server is responsible for retrieving the data as well as making sure that the user is authorized to see it. Add too many clients and the server gets overwhelmed.
A three-tier applications server model logically (not necessarily physically) separates the user interface, application logic, and data management components. This model removes the responsibility for retrieving and processing data from a single server. As the number of clients grows, you can add second-tier servers
to maintain response time. You can even split large databases across multiple servers to further balance third-tier network traffic and service requests.
Fistful of Benefits
Deploying servers in these ways can improve performance and manageability at all levels of the enterprise. Here are some potential benefits.
- An applications server can off-load all or parts of a mainframe's applications to departmental servers, improving performance without requiring costly upgrades to the mainframe. The lighter load may also extend the productive life of the mainframe and preserve the development investment it represents.
- The improved balance between local and remote processing chores can lower the required communications bandwidth.
- Enterprise-wide distributed computing and advanced database applications become generally available to network users. The improved access can increase productivity.
- Users see improved or more consistent response time. Local servers can
cache frequently used data when appropriate.
- Corporate headquarters can synchronize data architectures at remote sites with replication products.
- Multiprocessor, multitasking servers support scalability at a lower incremental expense.
- Independence between client and server components ensures that modification of one need not affect the other.
- Administration can be centralized at the workgroup or enterprise level as appropriate for each application.
Applications servers make a lot of sense. They're a logical bridge between the highly centralized, secure mainframe environment and the decentralized LAN environment, combining the best of both.
The remainder of this Special Report will give you guidelines for evaluating and choosing the operating system and hardware platform that will best suit the needs of your applications server.
Robert L. Hummel is an electrical engineer, programmer, and consultant. You can reach him at
rhummel@monad.net
.
Share the Wealth
