What Is J2EE?
Java 2 Platform, Enterprise Edition (J2EE) is a set of standards and specifications (called a platform) created and maintained by Sun Microsystems. It is not a product. This means that vendors can create a J2EE-compliant product by implementing the J2EE specifications. As the enterprise platform, J2EE describes components for software applications intended to serve an entire organization. Two other platforms describe architectures and technologies used for applications running in different environments:
Java 2 Platform, Micro Edition (J2ME) describes components used for applications that run on small, portable devices that have minimal memory, such as cell phones or personal digital assistants (PDAs).
Java 2 Platform, Standard Edition (J2SE) describes components used for applications running on a desktop computer. This platform also includes the Java language distributed as the J2SE Development Kit (JDK).
J2EE contains all components in J2SE, such as the Java language. The additional functionality that J2EE adds to J2SE is in the realm of multi-tier deployment and web technology. This makes J2EE popular with organizations that need to develop applications that will be run on the Web.
J2EE and Java EE 5
The “Java 2” part of J2EE refers to versions 1.2 through 1.4 of the language. The last version of J2EE was version 1.4. At this writing, a new Java platform specification was recently ratified by the Java Community Process (JCP)—the means by which new and revised features and technologies are added to the Java realm. The Java language is in production in version 1.5 (also called 5.0) and the platform specification (formerly called “J2EE”) has been renamed to “Java EE 5.” The industry will take some time to adopt this new moniker. In addition, JDeveloper 10.1.3 is certified for creating any type of J2EE 1.4 code (in addition to some Java EE 5 code, such as JavaServer Faces). This blog refers to the enterprise Java platform as “J2EE” throughout.
TIP
J2EE Parts
J2EE is comprised of the following parts:
The Java platform This part of J2EE defines the environment under which various components used to create application solutions run.
The Compatibility Test Suite (CTS) You can verify that a particular product or application complies with J2EE standards by running compatibility tests. You can use one of the tests, the Application Verification Kit (AVK), to check your application’s J2EE compatibility.
A reference implementation This part of J2EE supplies code that uses J2EE-compatible components and standards. You can use this code to assist in writing parts of your application (java.sun.com/j2ee/sdk_1.2.1).
BluePrints This part of J2EE supplies a set of best practices and guidelines for various uses of Java—for example, enterprise applications, web services, and performance tuning (java.sun.com/blueprints).
In addition to high-level best practices, BluePrints also offers design patterns, low-level code solutions for solving common problems. Model-View-Controller (MVC) is a popular design pattern that is used extensively in Oracle Application Development Framework (ADF) and in JDeveloper.
NOTE “Frameworks” are high-level architectures focused on providing a specific service, such as controller code or database access. Frameworks usually consist of code libraries, a development method, and tools to assist in creating code for that service.
Model-View-Controller
Model-View-Controller is a frequently used design pattern (originally developed for Smalltalk, an object-oriented programming language) that defines a separation of application code into three layers, as shown here.
Model The Model layer defines and validates the data used by the application. It includes code to validate business rules and to communicate data to and from the database. It interacts with the View layer to notify it of changes in the data. It interacts with the Controller layer by receiving and processing requests to update data in the application.
View The View layer provides the user interface that displays data from the Model layer. It interacts with the Controller layer by receiving requests for a specific view (page) and by sending it user events (for example, a button press).
Controller Code in the Controller layer determines what happens after a user event in the View layer. It interacts with the View layer to request a page; it sends requests to the Model layer when data needs to be updated. The Controller layer determines page flow — the definition of which page in the View layer will appear after a certain data or user event.
The intention of MVC is to allow the code that implements a particular area of the application to be reused by many implementations of another area. For example, you could use the same Model code to supply data to a desktop web browser application, as well as to an application displayed on a cell phone. These two display devices might not be able to share the Controller layer, but reusing just the Model layer code can save a great deal of work and many maintenance worries. Whatever the level of reuse possible between layers, MVC is still a valid guide.
Other than the MVC design pattern, the J2EE platform is the most important, most frequently used, and most referenced part of J2EE; therefore, it is important to understand it in a bit more depth.
J2EE Platform
Although J2EE is not a product, it defines components that are software products and technologies. When you use J2EE to guide your application, you assemble these components into a software and hardware architecture solution.
JRE and JVM
The Java runtime, called the Java Runtime Environment (JRE), consists of an executable file (such as java.exe) and a number of library files, which it requires to interpret and run the code in an application. A Java Virtual Machine (JVM) refers to both the executable file and to an instance of this executable running as an operating system process. Sometimes, the terms “JRE” and “JVM” are used interchangeably to refer to a Java runtime process.
Component Architecture
To understand some of the popular components and how they are assembled into a complete solution, it is necessary to understand the J2EE component architecture. Each component fits into a tier, or layer, of this architecture. Often, a tier represents a single computer (or multiple computers in a distributed processing or grid system), but more than one tier can also exist on a single computer. J2EE components are divided into the following four tiers:
Client Tier User interface code runs on this tier (usually a desktop computer or mobile client device). A web browser displays a Hypertext Markup Language (HTML) user interface, or a JVM presents the interface. These interfaces interact with the user.
Web Tier The Web Tier runs user interface code on a remote server. This tier is responsible for running application code inside a JVM and outputting user interface code (such as HTML) to the Client Tier device.
NOTE HTML was created so that plain-text files displayed in a web browser could be formatted with colors, fonts, graphics, and links to other pages. HTML also contains a set of user interface controls, such as fields and forms, so that information can be sent to the application server for processing.
Business Tier A JVM on this tier runs validation and business logic code, as well as code that accesses the database. It connects the Web Tier or Client Tier to the Enterprise Information System (EIS) Tier.
EIS Tier The EIS Tier represents the database for business data. The EIS Tier also represents preexisting database applications that are out of J2EE’s scope. This article assumes that you are using a single Oracle database, but that database could be distributed across a grid or a series of servers. The sidebar “Accessing the Database with JDBC” describes briefly how this kind of database access is accomplished.
NOTE You can create code in JDeveloper to access any database that offers a JDBC driver.
Popular Component Assemblies
Instead of offering a laundry list of the components of the J2EE component architecture, it is more useful to examine the components in context of how they are assembled into the following styles of code:
Application client The application’s JVM runs on the client computer.
Web client The application’s JVM runs on a J2EE (application) server.
The discussion of these solutions assumes, and therefore does not further discuss, an EIS Tier supplied by an Oracle database. The main discussion will be about the other three tiers. All examples show one of two types of components in the Business Tier: Enterprise JavaBeans or ADF Business Components.
Accessing the Database with JDBC
Java Database Connectivity (JDBC) is a library of Java classes included with the JDK that allows you to easily access a relational database from a Java program in the same way that SQL*Net allows easy access to the database from an Oracle Forms (or other client) application. You do not need to use SQL*Net if you are using JDBC.
JDBC is the most frequently used database access method because it is implemented in Java class files and, therefore, allows you to embed standard SQL inside Java code. JDBC is defined in the J2EE specifications but many frameworks have been built on top of JDBC to make it easier to use.
Enterprise JavaBeans Enterprise JavaBeans (EJBs) are Java class files that provide access, through JDBC, to specific database objects, such as tables or database views, located on the Business Tier. They can be used for validation and other business rules code and, in this way, are an alternative to running business logic in the database. EJBs are another J2EE standard and are used heavily by Java developers.
ADF Business Components ADF in JDeveloper offers an alternative to EJBs: ADF Business Components (ADF BC), which also supply access, through JDBC, to database objects. ADF BC was invented and developed by Oracle. Although it was written using J2EE design patterns, ADF BC offers some powerful advantages to EJBs, and ADF in JDeveloper is oriented towards using ADF BC. Therefore, we focus on ADF BC for our examples in this article. ADF BC fits into the Business Tier because it offers a place for validation and business rule code, as well as access to database objects. ADF BC has no client interface, so, in addition to creating ADF BC code, you need to create code for the Client Tier.
Application Client
The application client coding style runs Java application code in the Client Tier. J2EE defines two types of clients that run in the Client Tier: Java applications and applets.
Java Applications A Java application (also known in the Java world as an application) consists of compiled Java code that runs in a JVM on the client computer. The Java runtime code and the compiled Java application files must be installed on the client computer (or on a network computer accessible by the client computer). Figure 2 shows this component in the J2EE tiers. In this application client example, the application program running in the JVM on the Client Tier communicates with Enterprise JavaBeans on the Business Tier. The EJBs supply business rules logic and the JDBC connection to the EIS Tier database.
EJBs are shown on the Business Tier, which is often on an application server computer; locating the EJBs on a separate server allows multiple client applications (and multiple users) to access the same code. Alternatively, this code could be placed on the client computer. In this situation, J2EE Client Tier and Business Tier code would reside on the client computer and the computer architecture would be two-tier (client/server) — the same as Oracle Forms code running in client/server (non-web) mode.
FIGURE 2. J2EE application client architecture
Windowed Java applications are written using code objects derived from the Java Swing library such as panels, text fields, labels, pulldown lists, and checkboxes that result in a standard Windows look and feel, as shown next. JDeveloper is another example of a fully featured Java application.
A Java application is useful when the system requires highly interactive and controllable user-interface components that offer immediate event processing and design-time support. Swing is a standard J2SE UI component library, but other third-party libraries also offer this type of control set. The number of properties and events you can modify for these controls is similar to the controls used in the Oracle Forms environment.
NOTE Another Sun Microsystems technology, “Java Web Start,” allows you to distribute application code from an application server to the client. This eases the burden of installing the application code manually on each client computer. The client installs Java Web Start using a link in a browser window. Java Web Start then downloads and installs the Java application code. After this installation, the application can be run as a normal Java application, without using a web browser.
Applets An applet is a Java program running on the Client Tier within the JVM of a web browser, as shown in the J2EE tiers here:
An applet can be displayed as a window embedded inside the browser’s window; it can also be displayed as a separate window that is part of the browser session. Applets use the same highly interactive controls (for example, those from the Swing library) as Java applications, and their appearance and behavior is the same as Java applications written using those controls.
An applet and its supporting libraries need to be installed on the client computer. It is started when the user issues a Hypertext Transfer Protocol (HTTP) request using a web browser HTML control, such as a link or button. The request is for the web server to return an HTML page to the browser. The HTML page contains an APPLET tag that signals the browser to open a JVM session. The APPLET tag also includes a reference to the Java applet file that the session will run. If the Java applet file does not exist on the client computer, it is downloaded from the application server. Then, the JVM takes control and runs the applet.
Both Java applications and applets access compiled Java files on the client and run them in a JVM on the client. The main difference between Java applications and applets is that an applet runs in a web browser session. If the web browser session is closed, the applet closes.
One benefit of using applets is that you can distribute the application code centrally on a web server; all clients will download the application code if it does not already exist. (Applets can also be distributed using Java Web Start.) One drawback of applets is that they run in the browser session, which normally cannot read and write to the client computer file system. Security signature files allow client file system access to occur, but this is viewed by some organizations as a potential security risk because a program distributed from the Web in this way can access the local, and perhaps the network, file systems. Applications that use applet technology are, therefore, prohibited in some locations.
Web Client
A J2EE web client presents an interface on the Client Tier and runs application code in the Web Tier. For example, an application can execute Java code on an application server; this application code queries or otherwise interacts with the Business Tier for data needs; it then assembles an HTML page and returns it to a web browser. The user interacts with the browser page and sends data access and update requests to the application running on the application server. This is another example of J2EE multi-tier server architecture: the Client Tier runs a web browser on the client’s desktop (or mobile) computer, and the Web Tier runs the application code, as depicted in Figure 3.
Running application code on a centralized server offers easier maintenance than the application client, because the application is located on a central server and it can be updated or patched in one location. Clients access a single installation, so there is no requirement to maintain client-side installations other than the web browser. This architectural style places the burden of processing on the application server, but as the number of application users grows, servers can be added or upgraded to handle the increased load.
One limitation to web client architecture is its controls — elements defined using HTML. Although HTML offers basic user interface controls, such as text fields, buttons, checkboxes, pulldown lists, and radio button groups, the range of controls does not match those offered by the application client. For example, the Swing library available for application clients includes hierarchical tree, grid (table), slider, menu, and other controls that are not native controls in HTML. The default rendering of HTML elements is basic, although you can apply colors, fonts, and sizes to change this default. For example, a page with a default table, heading, and text might appear as follows:
FIGURE 3. J2EE web client architecture
You could apply color, font, and border attributes and make the same elements appear as follows:
Another limitation of the HTML control set is the limited event model. For example, while application client Swing controls can capture and interpret keypress and button-click events within the client session, by default, user interactions with web client controls are interpreted only when the page is submitted to the server. The use of JavaScript within an HTML page can mitigate this limitation, because JavaScript can run procedural operations in an HTML page without server submits.
As is true of the J2EE application client, a number of web client technologies offer alternatives for coding and functionality. The two main J2EE alternatives are servlets and JavaServer Pages (JSPs).
All of these technologies fill the role of the client program, as depicted in Figure 3. Before examining these technologies in more detail, it is necessary to introduce the web client runtime environment that is supplied in general by J2EE containers and specifically within the Oracle Application Server by Oracle Application Server Containers for J2EE (OC4J).
NOTE Much of the discussion in this article concentrates on how to write programs that output to a web browser. Most of the technologies are capable of output to other devices, such as PDAs and cell phones. A switch in client hardware usually requires modification of the code, however.
J2EE Containers J2EE services called containers provide the ability for the code in a component to run on a server. The Web Tier and Business Tier code runs inside JVMs located on a remote server (an application server). Thus, the Web Tier container is basically a JVM on an application server that is customized to run Web Tier components. Similarly, the Business Tier container is also a JVM on an application server that runs Business Tier components such as EJBs. J2EE-compliant application server programs, such as Oracle Application Server 10g, must supply these container processes as standard features. In addition to runtime services, these containers offer services such as connection pooling (so that many clients can share the same database connection) and transaction support (so that database commit and rollback operations can be associated with a particular user session).
Oracle Application Server Containers for J2EE (OC4J) Oracle Application Server Containers for J2EE (OC4J), originally called Oracle Containers for J2EE, supplies J2EE-compatible container services to the Oracle Application Server. OC4J runs within the Oracle Application Server environment, but can also be run as a standalone server. JDeveloper includes a copy of OC4J with which you can run web client applications inside of JDeveloper. This copy can also be started as a standalone process outside of JDeveloper.
Servlet In general, a servlet is a program that extends the capabilities of a server. In the case of J2EE code, the term “servlet” usually refers to an HTTP servlet that extends the capabilities of an HTTP server. You can use back-end servlets to perform server-level operations that do not interact with or display to the user. The examples in this article are servlets used for user interfaces. The following shows how this process works:
An HTTP server receives a request for content or processing, the HTTP request, from a client, such as a web browser. The request is transmitted from the client through the network using the HTTP protocol. A standard HTTP request causes the server to find a resource such as an HTML page in the file system and return it to the web browser (as an HTTP response). If the request is not for an HTML page or other standard resource, the server interprets the HTTP request and determines (by the directory or file name) what type of file it should process. If the request is for a servlet, the Client Tier container on the server runs a Java program (the servlet) that assembles the page dynamically based on parameters sent in the request. The Java program can then query and send data to the database and format the resulting data or message into the HTTP response—in this case, an HTML page.
The servlet is coded in pure Java. That is, all code is contained in a Java class file that is compiled and available in the file system of the server. Java class files use a .java extension for the source code and a .class extension for the compiled, runtime code. The Java class file can contain database access code as well as print statements that will be output to the HTTP stream (and that eventually will be rendered in the web browser). For example, the following code snippet might appear in a servlet:
out.println("<html><body>");
out.println(" <h2>Job History</h2>");
out.println(" <table border='1'>");
out.println(" <tr><td>");
out.println(" EmployeeId");
out.println(" </td><td>");
out.println(getJobHistoryEmployeeId());
out.println(" </td></tr><tr><td>");
out.println(" DepartmentId");
out.println(" </td><td>");
out.println(getJobHistoryDepartmentId());
out.println(" </td></tr><tr><td>");
out.println(" JobId");
out.println(" </td><td>");
out.println(getJobHistoryJobId());
out.println(" </td></tr>");
out.println(" </table>");
out.println("</body></html>");This code would send each print statement to the HTTP response stream. Since Java is a full-featured programming language, the Java file can contain any kind of logic to manipulate the data and the page. Three lines in this example include calls to Java methods in the servlet file: getJobHistoryEmployeeId(), getJobHistoryDepartmentId(), and getJobHistoryJobId(). These methods are simplified versions of code in a servlet that would retrieve data from the database. The servlet would then output the following HTML to the browser:
<html><body>
<h2>Job History</h2>
<table border='1'>
<tr><td>
EmployeeId
</td><td>
101
</td></tr><tr><td>
DepartmentId
</td><td>
110
</td></tr><tr><td>
JobId
</td><td>
AC_ACCOUNT
</td></tr>
</table>
</body></html>The browser would render this HTML as shown in the previous illustration.
In summary, servlets are written in Java, run in a container (JVM) on the server, and output HTML to the browser.
JavaServer Pages JavaServer Pages (JSP) technology is a variation on servlet technology. A JSP page is a web client file that is written in a combination of HTML and JSP tags. It is saved in a file with a .jsp extension; an HTTP request to the application server that contains this extension indicates that the file should be processed as a JSP page. JSP page processing is demonstrated in the following illustration:
The communication flows are similar to those of a servlet. As with the servlet, the web server runs the JSP file in the Web Tier container. The first time a JSP page is run on a server, the Web Tier container converts it to a servlet file (.java) in a process called JSP translation. It then compiles the servlet file into a .class file. Once the .class file is available on the server, it can be run for future requests from any client without the translation and compilation processes. If the .jsp file is changed and copied to the server, the server will sense that the .jsp file is out of sync with the .class file and will translate and compile it into a new .class file.
Then, the .class file is run in the same way as a normal servlet, because it is a normal servlet at that point in the process. The only difference between servlets and JSP pages is the additional JSP translation process and the style of code. JSP source code contains a mixture of HTML tags and JSP tags. For example, the JSP source code that would create the same HTML code as the example servlet shown before would be this:
<html><body>
<h2>Job History</h2>
<table border="1">
<tr><td>
EmployeeId
</td><td>
<%= getJobHistoryEmployeeId() %>
</td></tr><tr><td>
DepartmentId
</td><td>
<%= getJobHistoryDepartmentId() %>
</td></tr><tr><td>
JobId
</td><td>
<%= getJobHistoryJobId() %>
</td></tr>
</table>
</body></html>This source code is not that much different from the servlet’s HTML result. HTML elements are coded in the JSP file without print statements. The JSP translator wraps the HTML tags in print statements when it creates the servlet file. JSP coding style is different from the servlet use of pure Java because of these raw HTML tags. It is also different from a static HTML page because it contains dynamic, Java-like elements, such as the lines containing the method calls to obtain data from the database. The JSP specification defines standard JSP tags. You can also write Java class files to implement the custom functionality that you need to call from a JSP page. You then declare the files as a tag library, a set of files that is cataloged in an XML file called a tag library descriptor (.tld file). After including in the JSP code a reference to the tag library descriptor, you can then use these custom tags.
Other than HTML tags, a JSP file can contain the following standard JSP elements:
Directives A directive affects the structure of the servlet code; it uses the delimiters “<%@ %>”. Three directives are available: page (to supply file-level commands, such as code imports for the class), include (to cause elements from another file to be embedded inside the current page), and taglib (to specify the location, name, and alias of a tag library). Here is an example:
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%>Actions Actions use the syntax “<prefix: tagname>“where “prefix” is the name given the tag library in the taglib directive for the JSP page, and “tagname” is the name of the tag you are calling from that tag library. Actions allow you to call code written in another Java class file from the JSP file. Custom tags that you or a third party has written are action tags. The following is an example that calls a tag, “form,” in the tag library referred to by the prefix “html.”
<html:form action="/locDP.do">The JSP page would also contain the taglib directive shown in the previous example to define the prefix.
Scripting elements Scripting elements are snippets of Java code that you can embed inside the JSP file. They can supply logical processing inside the JSP page. Three types of scripting elements are available:
Scriptlets Scriptlets are excerpts of Java code logic that are embedded directly in a tag. The scriptlet appears inside “<% %>” tag delimiters. For example, to print a message conditionally, you would code the following:
<% if (getEmployeeId() == 101)
{ out.print('Employee 101');
} %>Expressions In the earlier example, the result of a method call is displayed in the HTML output using an expression tag (“<%= %>”). An expression will be placed inside a print statement in the servlet so you can place in an expression any Java code that you would place in the argument of a print statement, such as the following:
<%= "The employee ID is " + getEmployeeId() %>Declarations Declarations contain code snippets that you need to call from within a scriptlet or expression. They are delimited with “<%! %>” characters. For example, you could code in a declaration the getEmployeeId() method in the previous example. It would then be available to the other scripting tags. You can also declare variables that are required throughout the JSP page, for example:
<%! int empStartingSalary; %>Currently, most J2EE experts agree that overuse of scripting elements in the JSP page can make the code less reusable and harder to maintain. Therefore, the preference is to use libraries or custom action tags when complex logic is required.
In summary, JSP pages allow you to write code that will translate into a servlet when it is run. The source code makes use of raw HTML tags as well as JSP tags. Many non-Java experts find this style easier to code and work with than servlets.
