Panel: Java Object Persistence: State of the Union

It is understood from the whole set of comments that using relational databases as a de-facto standard is not a good idea but a cruel reality. And I agree.

Question is: Where is the mismatch? The round table topic was actually Java Object persistence. That is, we are talking about where/how to store Java Objects. Application data may be a very different kind of animal, which may not be as easy modeled into objects. Taking from Ted’s phrase “From each technology, according to its abilities, to each project, according to its needs”, some domains may require massive data manipulation that may dictate the need of Relational, Object or even Native XML databases.

This raises two more questions: Is the object modeling capable of handling all kinds of data requirements from the applications? Is it a requirement to persist the object model into a non-suitable data representation? I find several good points in the discussion about these.

To me, it is clear that storing the Objects into any other thing rather than an OODBMS goes against the natural way of how things should be. But it is also clear that Object modeling is not at all suitable for all data necessities. Ted’s idea of hybrid solutions, where there is separation between the Business logic and the Data processing logic (using stored procedures) fits quite well into a model of “Everyone works on what he/she excels” (I blogged of this once, I recall). Of course, it may be hard for one developer to master both SP coding and Java coding. But it is worse to allow an automatic tool handle one of both. I will bet for two developers, each a master in their own world. Same for technology: Modeling the BL solutions in Java and the Data solution in any SQL like language (pick the flavor XML, OO or RDB).

But then, where do I store my objects? A different question from Where do I store my data? I guess nobody things on having two different databases, or even three if XML is involved too! But, then, I see it now as a far away possibility...

Anyway, very interesting points from all of you.
Thanks.

William Martinez Pomares

Thanks for having this discussion; as a practitioner I am happy to see less emotion and more good thought - and good solutions! - around this topic. I would, though, like to comment about the “impedance mismatch” problem.

Ultimately in our applications we're just trying to create and persist some state (data) in such a way that it survives (persists) beyond each execution of our application and can later be retrieved. If this is the only data management requirement then we usually have many simple options available within the application's technical environment, be it OO or otherwise. Therefore, I don't think the “impedance mismatch” concept is relevant to this situation.

More than likely though, there are additional requirements that can be characterized by the need to *share* the persisted state with other applications in a useful way. These sharing requirements appear to belong to one of two technical categories:
1)where the set of applications that wish to share common data already share common type definitions; for example, different cell phone applications sharing a common phone book class.
2)where the set of applications use different types for representing similar data; for example, two Java applications from different suppliers probably don't share a common class definition for a common domain type like 'person'.

The first class of sharing requirements is very well served by using database solutions like db4objects. As long as every application has access to the same type definitions, applications can share domain object state pretty seamlessly. Again, the impedance mismatch concept doesn't really apply here.

It is this second category of data sharing where the impedance mismatch concept applies. If it is correct to characterize the impedance mismatch in these general terms – that is, as being a lack of common type definitions shared by the applications wishing to share data – then the impedance mismatch issue is not just a OO to SQL problem but one that is common to all application integration problems.

I bring this point up because I don't think RDBs should be singled out especially for having this impedance mismatch problem; RDBs ought to be thought of as just like any other application system with an interface through which applications can access their functions and state. Basically an RDBMS is just an application that happens to provide relational style data management functions.

So yes, accessing a RDB requires you to be familiar with SQL and the particular database you're trying to use. And yes, you'll have to somehow map this to your specific application(s). But this isn't any different from, say, working with an ERP system, a web service or some other separately designed application system.

So from this I draw two conclusions:
1.A typical RDB is not a very appropriate object persistence mechanism (and never tried to be). Let's use native mechanisms (like OODBMS) whenever we can in our apps.
2.When we can't, let's characterize whatever mapping layer we'll use instead as an integration component and keep it completely separate from our domain objects. In this regard, I think Neward's suggestion “adding sets as a first-class concept to our programming languages” would make this much easier.

Thanks!