EclipseLink RI of JPA

Seen this article about Oracle's EclipseLink being the RI of JPA on TSS.

Difficult to track Oracle's strategy about persistence... What the hell, are the differences between TopLink, TopLink Essentials and EclipseLink?

Is EclipseLink available outside of Eclipse? Or is it the Eclipse equivalent of TopLink Essentials, the one embedded within GlassFish? Why Sun would push an Eclipse-based component as an RI of a JSR? Now Sun has its own competitive open source stack (Solaris, Java, NetBeans, GlassFish and MySQL) what will happen to their historically strong relationship with Oracle? What Oracle will do with Kodo and AquaLogic Data Service Platform? Will they drop them, try to merge them? These are important pending questions.

Why JPA is the only standard with so many "official" RIs (Kodo, Hibernate, Eclipse)?

Anyway, there are certainly some very positive points in that announcement:

• Oracle is going on the open persistence way, you know the one not limited to RDBMS. That's the right way to go, initiated by Xcalia and Castor, and followed by JPOX.


• To that extent, I'm curious to see how they envision the evolutions of JPA, which is, by design, tightly coupled with RDBMS until now.


• The bridge between JPA and SDO seems very important to me. It seems to me this is also what SAP is pushing, and also IBM. BEA was not working in this direction until now (Kodo and ALDSP being fully seperated, except one experience which has been described in this blog), interesting to see how things will change in the coming months.

On all these points Xcalia has been a clear pioneer. It is nice to see big players following the same approach.

EclipseLink RI of JPA

Seen this article about Oracle's EclipseLink being the RI of JPA on TSS.

Difficult to track Oracle's strategy about persistence... What the hell, are the differences between TopLink, TopLink Essentials and EclipseLink?

Is EclipseLink available outside of Eclipse? Or is it the Eclipse equivalent of TopLink Essentials, the one embedded within GlassFish? Why Sun would push an Eclipse-based component as an RI of a JSR? Now Sun has its own competitive open source stack (Solaris, Java, NetBeans, GlassFish and MySQL) what will happen to their historically strong relationship with Oracle? What Oracle will do with Kodo and AquaLogic Data Service Platform? Will they drop them, try to merge them? These are important pending questions.

Why JPA is the only standard with so many "official" RIs (Kodo, Hibernate, Eclipse)?

Anyway, there are certainly some very positive points in that announcement:

• Oracle is going on the open persistence way, you know the one not limited to RDBMS. That's the right way to go, initiated by Xcalia and Castor, and followed by JPOX.


• To that extent, I'm curious to see how they envision the evolutions of JPA, which is, by design, tightly coupled with RDBMS until now.


• The bridge between JPA and SDO seems very important to me. It seems to me this is also what SAP is pushing, and also IBM. BEA was not working in this direction until now (Kodo and ALDSP being fully seperated, except one experience which has been described in this blog), interesting to see how things will change in the coming months.

On all these points Xcalia has been a clear pioneer. It is nice to see big players following the same approach.

Persistence: State of the Union

Seen on InfoQ this panel on persistence:

InfoQ.com and ODBMS.org (Roberto V. Zicari) asked a group of leading persistence solution architects their views on the current state of the union in persistence in the Java community, published here: Java Object Persistence: State of the Union.

The panelists included:

• Mike Keith: EJB co-spec lead, main architect of Oracle Toplink ORM


• Ted Neward: Independent consultant, often blogging on ORM and persistence topics


• Carl Rosenberger: lead architect of db4objects, open source embeddable object database


• Craig Russell: Spec lead of Java Data Objects (JDO) JSR, architect of entity bean engine in Sun's appservers prior to Glassfish

Persistence: State of the Union

Seen on InfoQ this panel on persistence:

InfoQ.com and ODBMS.org (Roberto V. Zicari) asked a group of leading persistence solution architects their views on the current state of the union in persistence in the Java community, published here: Java Object Persistence: State of the Union.

The panelists included:

• Mike Keith: EJB co-spec lead, main architect of Oracle Toplink ORM


• Ted Neward: Independent consultant, often blogging on ORM and persistence topics


• Carl Rosenberger: lead architect of db4objects, open source embeddable object database


• Craig Russell: Spec lead of Java Data Objects (JDO) JSR, architect of entity bean engine in Sun's appservers prior to Glassfish

JPOX 1.2

JPOX is clearly going in the right direction with their new release:

• Compliance with several persistence standards.


• Emerging support for non relational data sources.

It has always been our vision at Xcalia. What we have on top of this, is full support for SOA, both as data sources (services oriented data sources, like Web services, mainframe transactions) and as published APIs (SDO).

Like it or not, persistence, integration and SOA are converging.

JPOX 1.2

JPOX is clearly going in the right direction with their new release:

• Compliance with several persistence standards.


• Emerging support for non relational data sources.

It has always been our vision at Xcalia. What we have on top of this, is full support for SOA, both as data sources (services oriented data sources, like Web services, mainframe transactions) and as published APIs (SDO).

Like it or not, persistence, integration and SOA are converging.

Automatic Fetch Groups

Seen this article about AutoFetch on TheServerSide.

It is nice to see some some people start to understand limitations of well-known ORM solutions in terms of fetching. Xcalia has a nice solution for this since years, through the notion of "business use-cases".

Through this notion, you can associate runtime behaviours (including fetch groups) to sections of your code. Each section will be called according to the current context definition.

Here is a pseudo-code:

UseCase.start("MinimalEmployee");
Collection employees = getEmployees(pm, lastName);
UseCase.end("MinimalEmployee");

UseCase.start("CompleteEmployee");
employees = getEmployees(pm, lastName);
UseCase.end("CompleteEmployee");

In the first case, the getEmployees() method will just retrieve the name of employees, while in the second case it will retrieve all employee information, including related objects and collections.

Use cases can be defined statically in properties files, but they can also be modified at runtime through the JMX interface. This mechanism is not limited to queries and can also be applied during transparent navigation between objets.

It seems AutoFetch author claims to be able to automates the definition of dynamic fetch plans. The details should be available in this paper.