|Mailing List • Forums • IRC|
EclipseLink Application Architectures
You can use EclipseLink in a variety of application architectures, including three- 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
For more information on strategies for incorporating EclipseLink into your application architecture, see Designing Your Application with EclipseLink.
This section introduces some of the following common enterprise architectures used by EclipseLink applications:
- Three-Tier -- The three-tier (or Java EE 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). See Considering Three-Tier Architecture for more information.
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.
The presentation layer communicates with EclipseLink through other Java classes 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.
- EJB Session Bean Facade-- A popular variation on the three-tier application involves wrapping the business logic, including the EclipseLink access, in EJB session beans. This architecture provides a scalable deployment and includes integration with transaction services from the host application server. See Considering EJB Session Bean Facade Architecture for more information.
Communication from the presentation layer occurs through calls to the EJB session beans. This architecture separates the application into different tiers for the deployment. The session bean architecture can persist either Java objects or EJB entity beans.
- EJB 3.0 Entities with JPA -- The EJB 3.0 specification includes an additional persistence specification called the Java Persistence API (JPA). You can use this API for creating, reading, updating, and deleting plain old Java objects (POJO) within both a compliant EJB 3.0 Java EE container and a standard Java SE 5 (or later) environment.
EclipseLink JPA is a standards-compliant JPA persistence provider built on the EclipseLink foundation library. EclipseLink JPA offers a variety of vendor extensions (annotations and persistence properties) that give you full access to the underlying EclipseLink API.
For more information, see:
- Web Services -- A Web services architecture is similar to the three-tier 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 Considering Web Services Architecture for more information
- EclipseLink Database Web Services -- EclipseLink database Web services architecture (introduced in 1.1) 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 Considering 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.
See Considering Two-Tier Architecture for more information.