1
Oracle9i Overview

This chapter gives you a general picture of distributed object development in the Oracle9i JVM. This overview focuses on the aspects of Enterprise JavaBeans (EJB) development particular to Oracle9i, giving a brief general description of the EJB standard development model.

This chapter covers the following topics:

• About Enterprise JavaBeans

• Implementing an EJB

• Basic Concepts

• Types of EJBs

About Enterprise JavaBeans

Oracle9i complies with the EJB 1.1 specification and offers a highly scalable and high-performance execution environment for EJBs.

Enterprise JavaBeans (EJB) is an architecture for developing distributed applications. Additionally, EJB applications are developed entirely in Java. It is not necessary for developers to learn a new language, such as IDL for CORBA applications.

EJB is an architecture for transactional, component-based distributed computing. The specification for EJBs lays out not just the format of a bean itself, but also a set of services that must be provided by the container in which the bean runs. This makes EJBs a powerful development methodology for distributed application development. Neither the bean developer nor the client application programmer needs to be concerned with service details such as transaction support, security, remote object access, and many other complicated and error-prone issues. The EJB server and container furnishes these features for you.

EJB architecture makes server-side development much easier for the Java application programmer. Because the implementation details are hidden from the developer, and because services such as transaction support and security are provided in an easy-to-use manner, you can develop EJBs relatively quickly. Furthermore, EJBs offer portability. A bean developed on one EJB server should run on other EJB servers that meet the EJB specification.

EJB Development Roles

The EJB specification describes enterprise bean development in five roles:

• The EJB developer writes the code that implements an individual EJB. This code is the business logic of the application, usually involving database access.

  The EJB developer is a Java applications programmer familiar with both SQL and with database access using SQLJ or JDBC.

• The EJB deployer installs and publishes the EJB. This involves interaction with the EJB developer so that the transactional nature of the EJB is understood. The EJB deployer writes the deployment descriptor files that specify the properties of each bean to be deployed.

  The EJB deployer must be familiar with the runtime environment of the EJBs, including database-specific matters such as network ports, database roles required, and other schema-specific requirements. For the Oracle9i server, the EJB deployer is responsible for publishing the EJB home interfaces in a database and communicating this information to the client-side application developer.

• The EJB server vendor implements the framework in which the EJB containers run. For Oracle, the Oracle9i data server is the framework that supports the EJB containers.

• The EJB container vendor supplies the services that support the EJB at runtime. For example, when a client expects the bean to handle transaction support automatically, the container framework together with the data resource supports this.

• The application developer writes the client-side code that calls methods on server EJBs.

The roles of the EJB server and EJB container developers are not clearly distinguished. There is, for example, no standardized API between the container and the server. For this reason, the same vendor is likely to perform initial implementations for EJB servers and containers. This is the case for Oracle9i.

Oracle9i EJB Implementation Features

The Oracle9i EJB implementation is able to leverage the Oracle database server and offers the following features:

• a simple-to-use way of locating and activating beans, using a JNDI interface to an underlying OMG CosNaming service

• a session name space that uses the database as a name server, with its performance advantages, such as fast access to indexed tables

• secure socket layer (SSL) connections for added security

• standard Oracle database authentication and multi-layer access control to objects

• an implementation of the Java Transaction Architecture (JTA) for transaction demarcation

• a UserTransaction interface for bean-managed transactions

• tools that assist you in deploying your EJB application

RMI over IIOP

EJB specifies Java Remote Method Invocation (RMI) as the transport protocol. EJBs are based conceptually on the Java Remote Method Invocation (RMI) model. For example, remote object access and parameter passing for EJBs follow the RMI specification.

The EJB specification does not prescribe that the transport mechanism has to be pure RMI. The Oracle9i EJB server uses RMI over IIOP for its transport protocol. Because the CORBA Internet Inter-ORB Protocol (IIOP) is the transport protocol for CORBA and for a future version of RMI, Oracle9i effectively enables direct object-oriented access to an array of open systems.

