Xcalia has released Xcalia Intermediation Core (XIC) version 4.2.

XIC allows organizations to build composite applications against their business-level POJO domain model, which is mapped to any resource within or outside of the enterprise, including relational and nonrelational databases, XML files and streams, and any services that must be accessed as part of the application.

Notable changes with XIC include:

• UseCase enhancements: The definition of performance-improving information has always been outside source code, and now it also includes fetch groups. Encase the block of in 'UseCase.begin("MyUseCaseName");' and 'UseCase.end("MyUseCaseName");' calls to have all performance-related metadata take effect.
• Eager fetching improvements: New UseCase features allowing the user to associate fetch groups to a query or a transaction.
• New Metadata access API

XIC allows developers to build applications that transparently access any kind of database and dynamically compose Web services, EJB session beans, JMS message destinations, mainframes, packaged applications such as SAP R/3 or Oracle Financials and local Java objects.

Learn more at http://www.xcalia.com.

Well, since no one has commented ...

From a quick glance, I think this is a very good approach. Is there anything else like this going on in the Java world? I've not seen it. We've talked about this on the JDO 2.0 thread. I would like to see this built on a standard API. At least eventually. Or is it (JDO)?

Well, since no one has commented ...From a quick glance, I think this is a very good approach. Is there anything else like this going on in the Java world? I've not seen it. We've talked about this on the JDO 2.0 thread. I would like to see this built on a standard API. At least eventually. Or is it (JDO)?

It is indeed JDO! - yet again making EJB 3.0/JPA look somewhat limited.

It is indeed JDO! - yet again making EJB 3.0/JPA look somewhat limited.

OK Steve - I'll take the bait!

Can you list the technical advantages that JDO 2.0 has over the draft specification for EJB 3.0/JPA?


PJ Murray
CodeFutures Software
Data Access Objects and Service Data Objects

It is indeed JDO! - yet again making EJB 3.0/JPA look somewhat limited.

OK Steve - I'll take the bait!Can you list the technical advantages that JDO 2.0 has over the draft specification for EJB 3.0/JPA?PJ MurrayCodeFutures Software

Yes, I can.

What I view as the technical advantages are:

1. Less restrictions on the use of Collection. In EJB 3.0/JPA Collections have to contain Entities. In JDO 2.0 they can also contain non-mutable Objects such as Strings, Integers, Dates etc.

2. Less restrictions in POJOs. EJB 3.0 persistence imposes quite a few restrictions and requirements. In EJB3, the author of the class must supply an identity field; the class must not be final; it must not have any final methods; and it must have a no-arguments constructor which cannot be private. JDO 2.0 imposes far fewer restrictions and requirements. Classes must have a no-args constructor, but it can be private. There is no need for an identity field. This means that is is far easier in JDO 2.0 to apply persistence to legacy classes which can't be amended.

3. Less control over retrieval - there is no equivalent in JPA of JDO 2.0 fetch groups - simply lazy/eager fetching. I realise that this in particular is a highly debated topic, but many developers like me prefer the use of fetch groups over explict statements of what is to be retrieved in queries.

4. EJB 3.0/JPA has a primary focus on relational stores, just at the time when new approaches to persistence (such as LINQ) are widening the idea of what type of data can be queried and how. JDO 2.0 works fine on relational stores, but has a far wider focus.

5. Fewer lifecycle states - no equivalent of 'hollow' in EJB 3.0/JPA. This again has been hotly debated. My view is that the range of lifecycle states in JDO assists with reducing the memory requirements for very large transactions. Of course, some will argue that ORM is not appropriate for such 'batch processing'. I prefer not to mix technologies where possible, so I would like to be able to stick to the use of ORM, no matter how large the volume of data.

Obviously, individual implementations of JPA may well do far more than this, and not have such restrictions. However I am talking about specifications here, not products.

Of course, if I am wrong about these technical matters, I would be keen to know.

However I am talking about specifications here, not products.Of course, if I am wrong about these technical matters, I would be keen to know.

Your list looks fine. And you've stuck to the specs and technical reasons.

