This article, By Chris Richardson, shows you how to accelerate development using Java Data Objects (JDO). It looks at an example application and its JDO implementation, then goes into object relational mapping issues with JDO, including object identity and how to persist embedded value objects. You will learn how to write code that invokes JDO APIs in a way that works both inside and outside an application server.

The devil is in the details, so I'm wondering what JDO implementation you are using. Whatever implementation it is, it certainly has some odd behavior regarding embedded fields and one-to-many-relationships.

The jdo spec absolutely supports embedded objects (as per the 'embedded' field attribute in jdo.xml). An implementation that does not support simple embedded fields is a poor implementation.

Secondly, I'm having a tough time conceiving of why a JDO implementation would require a field object to hold a reference to its encapsulating class. JDO implementations doing this "automatically" seems weird at best. There is just no reason for it that I can see, and it certainly causes a nasty intrusion to the domain model, if it is in fact necessary. Could you elaborate on why an implementation needs to add the reference to the child? It can't have anything to do with the O/R mapping.

Support for embedded fields is optional and something that has not been implemented in JDO Genie (yet). I don't know of any JDO implementations that can do what Chris wanted i.e. to include the fields of the embedded class as columns in the referencing table. Most will just Serialize the object into a blob. EJB CMP does not support this either. The way Chris implemented it (using jdoPostLoad/jdoPreStore) will work with any JDO implementation.

The 1-m relationship mapping (inverse foreign key) in JDO Genie currently requires the child to reference the parent. This can just be a private field added to the class. Nothing else is required. It is updated automatically when children are addedfrom the parent. We implemented it like this as it is often useful for the child to know its parent. This requirement will be removed soon.

I spite of these issues the article concludes: "It is a lot easier to do this with JDO than it is with entity beans using the approach described in my previous article. Furthermore, JDO lets you do 2-tier testing of the domain model against a database, which is extremely useful, and not possible with entity beans."

Anyone considering persistence for Java (not just J2EE) should give JDO a try.

"Rather than each of these classes having its own table we want to store their fields in the parent object's table"

Why? Was this a business requirement? Seems more like an Academic exercise. This opens the door to people saying the classes don't have "transparent persistence".

When I use JDO, I design the object model without regards to the database. I then let my JDO vendor (Kodo) create my database tables for me. The result, I don't really care if this embedded value objects have their own table or not. It's transparent to me when working with the objects. And that's how I like to use JDO: I pretend the database is a black box and I only look inside when I have a bug or a problem and I want to verify what's in there. JDO gives you the power to treat your database like an object database.

"Unfortunately, the way some, but not all, JDO implementations specify the database mapping for 1 to many relationships requires the Java classes to reference each other."

Why did he pick a JDO vendor with such a stupid requirement? Kodo doesn't have this stupid requirement. One of my criteria for choosing a JDO vendor is that I absolutely refuse to add anything to my objects for persistence. If a vendor is lazy and requires users to add fields to classes just to make their job easier, they don't get my business!

"However, this simple approach couples the domain model classes that directly or indirectly use the repositories to JDO and therefore, to the database and potentially the application server, which would slow down development and complicate testing."

This is because he is using EJB! I don't even see a reason to use the Session Bean in this example, and if you take it all the code will run just fine without tomcat. His problem of slowing down development and complicating testing is a result of EJB, not JDO.

"Although this approach is straightforward, it can slow down development and testing because the logic in the session façade is coupled to the database and the application server."

He then shows how to "decouple" the session façade from the database. But all he did was hide the getting and closing of the PersistenceManager. There's a lot more interaction with JDO in between. For example, to save an object you'd call pm.makePersistent(). To delete you'd call pm.removePersistent(). If you're doing a query you'd have JDO code. If you want to rollback a transaction you'd have JDO code. So what good is hiding the get & close of the PM??

I really don't see the issue of coupling your code to JDO as an issue. JDO is a standard, it works with multiple vendors and multiple datastores (relational, object, etc.) But if for some reason you want to remove all JDO code, it's not that difficult. Is it really wroth complicating the object model, adding lots of indirection and classes, and increasing complexity just to hide the fact you're using JDO?

And don't forgot: "Simplest thing that could possibly work" = Tomcat & JDO. No need for most of the stuff mentioned in this academic article.

"When I use JDO, I design the object model without regards to the database."

At Hemisphere we generally do the same. However there are plenty of people out there who think a DBA should do that and who will never use a generated schema. It is certainly possible to save a huge amount of time if you do use the generated schema.

""Unfortunately, the way some, but not all, JDO implementations specify the database mapping for 1 to many relationships requires the Java classes to reference each other."
"Why did he pick a JDO vendor with such a stupid requirement?""

Actually I believe that Kodo has the same requirement if you use 1-many mapping with an inverse foreign key. Someone from Kodo please correct me if I am wrong.

"This is because he is using EJB! I don't even see a reason to use the Session Bean in this example
...
And don't forgot: "Simplest thing that could possibly work" = Tomcat & JDO."

You are correct, it is certainly much simpler to use JDO in a web app with no EJB tier. JDO provides caching, connection pooling etc so the app server is often not needed.

However on many projects an app server will be used anyway and this article shows how to speed up development of these apps. This is really useful stuff if you are using JDO with session beans.

It will take some time before people start realizing that with JDO very few apps need EJB and an app server. And then there are all the old EJB apps to port.

"When I use JDO, I design the object model without regards to the database"

