If you are going to be at RMOUG Training Days, be sure to come by Room 401 on Thursday, February 16th at 2:45. 

Let’s start with a disclaimer – there are few perfect things and I don’t claim this is one of them, I just know that this works really well and I hope it helps someone else. I also don’t know if anyone’s named this pattern already. If so, let me know. If there are any suggestions for better names, like “Lightning Bolt,” I’m all ears.

The Problems this Pattern Solves

Typically in a J2EE project involving Hibernate, the developers will encounter a situation where there are two or three conflicting needs. If they’re not specifically in conflict, these needs at least make the job a little difficult.

On one hand, there is a need to tune the Hibernate settings of an Entity bean to perform well in queries and take up minimal memory while executing the least number of sub-queries. On the other hand, there is a need for the Hibernate object to be editable and serializable in its original form, meaning that in some cases all data must be available and non-lazy. A third possible need is that somewhere out there is an Oracle/SQL Server/MySQL etc. DBA who is going crazy trying to tune for all the different ways Hibernate is generating queries. While each of these problems is reasonable on their own, solving all of them simultaneously (while doable,) takes up more effort than it should.

In other words, the following pattern allows the developer to solve all three problems with minimal effort on his or her part and minimal effort on the part of the DBA. Everybody’s happy, though I have heard complaints from Java purists. My response to purism is usually the same, whether it’s over-normalizing a database or writing software: “Purism and strict adherence to design doctrines are a means to an end, they are NOT the end. The end result should be cost effective deployment of a working application that can be maintained.” Sometimes I don’t actually say all of that, I may just mutter under my breath and go to refill my coffee.

How this Pattern Came to Be

Having been the software architect on several efforts where the above problems manifested (including one where Hibernate staff were involved and liked the approach,) this really didn’t become a standard until I was exposed to Oracle ADF. I like ADF quite a bit, it is a very short path to delivery and to a developer or business owner that means some good things. What caught my eye was that the ADF framework separated Entity objects from View objects. In ADF, an Entity object represents a table just like a Hibernate POJO usually represents a table. However, Entity objects proper are hardly ever shown in Lists of Values, Search results and so on. Instead, ADF abstracts the Entity objects with View objects. An ADF View object allows a layer of complexity or simplicity to built on top of one or many Entity objects, or it can be built using only a query as its source.

I decided that if it were a good idea for a core product and I’d made a similar concept work in my past projects, then maybe it was time it became a well defined solution to the aforementioned problems. The solution below isn’t exactly like ADF’s pattern. With ADF, View objects make reference to the underlying Entity objects. In the following pattern, we make an effort NOT to.

What it Is

The concept is very simple in practice. Hibernate mappings and beans are created as usual. However, when it comes time to run queries or search for data, a separate object is used. This second object is a Hibernate object that is not mapped to a table. Rather, it’s an object that includes one or more native SQL queries which alias columns. This has several benefits.

1. A DBA can easily tune queries that return more than one result
2. The Hibernate persistence context doesn’t need to track changes to the objects
3. The objects are immediately detachable without ever needing to worry about lazy loading.
4. The original entity can be tuned for any kind of eager or lazy fetching. This is especially useful if one isn’t using (or doesn’t want to deal with,) an  OSIV pattern.

To get these benefits, a few simple rules must apply to the View/DTO object.

1. Don’t map the object to a table
2. Don’t create more than one hibernate object to represent query results -in other words, NO relationship objects. No many to ones, no one to many… you get the idea.

There may be obvious exceptions to these rules and these are just the broad strokes. Usually when I implement this pattern I create a common abstract method in the View object that will allow a developer to get back a valid Serializable key for use in opening up a real Entity object for editing. In my implementations I usually call that method “getEntityPrimaryKey()” which returns a Serializable. Then I just pass that result to a simple Hibernate get or load operation and work with the Entity.

To reiterate: the purpose here is allow for peaceful coexistence between DBA approved queries, possibly massive search result tuning for various displays and individual tuning for editable objects.

How you choose to implement the pattern is up to you, but if I receive a few requests for examples, I’ll gladly post them here.

1.  Search/Edit Patterns

