10 important things using Hibernate/JPA

1) Become friends with the DBAs.

There is a tendency for some Java developers to marginalize the importance of DBAs. This is a huge mistake - a good working relationship with the keepers of the data is critical to success with any ORM technology. This is important for two reasons:

• DBAs alone usually can’t make your Hibernate efforts successful, but they often can make them fail.
• They usually have really good insight into the database itself, good modelling practices, and any pitfalls or shortcuts for you. I can think of several instances where a timely suggestion from a DBA saved us days and gave us an elegant solution.

In most cases, having good DBAs and having good relationships with them is highly critical to the success of your ORM efforts. Plus, database guys are usually pretty cool people :)

2) Use (and enforce) good naming standards from the beginning.

Who knew naming standards discussions could be so contentious? One of the things we try to accomplish with ORM tools is to make our data model more meaningful, which makes it easier for developers to use and helps avoid confusion. To this end, how we name entities and attributes is very important. I have naming standards I like and think are best, but I won’t try to push them on you here. The important thing is that you decide on something upfront and get everyone to use it. Actually, this should extend beyond just naming standards and should be inclusive of other standards as well (ie, Boolean vs “Y/N” or 0/1, primitive vs Object, Integer vs Long, etc).

3) Don’t try to map every attribute (and association).

We started out trying to use tools like Dali to map everything on a table quickly (some tables had several hundred columns!). This turned out to be a bad idea. Why? Since we were on a shared, legacy database, there were a ton of fields we didn’t care about and never used. Mapping them led to performance issues and confusion.

4) Let the database do the things it is good at.

We really wanted to have a good, clean data model, and so we avoided at all costs writing extra queries to fetch things pertinent to an object or using stored procedures or functions at all. This was also a mistake - databases are good for stuff other than just holding the data Hibernate creates and reads :) For example, we had one object that had a status associated with it. The status was used all over the app so it had to be performant, but we also didn’t want to have to make a separate query every time we needed it. The problem is, the status was derived based on some calculations that operated on several one-to-many relationships. Pulling back all that data as part of each load of the object would have been way to expensive. Working with one of our database guys (see #1), we found a sql function we could use to get the status very quickly. We mapped this to a status attribute using @Formula and had everything we wanted - it was part of the domain model still, and was very performant. Sometimes little compromises like this can yield big dividends.

5) Break up the database.

When we first started, I wanted to model the whole databse in Hibernate at the beginning. This turns out to have been really impractical for a few reasons:

• a) It was a huge job and would have consumed weeks of time while the customer would have seen no actual work being done.
• b) I was unlikely to get it right the first time, meaning developers would have to change it anyway as we got started.

There is a tendency to want to map the whole thing out before starting, but a lot of times you just have to work on it as you go. I did find it useful to break it up into pieces and try to do a whole piece at a time as we went - which really seems to have helped.

6) Watch out for triggers.

Watch out for database triggers for two reasons:

• a) They can do sneaky things behind the scenes that can lead you to pulling your hair out, wondering what happened.
• b) Sometimes they do stuff that you need to replicate on the Hibernate side. Several times before we fully learned this lesson, we missed some important things that triggers were doing and almost caused ourselves some real grief.
  

7) Shy away from tools to auto-generate your model.

Yeah, they can save time (although we found Dali to be terribly buggy at the time we used it), but you end up having to re-do a lot of it anyway. It doesn’t take that long to map them by hand, and it gives you a chance to familiarize yourself with the data more as you do it.

8) Use NamedQueries where you can.

It is easy to just pound a query out in-line, but in a lot of cases it is better to use NamedQueries. This helps to do two things:

• a) It fosters more re-use, since the named queries are generally located in central places in the code.
• b) Your queries get validated on startup, making it so errors in the queries (especially down the road when they can get messed up by model or table changes) discovered much more quickly.

It sometimes takes a bit of getting used to (and strong-arming!), but it is worth the effort.

9) Manage Expectations.

