PHP is a scripting language that can be seen as an extension of the HTML language: PHP code can be directly embedded into an HTML page. Built as an HTTP server module, PHP is executed within a Web server process and does not incur any inter-process communication overhead. When the HTTP server identifies a PHP tag, it invokes the PHP interpreter that executes the script. Requests to the database are performed using an ad hoc interface.
PHP scripts are easy to write and reasonably efficient, but the database interfaces are ad hoc. This makes code maintenance awkward, because new code needs to be written for each new database to which the scripts need to access. PHP scripts execute in the same process (address space) as the Web server, thereby minimizing communication overheads between the Web server and the scripts.
An HTTP servlet is a Java class that can be dynamically loaded by a servlet server and runs in a Java Virtual Machine (JVM). After the initial load, the server invokes the servlet using a lightweight method invocation, but since the JVM is a separate process from the Web server, inter-process communication takes place for each request. Concurrent requests are handled by separate threads. Servlets access the database using the standard JDBC interface, supported by all major databases.
HTTP Java servlets interface to the database using JDBC. This makes them easily portable between databases. Contrary to the PHP interpreter, the servlet server runs in a JVM as a separate process from the Web server. On the plus side, this implies that it can be placed on a machine different from the Web server to balance the load. On the minus side, servlets incur the overhead of the JVM. In addition, they incur the cost of inter-process communications with the Web server, especially when they execute on a separate machine.
The purpose of an Enterprise Java Beans (EJB) server is to abstract the application business logic from the underlying middleware. There are two types of EJB: entity beans that map data stored in the database (usually one entity bean instance per database table row), and session beans that are used to perform temporary operations (stateless session beans) or represent temporary objects (stateful session beans). The EJB server is responsible for providing services such as database access (JDBC), transactions (JTA), security (), naming (JNDI) or management support (JMX).
First, a client sends a request to the HTTP server. The HTTP server invokes the servlet server using a well-defined protocol (AJP12). The servlet queries the EJB server (using RMI) to retrieve the information needed from the database in order to generate the HTML reply. The EJB server calls the database.
The EJB architecture abstracts the application logic from any specific platform, protocol, or middleware infrastructure. In particular, the bean methods can be called through a Web interface or from an arbitrary program.
We use session beans to implement the business logic, leaving only the presentation logic in the servlets. This implementation uses the fewest services from the EJB container. The session beans benefit from the connection pooling and the transaction management provided by the EJB server. It greatly simplifies the servlets-only code, in which the connection pooling has to be implemented by hand.
In this implementation, we extract the data access code from the servlets, and move it into Data Access Objects (DAO) that we implement using entity beans. The business logic embedded in the servlets directly invokes methods on the entity beans that map the data stored in the database. Figure 3 illustrates the DAO separation with entity beans.
With container-managed persistence (CMP), the vast majority of the SQL queries is generated by the EJB container. EJB 1.1 CMP, however, requires stateless session beans to execute complex queries involving joins on multiple tables. To avoid fine-grain access of getter/setter methods of the beans, we provide functions that return results populated with the values of the bean instance attributes. With this implementation, we evaluate the impact of fine-grain accesses between the Web and EJB containers.
This implementation is the same as the DAO separation with entity beans CMP version except that we use bean-managed persistence (BMP). With BMP, the SQL queries have to be hand-coded in the beans. We implement exactly the same queries as the CMP version including the use of a stateless bean to execute complex queries. The goal of this implementation is to evaluate the cost of the container’s persistence service by comparing it with the entity beans CMP version.
The session façade pattern uses stateless session beans as a façade to abstract the entity components. This method reduces the number of business objects that are exposed to the client over the network, thus providing a uniform coarse-grained service access layer. Calls between façade and entity beans are local to the EJB server and can be optimized to reduce the overhead of multiple network calls. We use container-managed persistence for the entity beans.
This implementation involves a larger number of beans, and thus stresses the component pooling of the container. It also exploits the database connection pooling, transaction manager and persistence services.
Although the session façade beans and the entity beans execute inside the same JVM, with RMI (Remote Method Invocation) communication between them has to go through all the communication layers, as if they were on different machines. The EJB 2.0 specification introduces local interfaces to optimize intra-JVM calls by bypassing the communication layers. Beans with a local interface cannot be called remotely, i.e., from another JVM even if the JVM runs on the same machine.
Our final implementation takes advantage of these local interfaces. This implementation uses the session façade pattern, and container-managed persistence. Only session façade beans have a remote interface that is exposed to the servlets. The entity beans only have a local interface that is used by the session façade beans. Therefore, interactions between session and entity beans bypass the communication layers. This implementation requires EJB 2.0 compliant containers.
In this implementation, we extract the data access code from the servlets, and move it into Message Driven Beans (MDB). The business logic embedded in the servlets directly invokes methods on the MDB that query the database.
This implementation uses the session façade pattern and local interfaces as discribed above in the "Session facade with local interfaces" section. It also takes advantage of container-managed persistence 2.0. EJB-QL is used in most of the queries however a stateless session beans is required to execute some complex queries. This implementation requires EJB 2.0 compliant containers.