JDO also has non-technical advantages. For example, I'm not sure how many project managers will risk their projects on version 1.0 of a specification - which EJB 3.0 essential is - even if it's called 3.0.

Now the harder part, Steve: Can you list the technical advantages of EJB 3.0 over JDO 2.0?




PJ Murray, CodeFutures Software
Data Access Objects and Service Data Objects

However I am talking about specifications here, not products.Of course, if I am wrong about these technical matters, I would be keen to know.

Your list looks fine. And you've stuck to the specs and technical reasons.JDO also has non-technical advantages. For example, I'm not sure how many project managers will risk their projects on version 1.0 of a specification - which EJB 3.0 essential is - even if it's called 3.0.Now the harder part, Steve: Can you list the technical advantages of EJB 3.0 over JDO 2.0?PJ Murray, CodeFutures Software

Well, I would assume the use of a more SQL-like language as standard (even though use of such languages is allowed as well in JDO 2.0) is preferable for many developers. Also, because it requires Java 1.5, the ability to persist enums is included. Many developers will like the ability to include metadata as annotations. Finally, my impression is that EJB 3.0 persistence is simpler to implement than JDO 2.0.

Any other suggestions?

To be honest, I really can't see the motivation for current users of JDO to switch to EJB 3.0 with things as they are at present.

My hope is that JPA will progress and include more of the flexibility of JDO 2.0 and remove many of the restrictions of the current specification. I am not anti-EJB 3.0 in principle; I simply don't want the restrictions imposed by the current version.

Well, I would assume the use of a more SQL-like language as standard (even though use of such languages is allowed as well in JDO 2.0) is preferable for many developers.

but JDO 2.0 (for RDBMS datastores) provides exactly what developers are familiar with ... pure SQL. JPA provides EJBQL, which is only SQL-like. I see that as a JDO 2.0 technical advantage myself.

Sticking to the specs, yes JPA does require enum support and JDO 2 doesnt, ... but then all respectable JDO impls have provided support for that (even though it is beyond the spec) for some time.

Well, I would assume the use of a more SQL-like language as standard (even though use of such languages is allowed as well in JDO 2.0) is preferable for many developers.

but JDO 2.0 (for RDBMS datastores) provides exactly what developers are familiar with ... pure SQL. JPA provides EJBQL, which is only SQL-like. I see that as a JDO 2.0 technical advantage myself.Sticking to the specs, yes JPA does require enum support and JDO 2 doesnt, ... but then all respectable JDO impls have provided support for that (even though it is beyond the spec) for some time.

You are right, and this is a significant technical advantage of the JDO 2.0 - it supports SQL as a query language as standard, where as EJB 3.0 persistence does not.

You are also right about enum support in JDO implementations. However, I am personally concerned about the actual specifications - in my view JDO 1.0 relied far too much on vendor extensions to make it a usable API. IT seems to me that this may well be the case with EJB 3.0 persistence as it stands.

Well, I would assume the use of a more SQL-like language as standard (even though use of such languages is allowed as well in JDO 2.0) is preferable for many developers.

but JDO 2.0 (for RDBMS datastores) provides exactly what developers are familiar with ... pure SQL. JPA provides EJBQL, which is only SQL-like. I see that as a JDO 2.0 technical advantage myself.Sticking to the specs, yes JPA does require enum support and JDO 2 doesnt, ... but then all respectable JDO impls have provided support for that (even though it is beyond the spec) for some time.

You are right, and this is a significant technical advantage of the JDO 2.0 - it supports SQL as a query language as standard, where as EJB 3.0 persistence does not.You are also right about enum support in JDO implementations. However, I am personally concerned about the actual specifications - in my view JDO 1.0 relied far too much on vendor extensions to make it a usable API. IT seems to me that this may well be the case with EJB 3.0 persistence as it stands.

I think you've hit on one of the major issues with EJB 3.0/JPA - and its the reason CodeFutures is in no particular rush to implementent the specification and start recommending it to customers - the specification is incomplete and that means proprietary vendor extensions.