This is probably important to keep in mind for any new framework, technology, or even concept. For some reason, people tend to get sold on certain features that simply don’t exist, or are highly exaggerated. Sometimes it is small and understandable (ie, underestimating the actual work required to map stuff in Hibernate), and sometimes I have no idea how they came up with such ideas (ie, that Hibernate can somehow manage schema revisioning). At any rate, finding out what the expectations are and then managing them can be really important. If your team thinks that Hibernate will make DBAs completely obsolete (usually quite false) and fires them all, you will probably have a big problem on your hands.

10) Use rich domain modeling.

One of the sadder things I’ve seen with projects that use Hibernate (and in some cases, I’ve seen it because I’ve done it!) is when the domain objects become no more than simple containers of data. The goal of tools like Hibernate is to let us use data in an object-oriented fashion - simply mapping the data only gets us halfway there. As I’ve made conscious efforts to practice rich domain modeling, I’ve noticed that we reuse a lot more code, our other layers become less cluttered, and our code is more testable and easier to refactor.

Source: SpencerUresk

Acegi Security for Spring Framework

Acegi Security provides comprehensive security services for J2EE-based enterprise software applications. There is a particular emphasis on supporting projects built using The Spring Framework, which is the leading J2EE solution for enterprise software development. If you're not using Spring for developing enterprise applications, we warmly encourage you to take a closer look at it. Some familiarity with Spring - and in particular dependency injection principles - will help you get up to speed with Acegi Security more easily.

People use Acegi Security for many reasons, but most are drawn to the project after finding the security features of J2EE's Servlet Specification or EJB Specification lack the depth required for typical enterprise application scenarios. Whilst mentioning these standards, it's important to recognise that they are not portable at a WAR or EAR level. Therefore, if you switch server environments, it is typically a lot of work to reconfigure your application's security in the new target environment. Using Acegi Security overcomes these problems, and also brings you dozens of other useful, entirely customisable security features.

As you probably know, security comprises two major operations. The first is known as "authentication", which is the process of establishing a principal is who they claim to be. A "principal" generally means a user, device or some other system which can perform an action in your application. "Authorization" refers to the process of deciding whether a principal is allowed to perform an action in your application. To arrive at the point where an authorization decision is needed, the identity of the principal has already been established by the authentication process. These concepts are common, and not at all specific to Acegi Security.

At an authentication level, Acegi Security supports a wide range of authentication models. Most of these authentication models are either provided by third parties, or are developed by relevant standards bodies such as the Internet Engineering Task Force. In addition, Acegi Security provides its own set of authentication features. Specifically, Acegi Security currently supports authentication with all of these technologies:

• HTTP BASIC authentication headers (an IEFT RFC-based standard)

• HTTP Digest authentication headers (an IEFT RFC-based standard)

• HTTP X.509 client certificate exchange (an IEFT RFC-based standard)

• LDAP (a very common approach to cross-platform authentication needs, especially in large environments)

• Form-based authentication (for simple user interface needs)

• Computer Associates Siteminder

• JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign on system)

• Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)

• Automatic "remember-me" authentication (so you can tick a box to avoid re-authentication for a predetermined period of time)

• Anonymous authentication (allowing every call to automatically assume a particular security identity)

• Run-as authentication (which is useful if one call should proceed with a different security identity)

• Java Authentication and Authorization Service (JAAS)

• Container integration with JBoss, Jetty, Resin and Tomcat (so you can still use Container Manager Authentication if desired)

• Your own authentication systems (see below)

Many independent software vendors (ISVs) adopt Acegi Security because of this rich choice of authentication models. Doing so allows them to quickly integrate their solutions with whatever their end clients need, without undertaking a lot of engineering or requiring the client to change their environment. If none of the above authentication mechanisms suit your needs, Acegi Security is an open platform and it is quite simple to write your own authentication mechanism. Many corporate users of Acegi Security need to integrate with "legacy" systems that don't follow any particular security standards, and Acegi Security is happy to "play nicely" with such systems.

