|Mailing List • Forums • IRC|
EclipseLink Application Architectures
You can use EclipseLink in a variety of application architectures, including web, SessionBean, and two-tier architectures, with or without Java EE, to access a variety of data types on both relational and nonrelational data sources.
EclipseLink and Your Application Architecture
The Java Persistence API is the primary interface used to access EclipseLink. EclipseLink also provides a native API that existed before the JPA standard, and can still be used. EclipseLink's JPA support is built on top of its native API, so even if JPA does not expose a specific native API feature, it can still be access through casting the JPA EntityManager. JPA can be used in virtually any Java application architecture, and does not require a Java Enterprise Edition application server, or EJB 3.0 support.
This section introduces some of the following common enterprise architectures used by EclipseLink applications:
- Web -- A Java Web application is one of the most common EclipseLink architectures. This architecture is characterized by a server-hosted environment in which the business logic, persistent entities, and the EclipseLink Foundation Library all exist in a single Java Virtual Machine (JVM). The most common example of this architecture is a simple three-tier application in which the client browser accesses the application through servlets, JavaServer Pages (JSP), and HTML. Examples of this architecture include Apache Tomcat, or usage of the web portion of any Java EE application server such as Oracle WebLogic, Oracle Glassfish, Redhat JBoss or IBM Websphere.
The presentation layer communicates with EclipseLink through JPA in the same JVM, to provide the necessary persistence logic. This architecture supports multiple servers in a clustered environment, but there is no separation across JVMs from the presentation layer and the code that invokes the persistence logic against the persistent entities using EclipseLink.
Web applications typically use a RESOURCE_LOCAL JPA persistence unit with a non-JTA DataSource, or an EclipseLink JDBC connection pool.
- EJB Session Bean Facade-- A popular variation on the web application involves wrapping the business logic, including the EclipseLink and JPA access, in EJB session beans. This architecture provides a scalable deployment and includes integration with transaction services from the host application server.
Communication from the presentation layer occurs through calls to the EJB session beans. This architecture separates the application into different tiers for the deployment. Examples of this architecture include any Java EE application server such as Oracle WebLogic, Oracle Glassfish, Redhat JBoss or IBM Websphere.
EJB applications typically use a JTA managed JPA persistence unit with a JTA DataSource managed by the application server.
- Web Services -- A Web services architecture is similar to the web or session-bean architecture. However, in a Web services architecture you encapsulate business logic (the service) in a Web service instead of (or in addition to) using session beans. In a Web services architecture, clients communicate with your application using XML.
As in any architecture, you can use EclipseLink to persist objects to relational or EIS data sources. However, in a Web services architecture you can also use EclipseLink to map your object model to an XML schema for use with the Web service or as the Web service XML serializer.
See EclipseLink MOXy for more information
- EclipseLink Database Web Services -- EclipseLink database Web services architecture is similar to the Web services architecture. However, in an EclipseLink database Web services architecture, you use EclipseLink to automatically generate Web services that expose database operations such as queries, DML statements, and stored procedures and stored functions. Using EclipseLink database Web services, you can provide Java EE compliant, client-neutral access to a relational database without having to write Java code.
As in any Web services architecture, clients communicate with your application using SOAP (XML) messages. However, in an EclipseLink database Web services architecture you need only specify an XSD for persistent classes. Clients need only invoke the operations the EclipseLink database Web service exposes to create, read, update, and delete these persistent objects. EclipseLink database Web services return objects or row set data, depending on the type of operation. See EclipseLink Database Web Service Architecture for more information.
- Two-Tier -- A two-tier (or client/server) application is one in which the EclipseLink application accesses the database directly. Although less common than the other architectures discussed here, EclipseLink supports this architecture for smaller or embedded data processing applications.
Two-tier applications typically use a RESOURCE_LOCAL JPA persistence unit with an EclipseLink JDBC connection pool (normally with a single, or small number of connections in the pool).