|Oracle9i Enterprise JavaBeans Developer's Guide and Reference
Release 1 (9.0.1)
Part Number A90188-01
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:
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.
The EJB specification describes enterprise bean development in five roles:
The EJB developer is a Java applications programmer familiar with both SQL and with database access using SQLJ or JDBC.
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 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.
The Oracle9i EJB implementation is able to leverage the Oracle database server and offers the following features:
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.
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:
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.
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.
The EJB specification calls for two types of session bean: stateless and stateful beans.
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".
There are four major components that you must create to develop a complete EJB:
The home interface
Specifies the interface to an object that the container itself implements: the home object. The home interface contains the
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.
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:
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.
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.
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.
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.
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.
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.
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 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".