IIOP Transport Protocol

Oracle9i offers a Java interpreter for the IIOP protocol. Oracle embeds a pure Java ORB of a major CORBA vendor (VisiBroker for Java version 3.4 by Inprise) and repackaging the Visigenic Java IIOP interpreter to run in the database. Because Oracle9i is a highly scalable server, only the essential components of the interpreter are necessary--namely, a set of Java classes that do the following:

• decode the IIOP protocol

• find or activate the relevant Java object

• invoke the method the IIOP message specifies

• write the IIOP reply back to the client

Oracle9i does not use the ORB scheduling facilities. The Oracle multi-threaded server performs the dispatching, enabling the server to process IIOP messages efficiently and in a highly scalable manner.

On top of this infrastructure, Oracle9i implements the EJB programming model.

JNDI

EJB developers follow the EJB specification and use JNDI for access. Each bean is published automatically during the deployment process. JNDI provides access to the published bean through a CosNaming layer.

Figure 1-1 shows how applications access remote objects published in the database using JNDI.

Figure 1-1 Remote Object Access

Text description of the illustration overviea.gif

Stateful and Stateless Session Beans

The EJB specification calls for two types of session bean: stateless and stateful beans.

• Stateless beans--which do not share state or identity between method invocations--find use mainly in middle tier application servers that provide a pool of beans to process frequent and brief requests, such as those involved in an OLTP application.

• Stateful beans are useful for longer-duration sessions, in which it is necessary to maintain state, such as instance variable values or transactional state, between method invocations.

Because the Oracle9i ORB and JVM run under the multi-threaded server (MTS), the distinction between stateless and stateful session beans is not important for Oracle9i. Thus, EJB activates only stateful session beans on demand in a new session. Stateful beans can offer the same performance as stateless beans, while preserving the "conversational state".

Implementing an EJB

There are four major components that you must create to develop a complete EJB:

• the home interface

• the remote interface

• the implementation of the remote interface--the actual bean class

• a deployment descriptor for each EJB

  Component	Description
  The home interface	Specifies the interface to an object that the container itself implements: the home object. The home interface contains the create() methods that specify how a bean is created. The home interface, with the home object serves as a factory object for EJBs.
  The remote interface	Specifies the methods that you implement in the bean. These methods perform the business logic of the bean. The bean must also implement additional service methods that the EJB container calls at various times in the life cycle of a bean. See Basic Concepts for more information about these service methods.
  The bean implementation	Contains the Java code that implements the remote interface and the required container methods.
  The deployment descriptor	Specifies attributes of the bean for deployment and loading into the database. For example, the deployment descriptor declares the transactional properties of the bean. At deployment time, the EJB deployer, together with the application developer, can decide whether the container should manage transaction support or have the client do it.

The client application itself does not access the bean directly. Rather, the container generates a server-side object known as the EJBObject that serves as a server-side proxy for the bean. The EJBObject receives the messages from the client, and thus the container can interpose its own processing before the messages are sent to the bean implementation.

Figure 1-2 illustrates the interaction among these components.

Figure 1-2 Basic EJB Component Relationships

Text description of the illustration ejbover.gif

Basic Concepts

Before going into details about implementing EJBs, some basic concepts must be clarified. First of all, recall that a bean runs in a container. The container, which is part of the EJB server, provides a number of services to the bean. These include transaction services, synchronization services, and security.

To provide these services, the bean container must be able to intercept calls to bean methods. For example, a client application calls a bean method that has a transaction attribute that requires the bean to create a new transaction context. The bean container must be able to interpose code to start a new transaction before the method call, and to commit the transaction, if possible, when the method completes, and before any values are returned to the client.

For this reason and others, a client application does not call the remote bean methods directly. Instead, the client invokes the bean method through a two-step process, mediated by the ORB and by the container:

