Application servers

The browser used as an application presentation engine and user input collection device rather than a processing engine coupled to a powerful server architecture that provides processing

of the HTML form tags It will only be a matter of time before we will use XML to define our Java Beans and to compile the XML into the Beans byte codes

It is interesting to note that in the current JDK 1.2 release all the AWT and Swing components are implemented as Java Beans

Chapter 9 Application Servers

• How Did We Get to Here?

• What Is an Application Server?

• Some Explanations

Examining what is happening in the information systems (IS) shops of corporate America, we see a move away from the deployment of traditional client/server

applications and a large shift towards multitier, Web based computing Delivery of application functionality in the form of desktop-based, fat client tools is being dumped

in favor of server-generated, lightweight HTML-based user interfaces that derive their presentation layer from the lowly Web browser (that is already installed on almost every desktop in corporate America) The browser used as an application presentation engine and user input collection device (rather than a processing engine) coupled to a powerful server architecture that provides processing power and a multitier approach

to data connectivity provides a very powerful and versatile application delivery

vehicle

How did we arrive at this point? The answer is through the evolution of Web-based computing In the early days of the Web (i.e., the not too distant past) we started to develop applications that used the Web browser as the application presentation layer speaking via the HyperText Transfer Protocol and the Common Gateway Interface to programs being run on the Web server at the request of a browser page Voilà! Our Web server had become an application server; now instead of delivering content to a Web browser, the Web server was delivering an application

Many of the early Web-based applications were pretty simple, consisting usually of an HTML form and a script run by the Web server (these came to be known as CGI scripts) to read data returned to the Web server and act on it As time progressed and applications became more sophisticated, we became quickly aware of the limitations

of using the stateless HTTP and came up with a number of mechanisms (hidden variables, cookies,…) that allowed us to make our applications more stateful and take

on the guise of traditional client/server applications without having to resort to the heavyweight client model

Ahhh, life was good and computing was even better As the Web became more

popular and we (corporate America) decided that we needed to take commercial advantage of the new application deployment platform, we began to notice that there were some flaws in our new paradigm First, applications that operated well for a few users didn't do so well when we tried to scale them to thousands and tens of thousands

of users Second, there was this ever-present pain-in-the-neck of state preservation problem Determined not to let happen to Web computing what happened in

client/server computing, we started to examine our new environment and make

improvements where needed

One of the first things that we noticed was that the CGI scripts that we were using to add the processing power to our Web pages was a pretty bad way to do it There were

a number of options to increasing the throughput We could get rid of those shell and Perl scripts and move that processing to a compiled language (C or C++) that would run faster and free up processor horsepower; or we could take the tried-and-true approach to automotive repair philosophy and "jack up the radiator cap and drop in a new car" (i.e., if our current machine is too slow, save the software and buy a bigger, more powerful machine)

Both of these approaches have severe flaws Replacing the scripts with compiled versions only masked or postponed the real problem and actually introduced a few problems of its own The real problem was in the way that the scripts were being run (i.e., every time a script was called for, the Web server started up a new process to run the CGI program on, and we quickly ran out of system resources) Another problem was that, if we weren't religious about memory management and I/O programming, it was relatively easy for a hacker to figure out how to overload an I/O buffer and get the process to crash hard enough to bring down the entire site or accidentally give over control of the machine to the hacker

Along comes Java and server-side programming, and developers recognize that, because of the Java security model and its lightweight nature, it would be an ideal tool for doing server-side programming

Servlets are born The first servlets showed up as BAT files and scripts that loaded the

Java Virtual Machine and ran the Java code as a CGI program would be run The performance and scalability of these servlets is pretty bad due to having to load so many copies of the JVM, but the stage was set for the servlet API It was only a matter of time until the release of the all-Java Web server and the integration of the JVM into OEM Web server products like Netscape's Enterprise Server that true server-side servlet computing came on the scene

As we looked more seriously at the Web as an application deployment platform, a new type of program called an application server started to appear The application server started out as an application that could be run in conjunction with our Web server and would do things like state management and legacy system access Little by little, the application server architecture took on the general functionality shown in Figure 9-1 Currently there are more than 40 products on the market that all claim to

be application servers

Figure 9-1 General application server architecture

The following common threads run through all the application servers currently on the market and should be a help when comparing marketing information from the various vendors:

1 Inclusion of a high-performance Web server or the ability to integrate any of the popular currently available commercial Web servers easily

2 Integrated development environment or the ability to integrate any of the commercially available development IDEs

3 The ability to interface with Enterprise Resource Planning (ERP) systems especially SAP, BAAN, or PeopleSoft

4 The ability to interface with Transaction Processing (TP) monitors

5 Support for stateless and stateful database connections

6 Connection pooling of database connections

7 Access to legacy applications and legacy databases

8 Massive scalability through hardware replication and load balancing

9 Automatic fail-over capability in the case of a processor failure

10 Support of the Enterprise Java Beans Specification

This is shown in Figure 9-1

High-Performance Web Servers

