1.4 Non-Managed and Managed Environments

1.4 Non-Managed and Managed Environments

The previous section discussed the need for " someone " to call the datastore and persistence services. Figure 1-4 showed this someone as being the developer, and this needs a bit of elaboration. With the arrival of J2EE, Java applications environments can be broadly grouped into two categories ”namely, non-managed and managed environments.

1.4.1 Non-managed environments

A non-managed environment defines an operational environment for a two- tier application in which an application client connects directly to the resources that it needs. Applications do not depend on any J2EE containers and are typically standalone or based around client-server architectures. In such non-managed environments, the application developer and the application are responsible for all the interactions with the underlying persistence service. This includes configuring the service and its environment and invoking it at appropriate times in the applications lifetime so that data can be persisted . An application that would use JDO in this manner is shown in Figure 1-7:

Figure 1-7. JDO in a non-managed environment.

1.4.2 Managed environments

A managed environment defines an operational environment for a J2EE-based, multi-tier, web-enabled application that accesses Enterprise Information Systems (EISs). The application consists of one or more application components (e.g., EJBs, JSPs, and Servlet) that are deployed in containers . These containers can be any of the following:

• Web containers that host JSP, Servlets, and static HTML pages

• EJB containers that host EJB components

• Application client containers that host standalone application clients

In a managed environment, the J2EE container takes responsibility for configuring the service managing distributed transactions, and for providing security services and other similar system level functions that would be the responsibility of the application in a non-managed environment. As shown in Figure 1-8, in a managed environment, an application component still uses the JDO API; however, the JDO implementation now must support other features so that the application components that are being managed declaratively by the container can work correctly. For example:

• Pooling of objects implementing the transparent persistence service that the application components, e.g., the JDO PersistenceManager.

• The JDO vendor implementation must implement interfaces so that the transactions work as planned and get flushed from the application component to the underlying resources ; for example, the implementation must expose the javax.transaction.Synchronization interface.

• If the JDO implementation uses EIS resources, it is required to access those stores using resource adaptors in a managed environment. The J2EE Connector Architecture (JCA) defines the standard manner in which J2EE applications can communicate with legacy databases and transactional systems. This is covered in Chapter 8.

Figure 1-8. JDO in a managed environment.

Typically, and as most JDO vendors use today, a relational database or an object database is the underlying datastore. In this case, the JDO implementation is said to be using a native resource adaptor.