The J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multitiered Web-based applications.
In this article, we will examine the 13 core technologies that make up J2EE: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF. We will describe where and when it is appropriate to use each technology; we will also describe how the different technologies interact with each other.
Moreover, to give J2EE a real-world feel, we'll look at its main technologies in the context of WebLogic Server, a widely used J2EE implementation from BEA Systems. With that in mind, this introductory article will be of interest to developers new to WebLogic Server and J2EE, as well as project managers and business analysts with an interest in understanding what J2EE has to offer.
The big picture: Distributed architectures and J2EE
In the past, two-tier applications -- also known as client/server applications -- were commonplace. Figure 1 illustrates the typical two-tier architecture. In some cases, the only service provided by the server was that of a database server. In those situations, the client was then responsible for data access, applying business logic, converting the results into a format suitable for display, displaying the intended interface to the user, and accepting user input. The client/server architecture is generally easy to deploy at first, but is difficult to upgrade or enhance, and is usually based on proprietary protocols -- typically proprietary database protocols. It also makes reuse of business and presentation logic difficult, if not impossible. Finally, and perhaps most important in the era of the Web, two-tier applications typically do not prove
very scalable and are therefore not well suited to the Internet.
Figure 1. Two-tier application architecture
Sun designed J2EE in part to address the deficiencies of two-tier architectures. As such, J2EE defines a set of standards to ease the development of n-tier enterprise applications. It defines a set of standardized, modular components; provides a complete set of services to those components; and handles many details of application behavior -- such as security and multithreading -- automatically.
Using J2EE to develop n-tier applications involves breaking apart the different layers in the two-tier architecture into multiple tiers. An n-tier application could provide separate layers for each of the following services:
- Presentation: In a typical Web application, a browser running on the client machine handles presentation.
- Dynamically generated presentation: Although a browser could handle some dynamically generated presentation, for the widest support of different browsers much of the action should be done on the Web server using JSPs, servlets, or XML (Extensible Markup Language) and XSL (Extensible Stylesheet Language).
- Business logic: Business logic is best implemented in Session EJBs (described later).
- Data access: Data access is best implemented in Entity EJBs (described later) and using JDBC.
- Backend system integration: Integration with backend systems may use a variety of technologies. The best choice will depend upon the exact nature of the backend system.
You may begin to wonder: why have so many layers? Well, the layered approach makes for a more scalable enterprise application. It allows each layer to focus on a specific role -- for example, allowing a Web server to serve Webpages, an application server to serve applications, and a database server to serve databases.
Because it's built on top of the Java 2 Platform, Standard Edition (J2SE), J2EE provides all the same advantages and features of J2SE. These include "Write Once, Run Anywhere" portability, JDBC for database access, CORBA technology for interaction with existing enterprise resources, and a proven security model. Building on this base, J2EE then adds support for Enterprise JavaBean (EJB) components, Java servlets, JavaServer Pages (JSPs), and XML technology.
Distributed architectures with WebLogic Server
J2EE provides a framework -- a standard API -- for developing distributed architectures. The implementation of an engine to implement this framework is left up to third-party vendors. Some vendors will focus on particular components of the overall J2EE architecture. For example, Apache's Tomcat provides support for JSPs and servlets. BEA Systems provides a fuller implementation of the J2EE specification with its WebLogic Server product.
By providing a complete implementation of the J2EE specifications, WebLogic Server makes it easy to build and deploy scalable, distributed applications. WebLogic Server and J2EE handle certain common programming tasks for you. These include the provision of transaction services, security realms, guaranteed messaging, naming and directory services, database access and connection pooling, thread pooling, load balancing, and fault tolerance.
By providing these common services in an easy-to-use and standard way, products like WebLogic Server provide more scalable and maintainable applications. The result is increased availability of those applications to a larger number of users.
The J2EE technologies
In the following sections, we'll describe each of the technologies making up J2EE, and see how WebLogic Server supports them in a distributed application. Perhaps the most commonly used J2EE technologies include JDBC, JNDI, EJB, JSPs, and servlets, upon which we therefore focus our attention.
Figure 2 illustrates where each of the J2EE technologies are most commonly used within a distributed application.
Java Database Connectivity (JDBC)
The JDBC API accesses a variety of databases in a uniform way. Like ODBC, JDBC hides proprietary database issues from the developer. Because it's built on Java, JDBC also is able to provide platform-independent access to databases.
JDBC defines four fundamentally different types of drivers, as we'll see next.
Type 1: JDBC-ODBC Bridge
The JDBC-ODBC Bridge proved most useful when JDBC was still in its infancy. With it, developers can use JDBC to access an ODBC data source. As a downside, it requires that an ODBC driver be installed on the client machine which, generally speaking, should be running a version of Microsoft Windows. By using this type of driver, you therefore sacrifice the platform independence of JDBC. Additionally, the ODBC driver requires client-side administration.
Type 2: JDBC-native driver bridge
The JDBC-native driver bridge provides a JDBC interface built on top of a native database driver -- without using ODBC. The JDBC driver converts standard JDBC calls into native calls to the API of the database. Using a type 2 driver also sacrifices the platform independence of JDBC and requires installation of client-side native code.
Type 3: JDBC-network bridge
JDBC-network bridge drivers remove the need for client-side database drivers. They make use of network-server middleware to access a database. This makes such techniques as load balancing, connection pooling, and data caching possible. Because type 3 drivers often involve a relatively small download time, are platform independent, and require no client-side installation or administration, they are good for Internet applications.
Type 4: Pure Java driver
Type 4 provides direct database access using a pure Java database driver. Due to the way type 4 drivers run on the client and directly access a database, running in this mode would imply a two-tier architecture. A better use of type 4 drivers in an n-tier architecture would be to have an EJB contain the data access code, and have that EJB provide a database-independent service to its clients.
WebLogic Server provides JDBC drivers for some of the more common databases, including Oracle, Sybase, Microsoft SQL Server, and Informix. It also comes with a JDBC driver for Cloudscape, a pure Java DBMS, an evaluation copy of which comes with WebLogic Server.
Next, let's look at an example.
JDBC Example
Our example assumes that you have a PhoneBook database set up in Cloudscape, and that this database contains a table CONTACT_TABLE with fields NAME and PHONE. We begin by loading the Cloudscape JDBC driver, and requesting that the driver manager obtain a connection to the PhoneBook Cloudscape database. Using this connection, we construct a Statement object and use it to execute a simple SQL query. Finally, the loop iterates through all entries in the result set, writing the contents of the NAME and PHONE fields to the standard output.
import java.sql.*;
public class JDBCExample
{
public static void main( String args[] )
{
try
{
Class.forName("COM.cloudscape.core.JDBCDriver");
Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook");
Statement stmt = conn.createStatement();
String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name";
ResultSet resultSet = stmt.executeQuery( sql );
String name;
String phone;
while ( resultSet.next() )
{
name = resultSet.getString(1).trim();
phone = resultSet.getString(2).trim();
System.out.println( name + ", " + phone );
}
}
catch ( Exception e )
{
// Handle exception here
e.printStackTrace();
}
}
}
That's all there is to it. Next, let's look at the use of JDBC in enterprise applications. JDBC in enterprise applications
The previous example is, by necessity, somewhat trivial. It also assumes a two-tier architecture. In an n-tier enterprise application, it is much more likely that the client will communicate with an EJB, which, in turn, will make the database connection. To enable improved scalability and performance, WebLogic Server provides support for connection pools.
Connection pools reduce the overhead of establishing and destroying database connections by creating a pool of database connections when the server starts up. When a connection to the database is subsequently required, WebLogic Server simply selects one from the pool rather than creating one from scratch. Connection pools in WebLogic Server are defined in the weblogic.properties file. (Refer to the examples in your weblogic.properties file and the WebLogic Server documentation for more information.)
Another database feature frequently required in enterprise applications is support for transactions. A transaction is a group of statements that should be treated as a single statement to ensure data integrity. JDBC uses the auto-commit transaction mode by default. This can be overridden using the setAutoCommit() method of the Connection class.
Now that we have a sense of JDBC, let's turn our attention to JNDI.
Java Naming and Directory Interface (JNDI)
The JNDI API is used to access naming and directory services. As such, it provides a consistent model for accessing and manipulating such enterprise-wide resources as DNS, LDAP, local filesystems, or objects in an application server.
In JNDI, every node in a directory structure is called a context. Every JNDI name is relative to a context; there is no notion of an absolute name. An application can obtain its first context using the InitialContext class:
Context ctx = new InitialContext();
From this initial context, the application can traverse the directory tree to locate the desired resources or objects. For example, assume that you have deployed an EJB within WebLogic Server and bound the home interface to the name myApp.myEJB. A client of this EJB, after obtaining an initial context, could then locate the home interface using: MyEJBHome home = ctx.lookup( "myApp.myEJB" );
Once you have a reference to the acquired object -- in this case, the home interface of the EJB -- it is then possible to invoke methods on it. We will discuss this further in the section below entitled "Enterprise Java Beans."
![[Valid RSS]](http://feedvalidator.org/images/valid-rss.png "Validate my RSS feed")
Posts
