J2EE Fundamentals for .NET Developers

This is where you should start if you are a .NET developer and you want to understand the components and functions of the J2EE platform.

Sun Microsystems developed Java as both a platform and a programming language. There are currently three editions of the Java platform:

• J2SE (Java 2 Standard Edition)

• J2EE (Java 2 Enterprise Edition)

• J2ME (Java 2 Micro Edition)

  Note

  The term “Java” mostly refers to functionality available within J2SE. Areas that require the Enterprise Edition include the term J2EE.

Java 2 Platform, Enterprise Edition or J2EE is a set of linked specifications that allow developers to create multitier server-based applications. Hence unlike Microsoft .NET, J2EE is a standard, not a product. The J2EE specification consists of a series of downloadable Adobe PDF files that describe application agreements and the makeup of the containers in which these applications run.

Like .NET, J2EE makes it easier to write distributed enterprise applications by letting you focus on writing business logic rather than the enterprise framework itself. J2EE provides the “plumbing” that allows the application to run and would otherwise be tedious and time consuming to write.

Note

At the time of publication, J2EE v1.3 is the latest released version and v1.4 is in final draft.

Hence the J2EE platform is similar in vision to Microsoft .NET, with common themes that run through both platforms. However, it is important that you understand the fundamental differences. Java and Microsoft .NET differ in three main ways, which are:

• Operating system support

• Language support

• Execution method

From the beginning, Java was designed to work with as wide a range of operating systems as possible. Hence Java code runs in multiple environments, such as:

• Windows

• UNIX

• Linux

• MacOS

• BeOS

However, Microsoft .NET runs only on Windows.

Note

Rotor is a version of the .NET Framework that runs on FreeBSD. However, this is more of an academic exercise than a practical implementation scenario.

Language support covers the language, syntax, and grammar that you use to create your programs. You write Java applications only in the Java Programming Language. With .NET, you have the choice of any language that supports the .NET Framework.

There is also a major difference between the two platforms at application run time. When you build a project based on a .NET language, the output consists of MSIL code that the JIT compiler compiles at runtime.

To deploy a Java program, you compile the application to create Java bytecode. The JVM running on the target operating system then interprets this bytecode to produce the relevant instructions.

Note

There are also Java JIT compilers that work in a similar fashion to the .NET Framework component.

Understanding the Java Platform

There are two main components of the Java platform. These are:

• The Java Runtime Environment (JRE)

• The Java Language and syntax (API)

The main component of the JRE is the Java Virtual Machine or JVM. The role of the JVM is to interpret Java bytecode into native instructions for the operating system. However, the JVM also provides a number of functions that make it similar to the .NET CLR. The JRE also includes the Java class libraries.

Within the J2EE framework there are additional components that have evolved over the past decade. These include:

• Java Server Pages (JSPs)

• Server side APIs or servlets

• Enterprise Java Beans (EJBs)

• Java Naming and Directory Interface (JNDI)

• Java Message Service (JMS)

• Java API for XML-based RPC (JAX-RPC)

• J2EE Connector Architecture

• J2EE Management Model

• J2EE Deployment API

• Java Management Extensions (JMX)

• J2EE Authorization Contract for Containers

• Java API for XML Registries (JAXR)

• Java Transaction API (JTA)

• Common Object Request Broker Architecture (CORBA)

• JDBC data access API

Many of these components map to equivalents within the .NET Framework or in Windows. For example, JMS provides support for message-based transactions, and maps to the System.Messaging namespace.

Because J2EE is a specification, rather than a product, numerous vendors have created their own implementations under license from Sun. These vendors include:

• Sun (Sun ONE Application Server)

• IBM (WebSphere)

• BEA (WebLogic)

There are also several open source implementations, with JBoss being the most recognizable. For more information, see the JBoss Web site at http://www.jboss.org/

Implementing the Java SDK

Like the .NET Framework, Java has a software development kit to assist you in creating and compiling Java applications. The Java SDK has been through several revisions, and you can download the Java 2 SDK, Standard Edition 1.4 from Sun’s Java site.

Other vendors have produced their own implementations of the Java SDK under license. Like the J2EE Application Servers, these vendors include IBM and BEA, together with open source implementations. Up until version 1.1.4, Microsoft also had an implementation.

The Java 2 SDK contains the class libraries you can use when creating your own Java source code as well as the compiler and binaries for building and executing these applications. The bin directory of the SDK contains Javac.exe which you use to compile Java source code (*.java files) into Java Byte Code (*.class files). However, like with .NET applications, only the most die-hard conservatives work entirely from the command line, and most use a GUI-based IDE to create and build Java applications.

Building a Java Application

When you compile Java classes with the Java compiler, each class in Java generates a separate .class file, which is the standard unit of compilation. The JVM can then execute the .class file using the following syntax:

 java myapp.class 

