The following sections provide a brief overview of new features in EclipseLink.
EclipseLink allows you to expose JPA entities through a standards-based (JAX-RS/JAXB/JPA) RESTful service. REST is an acronym for Representational State Transfer, which is a design idiom that embraces a stateless client-server architecture. In this architecture, Web services are viewed as resources which can be identified by their URIs.
Basic HTTP operations, such as create (POST), read (GET), update (PUT), and delete (DELETE) can be called on the services.
Data in RESTful services are referenced using a URI. A URI can be constructed in different ways, depending on the target, for example:
URI for JPA entities with a single-part primary key
URI for JPA entities with composite keys
URI with mapped named read queries
URI for name update and delete queries
Clients can interact with the RESTful service in any of these ways:
By using a web browser as the client
By using Java SE as the client
By using implementation-specific APIs
For more information, see "Exposing JPA Entities Through RESTful Services" in Solutions Guide for EclipseLink.
EclipseLink simplifies the development of application components that offer support for multiple tenants. Developers and deployers have complete control of the application and data isolation they require. Each tenant has access to its own data, while other tenants' data is invisible to it.
EclipseLink provides these options for tenant isolation:
Single-table tenant isolation allows tenants to share tables. Each tenant has its own rows, identified by discriminator columns, and those rows are invisible to other tenants.
With table-per-tenant tenant isolation, each tenant has its own table or tables, identified by table tenant discriminators, and those tables are invisible to other users.
With Virtual Private Database (VPD) tenant isolation, tenants use a VPD database, which provides the functionality to support multiple tenants sharing the same table.
For more information, see "Using Tenant Isolation" in Solutions Guide for EclipseLink.
NoSQL is a classification of database systems that do not support the SQL standard. The NoSQL classification can be expanded to include Enterprise Information Systems (EIS) including application databases, legacy databases, messaging systems, and transaction processing monitors. EclipseLink supports persistence of Java objects to NoSQL databases through the Java Persistence API (JPA). EclipseLink's native API is also supported with NoSQL databases.
NoSQL maps objects to structured data such as XML or JSON. It also supports embedded data, embedded collections, and all of the existing JPA mapping annotations.
Whether querying is supported in NoSQL depends on the NoSQL platform you are using. The JPA transaction API is supported with NoSQL data-sources. Some NoSQL data-sources might not support transactions, so the level of transaction support is dependent on the NoSQL platform.
For more information, see Chapter 12, "Understanding Non-relational Data Sources." See also "Using EclipseLink with NoSQL Databases" in Solutions Guide for EclipseLink.
JAXB binding metadata is used to marshall Java objects to and from JSON. This feature is useful when creating RESTful services; JAX-RS services can accept both XML and JSON messages.
For more information on JSON support, see "Developing JAXB Applications Using EclipseLink MOXy."
A shared (L2) object cache reduces database access for objects and their relationships. This cache is enabled by default which is normally not a problem, unless the contents of the database are modified directly by other applications, or by the same application on other servers in a clustered environment. This may result in stale data in the cache.
If the contents of the database are modified, then EclipseLink Database Change Notification (DCN) ensures that the contents of the cache are synchronized with the database. DCN allows shared caching to be used in the JPA environment.
See "Using Caching with a Shared Database in a JPA Environment" in Solutions Guide for EclipseLink.
Extensible entities allow mappings to be added dynamically. In this case, the entity stores extended attributes within a map instead of static attributes. The entity then defines how values from this map are mapped to the database using an
eclipselink-orm.xml mapping file. Extensible entities are useful in a multi-tenant (or SaaS) architecture where a shared, generic application can be used by multiple clients (tenants). Tenants have private access to their own data, and to data shared with other tenants.
Using extensible entities, you can:
Build an application where some mappings are common to all users and some mappings are user-specific.
Add mappings to an application after it is made available to a customer (even post-deployment).
Use the same
EntityManagerFactory interface to work with data after mappings have changed.
Provide an additional source of metadata to be used by an application.
For more information on making entities extensible, see "Providing Software as a Service" in Solutions Guide for EclipseLink.
You can expose multiple persistence units (each with unique sets of entity types) as a single persistence context by using a composite persistence unit. Individual persistence units that are part of this composite persistence unit are called composite member persistence units. For more information, see "Using Multiple Databases with a Composite Persistence Unit" in Solutions Guide for EclipseLink.
You can store your mapping information in a metadata source that is external to the running application. Because the mapping information is retrieved when the application creates the persistence unit, you can dynamically override or extend mappings in a deployed application. See "Using an External Metadata Source" in Solutions Guide for EclipseLink.