My company runs a technology forum for its members every month (hosted by my lovely wife).  Tonight’s talk was entitled “Where’s the SQL?” and consisted of a discussion about whether the SQL logic should live in the application, the database or split between the two.  It turned out to be a very calm discussion about treating data as a service and abstracting its retrieval away from the application rather than placing prepared statements or dynamic SQL in the application code.  We discussed the use of ORM tools like Hibernate or iBATIS and how these tools fit within the concepts of separating data access from the application.  Obviously we came to no hard agreement, since we had OO developers and DBAs in the room, but there was one thing that was said (by a Java developer in fact) that struck me as wrong.

I asked how tightly bound to a given database vendor you’d be if you chose to use stored procedures and other database-resident methodologies for accessing data.  The answer was pretty much what I was expecting - that there’s a fairly tight coupling between your SQL and your database vendor.  There are tools that can help you migrate, but it seems like you’re stuck rewriting a fair amount of code (multiple people in the room have migrated from Sybase to Oracle and that seemed to be the universal experience).  One developer made the comment that you should consider swapping database vendors to be the equivalent of switching languages - from Java to C# for example.  While it may be true, this feels wrong to me.  I don’t want to be tied to my database any more than I want to be tied to my application server.  I want the flexibility to move from Oracle to MySQL if the license costs get too much for me - and I don’t want to have to rewrite my application if I choose to move.  I wouldn’t accept a full rewrite if I moved from WebSphere to WebLogic - why would I accept it at my database tier?

I think this lock-in is what makes me most nervous about putting large portions of my code at the database layer.  There are clearly times when it’s necessary - whether for performance reasons or because the logic is being invoked outside of the calling applications, in a batch for example (although you could definitely make that work in Java, perhaps with Spring Batch) - but I don’t think I’d feel comfortable committing to one database vendor for essentially the lifetime of my data.  Using ANSI standard SQL and putting my logic in my application tier essentially protects me from that.  My gut feel is that the cost is worth it in the long term, but I’m not sure if others (including my customers) see it the same way.

Like all good developers, I’m lazy. I follow the DRY principle.  On my current project, that means using our Oracle schema as the design of record, and then using iBATOR to generate our DAOs and transfer objects.  It also means extracting documentation out of Oracle.

One of my co-workers, Phil, found a very nice tool called Oradoclet that grabs the metadata and code from an Oracle database and outputs it in a Javadoc like form (see the example).   Unfortunately, it’s limited to Oracle, and apparently hasn’t been maintained in a few years.

It works quite nicely for our purposes now, and Phil and I are talking about reviving the project to expand it to other databases.  Our ultimate goal (a long way off) is a project-wide meta-data management system, that links the Java elements to the database objects (and ideally to requirements, UI screens, etc.)  We’ll see how that turns out.

After going into a demo blind last week (bad idea!) and having our application fail on the demo laptop (big surprise!), I had to figure out why our application completely refused to work using Internet Explorer 6.  Turns out that IE 6 is totally flummoxed by the HTML <button> tag.  If you have more than one a page, IE submits all the buttons - so in our case, the last one was winning.

I had forced Apache Beehive to display all the buttons using the <button> tag so I could take advantage of setting a global style.  Obviously that was now out of the question.  I had to switch back to using <input type=”button”> tags (by removing the Beehive attibute renderAsButton=”true”) and apply a style to each of them.  Crisis averted, but only after an embarassing incident in front of the customer.

P.S. The problem is resolved in IE7 - where we’d been doing all of our IE testing.

In one of my current projects, my application has some pretty strict security requirements.  It’s designed so that only a small piece of the functionality is available to external users, while the full application can only be accessed by internal and partner users.  To ensure that the line isn’t breached, we’ve set up two parallel environments - the private side runs on the same servers as the rest of the internal applications with the public side isolated from the more secure internal applications.  This isn’t really anything that out of the ordinary.

Obviously we’ve got authentication and authorization procedures on the public side to ensure that users only see only what they’re allowed to see.  But is there a way to be even safer?  What if our public application included only the functionality that the public can see?

That’s exactly what we’ve done.  Our build script, which I’ll cover in more detail in a future post, allows us to declare Java packages to exclude from the public application package.  In the build.xml for each project, we optionally include an Ant property called “exclude.public” that contains a comma separated list of packages to exclude.

<property name="public.exclude" value="com/mycompany/myapp/packagea/**,
              com/mycompany/myapp/packageb/**,
              com/mycompany/myapp/packagec/**"/>

We’re using the Ant-contrib library to get real conditional logic within our Ant scripts, to make it easier to provide a default value for our properties in case we’d like to publish the full application.

    <target name="public-only">
        <if>
            <isset property="exclude.private"></isset>
            <then>
                <property name="excluded.files" value="${public.exclude}"/>
                <property name="dist.subdir" value="public/"/>
            </then>
            <else>
                <property name="excluded.files" value=""/>
                <property name="dist.subdir" value=""/>
            </else>
        </if>
    </target>

If we indicate we only want to build the public application, the public.exclude property becomes the value for the “excludes” attribute of the javac task - completely removing the code from the public application.

<javac srcdir="${src.dir}" destdir="${classes.dir}"
        classpathref="lib.path.id" debug="true"
        excludes="${excluded.files}"></javac>

Since the final package doesn’t even contain the dangerous code, we’ve made it impossible to execute even if all our other security fails us (unless of course we deploy the wrong package to the server).