However, .class files are not directly equivalent to .NET assemblies, because .NET assemblies are both units of execution and distribution. To create distributable applications containing multiple .class files, Java developers use Java Archive (JAR) files. A basic JAR file is a collection of compiled Java classes, although JAR files can contain files of any type and have an internal directory structure, like a ZIP file. You use Jar.exe, from the \bin directory of the SDK to add, list or extract .class files from a JAR file.

You can execute a JAR file with the JVM Java.exe. The syntax is:

 java –jar myapp.jar 

If you really want to, you can build and deploy a complete J2EE application using only native operating system commands and the basic tools supplied with the Java 2 SDK. However, this method can be tedious and prone to errors. Instead, developers often make use of build tools such as ANT, part of the Apache Jakarta project. ANT is a platform independent build tool that automates the compilation, packaging and deployment of applications. It makes use of XML build files to determine the tasks required to compile and deploy a project.

For more information about ANT, see the Apache ANT Web site.

Locating and Sharing Classes

The Java platform does not include an equivalent to the global assembly cache. However, applications may still need to refer to or share other classes. In Java, you do this using an environment variable named CLASSPATH. This is similar to the PATH statement in the Autoexec.bat startup file or the System Profile property in Windows.

The default class path is the current directory. You can set the CLASSPATH environment variable to one or more different directories if you want; when you do this, you must explicitly include the path to the main Java 2 SDK tools JAR and to the current directory. Hence, a simple CLASSPATH statement in release 1.3 of the Java SDK running on Windows would look like this:

 SET CLASSPATH = .;%J2EE_HOME%\LIB\J2EE.JAR; 

If your application requires other classes or JAR files, you then amend the CLASSPATH variable before running the application. You do this by referring to the current CLASSPATH variable as follows:

 SET CLASSPATH = %CLASSPATH%;C:\OTHERAPP\RESOURCES.JAR;C:\OTHERAPP\CLASSES 

This appends the new directories to the existing CLASSPATH so that when a Java application loads and asks for a class, it also searches any class in the directory C:\OtherApp\Classes or the JAR file C:\OtherApp\Resources.jar.

Both the Javac.exe compiler and the Java.exe execution tool can accept parameters to include or modify the CLASSPATH variable. Java IDEs also allow you to include CLASSPATH statements. You can also add libraries to the class search sequence automatically without setting CLASSPATH by installing them as extensions in the JRE.

Note

If a Java application generates a ClassNotFoundException, you can almost guarantee that this is because the required libraries are not in the CLASSPATH statement.

Implementing Other Environment Variables

Java applications tend to use environmental variables more than .NET-based applications. This is because Java applications can run on multiple operating systems, so they need to be able to cope with differing environments. Environmental variables provide an easy way to ensure consistency for setting and controlling configuration and application execution paths.

Table 2.1: Common Environmental Variables

Variable Name	Function
JAVA_HOME	Installation location of the Sun Java SDK
J2EE_HOME	Installation location of the Sun J2EE SDK
ANT_HOME	The ANT home directory
PATH	As for the Windows PATH statement

Using Java Integrated Design Environments

Several vendors produce IDE packages to assist with creating and editing, ranging from beefed up text editors to full blown packages that resemble Visual Studio .NET. Some are commercial packages, others are free. Examples include:

• Sun One Studio

• JCreator

• Borland JBuilder

• Java GUI Builder

• JPad Pro

• CodeGuide

• NetBeans

• AnyJ

  Note

  Although you can create and edit Java applications using Visual J# from Visual Studio .NET, J# IntelliSense technology only works for Java API classes up to release 1.1.4 of the Java SDK and you need to build the application from the command line using Javac.exe.

All the IDE packages allow you to build applications from within the IDE environment. Alternatively, like Visual Studio, you can build applications from the command line.

Creating Web Applications

For Presentation tier components, Java implements JSP where you would use ASP.NET in the .NET architecture. JSP provides a server side technology for developing Web applications and JSP pages are a mixture of HTML and Java code.

Java-based Web applications use the concept of dynamically compiled JSP pages and servlets. A servlet is a Java programming language class that extends the capabilities of computers hosting applications accessed through request-response programming models. You can also think of Java servlets as portable components that provide dynamic content to user requests.

At first glance, JSP and servlets appear very similar, with both producing dynamic content. You create any scripting elements within the JSP pages or the servlets in the Java programming language. Additionally, the JVM compiles JSPs into servlets at run time and therefore both use the same engine. However, developing a servlet entails writing a Java class and therefore requires stronger programming skills than are needed to develop a JSP. You can think of a servlet as Java code wrapping up HTML content.

Like servlets, JSPs provide dynamic content to users but at a higher level abstraction of servlets. You can think of JSPs as static HTML wrapping up dynamic Java code.

You can host both JSP and servlets on a number of environments. These include free offerings such as Apache Tomcat up to the large commercially available and vendor-supported implementations.

To implement a JSP-based application, you design the application using a Java IDE. Several IDEs include facilities for real-time editing of JSP pages, with previews showing the effect of any changes to the graphics or the controls.

Note

The current JSP specification is release v1.2 and the servlet API is v2.3.