Web servers have always played a central role in Web-based computing In the past they were used to serve content to users and provide the capability to run CGI scripts

to create dynamic Web pages with database connectivity Newer Web servers have integrated JVMs and support the full servlet API, making the use of CGI

programming unnecessary This new breed of Web servers also support remote

administration via a Web-based GUI interface and even the administration of multiple servers through the same GUI

Integrated Development Environment

Because the environment provided by application servers is so rich and supports so many APIs, OEMs all provide Integrated Development Environments to help the end

user create applications that are timely and supportable Included with the tools are source control and configuration management systems

Interfacing to Enterprise Resource Planning Systems

Today the darling application of the corporate IS shop is the ERP system One of the things that was painfully (and expensively) pointed out to IS Managers over the last 3 years (Y2K preparation) was how terribly dependent corporations were on old legacy systems written 20 and 30 years ago in COBOL and PL/1 One of the options to

becoming Y2K compliant was to move the corporate computing model away from the hodge-podge of legacy applications and databases that had grown up with the

corporations that fostered them and toward a relatively standardized model that had been developed relatively recently under the guise of ERP systems

ERP systems, like SAP, BAAN, and PeopleSoft, are based on a large database model

of the entire corporation After all, most corporations have a similar make-up (i.e., an accounting organization, accounts payable, accounts receivable, payroll, personnel, manufacturing, planning, etc.) If all these functions could share a common database and a common set of processes and procedures, the corporation could run more

effectively and efficiently

Since one system can never meet all possible needs, application servers provide

certified tools that allow interfacing with ERP systems in such a way that application server-based programs will be well behaved and supported even through new releases

of the ERP system software

Ability to Interface with Transaction Processing Monitors

One of the applications that was developed during the client/server paradigm of

application development was a program called a Transaction Processing (TP) Monitor (BEA Tuxedo is the most notable of these) TP Monitors are systems that handle high transaction-rate-based jobs like airline reservation systems, banking systems, and such

To be able to interface with these systems from the Web is crucial to e-Commerce

Support Stateful Applications

One of the hardest things about programming the Web has always been how to make stateful applications In our attempt to do this, we have tried every trick we could come up with from cookies to hidden variables Application servers take a more

rigorous approach by actually maintaining state databases of our applications In most cases, databases are maintained in two forms: a state that can be recovered after a reboot (persistent via a DBMS) and a state that cannot be recovered after a reboot (in memory data caching)

Connection Pooling of Database Connections

One of the lessons we learned from the two-tier client/server model of database

programming is that databases are not good connection managers and that making the initial connection to the database in many cases takes longer than the actual database

activities we are trying to perform To help improve overall database performance, the application server will open a number of database connections at startup and then manage those connections for the various applications that are using the database(s) This way the cost (time) of establishing the database connections is only incurred once (at startup) Once opened, the connections are never shut down; instead, they are shared by the applications After all, a connection is a connection is a

connection…and Web-based applications do not usually need a connection for more than the current query

Access to Legacy Applications and Legacy Databases

There are a number of ways to provide access to legacy system applications

• One is to incorporate a terminal emulator in the form of a Java applet as one of the client interfaces provided by the application server and actually allow the end user to interact with the legacy system

• Another is to provide a screen scraper that allows the data portion of a legacy screen to be scraped out and placed in a dynamic HTML form or a Java applet

• A more common way is to place a CORBA wrapper around the legacy system and provide a new CORBA (Java or C++) client for the user to interface with the application through

For access to a legacy database, the approach is somewhat dependent on the database and the hosting operating system In many cases, we are looking at IBM mainframes and DB2, VSAM, and IMS databases Because these databases are based on IBM's proprietary SNA (System Network Architecture) connectivity scheme rather than TCP/IP, one requirement is the installation of a gateway between the two systems (TCP/IP and SNA) that is responsible for the protocol conversion between the two systems Because DB2 is a relational database, JDBC drivers can be installed on client workstations; they will allow normal JDBC access to DB2 VSAM (Virtual

Sequential Access Method) is an older, flat file data structure in which many legacy databases are maintained In many cases, these databases should have been moved to DB2 years ago, but the "if it isn't broken don't fix it" mentality prevailed IMS is a database model from the 1970s that viewed a database as a hierarchical structure and provided its own database programming language to support it For VSAM and IMS databases there are tools from IBM and companies like Intersolv and Cross Access that allow these databases to be treated as relational tables Because of the number of gyrations that these have to go through to make everything look like a table, the performance is limited

Scalability Through Load Balancing

Scalability is the ability of a system to meet the performance demands of an

increasingly larger user community A single processor, no matter how fast, can only service a finite number of user requests with some degree of performance Adding multiple processors to a box can buy some additional performance but not really increase the overall scalability of the overall system To increase the scalability of the system in a meaningful way requires the introduction of additional processing units (boxes), one of which is to be used as an HTTP dispatcher All requests will come in

to the dispatcher, and the dispatcher will direct the request to the least busy box in the