Actually, why didn't the JDO experts in the EJB 3.0/JPA specification group warm about this? Maybe they did and were ignored? Or maybe they were fine with the first version of EJB 3.0 being far from perfect.

PJ Murray, CodeFutures Software
Data Access Objects and Service Data Objects

Actually, why didn't the JDO experts in the EJB 3.0/JPA specification group warm about this? Maybe they did and were ignored? Or maybe they were fine with the first version of EJB 3.0 being far from perfect. PJ Murray, CodeFutures Software

I have absolutely no idea why they simply didn't adopt JDO as JPA. After all, JDO 2.0 now has a full ORM specification, and is extremely close to EJB 3.0 persistence, so much so that many vendors allow both to be used at the same time on the same objects. Can it really be that those extra lifecycle states mandated by the JDO spec are so hard to implement?

But anyway, I am puzzled as to why they have come up with a spec that is a poor subset of the supposed influences; JDO, Hibernate, Toplink etc.

But anyway, I am puzzled as to why they have come up with a spec that is a poor subset of the supposed influences; JDO, Hibernate, Toplink etc.

It's all very strange. CodeFutures set out to implement EJB 3.0 in FireStorm/DAO, realized it was just a work in progress, and decided to hold off bringing out a commercial product based on a half-baked specification.

We can speculate:
-the spec team just broke down, could not agree on JDO versus Hibernate and just got stuck?

-the JDO guys said nothing because they wanted their specification to be better than EJB 3.0?

-It's only a draft specification. Maybe they are going to sort it out before it is finalized?

-they are waiting until 3.1?

The CodeFutures response was to implement SDO 2.0 in a new product and adopt a wait-and-see for EJB 3.0/JPA.


PJ Murray, CodeFutures Software
Data Access Objects and Service Data Objects

the JDO guys said nothing because they wanted their specification to be better than EJB 3.0?

Well, a theory (for which I have no evidence whatsoever) is that EJB 3.0 persistence as it is now suits various implementors as they can claim to comply with a standard, yet also provide product-specific extensions. This could easily lead to vendor tie-in.

but JDO 2.0 (for RDBMS datastores) provides exactly what developers are familiar with ... pure SQL. JPA provides EJBQL, which is only SQL-like.

As a self-correction, JPA actually provides a EntityManager.createNativeQuery() method which is for pure SQL, so does provide this too so JDO 2 and JPA 1 are comparable in this respect.

I would like to see this built on a standard API. At least eventually. Or is it (JDO)?

It is currently built using a preview of the JDO 2.0 API, and it will be built using EJB 3.0's JPA as that becomes available in final form. We also support the use of SDO 1.0 as a solution to the DTO pattern. SDO 2.01 support is also planned.

--matthew

I would like to see this built on a standard API. At least eventually. Or is it (JDO)?

It is currently built using a preview of the JDO 2.0 API, and it will be built using EJB 3.0's JPA as that becomes available in final form. We also support the use of SDO 1.0 as a solution to the DTO pattern. SDO 2.01 support is also planned.--matthew

So you will be dropping support for JDO 2.0?

We will continue to support JDO2 but we will add EJB3.
We will also support SDO2 for a non POJO-oriented persistence.

Best Regards, Eric.

We will continue to support JDO2 but we will add EJB3.We will also support SDO2 for a non POJO-oriented persistence.Best Regards, Eric.

Excellent. Your phrase 'built using EJB3' did imply a switch-over, at least to me.

So you will be dropping support for JDO 2.0?

Absolutely not, and I didn't mean to lead anyone to think that! We are supporting the APIs that the market demands. As you've noted elsewhere on the web, the EJB 3.0 JPA is a functional subset of the JDO 2.0 API. Anyone who implements JDO 2.0 can implements EJB 3.0 as well, with not a terrible amount of effort.

--mathew

I would like to see this built on a standard API. At least eventually. Or is it (JDO)?

It is currently built using a preview of the JDO 2.0 API, and it will be built using EJB 3.0's JPA as that becomes available in final form. We also support the use of SDO 1.0 as a solution to the DTO pattern. SDO 2.01 support is also planned.--matthew

Good. I want it to be as un-invasive as possible.