Java Hair

It looks like my abstract was accepted to be presented at Collaborate 09 coming up in Orlando in May this year. As the schedule stands now my session will be first thing Monday morning (first thing being 10:45 thankfully!), which leaves me the rest of the time to see what’s new in the world of Oracle and Oracle Users.

In case you haven’t heard of it, as their website says: “COLLABORATE 09 helps users of the full family of Oracle business applications and database software gain greater value from their Oracle investments. Created by and for customers, COLLABORATE 09 offers an expert blend of customer-to-customer interaction and insights from technology visionaries and Oracle strategists. Expand your network of contacts by interacting with Oracle customers, solutions providers, consultants, developers and representatives from Oracle Corporation at COLLABORATE 09.”

So if you are going to be there, be sure to stop by my session and say hello.

Though this blog typically contains how-to’s and editorials and Java and ADF related topics, it is supported by my company, Vgo Software, and so I occasionally need to plug one of our products.  This post is one of those, so read it at your own risk.  However, if you are working in a company that works with Oracle Forms in addtion to Java or ADF, I encourage to read it, you may find it of use to you.  If you have no idea what I’m talking about, feel free to skip it.

Many of our customers over the years have asked us that very question about their Oracle Forms applications.  As a provider of tools and services to help customer modernize their forms applications we took the opportunity to develop a product that would help answer this question.

Forms is a 4GL developed by Oracle that has been around for many years.  I first started working with Forms in version 3.0 about 15  years ago.  At that time I was working in the IT department of a chain of supermarkets.  All of their accumulated data was stored on a mainframe, of course, but each store had a couple systems running on IBM servers that ran an Oracle database and Oracle Forms.  Part of my job consisted of making fixes and enhancements to those applications.

What I found, as did many others, was that Oracle Forms was a very easy way to create applications that were based on an Oracle database.  As a developer I could create a Block based on a database table, provide some validation triggers and a couple of buttons, and voila!, a user could now input validated data into a table.  Master-detail relationships were also simple to create.  Interaction with other systems was more difficult and typically done via Oracle Pro*C programs run by shell scripts.  One application I worked on synced data from a handheld device to the store’s database using a C program, that was probably one of the more interesting applications I worked on then.

As I moved on in my career, I lost touch with Forms, but came back to it many years later.  In a later job, I was asked to research communicating with a Java server-side application from a Forms Client/Server application.  If I remember correctly, the implementation included creating an Active-X control (or was it COM back then, I can’t remember?) that was embedded in the form and could make a call to an EJB on a Weblogic server.

Forms has come a long, long way since those 3.0 character-mode days, and even from those Client/Server days.  As Oracle Forms has evolved, so have the applications that customers have created with them.  Working in the business that I am now, modernizing forms applications, I have seen plenty of forms applications ranging from relatively simple applications that consisted mostly of Blocks based on tables, to incredibly complex applications that never tie a block directly to a table but instead us a Control Block to capture user input and then run some complex logic on it both in the form itself and on the database server through complex stored procedures and functions.

What we found when we first started out, was that everyone has their own idea of what is simple and what is complex.  In order to deal with that and improve our ability to estimate the amount of work required to complete a project, we developed into our modernization tool a function that analyzed what we perceived to be the complexity of any given Oracle Form.  As we did more of these projects we realized that there are many customers out there with Forms applications that have existed for so long and been developed by so many different people that they themselves have no idea of what those forms consist of.

Evo ART is a product that we started about a year ago.  It is an Analysis and Reporting Tool for Oracle Forms applications.  It is written in Java and so requires having a JRE verison 1.5 or higher installed.  It helps those customers that are wondering what is inside their Forms applications.  It has itself evolved from consisting of only a complexity analysis to providing many details about the application that would take a developer potential months to discover on their own.

From being able to see the dependencies within the form modules and their libraries, to the dependencies on database objects, ART is able to show all of that at a glance.  If you are interested in upgrading from a Client/Server version of forms to a web version of forms, ART can show you where you are going to run into trouble in the guise of functions that aren’t going to be available anymore.  If you are interested in modernizing to a completely new multi-tiered web architecture, ART can show you where you are going have problems finding equivalents and may require a re-design.  Want to know how much of your code in your forms is redundant, ART can show you that, too.  You’d be surprised how much cutting and pasting went on in those PL/SQL-based applications.

The other cool thing about ART, in my opinion, is that like our Evo tool, its output is customizable.  Have a PLL-based function that you know you want to redesign and want to know what forms out of your 500 form application are calling it?  A new report can be easily added to ART to show you that.   Want to create a report that only shows which forms will be impacted by a certain table-change?  ART can do that too.

So if you are one of those unfortunate enough to have inheritied a large Oracle Forms system and you are unsure of what it contains or how complex it is take a look at how ART may help you.

Sorry for the product plug, more informational posts will follow, I promise.

Lately we’ve been doing a lot of discussing about how to reuse components within an ADF application over on the ADF Methodogy Google Group. A lot of interesting comments have been made and Avrom even blogged about some in his post about SOA without the S.

A lot of clients we talk to are interested in modernizing their applications but they don’t always realize that in order to modernize a client/server application in a large enterprise environment AND take advantage of the technology they want to move to, a lot of work is involved. Not just in the actual development, but in the planning and designing of the new application.

Sure, the simplest approach is to just convert what you have and go with that, and in a lot of cases, that is a good first step, but it doesn’t make sense to just convert what you have to end up with the same exact application in a different technology stack, the only thing that is going to buy you is different support costs, probably along with a bunch of flack from the business who’s paying for the change.

Many large enterprises have already created a stockpile of available enterprise services that are meant to be re-used by new applications. Make sure that part of your modernization project is to take a step back and analyze what existing services already exist and how they can be used in your modernized version of the application you are migrating or converting.

After you have analyzed existing services, take the time to determine what this applicaiton that is being converted can offfer as far as services.  Does it make sense to provide some of this data as a service to the enterprise?  Are other applications going to be converted that will want to make use of the same data?

So though the application you are looking at may seem quite isolated, chances are, if it is part of a larger infrastructure, it really isn’t all that isolated at all, it’s just that the old technology couldn’t support it any other way.