1. The client invokes the bean method off of the remote interface object.
   1. The client actually calls a local proxy stub for the remote method.

   2. The stub marshals any parameter data, and then calls a remote skeleton on the server.

2. The skeleton unmarshals the data, and upcalls to the bean container.

   This step is required because of the remote nature of the call. Note that this step is completely transparent both to the client application developer as well as to the bean developer. It is a detail that you do not need to know about to write your application code, either on the client or the server. Nevertheless, it is useful to know what is going on, especially when it comes to understanding what happens during bean deployment.

3. The bean container receives the skeleton upcall, then interposes whatever services are required by the context. These can include:
   • authenticating the client, on the first method call

   • performing transaction management

   • calling synchronization methods in the bean itself

   • identity checks and switch

4. The container delegates the method call to the bean.

5. The bean method executes.

6. When it returns, the thread of control returns to the bean container, which interposes whatever services are required by the context.

   For example, if the method is running in a transaction context, the bean container performs a commit operation, if possible, depending on the transaction attributes in the bean descriptor.

7. The bean container calls the skeleton, which marshals return data and returns it to the client stub.

These steps are completely invisible to client-side and server-side application developers. One of the major advantages of the EJB development model is that it hides the complexity of transaction and identity management from developers.

Types of EJBs

There are two types of EJBs: session beans and entity beans. An easy way to think of the difference is that a session bean implements one or more business tasks, while an entity bean is a complex business entity. A session bean might contain methods that query and update data in a relational table; an entity bean represents business data directly or indirectly through another persistent bean.

Session beans are often used to implement services. For example, an application developer might implement one or several session beans that retrieve and update inventory data in a database. You can use session beans to replace stored procedures in the database server, thereby achieving the scalability inherent in the Oracle9i Java server.

Entity beans are often used to facilitate business services that involve data and computations on that data. For example, an application developer might implement an entity bean to retrieve and perform computation on items within a purchase order. Your entity bean can manage multiple dependent persistent objects in performing its necessary tasks.

Persistence

Session beans are not inherently persistent. Persistence can refer either to a characteristic of the bean--entity beans are persistent, session beans are not inherently persistent--or it can refer to data that a bean might save, so that the data can be retrieved in a future instantiation. Persistent data is saved in the database.

Therefore, a session bean can save its state in an Oracle9i database, but it does not directly represent business data. Entity beans persist the business data either automatically--in a container-managed persistent entity bean--or by way of methods that use JDBC or SQLJ and are coded into the bean--in a bean-managed persistent entity bean.

Implementing the synchronization interface can make data storage and retrieval automatic for session beans.

Session Beans

Created by a client, a session bean is usually specific to that client. In Oracle9i more than one client can share a session bean.

Session beans are transient in that they do not survive a server crash or a network failure. If, after a crash, you instantiate a bean that had previously existed, the state of the previous instance is not restored. State can only be restored to entity beans.

Stateful Session Beans

A stateful session bean maintains its state between method calls. For example, a single instance of a session bean might open a JDBC database connection and use the connection to retrieve some initial data from the database. For example, a shopping-cart application bean could load a customer profile from the database as soon as it's activated, then that profile would be available for any method in the bean to use.

A typical stateful session EJB is a relatively coarse-grained object. A single bean almost always contains more than one method, and the methods provide a unified, logical service. For example, the session EJB that implements the server side of a shopping cart on-line application would have methods to return a list of objects that are available for purchase, put items in the customer's cart, place an order, change a customer's profile, and so on.

The state that a session bean maintains is called the "conversational state" of the bean, as the bean is maintaining a connection with a single client, similar to a telephone conversation.

Keep in mind that the state of a bean is still transient data, with respect to the bean itself. If the connection from the client to the bean is broken, the state can be lost. This depends on whether the client is unable to reconnect before timeout.

Entity Beans

Entity beans are persistent in that they do survive a server crash or a network failure. When an entity bean is re-instantiated, the state of previous instances is automatically restored. For more information on entity beans, see "Definition of an Entity Bean".