7.3 J2EE, RMI, and CORBA


As well as standalone Java applications, JDO can be used to build J2EE, RMI, or CORBA applications also. In particular, JDO has been specifically designed to work in conjunction with J2EE. Essentially, wherever a Java application can directly use JDBC today, JDO likewise could be used.

In many ways, JDO offers a programming model and approach to object persistence similar to Container Manager Persistence (CMP) from the Enterprise JavaBeans (EJB) specification. However, unlike CMP, JDO keeps persistence orthogonal to the component architecture being used. This means that the power of object persistence can be taken advantage of directly within a Java application or a Servlet without incurring the overhead of the J2EE component architecture. Or it can be used by any other non-J2EE distributed platforms like RMI and CORBA.

That is not to say that JDO has no role to play within EJB. In fact, JDO combined with SessionBeans makes for a powerful architecture. SessionBeans provide the remote, component-level interface, leveraging the container services like resource pooling, connection, and transaction management, while JDO provides portable, lightweight object persistence.

Although the EJB 2.0 specification provides an enhanced specification for CMP that aims to address some of the performance issues of the previous version, from a development standpoint, CMP is still an order of magnitude more complex than JDO to use.

With CMP, a developer needs to do the following:

  • Provide a local and/or remote Home interface that defines the methods used to locate instances of the EntityBean class.

  • Provide a local and/or remote EntityBean interface that defines the public methods of the EntityBean class.

  • Provide a local and/or remote abstract class that implements the methods as declared in the associated EntityBean's interface. The class doesn't actually declare the fields of the EntityBean; instead, it declares JavaBeans-style getters and setters for each field. Fields and relationships to other EntityBeans must be declared in the deployment descriptor for the EntityBean.

  • Provide a deployment descriptor that declares all of the following: the EntityBean's local and/or remote Home and EntityBean interfaces, the abstract class that implements the EntityBean's methods, and the fields and relationships of the EntityBean.

  • Deploy the EntityBean, at which point a concrete implementation of the EntityBean's abstract class is generated by the container along with the necessary code to store and retrieve the fields or the EntityBean to/from the underlying datastore.

When these things have been done, the EntityBean can be run and tested ; however, any issue that requires a code change requires a redeployment of the Entity Bean. Also, the EntityBean itself can be run only within a J2EE container, although a local interface at least allows an application within the same JVM to bypass the overhead of remote invocation.

With JDO, a developer needs to do the following:

  • Provide a normal Java class. Fields are declared as normal; relationships are implemented using Java references and standard collection classes. Inheritance can be used.

  • Provide an XML file containing the metadata for the persistence-capable class. Because most of the metadata is derived, often all that is needed is the class name .

  • Compile the class using a standard Java compiler, and use a JDO-compliant byte-code enhancement tool.

At this point, the class can be used by any Java application, a Servlet or EJB SessionBean, RMI, or CORBA application.



Core Java Data Objects
Core Java Data Objects
ISBN: 0131407317
EAN: 2147483647
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net