Sometimes the mere process of authentication isn't enough. Sometimes you need to also differentiate security based on the way a principal is interacting with your application. For example, you might want to ensure requests only arrive over HTTPS, in order to protect passwords from eavesdropping or end users from man-in-the-middle attacks. Or, you might want to ensure that an actual human being is making the requests and not some robot or other automated process. This is especially helpful to protect password recovery processes from brute force attacks, or simply to make it harder for people to duplicate your application's key content. To help you achieve these goals, Acegi Security fully supports automatic "channel security", together with JCaptcha integration for human user detection.

Irrespective of how authentication was undertaken, Acegi Security provides a deep set of authorization capabilities. There are three main areas of interest in respect of authorization, these being authorizing web requests, authorizing methods can be invoked, and authorizing access to individual domain object instances. To help you understand the differences, consider the authorization capabilities found in the Servlet Specification web pattern security, EJB Container Managed Security and file system security respectively. Acegi Security provides deep capabilities in all of these important areas, which we'll explore later in this reference guide.

Source: Official Reference Guide

Interview with Gavin King, founder of Hibernate project

Gavin King is the founder of the Hibernate project, a object / relational mapping framework for Java. Currently, he works full time in the project, paid by the JBoss Group. In this interview, Gavin King talks about his entering in the JBoss Group, and the Hibernate Project, what's new in version 3 and the integration of the framework with the new features of Java 5.

1. Please, tell us a little about yourself and your 'real' job.

I live in Melbourne, Australia and I've been working in IT - mostly Java - for about five years now. For the past year my "real" job has been Hibernate. I'm a rare example of a developer who is paid to write open source software. In fact, myself, Christian Bauer, Steve Ebersole and Max Andersen now all work for JBoss, developing Hibernate and providing commercial services. I'm also an active member of the JSR-220 (EJB 3.0) spec committee.

2. In your opinion, Hibernate become so successful?

Hibernate became successful because it solves a very common problem reasonably elegantly, because it is an open source solution, and because it is practical. We took seriously the idea that OO and relational technologies should work smoothly together. And we allowed our project to be driven by user requirements. We also knew that great technology is useless if you can't explain it.

3. What was your main motivation when you created Hibernate?

I wanted to solve an interesting problem, a problem that affected me personally. I was frustrated with working with EJB 2 style entity beans and brittle handwritten persistence layers.

Also, I wanted to win an argument with my then-boss; -)

4. What benefits your decision of joining the JBoss Group may bring to the Hibernate project?

In the long run, it's simply not possible to do a project with the scope of Hibernate in your spare time. By the time I joined JBoss, I was spending so much time responding to questions from users and fixing minor bugs, that there was no time left for sleeping, let alone improving Hibernate. So working for JBoss has made it possible for Hibernate to continue to exist and grow. It also allows us to actually get out there in the field, speaking at conferences and JUGs, working on site with Hibernate users, and participating in the JCP.

From the point of view of Hibernate users, they get not just a better product (due to having four fulltime developers), but also the opportunity to get training and buy 24 / 7 production support. Not everyone cares about these things, but a lot of people do, especially in larger organizations.

5. How do you see other ORM tools like OJB, JDO and Toplink? Do you evaluate or spend time looking at feature of those products? Why people would choose Hibernate?

Um, traditionally, no, we did not pay that much attention - I was much more comfortable being guided by request from users, than by "what the other guys got". However, more recently, we have done some feature-by-feature competitive evaluations of the two leading commercial ORM solutions, just to make sure we didn't miss anything. This has had some influence upon the feature list of Hibernate3, where there are a couple of features that I would describe as being more useful for marketing than for practical purposes.

The Hibernate3 core is the most powerful ORM engine in the world - and it will take a little while for others to catch up. However, we've realized more recently that there is more than just the runtime engine to think about and over the next year there will be a lot more focus upon polishing and in some cases rewriting our development-time toolset. Max is leading that effort. Hibernate will evolve into a suite of products that address the whole problem of writing Java applications which use relational data.

6. How do you see alternatives to relational databases, like XML and OO databases, or Prevayler?

We don't see them; -)