I agree that the JDO implementation generating the database schema transparently should be the way forward. However, creating a database schema is still not an exact science, and while it makes sense that schema auto-generation should be the 90% percent case, in the real world, sometimes (specially on large projects) you need to do things to databases that make absolutely no object sense. This is where I&#8217;d like to have my big black box crowbar and have the ability to change mappings however I feel fit. Incidentally, Genie, seems more than competent at auto-magically creating database schemas. Maybe JDO vendors should look to include a &#8220;by pattern&#8221; method of creating relationships?

&#8220;Why did he pick a JDO vendor with such a stupid requirement?&#8221;

In the posting above yours it was made clear that the requirement was going to be removed. That just shows me vendor flexibility.

&#8220;Simplest thing that could possibly work" = Tomcat & JDO&#8221;

Couldn&#8217;t agree with you more! But placed in context, that is the simplest thing that could work for small to mid sized applications. Most of the enterprise battle is talking to many disparate systems across many networks possibly/probably on many protocols. The pluses for wanting to wrap your domain logic in an application server in this environment are beyond question, and not certainly not academic.

I agree that the JDO implementation generating the database schema transparently should be the way forward.

I cant believe what I am reading. You guys must have never worked in a corporate environment, have you? My experience is that in most settings, the specifics of the mapping between object model and database are *extremely* important and a lot of flexibility is required on the side of the O/R tool to cover all requirements. And, of course, a human with a good understanding of all aspects (OO, tool and DBMS) is also a must. After all, we are dealing with a technology (DBMS) which is extremely crucial from the performance and security/stability aspects. IMO, a DBMS is not designed and should not be looked upon as a "black box", but as an open repository of corporate data (BTW, the relational model is ideal for this purpose).

"I cant believe what I am reading. You guys must have never worked in a corporate environment, have you?"

There is space for both points of view. Hemisphere has done projects in corp environments where the DBA does the schema and says use it. We have also done much smaller projects where there is no DBA on the project and the client has no budget for one.

JDO makes it possible to do the smaller projects really quickly (i.e. cheaply) as the whole persistence problem, including database design is done for you.

In my experience, it's not only the matter of to DBA or not to DBA. Most companies already have databases, and they want new java apps to simply use them like hundreds of other apps already do. If your persistance doesn't allow/support certain database constraints/specialties - tough luck. Most companies will rather reject persistance tool then change the database model.

