Java Virtual Machines Oracle Application Server Tips by Burleson Consulting

A Java Virtual Machine is needed to execute compiled Java code or class files. When Java code is compiled, it creates a file of byte-code that ends in .class. The JVM interprets the byte-code when the application is run. This provides Java?s portability. Once Java code is compiled, it will operate on any platform that has a compatible JVM. It is the job of the JVM to take the byte-code in the class file, convert it into the local computer?s machine code, and execute it.

Figure 2: Executing Java on the Java Virtual Machine

Hence a Java application written on a Windows box will execute in the same way on a Solaris or Linux server. Java Virtual Machines also allow you to have nonhomogenous systems, with a powerful Solaris server hosting the database, two servers (one Linux and one Windows) hosting the application server, and clients using Netscape, Mozilla, and IE, all accessing the same Java application. Most Java tools (such as JDeveloper) are written in Java, and so the same program can run on multiple operating systems with pretty much the same appearance.

JVMs do much more than just execute class files. The JVM is responsible for security, allowing the application access only to those parts of the server allowed. This is why some applications have problems running in a browser. For example, the JVM that supports a browser ?assumes? an applet is untrustworthy and will not allow it to interface directly with operating system resources.

Enterprise JavaBeans

Enterprise JavaBeans often constitute the heart of an application running on Oracle Application Server 10g because EJBs contain the business logic of the application. They require a J2EE container to run, and they support distributed objects within the application. EJBs are constructed following a strict specification that insures EJBs work together within a large application. Applications find EJBs by using the JNDI service and interact with them through the container. By encapsulating business logic inside EJBs, you can distribute the application across different servers or have multiple copies of an EJB on different servers to load-balance the application. Although the discussion of writing EJBs is beyond the scope of this book, an introduction to the types of EJBs is needed. For additional information on creating EJBs, refer to the books identified at the beginning of this chapter.

There are three types of Enterprise JavaBeans: session, entity, and message-driven.

* Session EJB - These support a single client in the execution of a task. A session EJB exists only as long as that single client exists. It is not shared. A session EJB can be used to interact with a customer database to include executing dynamic or static SQL, or stored Java, or PL/SQL procedures or functions. Session EJBs are either stateless or stateful. The state of a bean is defined as the variable values it holds. A stateless session EJB implements business logic and does not maintain a state between calls. A stateful session EJB maintains a state (a set of variable definitions) between method calls. Methods can be used to change its state, and the new state will be maintained until it is changed again or it is removed from the container. Hence a stateful bean can support only one client, while a stateless bean can support multiple clients (one at a time).

* Entity EJB - These represent business data rather than business logic. An entity EJB represents data in a database, such as a customer order. Like data in a database, an entity bean can be shared by many clients and has a unique identifier called a primary key. Because an entity EJB?s state is based on some external persistent storage, its state does not change unless the data in the persistent storage changes. Entity beans normally connect to a database through the container. The container implements all the database connectivity. As with session EJBs, entity EJBs also come in two flavors?container managed or bean managed. Container managed persistence (CMP) is more popular because this type of EJB forces the container to handle the task of reading and writing object attributes back and forth to the database. The developer is normally not required to write any JDBC or SQL code. Bean managed EJBs, on the other hand, require that the developer handle the task of persisting object attributes to the database and then loading them back into the EJB when it is instantiated. This means writing all the SQL required via JDBC. This offers a great deal of flexibility, but it can be quite complex. It is easy to see why container managed persistence is the more popular choice today among Java developers. This will be discussed in detail in Chapter 8.

* Message-Driven EJB - These process JMS (Java Message Service) messages asynchronously. This differs from session EJBs, which will block while sending a request to another bean. Unlike session or entity EJBs, message-driven EJBs have no interfaces that clients can call directly.
 

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.