Truly, the relational data model is a wonderful innovation, and it would be an absolute disaster to replace it with flawed persistence technologies like XMLDBs or OODBMS. Fortunately, that simply won't happen, since there is simply no industry interest or momentum behind either.

Technologies like OODBMS sacrifice sound, application technology agnostic data management for sort-term convenience (convenience for one single application, written using one particular programming language). Relational technology essentially completely replaced network or hierarchical database technology, and there were excellent reasons why that happened. We should most certainly not be reviving either of those discredited approaches by slapping on the latest buzzwords (OO, XML, etc) as window dressing.

7. Are there any changes you would like to see in the JDBC API to make Hibernate better and faster?

It would be great to be able to batch together different SQL statements using the JDBC batch update API (at present, you can only batch multiple parameter sets for the same statement).

However, rather than seeing many new features in JDBC, I would be incredibly happy if vendors would simply provide complete, reliable implementations of the features that are already there in JDBC 3. It's actually quite disgraceful how broken the JDBC drivers of certain big-name RDBMS vendors are. They don't seem to care.

8. Is there any plan to make Hibernate compliant with the JDO Spec?

No. Hibernate will provide an implementation of the EJB3 EntityManager defined by the JSR-220 specification. Sun has just announced that the scope of JSR-220 will be expanded to cover operation outside the traditional monolithic J2EE container.

We don't see any future for JDO.

9. Do you foresee the upcoming release of EJB3 reducing the need for Hibernate? Are there any benefits of using both, like in a BMP environment?

EJB 3.0 is a specification. Hibernate will be an implementation of that specification. So you can use both at the same time; -) Alternatively, we intend that some people, who don't care about standards as much, will continue to use Hibernate-specific APIs, especially for functionality that is not yet standardized by JSR-220.

10. Could you tell us about what's new in Hibernate 3, and the benefits these changes will bring to users?

The biggest, most innovative new thing is the support for parameterized "filters". This feature let's you see an object graph that is just a subset of the total data in the database. This is incredibly useful when dealing with temporal, versioned, regional, or permissioned data. In fact, I expect that most business domains have usecases for this feature and that it will soon be considered an indispensable feature of Hibernate.

We have done a huge amount of work on adding greater mapping flexibility, to support more complex (or even broken) relational models. This takes the form of a number of small new features, that are really most significant when taken together. Hibernate is now able to handle just about any crazy thing you are likely to find in a legacy database.

In addition, it is now possible to override any SQL statement that Hibernate generates with your own hand-written SQL. This gives your DBA the freedom to hand-tune the SQL when necessary.

Some further major changes in Hibernate3 were designed to align us more closely with JSR-220.

Finally, we put a huge amount of thought into what small changes we could make that would make Hibernate easier to use for beginners. Hopefully that will reduce the incidence of certain FAQs in the Hibernate forum!

11. How about Metadata in Java 5.0? Do you have plans to support it? It is a real alternative to hbm.xml?

Absolutely! Emmanuel Bernard is working on implementing the EJB 3.0 ORM metadata for Hibernate, and adding Hibernate-specific extensions.

We've seen how many people like to use XDoclet annotations to express their Hibernate mappings, and so I'm quite certain that even more people will feel comfortable using JSR-175 annotations.

In fact, I fully expect that this will be the most common way to use ORM in the future.

12. How can Generics change our Hibernate code?

Not a great deal. Hibernate can already persist templated collections, so you can get a bit more strongly typed in your domain model. Templated collections could even help Hibernate guess the type of an association and reduce the amount of metadata you have to write. However, I don't think this is an especially significant new feature in the context of ORM.

13. Which of Tiger's new features are more likely to be used in the Hibernate code base in the future? Why?

Well, we are a bit stuck. We can't use many of the new features, because Hibernate needs to stay source-level compatible with older JDKs. The annotations stuff is okay, because we can provide it as an add-on package.

Certainly, annotations are the most significant new feature of Java 5, and it's very likely that they will completely change the way we write code.

14. What do you do in your free time?

Retail therapy.

Source: www.javafree.org