RMOUG Training Days 2012

I will be co-presenting at RMOUG Training Days with Jigar Parsana on the topic of modernizing Oracle Forms to a Struts 2 / Spring / Hibernate solution.  We will present a case study and a comparison between this "open" framework and Oracle's ADF framework.

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

A Pattern for Development: ORM Reverse DTO Pattern

The following issues and solution are fairly common in a modernization effort, especially when porting from an older system where complex queries already exist and no one wants to change them or tune for other scenarios. While this may not apply to your software effort, it does ease a lot of pain when solving certain niche problems.

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.

Design Considerations When Modernizing Legacy Apps

We have done a lot of modernization projects over the past few years, mostly modernizing Oracle Forms applications to a Java web type platform such as JSF or Struts.  What we have learned over the years is that one aspect that all of these projects have in common is that making some design decisions at the beginning of the project is really important.  Even though customers usually say, follow this style guide, this architecure (or we suggest both), and do the rest as the existing application is, they don't usually realize that there are additional requirements or considerations.

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.

Another JBO-25030 Problem

Chris Muir has a good article explaining a typical JBO-25030: Failed to find or invalidate owning entity problem.  Recently, however, I came across another atypical reason for the same error.

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.

Google admits I was right, buys Motorola

Ok, so maybe a little hyperbole in the headline, but Google may have admitted that Apple, at least, had it right.  A lot has been said about the Motorola purchase and it's implications for the bubbling patent wars but could this purchase represent more than that?

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.