First of all, as I've mentioned many times, modernizing the application provides a chance to modernize the workflow a little bit.  Ultimately you would want to go from data-oriented views to task-oriented views, but often in the interest of time and budget, the customer sticks with the data-oriented views.

Even when staying with data-oriented views, however, it makes sense to think about redesigning the workflow slightly.  Most form applications allow search and edit on the same screen, when modernizing it makes sense to split these into search and edit screens.  No matter how you do this, make sure you come up with how it will be done for the basic types of screens in the application.  Ideally you would want to create mock-ups for each page to demonstrate layout and flow, but unfortunately, this is now always something that can be budgeted for.

2. Keyboard Shortcuts

Many client/server applications make use of keyboard actions.  Typical in a forms application, is to have one keystroke for insert, for instance, and the application will determine the data block to be edited based on the component that has focus.  While this can be done in web applications, it isn't usually the preferred method.

3. Transaction Handling

Transaction handling will most likely be different when you are using an application server.  Interaction with the databse should be done through a pool of database connections set up on the server, this reduces the load on the database but it also means that transactions should be made shorter.  If a longer transaction is needed to accomodate the business process it will be necessary to either code the transaction handling and state management manually or make use of a framework that supports longer transactions such as ADF or Seam.

4. Pop-ups vs. Drop-downs

Most web applicaitons make use of drop down lists to provide selection lists to users but older legacy applications often made use of pop-ups.  Decide ahead of time which to use and when to use them.

5. Mixed Case Data Entry

Many legacy applications converted text input from the user to uppercase before storing it in the database to make future comparisons easier.  These days the amount of processing required to ignore case when search or comparing is minimal and the conversion not necessary.  Should the modernized application take advantage of this?

6. Security

Often, in legacy applications, security is handled through database access.  In modern applications, database access is normally handled via a pool of connections maintained by an application server.  This makes handling security the same way not feasible.  Instead, consider using the tools your application server provides for security or some sort of Single Sign On.

These are just a few of the design decisions that need to be made before starting a modernization project regardless of the architecture and frameworks chosen for the new application.  Before you embark on such a project, make sure you understand the changes that will need to be made and the implications of those changes on the customer base.  Try to get buy-in from the customer-base ahead of time, potentially using a POC or Mock-ups to convey the changes when appropriate.

In this particular instance, converting the logic from an exisitng form to an ADF application, there was a master-detail relationship on the page.  When the user created a new master record and then attempted to create a new detail record, the JBO-25030 exception would be thrown.  What I found when investigating this was that if the user saved the master record first, then added a detail record, everything would work as expected.

Investigating further revealed that there was a primary key on the master record that was not updateable by the user.  It was generated by a trigger on the database table.  Since the primary key could not be validated when the child record was to be created, the exception was thrown.

This type of issue is easily overcome by putting the logic to get the new primary key (in this case from a sequence) in the ADF Code and removing the table's trigger.

My last post in this area was about how Apple beat Oracle and Google, referring to their control over the hardware and the software in their business.  It now appears that Google agrees and decided to do something about the situation by purchasing Motorola.

While some articles have pointed out that Google is both alienating it’s friends, and bolstering it’s enemies, others have pointed out that this gives Google the control it needs to make Android a success.  Hopefully this will give them a hardware platform that can keep up with releases of the software and provide a consistent less bug-prone environment for Android to shine in.  If this alienates some previously Android friendly companies such as Samsung and Sony, so be it, it may just help them keep up with Apple.

Of course the mobile platform is just one industry that Google will now have a hardware presence in.  Motorola does produce a great many cable boxes which means Google TV may have found a new platform to shine on as well.  While I love my Tivo, I am curious to see what Google may do in this arena in the future.

I should mention, in regards to my last article, that though Sun did provide the hardware platform and the software for Java to grow, they never had any kind of pull in the desktop arena, though they did try.  Sun and Java did become a very popular combination for supporting web applications.  Oracle has also pointed out that one of their reasons behind the Sun purchase was to provide a hardware platform to support their database.  The Exadata hardware/software combination is a great example of this ability Oracle now has to control the entire environment.

The trends certainly seem to indicate that while open specifications and standards are great in some areas, it is easier to move forward when both the hardware and software can work together closely.

