Skip to Content
My first posts focused on pure technology. And I can say that I’m a strong supporter of some, sometimes quite radical, modern and innovative, technological approaches. But, I have to admit, that of course, it depends. Requirements dictate the way project goes, dictate technical decisions. Different projects exist in the industry, with different service and business level requirements and with various levels of project teams. Recently reading Enterprise Application Architecture by Martin Fowler, I once again saw that people have lots of views on how to solve problems. There are tons of methods for skinning one single poor cat. In this post I’d try to focus on the way of bridging the gap between object layer, and database layer.

Look, who’s that? It’s an object. Object, where do you live?
There’s a serious activity going on theServerSide.com (I seem to be constantly mentioning this resource, pardon me) in regard to persistency mechanisms in the next version of J2EE. Latest trends show that lots of people shift their developments to the lightweight component frameworks like Hibernate. People want to persist POJOs, they usually have no desire to invest into CMP or BMP, or whatever else 3-letter acronym you have in mind, unless such technology is already used in the project they work in, or unless they want to play with it. I find this tendency of lightweight approach very interesting. Still, I’m a bit skeptical about OR mapping buzz, because projects I worked in, required a lot of work on the database level, including (oh, no!) stored procedures development and SQL queries tuning (once again, it was before my coming to SAP. Oh good old days! ;)). So, usually I opt for development of custom data mappers (or DAOs, in terms of Core J2EE Patterns), which map domain model into the database and vice versa. This is usually very efficient in all terms, given that your team has no problem with such approach. Of course, ideally, it’d require a dedicated DBA person, who’d watch how people access a database schema. But, approach which Hibernate takes, and which JDO addresses, is very attractive for the projects that don’t require serious database tuning, which don’t have insane performance requirements (telecom sector usually has very serious performance expectations and the same is also true for trading applications in the banking sector). People can just take the tool, tell it – persist my data and that’s it! And people say that some of these OR mappers perform the task really well.

Maaa, look at these cute EJBs!
I don’t understand why CMP&BMP came into existence at all. It’s a heavyweight and hard to wield technologies. But, this pair already had its bashing session, so I wouldn’t repeat what was already said. You can find discussions of this problem all over the web (especially on my favorite resource). Although, Entity Bean zealots are still in the field, so be wary! CMP&BMP in their early days combined remote invocation mechanisms, support for transactions, security, and, of course, persistency. In my point of view, it’s just a big and heavy burden. Anyway, we learn from experience, and experience doesn’t come without mistakes. So, we must be 100% sure that we learn from our mistakes, do not repeat them, and, hopefully, learn from mistakes others make, too. So, what do we have today? Strong reaction from the industry against persistence using CMP or BMP technologies, because it’s simply a biiig overkill. So, before you decide to develop your next project with either of these two, please, check your requirements at least twice.

Strategy? Who needs a strategy?
You have to be very careful about choosing what kind of persistency strategy to take. Numerous amounts of factors would make their crazy dance, and it wouldn’t be simple to make a decision. So, generally speaking, you’d have to choose between 3 levels of complexity:

  • Simple: JDBC, wrappers around JDBC(like SQLJ)
  • Medium: OR mappers, JDO
  • High: CMP& BMP

Existence of Open SQL, on top of which you can run any of these 3 approaches, solves one general problem for you – of portability between databases. It’s a way of doing things, established by SAP quite some time ago. Of course, it gives some certain flexibility to choose database vendor you want, BUT, flexibility doesn’t come without a cost. And sometimes this cost can be simply dramatic. You’re unable to use database vendor’ tricks to optimize your SQL query, like telling Oracle to use this execution plan for the query and not that. And, you’re unable to use stored procedures and triggers. I used to move all logic, related to persisting some data, to the database level. But, very often, you cannot do this, because you have requirement to be portable between database vendors, and so, you have to use Open SQL, which has restrictions against doing such kind of things. So, the only thing that can partially save you is batching of SQL statements, so that each statement wouldn’t end in a roundtrip to the database.

Schema? What kind of schema?
Existence of a number of technologies doesn’t save you from errors in the database schema design. It’s a big mistake to claim that every single developer is able to design tables for the problem domain or application (s)he’s working in. It’s simply wrong. Couple of years ago I thought that I can do database design and write stored procedures and SQL queries. After half a year of work with Oracle DBA in one project side by side I understood that I know nothing about database technology! The guy was doing things with his left hand and closed eyes I was able to understand only after some proper effort. And before that I had a couple of years studying some pretty serious database courses in university! Ok, Java Dictionary and Open SQL abstract you from a big number of problems, but still, a number of basic things must be solved and maintained by a single person per project. So, I would strongly recommend having a dedicated DBA, or at least somebody, who’d be responsible for data model, indexes, keys, etc.

So, persistency problem usually crosscuts the whole project. It’s reflected in the organization of the project team, in the architecture of the solution, in the design, in the way people write code. It’s just something you usually have to think about.

I don’t pretend to have covered the whole Java persistency problem domain. It’s huge. But I hope, this post would at least provide some ideas on the possible ways of bridging your gap between object and database layers.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. David Beisert
    Stepan, thanks for your weblogs I must say I feel totally the same and I think the lightweight approach will win eventually. Why is everything so complicated in J2EE? As in life the simple answers are always closest to the truth. I was also always unhappy with EJB especially Entity Beans because there is no reason I am aware of why you would need them. Spring is also a framework that is a perfect alternative to EJB. I am using hibernate in a project and so far I am very pleased. Keep up your weblogs your last comment was very true as well though SAP is not aware of it. Stored procedures can solve a lot of problems if performance is critical and the database is set.
    (0) 
    1. Benny Schaich-Lebek
      OK David, one question:
      Your application uses stored procedures, mine not. Same logic on my app is on the middle tier. This means that your database machine has more work then mine.
      How long does it take until i outperform you? Remember, when you run out of breath, I can still add machinery to my three tier cluster, which you cannot – because logic is on the database.

      Your concept just doesn’t scale.

      Regards,
      Benny

      (0) 
  2. Dale Seng
    Wanting to separate your database access logic into stored procedures in an attempt to wring every ounce of muscle from your DBMS doesn’t sit very well if you think that keeping all of your entity manipulation in one spot is important (ie think OO concepts are important).

    It seems to me that there are a lot of folks that like stored procedureds for the speed advantage.  I don’t like them because now if something breaks, I have two places to look, two things to test, maybe two development environments, two steps to saving my changes in source control (oops- my sproc and code got out of synch again), etc.  So in order to keep my data access and code together, it would seem logical to use the prepared statement functionality if something was going to get called repeatedly.  I think this technique retains most of the speed advantage, yet keeps everything related to the data in one place.

    The concept of keeping everything having to do with your data access in one spot (or under a unified dev-time umbrella) is one that sometimes gets lost in technology discussions.  With respect to CMP, it’s heart is in the right place, and some day it will get there.  Even today, with the right understanding, and the right wizards, it’s sort of okay (not exactly a ringing endorsement, eh?).  But there seems to be agreement that it’s hard (impossible?) to be a really good DBA and a really good coder.  Why not let the DBA do that they do best, and have the coders stay the heck out of the DBMS-specific layer?  If that means we put some better smarts in how a generic SQL is optimized for a specific platform, then we need to push in that direction instead of trying to keep a foot in a world where the door is closing.

    –Dale–

    (0) 

Leave a Reply