I absolutely agree. Except "shopping cart" application (where you do not care what your db schema is) schema should be designed and generated by human beings. For large companies and (shared) data, data usually outlives code - data lives longer than object model, object model lives linger than GUI. So quality of your object model has to be good.
Also you are forgeting that this data usually goes to data warehouse for processing and reporting so you should have a decent schema to begin with.
I would never let DBA to design my schema (he is not a developer but an administrator after all) but I will design schema and object modell in parallel trying to make sure I am happy with both. I use to use Toplink which as far as O/R mappings concern still more powerfull than any JDO implementations available and they always recommended to do it in parallel. And that's why I choose Kodo - from the begining they realized importance of 2 way O/R mapping unlike PrismTech who only allow autogenerated schema which does not make sence as DB schema.
I did not read the article but one reason to use embedded collections/objects - performance. We had a case where we had to implement an embeded collection (its serialized content stored in owner's table) because we needed to make calculeations on large numbers of objects which involved this collection and it was awfully slow to read it from second table (instead of single select you get 1 + number of objects you need to realize) This custom mapping observed transactional behaviour and was transparent for API users so it was not bad thing after all.

Just to clarify JDO Genie has strong support for mapping to existing schemas (both meta data extensions and a mapping GUI). This is definitely an essential feature as you point out. Our generated schemas are also 'friendly'. We put a lot of effort into producing a schema that someone could write reports from for example.

Thank you very much for your post. I am glad to see more and more JDO offerings.
I briefly checked you web site and feature list is pretty impressive including some features I was asking from Kodo vendors for long time. I should definitely give it a try. I would be extremely interested in performance comparison of different implementations too (may be do somethin myself)

JDO lets you interact with the database. Ideally this is done in some kind of facade (or a helper class called by the facade). The facade is usually either a session bean (EJB approach) or a "Plain Old Java Object" (POJO) (Non-EJB approach).

It's tempting to just have a struts action do a query to get some items out of a database. And for a small and simple project I think it's OK (remember simplest thing that can possibly work). You can always refactor that code out into the service layer (the facade or its helper). But doing any kind of transaction really should be done in the service layer. This has an added bonus that you can easily unit test your code without using the web (using JUnit in the case of a non-EJB approach).

Performing a business action inside the web tier, using EJB, is considered to be a bad J2EE practice. Does this apply to JDO?

Performing a *business* action inside a *presentation* tier is always a bad practice, regardless of the technology.

What the JDO standard intend to provide is transparency, i.e. allowing you objects to be transactional and/or persistent without design or implementation constraints. Today using JDO 1.0, those contraints will be more or less minimal, depending on the JDO implementation (product) you choose. However any of those JDO implementations will imply less constraints than any alternative solution (i.e. EJB, ODMG, proprietary framework).

However JDO is not an EJB competitor, as it does not answers to the same needs : EJB provides *components* (i.e. software blocks reused and assembled without code modification) while JDO provides *object*-level transactions and persistence. For example, a EJB will typically wrap JDO objects, thus combining benefits of components and persistence transparency and flexibility.

<quote>
However JDO is not an EJB competitor, as it does not answers to the same needs : EJB provides *components* (i.e. software blocks reused and assembled without code modification) while JDO provides *object*-level transactions and persistence. For example, a EJB will typically wrap JDO objects, thus combining benefits of components and persistence transparency and flexibility.

Jerome,

It seems you only talk about EJBs "session". But don't the entity EJBs (CMP or BMP) provide transaction and persistence services ? Sure they do.
And the "component" approach can be integrated in an EJB model through the combination of many EJBs (sessions and/or entity) but an *object*-model can absolutely be applied on a single EJB CMP.

A full-object-based persistence-layer model is obviously not convincing: the first failed experiences with EJBs entity (before using best practices) are already 2 yeard old. What about the performance problems when you have to display data from hundreds of business objects ?

By these days, as we use to listen more often "services" than "object",
IMO, JDO is not in phase with the market reality.

I think what Jerome means is: "there is no opposition between EJBs and JDO".

Nobody denies the benefits of Session Beans.
Entity Beans provides a Component layer (not object-oriented), for large-grained objects.
But Entity Beans have a cost in terms of resource usage, so you cannot use them for all fine-grained objects.
You can use JDO to easily and efficiently access information from Session or Entity Beans. You can also use JDO to easily implement patterns like DAO.

This is where JDO complements EJBs.

But I agree with Yann: if you don't need a "Business Object" Layer, then you don't really need a fully-object-persistence-layer.
But in that case why using Java ?
Java is basically an object-oriented language and the bet is you can get benefits using object principles, not only in the technical layers but also in the business layers.

The question is do you want to "manually manage Data" from your Java Application, or do you want to "transparently use objects" ?

One key point as you stated is performance. I think everybody would chose objects if needed performance (and other QoS constraints) is reached. From this point of view this is not because Entity CMP (that is not an object model) failed that JDO will fail.

It seems you only talk about EJBs "session". But don't the entity EJBs (CMP or >BMP) provide transaction and persistence services ? Sure they do.

I had session EJBs in mind but I extend my statement to all EJB types. Entity EJB do provide transaction and persistence services, but, once again, in a different goal (and so different way) than JDO :

- EJB need a transaction service to define transactional *interactions* between assembled components, i.e. if the transaction propagates to another component, if one component's transaction is independent of a caller's transactional context, etc. As expected in component models, such "transactional assembly" is specified in a code-independent way (external deployment descriptors). This is a very useful and proper way to define transactions when reusing software blocks.

- EJB need a persistence service (the real, intended one is CMP) to allow components to read and write persistent data while insulating them from persistence-specifics (i.e. mix of technical and business code, proprietary APIs, host-dependent data, etc.).

As you may read, the goal in always the same in EJB : allow maximum reuse, and so minimum dependency. A lot of people never understood that, and misused EJB as "persistent objects", thus leading their projects to a dead-end. They very often forgot assembly (using absolute references because it's "simpler" but a nonsense for component reuse), and also local/remote and security services issues. They also claimed for a lack of capabilities that are not well suited for components (component inheritance required a strong, code-specified dependency between components for example).

JDO is at a the lower, object level. Its goal is simply to add transparent, low-level services to objects such as persistence and transactions. In a J2EE context, such services can be leveraged by an EJB container vendor to provide CMP, or by a EJB developer to encapsulate a set of objects that would be difficult to persist (i.e. would necessitate a lot additional and technical code).

However JDO is not J2EE-specific. It is a J2SE standard extension and can be used in a variety of contexts (J2ME, J2SE, J2EE). From a low-level point-of-vue, it goes beyond EJB capabilities by allowing any fine-grained object to persist, non-persistent transactional objects, persistence by reachability, inheritance, a powerful query language (JDOQL, using java syntax and predicates), etc.

> And the "component" approach can be integrated in an EJB model through the >combination of many EJBs (sessions and/or entity) but an *object*-model can >absolutely be applied on a single EJB CMP.

True, and that is the point. Components needs EJB, and a (persistent/transactional) object model (with inheritance, fine-grained objects) needs something else : JDO. However, an object model can be encapsulated into a component (a component is a software reusable part, not a single object, and could even not be an object).

> A full-object-based persistence-layer model is obviously not convincing: the >first failed experiences with EJBs entity (before using best practices) are >already 2 yeard old.

That what I explained above. Some failures of EJB projects are due to a misunderstanding of what EJB are intended to provide. The main goal of EJB is reuse. Automatic persistence is required for maximum reuse, but just a requirement. Today JDO 1.0 provides the first version of the persistence layer you're talking about.

>What about the performance problems when you have to display data from hundreds >of business objects ?

The primary causes for performance problems is application design, and, once again, technology misunderstanding and unproper use. Designing every analysis object as an EJB is the failure. Using EJB finders to display a list of table rows is the failure. Actually, the real failure is that JavaSoft was not able to make EJB technology understood (even if theirs BluePrints are now quite good).

> By these days, as we use to listen more often "services" than "object",
> IMO, JDO is not in phase with the market reality.

It is true that today people use service-oriented designs. There is various reasons for that. One is the emergence Web services fashion, another major one is that people don't know how to design efficient object-based or component-based applications. So they go back to the service, procedure call age, until they say "hey, I miss some context info in this call, let's add it", then "hey, what if this context is modified by another client ?", etc.

So maybe objects are not really in phase with some part of the markey reality, but if it wants to save time and money (throuh quicker design and implementation, maintenance cost cut, reuse), this latter part will have to think about it IMHO.

"Rather than tightly coupling application logic with a specific persistence technology, it is often a good idea to use the Data Access Objects (DAO) design pattern to de-couple business logic and domain objects from the underlying persistence framework. This gives the advantage of being able to transparently switch between JDBC, JDO, EJB, etc. without reworking application logic."

The whole point of JDO is that it allows manipulation of objects in a way that is very close to pure POJOs - you can put your business logic in the objects and invoke business methods directly just like POJOs, and navigate around the model just by following native java references. Hiding this behind yet another persistence abstraction layer is pointless. And TBH I find it very hard to imagine circumstances where one would actually want to switch between JDO, EJB or JDBC - if necessary Id rather take the hit when a specific requirement arose rather than significantly increase the complexity of my system on the off chance.

What I meant to say was that JDO, uniquely amongst the other persistence APIs such as EJB and JDBC, allows a system to be design around a *behavioural* model rather than just a data model. By wrapping it behind another persistence layer much of its power and elegence is cast away since it is relagated to role of pure data model.

JDO gives a chance to start moving back to designing systems based on true OO behavioural business models and this makes it much more that just AN-Other persistence API.

I agree, but please stop saying that EJB is a "persistence API". EJB is a *component* API thay provides CMP persistence to reduce component dependency. Don't use EJB for persistence, use them to build reusable components.

Let's concentrate on the JDO part applicable to the O/R mapping, since DBMS-R are still the main type of store for applications today.

I agree with you, EJB is not a persistence API but persistence is one of the different services provided by the component API (security, transaction,
clustering and so on...).

But why rejecting the persistence layer included in the EJB spec and defining a new one. I really feel the same debates about persistence problems in JDO now and the ones that happened after the EJB 1.0 spec.

Is JDO an 'experiment work' which may be used by sun to define a new spec about the EJB persistence ? Why not... but this new framework would have to add new features or good performance to become a real competitor.

Could u explain the conceptual differences between the EJB persistance spec and the JDO one which may lead JDO to success ?

> But why rejecting the persistence layer included in the EJB spec and defining a new one. I really feel the same debates about persistence problems in JDO now and the ones that happened after the EJB 1.0 spec.

>but this new framework would have to add new features or good performance to become a real competitor.

It already has a better performance than EJB because JDO is only about persistence/transactions (not other services such as security, distribution, etc.) and a lightweight model (objects, not components).

> Could u explain the conceptual differences between the EJB persistance spec and the JDO one which may lead JDO to success ?

First there is some similarities between the EJB and JDO persistence (about transactional basics, some lifecycle events, some identity mode). However JDO persistence is 1) Really transparent for PersistenceCapable objects, whereas EntityBeans are not (you have to implement some interface, use patterns for fine grained objects) 2) Suited to persist any object model, even complex (collections, inheritance), without granularity issues and need for patterns 3) More complete through its support of optimistic transactions (nothing specified about this in EJB), various parameterization features (behavior on commit, behavior on rollback, support for non transactional read/writes, non-persistent transactional objects, application or automated (datastore) identity, its query language (JDOQL allow querying for "collection.contains(someElement)" for example where EJBQL don't) 4) More performant because of its lightweight model, change tracking (only write what has changed)

Hiding this behind yet another persistence abstraction layer is pointless.

Hello paul,

I agree that the capability of switching between JDBC/JDO/EJB for the same application is rather a failure of the application's architect :)

However, I think that an abtraction layer hiding JDO stuff skill make sense : the fact is that JDO still require some API (PersistenceManager::makeTransient(), PersistenceManagerFactory::getPersistenceManager(), Extent, Query.executeWithMap(), etc.) that one might want to hide. With JDO, persistence-capable transparency is achieved, but there's no full transparency for persistence-aware classes (even if the API is lightweight, JDOQL uses a Java filter syntax, etc.).

Consequently it still makes sense to provide some pure business interface that encapsulate persistence-aware objects. For example one init() method would get an PersistenceManager, another retrieveLatestAccounts() method would provide a Collection of persistence-aware objects according a proper JDOQL filter, etc.

Actually if you look at the code of applications using JDO, you will often find such a abstraction layer called "Manager", "Wrapper" or a with similar name.

<quote>
However, I think that an abtraction layer hiding JDO stuff skill make sense (...) Consequently it still makes sense to provide some pure business interface that encapsulate persistence-aware objects. For example one init() method would get an PersistenceManager, another retrieveLatestAccounts() method would provide a Collection of persistence-aware objects according a proper JDOQL filter, etc. Actually if you look at the code of applications using JDO, you will often find such a abstraction layer called "Manager", "Wrapper" or a with similar name.
</quote>

I believe that this is indeed good practice. The data access services of one of our application projects (called e.g. "UserManager", in this particular case) are purely based on interfaces and implementations with bean-style configuration properties. There are simple, collection, or domain objects going in as parameters, and coming out as results. Higher-level services use these data access services to implement the actual business logic.

So the client of a data access service just needs to know WHAT the service method does, not HOW it achieves it. E.g. for retrieval, the parameters will get converted to some query which will get executed, and its results will get converted to the interface result type. One service implementation can retrieve a list of tasks (a domain object) via Hibernate, another one via JDO, and a third one via plain JDBC. This works nicely, and many data access scenarios of this style are perfect fits for O/R mapping behind the scenes, in our case Hibernate.

I wouldn't call this "another abstraction layer", though. I rather consider this good practice in terms of layering the application itself. You do not gain code-level portability with this approach, but in most cases that isn't a valuable goal anyway. What you do gain is the possibility of migrating a data access service to a different persistence strategy with as little coding effort as possible, in as few places as possible.

BTW, we use the Spring Framework for managing and configuring our service instances (and for web MVC, in a later stage of the application). The service instances themselves are Spring-independent to the greatest possible extent (just for certain startup callbacks). IMHO, Spring's application context is a neat and very lightweight approach to service management and configuration. Admittedly biased trailer: ...and just one of many good and original ideas in Spring that are implemented in a reusable way, allowing for easy integration with existing approaches! :-)

Regards,
Juergen
(Spring Framework developer)

P.S.:
some current info on the Spring Framework:
- http://sourceforge.net/projects/springframework- based on Rod Johnson's book "Expert One on One J2EE Design and Development"
- already very stable foundation layer, JDBC framework, and web MVC support
- currently active development e.g. in the areas of transaction handling and AOP
- release 0.8 coming very soon, 1.0 to be expected around end of May

<quote>
JDO is at a the lower, object level. Its goal is simply to add transparent, low-level services to objects such as persistence and transactions. In a J2EE context, such services can be leveraged by an EJB container vendor to provide CMP, or by a EJB developer to encapsulate a set of objects that would be difficult to persist (i.e. would necessitate a lot additional and technical code).
</quote>

Oki. Let EJB container vendors use JDO and let's use the EJB API ;-)
Technical code in EJBs is now hidden thanks to code generators or enhanced IDE.

<quote>
However JDO is not J2EE-specific. It is a J2SE standard extension and can be used in a variety of contexts (J2ME, J2SE, J2EE). From a low-level point-of-vue, it goes beyond EJB capabilities by allowing any fine-grained object to persist, non-persistent transactional objects, persistence by reachability, inheritance, a powerful query language (JDOQL, using java syntax and predicates), etc.
</quote>

- fine-grained ojects *can* be designed as EJB (i don't say it is a good practice but it is feasible).

- Non-persistent transactional objects: interessant, but how do they manage concurrent access ? Through a big object locking system ? Looks interesting.

- Persistence by reachibility : what do u mean exactly ?

- Inheritance : good point, even if it add difficulties to propagate the persistence declarations in a way to allow all the super and sub-classes to be persistent. Waiting for a good implemntation.
- New *powerful* query language. Oki, another one...

<quote>
That what I explained above. Some failures of EJB projects are due to a misunderstanding of what EJB are intended to provide. The main goal of EJB is reuse. Automatic persistence is required for maximum reuse, but just a requirement. Today JDO 1.0 provides the first version of the persistence layer you're talking about.
</quote>

REUSE ????
I really disagree with this point. EJB associated services like CMT and security are essentials in transactional webapps. Re-use is just indeed by the component approach.

<quote>
It is true that today people use service-oriented designs. There is various reasons for that. One is the emergence Web services fashion, another major one is that people don't know how to design efficient object-based or component-based applications. So they go back to the service, procedure call age, until they say "hey, I miss some context info in this call, let's add it", then "hey, what if this context is modified by another client ?", etc.
So maybe objects are not really in phase with some part of the markey reality, but if it wants to save time and money (throuh quicker design and implementation, maintenance cost cut, reuse), this latter part will have to think about it IMHO.
</quote>

Right, the procedure call-like paradigm is a misuse of an OO language when u want to build "Business components". You can still use a "Context" object to pass parameters but this is just a denormalization of the procedure call mechanisms.

And WebServices are just a common way to build B2B data exchanges, not a core part of an application's architecture.
But i may be out of subject there ;-)

I would rather say, let's use EJB for components, and JDO if I only need persistence and/or transactions.

> Technical code in EJBs is now hidden thanks to code generators or enhanced IDE.

That's quite correct. But you still have the heavyweight of EJB where they only represent persistent objects, and you still have to use some patterns to manage fine-grained, depend objects, and you still have to choose between vendor CMP capabilities and BMP-JDBC stuff.

> - fine-grained ojects *can* be designed as EJB (i don't say it is a good practice but it is feasible).

So if you want to avoid bad practices, avoid EJB as fine-grained objects ;)

> - Non-persistent transactional objects: interessant, but how do they manage concurrent access ? Through a big object locking system ? Looks interesting.

Have a look at the JDO spec. Every object is managed by a PersistenceManager (even if only transactional) which is associated with a transaction. Transactional object state is typically managed into a cache from such a PersistenceManager.

> - Persistence by reachibility : what do u mean exactly ?

I mean that if you define a Company that references a collection of Departements, and every Departement references a set of employees, making the Company persistent will make all objects referenced by that Company (Departements collection, Employees set) persistent at the same time.

> - Inheritance : good point, even if it add difficulties to propagate the persistence declarations in a way to allow all the super and sub-classes to be persistent. Waiting for a good implemntation.

With JDO, a superclass may be persistent or not, abstract or not, etc. All this is supported by JDO and by existing implementations. Of course only concrete classes can persist.

> - New *powerful* query language. Oki, another one...

It goes beyond EJB QL as I quoted in my previous post, and it's not a new syntax : it's a Java syntax.

> REUSE ????
> I really disagree with this point. EJB associated services like CMT and security are essentials in transactional webapps. Re-use is just indeed by the component approach.

I don't say the opposite. Security is part of WebApps (Servlets) specification. Transactions is available in webapps using JTA. CMT is a powerful feature but that only make sense for reusable components assembly.

> Right, the procedure call-like paradigm is a misuse of an OO language when u want to build "Business components". You can still use a "Context" object to pass parameters but this is just a denormalization of the procedure call mechanisms.

Right.

> And WebServices are just a common way to build B2B data exchanges, not a core part of an application's architecture.

WS were intended for that, but today it's more a technology to make incompatible technologies work together in the IS.

I would never let DBA to design my schema (he is not a developer but an

This is a very risqué assertion(Unless one worked as a DBA for some time). I went once for an interview and the young, bright, napster-inventor-dotcom wizard style guy in front of me said: and after building the database(this was something like a 3 weeks project in his mind)we will concentrate on programming.
ANd I know a project where new types are generated programatically and new tables are generated programati8cally(with names like T10awe, T11awe, etc).

Sorry if it sounded to strong. I did not mean it. I would gladly take DBA's help as far as defining physical properties of my tables (partitioning, parallel processing, tunning etc) but in order to design schema he/she has to know what I am trying to do how it should blend with my object model etc and also have solid design background. In the past we use to pass our ERwin (entity relational) diagrams plus expected table sizes etc to DBAs who would decorate them with various oracle physical attributes and take over the schema but initial design was ours

Christian Sell must be working on enterprise level applications. So do I.
For simple/middle applications, JDO/JSP server is OK, and developers needn't care about the underlying mapping, or the exact database structure. But when applications that use different technologies are mixed together, much complications appeared. Usually, in such cases the database structure of a JDO application is important for other referencing apps(maybe not JDO powered) to work.
However, my opinion is that for the JDO application, developers still needn't care about the mapping layer. Then who should care? My answer is the coordinator of different apps. He/she should adjust the metadata of the model classes regarding specific vendor extensions to fit diverse requirements from other apps.
So, should anyone argue more on what JDO can help us or impede us, he or she must consider the respective roles for potential problems.

If developer / engineer claim's "I'm an enterprise developer" - he/she MUST know about database details - including theory :), and must work together with DBA in order to improve performance of developed model.

Database is a corner stone of Enterprise.
CMP is very good for prototyping apps, and BMP, which is inherited from CMP is good for improving performance. Both technologies should be used appropriately.

I really disagree that people should consider using JDO, or any Object model, to generate a relational database. The relational world has a whole differnet set of best practices all together. Many CMP vendors implemented this type of generate as well as the reverse. Most development in the Enterprise expand on existing databases with existing apps.

OR tools are suppose to provide an Object interace to the Domain not replicate or create it. You are assuming that databases will only be accessed by Object Oriented systems from now till kingdom come. What's worse generating this from Java types makes it difficult for other languages. I know the goal is to access the system only through the Object Model but that is unrealistic. There are just some things performance wise you can gain for Stored Procedures and database tools. I mean what if you create this DB and Mapping between Aspect Oriented Systems and Relational Databases get hot.

The majority of the time you will map existing databases to existing Object Models. Objects have their benefits and so do relational databases.

As for me, it does not look attractive. Did the author want to show that this approach is easy? It doesn't look easy. I am not an expert in JDO and don't know the best practices. If it represents the best practices, I am a bit frightened.

I did quite a bit of research looking for one at the end of last year and I unfortunately there are not. I found Kodo JDO which I found to be of top quality and the cost is very low (starts at $800/developer with no runtime). I also contacted LiDO and they want $4,000/cpu! So you can see the price range for JDO varies quite a bit. For me Kodo was cheap enough, and in the architecture I did for my project Kodo was the only commercial tool in my entire architecture. But it was worth it because the quality is so good.

There is also a big effort at Apache to transform the OJB to implement the JDO specification. This is Apache OJB.

I have had also a very pleasing experience with JDO and I think that the development time for some of our projects has decreased at a half compared to JDBC and EJB 2.0.
This is also true because we also used JDO with Echo Web Framework and I have started a project at sourceforge for components that are binded with the database such as Trees, Tables, Forms (similar to DataGrids in ASP.NET) that use JDO. The project is here.

There is another open source JDO implementation: Speedo. This project is supported by the Objectweb open source community (www.objectweb.org). This project is based over two frameworks:
- Jorm makes persitent java object over a data support (www.objectweb.org/jorm).
- Medor permits to build queries over data supports or in memory (www.objectweb.org/medor).
Both framework permit to work with classical relational databases such as Oracle, postgres, ... or other data support types (file, object data base, ...). They are extensible.
Both frameworks are also used in the new JOnAS version (J2EE server) in order to implement the CMP2.0.
Speedo will be availlable at the end of april. Currently speedo is in arefactoring state. The main evolution is the support of legacy relational databases.(http://debian-sf.objectweb.org/projects/speedo/)

Firstly, thanks Chris for taking the trouble to write the (informative) article. I've been wondering how solve the database/ testability aspect for some time.

Sometimes the use of EJB is a technical constraint. In this case (if you want the job) there is choice except to use EJB.

The way I see it (ppl please correct me if I am wrong), Chris's example assumes that there is only 1 transaction, and declarative transactions are used. Furthermore it assumes that the session facade (actually the bean holding the business) is not going to talk to any other EJBs.

My gut feel is that in an EJB environment, it may be necessary to use unit tests running in the application server, and the dbms, for tests that span more then a few components. The alternative is to produce a platform-hiding framework, which just adds too much complexity for what it is providing.

Perhaps IBM's in-IDE app server testing framework concept is a good one for this reason.

Has anyone seen any non IBM alternatives? (i.e. an app server execution environment which plugs into netbeans, eclipse, or jbuilder?).

I tried using jdo-Relay for sometime. Unfortunately, I had a hell of a time, mappping the objects to existing database tables. Is this a common problem amoung jdo vendors like the earlier stages of EJB 2.0 development.

<Quote>
... Unfortunately, I had a hell of a time, mappping the objects to existing database tables. Is this a common problem amoung jdo vendors like the earlier stages of EJB 2.0 development.
<Quote>

You can try FrontierSuite for JDO. It provides you a lot of flexibility and support for mapping objects to the database. You can do the mapping in a GUI environment. Among the options that are available in FrontierSuite for JDO are:

Several people brought up good points, mainly that it's not always an option to generate the DB schema from the object model. I agree with this point. I see three scenarios:

#1 - New Project & New Database

I think if it's a new project, it's best to let the JDO tool generate the schema based on the object model. I know many will disagree but this is the simplest/easiest/fastest. I don't know about most of you, but I'm a java developer not a DBA. My JDO tool can generate a better schema than I can, and the typical clients I work for are start-ups who cannot afford a DBA!

#2 - New Project & Legacy Database not used by any other applications

If the database isn't used by any other applications, why not migrate it to a new schema that is consistent with the object model and JDO? I haven't tried configuring JDO tools to map to existing schema, but in this thread I've read it's possible.

#3 - New Project & Legacy Database used by other applications

If the other apps use Java, it's a great opportunity to convert them to JDO as well. If that's not possible, or if the other apps aren't written in Java, then there's no choice but to do an O/R mapping from the object model to the existing schema.

In all three cases, JDO will work! And in any case, I really believe JDO is much better than JDBC. It reduces the amount of java coding substantially (sometimes 80%). 80% less code means a 5x faster development time, 80% less bugs, a 5x increase in quality, etc.

I think if it's a new project, it's best to let the JDO tool generate the

> schema based on the object model. I know many will disagree but this is the
> simplest/easiest/fastest. I don't know about most of you, but I'm a java
> developer not a DBA. My JDO tool can generate a better schema than I can, and
> the typical clients I work for are start-ups who cannot afford a DBA!

But then one day, one of these startups might be an enterprise, and your app will be a legacy application, maybe in the core of the business. Other applications might be forced to integrate with your application, maybe on the database level. Guess whos name will be forever cursed by the poor DBA´s that has to maintain your generated schema, and by the EAI department, and by the...

"Other applications might be forced to integrate with your application, maybe on the database level. Guess whos name will be forever cursed..."

That depends on what the generated schema looks like. With JDO Genie we put a lot of effort into producing a schema that looks "human" designed. If you dont like the way the tables and columns are named you can configure the built in name generator or write your own. The structure is perfectly consistent - something often lacking in schemas built up over time by several different people.

As we say in XP: "You Aren't Gonna Need It". Why design for something, that "one day" "might". If that happens then redesign the schema. But no need to suffer productivity during the near term for something that "one day" "might"..

You can't "refactor" the database. In real world, it doesn't work, ever - it's possible only when you don't need it, when database is small and availability is not an issue. When you really need it, when it's a huge, unmanageable monster, used 24x7, you don't stand a chance. Even when it's physically possible cost of it so huge no sane manager would aprove it. And that's why they last for decades, sometimes. (databases, not managers :P)

You can't "refactor" the database. In real world, it doesn't work, ever - it's possible only when you don't need it, when database is small and availability is not an issue. When you really need it, when it's a huge, unmanageable monster, used 24x7, you don't stand a chance. Even when it's physically possible cost of it so huge no sane manager would aprove it. And that's why they last for decades, sometimes. (databases, not managers :P)

Yes, what you say is true. I guess we are not living in the wonderfull world of XP you and I. I hope someday to transcend to this wonderfull place where you always get a second shot at correcting your mistakes, "Just refactor...".

I guess thats what them boys who designed vsam files with 2 digit years did, in the end of the last century. They went back and did some re-factoring, and at no mentionable cost either... =)

Even if you don't refactor it after it's been 5 years in production, and it's being used by 15 applications written in 6 languages, you'll want to refactor it during development. (Same as the classes, interfaces, etc.)

For starters, sticking your head in the sand about performance issues is one of the most dangerous things to do. No, you don't want to get stuck on micro-optimizing every class that's maybe used once an hour, but yes, you'll want to run some extensive benchmarks and optimize the big picture. And in the case of database apps, about half the performance problems will be in the database part: either in the table structure, or the SQL statements used on the client side. Even on big iron machines, database performance can -- and often will -- be an issue. And, yes, I've seen it actually happen on quad processor Sun's with a whole array of expensive SCSI drives. If anyone thinks they can do just a straight mapping from some high level classes to database tables, whether by hand or via some program, and then get it to work right by just tweaking the database caches and whatnot... they're going to have a big surprise at some point.

And then there's the issue, which XP rightly takes into account, that the client never knows exactly what he/she wants in advance. The whole "we don't change the database" (or interface, or whatever) approach just leads to a state of war between developpers and clients, and 2000 page specifications which aren't even worth the paper they're printed on. The client strictly speaking got _exactly_ what he signed for, but it's useless anyway. And if you don't want to change it, chances are he'll find someone else who will.

Now I'm not saying that this disqualifies JDO or anything. But it does mean any particular implementation must fit a pretty tall order. Choosing any particular approach or tool just because it allows you to make a quick first implementation, but then makes it impractical to change anthing later, is the kind of thinking which produces monolything servlets or other antipatterns.

I have continually heard rave reviews about Hibernate that I have come to the conclusion that it is the undisputed best when it comes to persistence. It is easy to use, efficient and complete while OJB is vastly incomplete. Did somebody say that Hibernate does not implement JDO?

IIRC Hibernate does not implement JDO because JDO mandates some kind of byte-code manipulation. And while I don't think they are against such a thing (they use cglib), they don't want to be forced to do it by specification.

As you will see, all the possible approaches are covered, and all are through a user friendly, GUI environment. And you can choose any of the above approaches and create a scaleable, high performance JDO application using FrontierSuite for JDO. And to answer some of the pricing questions, the price ranges from $999 (Standard version) to $2999 (Enterprise edition with secondary and distributed caching). No runtime charges.

Want to address a few of the concerns raised by Chris with respect to FrontierSuite for JDO.

Embedded Objects Storage
------------------------

The choice of the location of the embedded objects in the database is left to the JDO implementations. The options available are:

a. In the same table (As Compound Attributes). Benefit is the quicker reads. The downside is that readability vis a vis the domain object model is lost.
b. In a separate table (As Second Class Objects). In this case, the reads are slower because of the join that is needed, but it mirrors the domain object model.

Both these options are supported by us. And both these options do not need the use if the instance callbacks interface.

Primary key generation
---------------------

In the case of datastore identity, the choice of values used as primary key is left to the JDO implementation. As the article points, this may result in some readability/interpretation issues. And the developer really has no control over the primary key values. What we have found is that developers need control over the type of the primary key/id fields, but would like to delegate the burden of generating the actual values to some generation mechanism. This will provide the transparency of the Application Identity and the reduced burden of the datastore identity.

FrontierSuite for JDO supports a variation of datastore identity, which allows the developers to define primary key fields, and then generates the values for these fields automatically.

1 - m Relationship issues
--------------------------

In case of uni-directional relations, there is no need for the child object to maintain a ref to the parent object. This is not required in FrontierSuite for JDO.

Is there a reason to discuss about such patterns concerning JDO ?
I seem to be back 2 years earlier when discussing about EJB Patterns... Issues & solutions are conceptually exactly the same, right ?
Thus, i totally agree with a previous article in this thread: is "complexity" the way to "simplify using of JDO".

It looks like JDO-related companies have changed their marketing shoot angle: the strategy "don't pain with persistence" didn't success due to the power of DBMS. Now, they try to attack the battle field of O/R mapping, concurrencing products like Toplink or J2EE spec like EJB. Is JDO a real technological advance or just a mix of existant good ideas, with a ready-for-market common name ?

There is definitely a reason why patterns are relevant here. Persistence is a generic application requirement and different applications realise it in different ways, depending on their needs. If I want persistence is an application server environment, session beans will be good, if the environment is distributed, you may need value objects etc. The usage depends on the actual application architecture - the patterns just tell how all it can be used.

There is no debating the power of RDBMS. What JDO provides is an object oriented abstraction to the data in RDBMS. You can leverage the power of RDBMS (most of it anyway) through an object oriented interface - makes development simpler, quicker. And JDO is a result of a lot of experience garnered over the years - it provides a solution to persistence needs - and the solution is defined to be applicable to any datastore, not necessarily RDBMS. But with RDBMS dominating the storage space, most of the JDO implementations are RDBMS related only, though you can find OODBMS based solutions also. And pretty soon, implementations for other EISs also should be available.

And by the way, we are also an O/R mapping company, who now provide a JDO implementation as well (Toplink is also on its way). So it is not that JDO vendors are opposed to O/R Mappers, in fact you will find that quite a few O/R mappers provide you a JDO impl (maybe with a few notable exceptions...).

Readers of this thread may be interested in another view and approach to persistence. Whilst JDO is a technology with many benefits, it is yet another technology choice for implementing a persistence tier or an object-relational mapping. In terms of Java APIs, the list now includes JDBC, EJB 1.1, EJB 2.0, and JDO. Each of these technologies has pros and cons.

Rather than tightly coupling application logic with a specific persistence technology, it is often a good idea to use the Data Access Objects (DAO) design pattern to de-couple business logic and domain objects from the underlying persistence framework. This gives the advantage of being able to transparently switch between JDBC, JDO, EJB, etc. without reworking application logic.

There is a better overview of the benefits of DAO at the following URL:

This article also discusses the relationship between DAO and EJB and JDO.

There are many tools on the market that can automatically generate the DAO tier for you and give you a choice of generating implementation according to EJB, JDBC, etc. FireStorm is one such product. More information available at:

After an EJB project, I started using JDO in a new project. What pleases me most are the ease of testing and the support for inheritance.

Easy testing:
In the article complexity is added to be able to test with or without database. AFAIK this is really overkill: the tests for your business classes dont need to know anything about JDO anyway, and if you want to test the manager classes you generally want to take the database into account (especially because the tests are ran and debugged just as easily as other tests).
With JDO you can just write, execute and debug your tests without leaving your IDE (eclipse in my case). Compared with EJB this speeds up tremendously.

Inheritance:
It was the lack of support for inheritance in EJB that pushed me towards JDO. Most object models use inheritance in some way and in my project it is crucial. JDO stores class hierarchies just as easy as simple classes.

I hope that it will become easier to integrate JDO inside an EJB container in the future, although it seems to me that EJB vendors see JDO as a hostile technology.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.