Middleware/Application Servers
N-tier computing:
Traditional database applications were built using two tiers: a client and a server. This is the model that we have been using in class. Increasingly complex database applications are following an n-tier model, where there are one or more layers between the client and the database.
Diagram:
Advantages:
By having multiple tiers we can increase the performance of the system. For large IT organizations we can deploy thin clients (i.e. web browsers) to the end users, we don’t have to update the client every time the application changes. All updates can happen at a few application servers instead of across thousands of clients. Imagine if amazon.com had to send each customer a new application every time they added new functionality.
Application Servers:
There are many different types of application servers. Some examples are TP monitors such as Encina or Tuxedo that are used by large organizations such as banks and other financial firms. Increasingly popular are a new breed of application servers specifically targeted to delivering Internet content. These servers generally support java based Internet applications. Popular examples of these include BEA Weblogic, IBM Websphere, and Sun/Netscape iPlanet.
Connection Pools:
Connection pools allow multiple clients to share a pool of connection. Clients acquire a connection when they need to operate on the database and release the connection when they are done.
Advantages:
Establishing a connection to the database is very expensive. A socket connection must be established, the user must be authenticated by the database, and the database must set up a session of that connection. Connecting to the database becomes even slower if there are many clients trying to connect at the same time. By using a connection pool, we can create many connections to the database when the application starts up, by reusing these connections we can increase the performance of the system.
Disadvantages:
The application developer has more restrictions when using connection pools. Because the connections are reused across many different clients who may be running different applications, the application developer must make sure that when he is done with the connection, the connection is returned to its initial state. Any changes that the developer makes to the connection and/or the database session backing the connection must be undone. Any open transactions must be committed or rolled back.
Security:
Application servers generally implement an authentication/authorization system. The administrator of the system grants users permission to execution application functions, components, and/or methods.
Because of the use of connection pools, this security level replaces what we learned about database security. Each connection to the database is created with the same credentials, the database generally does not know who the ultimate user is. One database user is created that has permission to access all data in the database. That user is then used to establish the connection pools. Security is achieved by giving individual users the ability to only execute certain methods. This is similar to using stored procedures in the database.
Example:
An app server may have two functions listEmployees, and listEmpSalaries that access Employee(Id, name, salary). All Employees may access listEmployees, but only managers may access listEmpSalaries.
Transaction Management:
Application Servers usually have their own transaction manager. The reason being is that the business methods that are executed in the app server are generally transactional and may run across multiple database systems.
Diagram of typical setup:
Because of this the developer will often communicate only with the App Server’s Transaction Manager, completely bypassing the TM of the database. The application server will take care of coordinating with the database. This actually makes application development much easier as you can easily extend transactions to span multiple components.
One interesting aspect of this is that we can run transactions the span multiple database systems.
Question:
Why is this difficult?