Sun Microsystem Inc

•Can be transaction-aware.

•Updates shared data in an underlying database.

•Does not represent directly shared data in the database, although it may access and update such data.

•Is relatively short-lived.

•Is removed when the EJB Container crashes. The client has to re-establish a new session object to continue computation.

A typical EJB Container provides a scalable runtime environment to execute a large number of session objects concurrently.

Session beans are intended to be stateful. The EJB specification also defines a stateless Session bean as a special case of a Session Bean. There are minor differences in the API between stateful (normal) Session beans and stateless Session beans.

4.3.2 Entity objects

A typical entity object has the following characteristics:

•Provides an object view of data in the database.

•Allows shared access from multiple users.

•Can be long-lived (lives as long as the data in the database).

•The entity, its primary key, and its remote reference survive the crash of the EJB Container. If the state of an entity was being updated by a transaction at the time the container crashed, the entity’s state is automatically reset to the state of the last committed transaction. The crash is not fully transparent to the client—the client may receive an exception if it calls an entity in a container that has experienced a crash.

A typical EJB Container and Server provide a scalable runtime environment for a large number of concurrently active entity objects.

4.4 Standard mapping to CORBA protocols

To help interoperability for EJB environments that include systems from multiple vendors, we define a standard mapping of the Enterprise JavaBeans architecture client-view contract to the CORBA protocols.

Sun Microsystems Inc.

The use of the EJB architecture to CORBA mapping by the EJB Server is not a requirement for EJB 1.1 compliance. A later release of the J2EE platform is likely to require that the J2EE platform vendor implement the EJB architecture to CORBA mapping.

The EJB-to-CORBA mapping covers:

1.Mapping of the EJB architecture remote and home interfaces to RMI-IIOP. This mapping is an identity mapping because every remote and home interface is an RMI-IIOP interface.

2.Propagation of transaction context over IIOP.

3.Propagation of security context over IIOP.

4.Interoperable naming service.

The EJB-to-CORBA mapping not only enables on-the-wire interoperability among multiple vendors’ implementations of the EJB Container, but also enables non-Java clients to access server-side applications written as enterprise Beans through standard CORBA APIs.

The EJB-to-CORBA mapping depends on the standard CORBA Object Services protocols for the propagation of the transaction and security context.

The CORBA mapping is defined in an accompanying document [8].

While the EJB-to-CORBA mapping defines the mapping of the EJB application interfaces and transaction interoperability, the mapping must be used in conjunction with other CORBA standards to ensure full “on-the-wire” interoperability. For example, multiple EJB servers must agree on the security protocol to achieve seamless interoperability.

The following figure illustrates a heterogeneous environment that includes systems from five different vendors.

Sun Microsystem Inc

Sun Microsystems Inc.