Working in the field of software modernization and being specifically focused a lot of the time on modernizing client/server applications, that is, bringing native applications to the web, I couldn't help but wonder if we haven't come full circle already.  

Many years ago with Sun's release of Java as the write-once, run anywhere answer to every developer's problems, it looked like Java Applets might be the wave of the future.  That never did quite catch on as Sun had hoped.  It was plagued mainly by the practical problem of having a platform that runs on every operating system in the same if not very similar fashion.  Because of this "feature", the platform could be limiting at times.  I believe that this type of limitation and the advance of dynamic HTML, CSS, and the web platform in general led to a huge number of web-based applications and a very small number of Java client applications.

Fast forward from then to now and Apple has taken a lesson from Java and decided early on to do things the "right" way.  Of course, the "right" way means being in control of the hardware platform as well as the software platform.  Because Apple controls the whole environment, "apps" are less likely to break, testing is simplified quite a bit, and even development to some extent is simplified.  The result is the creation of some truly amazing client applications for consumers.

Google's Android is a player, but it is starting to suffer from what Java suffered from.  I am not an Android user, but I have seen the complaints that some applications are only supported by newer versions of the software but some hardware platforms do not support the newer version.  This comes across as an Android problem, but surely Apple has the same problem with their platforms?

For some reason, when I can't get an App for my iphone 3G because it doesn't sport the right hardware, it feels like MY problem for being 3 years behind the technology.  That's probably because it isn't just a hardware compatibility issue, the device itself feels clunky and dated compared to newer versions of the iPhone.  Android hardware is so varied and different that the same comparison really cannot be made unless it is among one manufacturer.

Anyway, my point is that Apple has created this beautiful sandbox where these great apps can be created that use the web, but are not web applications.  They are client/server applications with the server being multi-tiered now.  Just look at the articles that have come out regarding iCloud and the amount of app traffic vs. web traffic.  iOS is really what Java should have been.

We haven't seen the push at the Enterprise level yet.  Most customers want a web application, a more and more sophisticated web application, but still, not native apps.  More and more, however, companies are looking at iPads as tools for their workforce and once that happens, their new apps are going to be native iOS apps.

Now the big question remaining is what is Oracle going to do about it?  Does Java have a chance or has it's time passed?

In the Dynamic Forms and Tables in ADF presentation I learned that you can create a basically empty ViewObject (by basing in on something as inane as "select 1 from dual", and then in your Application Module you can create whatever query you want by using the createViewObjectFromSQLStatement method and passing in your SQL.  This is a clever idea and I can see some use for it, especially in reporting type screens, but currently the implementation is a little limited.  You can create a Dynamic Table to display the results, but the table cannot have sorting or filtering enabled, which, for a lot of the ADF applications we build, would make those screen noticeably different than other screens.

In a presentation about developing products I learned that Oracle MDS can be used to hold customized information for a specific implementation of an application.  That is a very useful feature for ISVs.

A presentation about Javascript in ADF taught me that if you want to use it, you should manipulate the UI Component Model and not the DOM or the "Peer Objects" that would also be available but may not staty consistent.

Finally, in addition to learning that a new utility for creating custom skins is being developed, I learned that if I put a parameter called "DISABLE_CONTENT_COMPRESSION" in my web.xml and set it's value to "true", Firebug would be much more useful in helping to create skins.

One of the most important things I learned is that some things you just don't find out unless you attend these conferences.  You could spend your entire career with a product like JDeveloper and not know all the tricks, especially the undocumented ones, but one trip to a conference like UKOUG and you could at least pick up a few of them.

In the past I have done presentations on why converting to ADF is a good idea.  This time I will be focusing less on the why and more on the how so it is bound to be a more interesting presentation for those who are actual Forms or even ADF developers.

One of our staffers will be re-posting the content from the old blog up here on the new site, so you will be sure to see a lot of recycled content in the coming weeks, but after that, we'll be on to the new stuff.

So with our technical issues now behind us, we will continue to delight and enlighten you with our vast knowledge of Java, ADF, XML and other enterprise technologies!  Be sure to visit frequently and comment often!