Oracle8i Enterprise JavaBeans Developer's Guide and Reference Release 3 (8.1.7) Part Number A83725-01 |
Library | Service | Contents | Index

## About Enterprise JavaBeans

Oracle8i JServer 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 Oracle8i 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 Oracle8i 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 Oracle8i.

### Oracle8i EJB Implementation Features

The Oracle8i 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 Oracle8i 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, Oracle8i effectively enables direct object-oriented access to an array of open systems.

### IIOP Transport Protocol

Oracle8i 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 Oracle8i 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

Oracle8i 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, Oracle8i 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

### 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 Oracle8i ORB and Java VM run under the multi-threaded server (MTS), the distinction between stateless and stateful session beans is not important for JServer. 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".

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index