To deploy Web applications, you package them up into a single deployable unit called a Web Application Archive (or WAR) file. This is similar to how you package Java applications into JARs. You can then easily deploy the WAR file onto the Web server.

Hosting Components

The main function of JSP pages and servlets is to interact with the user through the browser in the Presentation tier. However, executing business rules in the Business tier uses components called Enterprise Java Beans (EJBs). EJBs are the equivalent of COM+ components or managed code components, and can provide the following services:

• Maintaining state

• Transactional support

• Method level security

• Logging

• Impersonation

• Message queue support

EJBs come in three forms:

• Session beans

• Entity beans

• Message-driven beans.

Session beans host business logic, such as the rules defining the operation of a customer relationship management system. Session beans can be stateless or can maintain state, tying the client to the session bean for the object’s lifetime. Typically a session bean provides some sort of service, such as performing a task, such as authentication, for clients.

Entity beans represent an object in persistent storage. Each instance of an entity bean corresponds to a row of data from a database table. There are two types of entity bean: container managed persistence (CMP) beans, which are managed by the container; and bean managed persistence (BMP) beans, which manage their own persistence.

With CMP entity beans, the container manages the mapping between bean and database fields using a mapping file. This mapping file usually stores these mappings as XML deployment descriptors. The container manages all the communications with the database. CMP has the following advantages compared to BMP:

• Easier to configure

• Easier to maintain

• Requires no database code

The main disadvantage of CMP can be that of performance, due to greater abstraction levels. However, newer features of the J2EE specification have introduced features such as virtual accessors, which have improved the performance of beans using CMP.

With BMP entity beans, the developer is responsible for writing all the JDBC code for transferring data between a bean and the data store. BMPs require the developer to write much more data-related code than CMPs, but nevertheless there are several good reasons for using BMPs:

• Greater flexibility

• Better performance

• Ability to connect to multiple database sources

A Java developer would use CMP for connecting to standard databases such as Oracle or where the number of transactions per second is low. BMP comes into its own with high data access rates or where the developer needs the flexibility to connect to a non-standard database such as an LDAP directory.

You would use message-driven beans (MDB) in conjunction with the JMS API to process messages asynchronously. Message-driven beans are JMS message consumers. Clients do not access MDBs directly; they send a JMS message to a destination where there is a listening MDB. This enables reuse of the MDB, and also means that the developer does not have to worry about where to go to get the message.

The two main benefits of using MDBs are that MDBs enable parallel processing of user requests, which provides a faster response compared to serial invocation using non-message based entity Java beans, and that an MDB implementation can guarantee user response times when searching multiple data sources.

Building Enterprise JavaBeans

When building an Enterprise JavaBean, a developer must create the bean’s implementation class and a number of interfaces. Clients access session and entity beans through the methods that the developer defined in the bean’s interfaces. The interfaces determine how the client can communicate with the EJB. Message-driven beans differ from entity and session beans in that they do not have interfaces; they contain only a bean implementation class.

The interfaces defined on an entity or session bean are dependent on one key factor: Is the bean going to be accessed remotely or locally?

A remote client is:

• An application or component that runs in a separate JVM from the client (although the application does not necessarily have to run in a separate JVM.)

• An application or component executing on a different computer.

• A Web component such as a servlet, a client application, or another EJB.

• Where the client does not know (or need to know) the location of the EJB.

If an EJB services remote clients, the developer must create two interfaces: a remote interface and a home interface. The remote interface defines the business methods specific to the bean, for example, AuthenticateCustomer. The home interface defines methods that manage instances of the bean. For example, session beans have methods to create and remove instances of the beans. Entity beans also include finder methods. Finder methods allow clients to locate entity beans, for example, findByPrimaryKey.

A client is local if:

• The client component or application executes in the same JVM as the EJB.

• The client could be a Web component or EJB.

• The location of the EJB is not transparent to the client.

If an EJB is required to service local client, it is also necessary to create two interfaces, a local interface and a local home interface. The local interface defines the bean’s business methods in a similar fashion to a remote interface. The local home interface is similar to the remote home interface in that it defines methods for manipulating instances of the bean and defining finder methods.

It is usually more efficient for a local client to invoke methods on the local interfaces than through remote invocation. In a typical J2EE application, a session bean provides remote client access, whereas entity beans normally provide local client access. Entity beans that use CMP almost always employ local access.

Deploying Applications

Building and deploying a J2EE application involves a number of steps to ensure that you deploy everything required for the application to function. In addition to JAR files containing EJBs or other classes, your application may need WAR files. WAR files are JARs with the required structure for a Web application. Finally, Enterprise Archive files (EARs) can contain WARs and JARs stuffed with EJBs and other content.

You configure deployment settings using deployment descriptors, which are XML files with a defined structure. Deployment descriptors specify settings such as security, transactional support, and logging that tell the application server how to deploy and support the components in the application. Again, these settings correlate to those in component services. Some deployment descriptor settings are part of the J2EE specification, whereas others relate to the application server and are vendor-specific.