In recent times, IT organizations have been tasked more and more with charting a course for writing new applications and migrating existing applications to a Java 2 Platform, Enterprise Edition (J2EE) environment. On the surface, this task might seem to be a matter of using predetermined methods, as was the case with the migration to client/server technology. However, one major aspect of J2EE is its variety and breadth. There is no one way to create a J2EE system; in fact, there are probably hundreds of combinations of J2EE technologies that could serve any one purpose. This makes the decision of selecting the proper technology combination daunting, especially if the J2EE environment is new to the organization.
When making a decision, you need to collect as much information about the choices as possible. Information about J2EE is certainly prominent in the Oracle world, as it is across the IT industry. However, information about what J2EE actually consists of is rare. Literature available in trade publications and on the Web often assumes that the reader is familiar with at least some of the J2EE basics and buzzwords. Grasping these basics is essential to assimilating and understanding any specific J2EE technology. In turn, understanding the technologies will help in making the decisions needed to collect these technologies into the proper environment for a particular application, as well as in the work performed during development of the application.
This article provides overviews of the technology concepts you will need to know when developing J2EE web applications. It starts in this blog note, with an explanation of the J2EE basics and the main technologies that it offers for implementing database applications.
The objective of this article is to provide a bit of background in the popular J2EE technologies to prepare you for the details of these technologies discussed in the rest of this article. The discussions in this article focus around these questions:
- What do I need to know about database application architecture?
- What is J2EE?
- What non-J2EE web technologies are popular in J2EE environments?
After explaining those foundation subjects in some detail, we will then draw some conclusions by briefly answering the following questions:
- How do J2EE architectures differ from traditional architectures?
- How do I choose between J2EE and Oracle Forms and Reports?
- Should I pay attention to .NET?
- How does Oracle Forms Services fit into J2EE?
What Do I Need to Know About Database Application Architecture?
The authors, along with many Oracle technologists, have experienced technology shifts from mainframe to mini-computer, from mini-computer to microcomputer client/server, and from microcomputer client/server (two-tier) to microcomputer multi-tier, as well as its recent variation of web browser clients and web servers. Each shift requires a retooling of decision processes for architectures, system design methodologies, and best practices for development. However, there is a common thread in the architectures that has appeared throughout the years, and it is worth reviewing this common aspect to help understand J2EE architectures.
The main actions in a database system are interacting with the data—inputting and outputting it—and managing the data—storing and serving requests for input and output. Data is kept and managed by a specific program—in the case of relational systems, a relational database management system (RDBMS). Users or systems requiring access to the data use another program, the application (or interface). The application program recognizes and interprets user input to be sent to the RDBMS and also receives data and message results from the RDBMS. A communications network transmits data and messages between the RDBMS and the user access layer. J2EE is no different in these basic characteristics. The difference in technologies through the years has been where (on which computer) the various programs are located and how communication between the computers is provided, as described in the following examples.
NOTE
For the sake of clarity in the examples in this section, the client computers with which the user interacts are described and diagrammed in a singular way, but most enterprise database application systems are set up to serve more than one user simultaneously.
Mainframe In a mainframe architecture (shown in Figure 1-a), the application program and the database management program often reside on a single computer — the mainframe. All processing occurs on that computer. The user interacts with the application program using a dumb terminal session. No communication lines are required other than to connect the dumb terminal to the mainframe.
Client/Server Client/server (two-tier) architecture divides the processing, as shown in Figure 1-b. The application program resides on a client’s desktop computer (often a microcomputer). The database management program resides on a centralized server computer, and a communications network connects the database server with all client computers. Application processing occurs on the client computer; data management processing occurs on the database server.
FIGURE 1. Sample database system architectures
Multi-Tier A multi-tier architecture places program components on different computers, each of which is a tier, that is, a location for a specific type of processing. Figure 1-c shows a sample multi-tier architecture. This architecture is also called n-tier, because, unlike client/server, which always runs programs on only two tiers (client and server), multi-tier systems can operate on any number of computers. In the example shown in Figure 1-c, the client computer runs part of an application program that communicates with application services running on an application server.
The application services consist of parts of the application that can be shared among programs and among client users—for example, code to manage and maintain connections to the database server, as well as data-caching software that offloads processing from the database for frequently accessed data.
The database server operates the same type of database management system as in the other architectures. The only difference is that the database server communicates with the application server (middle tier) programs, not directly with the client computer.
Oracle Forms Services (Oracle Forms 9i and later versions running on the Web) is an example of a multi-tier architecture. The client runs inside a web browser; the application code runs mainly on the application server (but partially on the client); and the application server communicates with the database server.
If these concepts are not new, you already have a basis for understanding J2EE architectures. J2EE offers the same types of architectures, variations on familiar architectures, and new architectures. Before discussing how J2EE architectures differ from those just described, a discussion of the J2EE basics is in order.
NOTE Multi-tier environments often separate the web server, which handles requests from web clients and returns results to those clients, and the application server, which runs the application code.
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.
What Non-J2EE Web Technologies Are Popular in J2EE Environments?
In addition to the J2EE servlet and JavaServer Pages web client alternatives, three other web client user interface technologies are worth mentioning: JavaServer Faces technology, ADF UIX, and ADF Faces. Although they are not part of the J2EE 1.4 specification, they are solid alternatives for creating web-deployed, light-client applications. In later discussions of how to develop web applications, my blog provides examples using JSF and the successor to ADF UIX, ADF Faces. In addition, web services provide supplemental functionality for J2EE client and server environments. All of these technologies are worth a brief mention here to round out the view of J2EE basics.
User Interface Technologies
Although JavaServer Faces, ADF UIX, and ADF Faces are not part of the J2EE 1.4 specification, they are J2EE 1.4–compliant and can, therefore, be run in a J2EE 1.4 environment.
JavaServer Faces Technology
JavaServer Faces (JSF) technology is a Sun Microsystems framework that provides View and Controller layer functionality to J2EE applications. Although it was not included with the J2EE 1.4 specification, JSF is part of the new platform specification (Java EE 5), mentioned before. The JSF tag libraries offer components that contain a rich set of properties and events that manage user interactions and the state of the data inside the component. JSF components also include the capability to easily bind the data in the elements to database objects and other data sources. In addition to these rich components, JSF offers controller classes and tags that manage page flow and handle events to and from the components.
For Oracle Forms developers, JSF tags offer a development model that is more familiar than other J2EE-based technologies—that is, user interface components and the page provide events to which programming code for validation and navigation can be attached. Without a technology such as JSF, events occur at the page level, that is, when the page is submitted to the server, and component-level event handling is limited to the code you add using JavaScript. However, JavaScript is an addon to HTML that is not well integrated with the controller.
Since JSF tags are usually embedded inside a JSP page, the runtime architecture for JSF is the same as for JSP pages. The difference between JSP pages and JSP pages with JSF is the additional functionality and built-in components, events, and controller code that JSF provides.
ADF UIX
ADF UIX (formerly called UIX or User Interface XML) is a user interface framework created by Oracle Corporation. It has been used extensively in the Oracle E-Business Suite self-service applications for over four years. Since ADF UIX is not discussed elsewhere in my article and since it is a basis for ADF Faces, which is used for examples elsewhere in this blog, it is appropriate to examine ADF UIX in a bit more depth here.
ADF UIX is coded in XML, in contrast to JSP pages, which are coded using HTML and servlet tags. The XML elements represent Java classes that render HTML elements in the same way as a JSP tag renders HTML elements. ADF UIX offers a well-evolved and rich set of user interface components and other features that allow you to easily implement functionality that is not native to JSP pages, for example:
Layouts ADF UIX ships with a set of tags that can be used as containers for components. For example, the pageLayout tag draws an HTML table with a set of prebuilt areas for various components, such as branding graphics, a tab header, global navigation buttons, a content area, and a copyright area. Including this tag on a UIX page allows you to plug components into those areas without having to worry about how the HTML table cells and rows are drawn around those components.
Rich components One example from the extensive set of ADF UIX components is listOfValues, which you can use as the basis for a popup LOV window. This single component draws a number of user interface items, as shown in the example here:
The user would enter a query value in the Search field and click Go; query results would appear in the Results area. Then, the user would select a record and click Select to return the value to the screen. This component includes a number of properties that you can use to specify its appearance and behavior (such as title, which appears as “Employee” in this example). listOfValues is displayed as a number of HTML tags when the page is run. Implementing this control in a JSP page without a tag library would require coding individual HTML tags, as well as custom code, to handle the action of querying and returning a selection (all of which is built into the UIX control).
Partial page rendering Several ADF UIX components offer partial page rendering (PPR)—a combination of prebuilt JavaScript and frames that allow just a section of the page to be redrawn. A good example of a PPR component is table. This component draws a standard HTML table, but adds column headings that allow the user to click and automatically sort the rows by the values in the column. When sorting in this way or scrolling through sets of records, only the table data area is redrawn. The rest of the page remains static. This results in an interface that can enhance user productivity because the new page is ready more quickly than it would be with a full page redraw.
Automatic graphics file generation Some components, such as the tabBar, create graphics files when run. This eliminates the need to create and manage separate files for standard decorative elements. The text property of the tag specifies the text that will appear on the graphics file. For example, the following code will be rendered as shown in the illustration following it.
<tabBar>
<contents>
<link text="ADF UIX" destination="http://oracle.com"/>
<link text="ADF Faces" destination="http://oracle.com" selected="true"/>
<link text="JavaServer Faces" destination="http://java.sun.com"/>
</contents>
</tabBar>The server architecture used for ADF UIX is similar to that used by JSP pages, but ADF UIX pages run under a servlet process, the UIX servlet. The UIX servlet is a Java class run inside the Web Tier container; it interprets the ADF UIX XML code, runs the Java class files referenced by ADF UIX tags, and assembles an HTML result page that is sent to the browser.
Since ADF UIX is an Oracle technology, it is not part of the J2EE specification. However, it uses J2EE design patterns, and its successor, ADF Faces, is used as an extension to JSF, which is part of the new J2EE specification.
ADF Faces
ADF Faces is a set of JSF components that add to JSP pages with JSF the same kind of rich user interface controls available in ADF UIX. As mentioned, examples throughout my blog use ADF Faces as the underlying technology because ADF Faces is highly integrated with JDeveloper, and the development experience is closer to the experience in Oracle Forms than anything else that has come before.
Most of the ADF UIX controls have ADF Faces equivalents. For example, the tabBar control described and shown previously has an ADF Faces equivalent—menuTabs. Features such as PPR and automatic graphics file generation have also been rewritten into ADF Faces. ADF Faces components are handled in the same way as all other JSF components, which provides a consistent way to handle both JSF and ADF Faces components. More than 100 ADF Faces components are available including the following:
chooseDate This component displays a control that opens in the same window as the main page. chooseDate allows the user to scroll between months in a calendar display and select a date to be returned to a field on the page.
selectOrderShuttle This component displays a shuttle control—two text areas filled with selections—that allows the user to select more than one value for a single field. All required headings, graphic buttons, and text areas are built into a single control.
menuButtons This component displays a set of buttons that navigate to another page.
panelPage This container component provides a number of areas that you can use to place other components.
You can think of ADF Faces as being a merge of JSF technology, which supplies the underlying J2EE architecture and development methods, with ADF UIX components, which offer highly evolved and extremely rich user-interface controls.
Web Services
Web services are application components served from a host provider that allow client applications to tap into the provider’s data and functions through the Web. For example, Amazon.com offers a web service that allows associates and vendors outside of the company to search its product database. An application created by outside organizations can, among other things, allow users to perform searches on Amazon.com without leaving the organization’s application. The Amazon web service provides an ability that the organization’s application would otherwise not include or would include only after a great deal of development effort.
Web services have two aspects: server and client. The server aspect requires creating an application that provides the function (such as searching a product database). The provider develops a standard interface to the service so that the service details are easily accessible. The function is then published to a registry so that it can be available to Internet users.
The client aspect of web services consists of application calls to the web service interface. Data is transmitted from the server to the client using a standard protocol. The web service is a black box to the client. That is, the client does not know specifics about how the web service performs the functionality; it only needs to know how to call the service.
Figure 4 shows the components and communication flow for a web service. In this diagram, the user’s browser sends an HTTP request for the organization’s local application. This request is handled by the organization’s local application server that runs the local application. The application consists of normal application code that accesses the organization’s services and databases in addition to calling the web service to retrieve or modify data from that source. When the web service returns a result, the application combines it with the rest of its data and sends a result back to the browser.
In addition, a web service stub is created in the application code to call the web service. The stub is built using information retrieved at design-time from a descriptor document in the registry.
FIGURE 4. Web service communication flow
Web Services Technologies
Universal Description, Discovery and Integration (UDDI) is the registry technology used to hold the web services information. A public UDDI registry, the UDDI Business Registry (UBR), holds information about web services available on the Internet. Organizations may also create private UDDI registries that hold web services information for their own and their customers’ use. UDDI registries can be likened to telephone yellow page books, because both contain a list of services and a method for accessing those services.
The web services descriptor (API) is written in a standard format using Web Services Definition Language (WSDL), an XML language. It contains information about the provider’s host, the call interface, and the format in which the data will be returned. The application calls the web service code using Simple Object Access Protocol (SOAP)—a lightweight communications protocol used for web services requests and responses in conjunction with HTTP.
How Do J2EE Architectures Differ from Traditional Architectures?
Now that we have discussed traditional database application architectures and details about J2EE, we can draw some conclusions about how J2EE fits into the molds of previous architectures. As discussed earlier in this blog, the mainframe architecture places the application and data management programs on a central server. The user accesses the application program using a dumb terminal, a computer that collects information input by the user and sends this information to the central computer a block at a time. This model has some similarities to the J2EE web client architecture because very little, if any, processing occurs on the client computer. The client computer is responsible for displaying the application interface assembled by the server and for sending the user’s requests to the server on a form-level basis.
The J2EE application client architecture fits into the client/server architecture also discussed earlier in this bloge article. The client computer in both models runs the application program and accesses data from a central server that runs the data management system.
The J2EE web client architecture fits into the multi-tier architecture described in the article. The J2EE web client relies on some client processing occurring on one tier, application code running on another tier, and a data management program running on a third tier. Multi-tier usually describes three roles for computers in the system: client, application server, and database server. Naturally, a computer system often serves more than one user, so many computers fill the role of the client in this model. In addition, variations on how the application server divides its work (for example, in the J2EE Web Tier and Business Tier) can add more computers to the middle tier. Distributed databases, database links, and grid computing strategies can cause more than one computer to be used for the database server tier.
As this discussion implies, the real answer to the question of how J2EE architecture differs from the traditional architectures is that it really does not differ at all. J2EE architectures fit into the standard computing models that you are likely accustomed to using. The way that code is divided among the tiers in these models may be slightly different, but we can conclude that J2EE web client architectures, at least, are really no different from the traditional multi-tier architecture.
In addition, as web application interface components become more sophisticated (and they have made a large jump in this direction recently with ADF Faces), J2EE web application technologies will be able to serve the highly interactive application styles associated with traditional tools such as Oracle Forms.
How Do I Choose Between J2EE and Oracle Forms and Reports?
The requirement for applications to run on the Web is nearly assumed these days. A lightweight web client (web browser) requires little installation and maintenance on the hardware and software sides. In addition, web browsing is popular and users are quickly able to learn new applications that use a browser front-end. Long gone are the days of special training and manuals, such as SQL*Forms Operator’s Guide (old Oracle part number 3301), to teach computer operators how to perform system functions using keyboard function keys. The requirement for building a user-friendly, intuitive interface, which took some effort with traditional tools, is handled nearly automatically now. Deploying applications to the Web is common practice.
Applications developed using J2EE web technologies are an alternative to Oracle Forms and Reports applications running on the Web. Since Oracle Forms and Reports are mature products, many Oracle customers have significant amounts of application code and development expertise in these products. They need to be careful when moving to any new environment, especially one that requires retraining and retooling for both infrastructure and development resources.
Oracle’s Direction
Oracle’s statement of direction for applications built with Oracle Forms and Reports is to move them to the web environment. Although support for Oracle Forms and Reports has no planned ending, Oracle has set a future direction towards J2EE because it offers flexibility, wide industry support, and greatly increased openness. For example, although many Oracle Forms developers invented ways to fill extraordinary requirements, they ultimately ran into a limitation—Oracle Forms design-time and runtime code cannot be modified. In J2EE technologies, the base Java classes that correspond to Oracle Forms runtime are extendable and replaceable. This opens a world of possibilities to the developer.
NOTE You can find the plan for support of Oracle tools in the statements of direction on otn.oracle.com. These documents change periodically, so it is worthwhile to check the latest statement before making decisions that rely on Oracle tools support. At this writing, the statement of direction for Oracle Forms and Reports states that “Oracle has no plan to desupport these products.”
The cost of this type of development derives from the classic difference between working in a 3GL environment, such as those based on Java, and a 4GL environment, such as Oracle Forms. Less work is done by the base runtime in a 3GL, so the developer is responsible for much more code. With Java frameworks, this responsibility is lessened, with little loss of flexibility. With fully featured tools, such as JDeveloper 10.1.3, that assist in generating and managing basic code, the responsibility is lessened even further.
Oracle customers are often satisfied with the functionality of 4GL applications, and they have significant investments in applications built with the traditional Oracle development tools. Applications built with these tools are stable and user-friendly. However, they have some serious drawbacks beyond the client/server and intranet web environments. One of these major drawbacks is that Oracle Forms uses Java applet technology, which requires a Java runtime and an applet viewer (JInitiator) to be installed on the client. Although mechanisms exist to make this requirement manageable, it can be unmanageable with a large Internet user base. Applets also have the security drawback mentioned before, and their use in some environments might be prohibited by an enterprise-level policy.
Although support and development is continuing for Oracle Forms and Reports, Oracle is concentrating on guiding customers towards J2EE and is spending much time and effort on new and competitive features for JDeveloper. This trend is a natural reflection of Oracle’s direction towards J2EE for the application server and the database, which are based upon or well integrated with J2EE technologies.
Oracle Forms or J2EE?
The preceding discussion has mentioned both Oracle Forms and Oracle Reports as examples of traditional development environments. However, the considerations for weighing each tool against J2EE alternatives are different. The decision of whether to use Oracle Forms or J2EE forms is more difficult than the decision of whether to use Oracle Reports or J2EE reports. Although Oracle Reports on the Web requires only a browser on the client computer, as do J2EE web applications, Oracle Forms requires a Java runtime and the applet viewer on the client computer.
NOTE The Oracle Application Server provides robust runtime environments for both Oracle Forms and J2EE applications, and you can definitely run both types of applications simultaneously. The questions in this section apply to decisions you will make for individual applications. Mixing Oracle Forms and J2EE within the same application may require some workarounds and additional coding.
When making the decision whether to use Oracle Forms or J2EE, you need to answer at least the following questions:
Are Users Familiar with Web Browser Applications? Most users are now accustomed to web browser applications. Even if they do not interact with a web browser for business applications, it is likely they do so outside of the work environment. However, your user base may not have such familiarity, and you will need to plan time for training, as you would for any new environment. If this time or the required training resources are not available, you may be better off creating a traditional-style application that is more familiar to users.
Do I Need to Migrate an Existing Application to J2EE? If you are considering a new application, you can go on to other questions. If the application does exist and is not deployed to a light client (web browser), you need to first confirm that users will be able to adjust to the new front-end, as just discussed. However, you need to ask why you want to rewrite it in the first place. If the application is written in Oracle Forms, you are not risking nonsupport in the foreseeable future, so moving it to J2EE may not be necessary at this time.
Does the Application Require High Interactivity? Oracle Forms offers a highly productive data entry environment. Users can quickly enter data and have data validated before committing it. This allows them to quickly enter a large volume of data. Nothing in the web client J2EE stack yet rivals this ability for high-volume data entry. If the application requires this type of high interactivity, Oracle Forms (or a thick J2EE client that uses a Java application or applet) is indicated. As web technologies mature, this type of interactivity will become more possible. For example, features such as the UIX and ADF Faces partial page rendering mentioned before allow the user to scroll through records without refreshing the entire screen.
If universal access and other benefits of thin client applications are more important than high interactivity, a J2EE solution may be appropriate.
Are Your Infrastructure and Development Teams Ready for the J2EE Technology Stack? If you have already developed applications using
J2EE technologies, this answer will most probably be “Yes” and your decision will not need to weigh this factor. However, if this is the first or an early J2EE project, the IT personnel will require training and more time than usual to develop the application.
You will also need to weigh into the budget the costs of training, development and application server software, hardware (for application servers), and loss of staff time while being trained.
If you have an in-house, experienced J2EE expert in the position of architect, that person will be able to spearhead the effort and direct staff, and the project, effectively towards the goal. If you do not have such a person, it might be necessary to hire one as an employee or to use the consulting services of an outside vendor who has experience in bringing Oracle Forms shops into J2EE development. Often, an arrangement that schedules project work close to training is more effective because development staff will be able to use what they learn immediately. It is also helpful to assign an experienced Java architect (employee or consultant) to the role of technical lead, which would include the role of mentor.
NOTE When leading a group into J2EE, any development tool that can assist in generating code will be helpful. Oracle Consulting offers a product, JHeadstart, that generates a starting set of controller and front-end code files based on database tables. This product can also migrate definitions from an Oracle Designer repository to create J2EE code.
Is the Application Large, Mission-Critical, or Time-Sensitive? Actually, most applications are mission-critical, but there are degrees of importance. The application might be mission-critical to a smaller team of IT staff, or it may be mission-critical to a multi-thousand member user organization. The size of an application is relative, but a small application with few screens and a small data model is a better test bed for learning a new technology stack than is a large application. You will then be able to spend more time learning than coding. Also, a smaller application will be faster to rewrite if a wrong direction was taken due to incomplete knowledge of the solution.
Since you will need to incorporate time to learn and absorb new technologies and potentially to set up new servers, the time factor will be greater
for the first application that uses J2EE. The amount of time for ramping up on the new technology must be factored into the project. If there is no time for that ramp up, the decision will probably be made to wait on the new technology.
You rarely have a choice of the importance or size of the application, but you might have a choice about when to start using J2EE. A smaller, less widely deployed application will be a better first effort for a team that is not accustomed to J2EE development. If your shop is a traditional Oracle Forms shop, you still might choose Oracle Forms for a mission-critical application with a tight deadline. If you have a small application with a limited number of (hopefully adaptable) users and have time at hand to learn and set up a new environment, J2EE might be indicated.
NOTE As with any IT decision, you will probably also need to weigh organizational politics and directives from management into the mix when deciding when and how to move to J2EE.
Oracle Reports or J2EE?
J2EE technologies have few alternatives for reporting that match the flexibility and robustness of Oracle Reports. Oracle Reports contains features for exact placement of text that are unrivaled by J2EE alternatives. It also provides multiple output styles (HTML, PDF, Excel, and delimited text) more easily than other tools. Oracle Reports integrates easily with Oracle’s J2EE application server; this makes it an automatic choice for organizations that license that server. If the organization does not use Oracle’s application server, it would not be using Oracle Forms and Reports, and would probably have its own reporting solution in place.
Naturally, the question of support needs to be answered for Oracle Reports, as it does for Oracle Forms, but the urgency of migration is almost nonexistent because Oracle Reports runs in a lightweight client (web browser) application server environment already. In addition, Oracle does not currently offer a clear J2EE alternative to Oracle Reports as it does for Oracle Forms.
Should I Pay Attention to .NET?
We assume that since you have gotten this far in the article, you have some leaning toward at least exploring the capabilities and coding styles of J2EE. However, you may be curious about or already be considering an alternative offering by Microsoft called .NET.
.NET is a set of standards and architectures published by Microsoft Corporation. It is an alternative to J2EE and does not use J2EE components. .NET has at its core a number of Microsoft products, such as the following:
- Windows as the operating system
- Internet Information Services (IIS) as the application server
- SQL Server for the database
- Visual Studio as the development environment for programming languages such as Visual Basic and C#
.NET offers all of the major services and strategies offered by J2EE and is popular in corporations that have a large existing investment in Microsoft products. Oracle products support the use of .NET and several pages on otn.oracle.com discuss using .NET with Oracle products. However, Oracle is not developing mainstream tools or products to create .NET applications. .NET is looked at with caution by those who do not have heavy investments in Microsoft products, because .NET is a single-vendor solution, is less mature, and requires a specific operating system and, therefore, specific hardware.
Java and J2EE are designed to be platform-independent. An attractive benefit of J2EE to an organization is Java’s multivendor support. In addition, shops that are heavily invested in the Oracle database prefer J2EE over .NET because of Oracle Corporation’s interest in Java as a flexible, cross-platform solution. .NET is still a strong competitor to J2EE, however, and may be the right choice for some IT shops. In addition, as suggested before, the choice of technology sometimes has political motivations instead of purely technical considerations.
How Does Oracle Forms Services Fit into J2EE?
Although the architecture of Oracle Forms Services (Oracle Forms running on the Web) does not fit into the standard configurations mentioned in this blog, it relies solely on mechanisms defined by J2EE to start and run the form. It is deployed in a J2EE application server, run in a J2EE Web Tier container, and displayed through a web browser on the J2EE Client Tier.
Oracle Forms Services contains the Forms Servlet and Forms Listener Servlet, both of which are standard Java servlet files run in the J2EE Web Tier container (OC4J). These servlets are back-end servlets (as mentioned before) configured using standard J2EE property files. The client interface runs within a JVM in the browser session and, therefore, fits into the category of application client (applet) as defined by J2EE. Thus, Oracle Forms Services uses both the Web Tier (the servlets) and the Client Tier (the applet) to run a form. J2EE applications usually run the application code in one of these tiers.
For example, the front-end J2EE servlet architecture mentioned before runs the application in the Web Tier and sends the application’s output to a web browser in the Client Tier. In the case of Oracle Forms, the Forms Servlet running on the Web Tier communicates with the applet running in the Client Tier. Therefore, Oracle Forms Services requires both tiers to run the form and, in that respect, its architecture fits into both the J2EE application client and web client styles.
NOTE Although J2EE applications can be deployed on any J2EE-compliant application server, Oracle Forms Services must be run under the Oracle Application Server.
