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:
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:
At this point, the class can be used by any Java application, a Servlet or EJB SessionBean, RMI, or CORBA application. |