Java Hair

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.

Tomorrow morning I am off to Oracle Open World 2008.  This is the 5th year that we will be exhibiting there, and I believe this will be the most exciting year yet.  I’m sure that the show will be interesting, it usually is, and I get to hang out with some people that have become friends over the years via the show.  I believe their Appreciate event features Elvis Costello this year.  I don’t think that is going to compare to Billy Joel’s performance last year, or the sheer fact that you had to choose between Stevie Nicks, Lenny Kravitz and Billy Joel, but it should be fun nonetheless.

What I am really excited about this time around, however, is more business oriented.  This year we will be demoing our Evo forms conversion tool, as we always do, but this year we are converting forms to Oracle’s ADF 11g framework, both the ADF Business Components and the ADF Rich Faces layer.  I’m not going to tell you that these forms are being converted 100%, frankly, I don’t think that it’s possible in a practical way.  We are converting enough of the forms to show a fully functioning BC layer and a fully functioning UI layer, however, and that is, IMHO, pretty cool to see.

So if you are going to OOW this year, be sure to stop by Vgo Software’s booth and ask for a demo.  Be sure to check out the group discussion about creating an ADF Methodology that I will be participating in at the Unconference, stop by to see Andrejus Baranovski’s presentation and the other Unconference presentation Andrejus and I will be doing about using ADF 11g as a platform for forms conversions.  It will be similar to the talk I gave at ODTUG, but it will probably be a little more technical with Andrejus’s input.

Hope to see you there!

Today was a short day, for manning the booth anyway. We didn’t have anything to give away this year so it made the close of the booth somewhat less exciting. I didn’t actually get to see any sessions today, but I did manage to talk to many people that are trying to decide what to do with their old Oracle Forms applications.

I told them what I always tell ‘em. Upgrade your forms for the most part, unless you have a compelling reason not to do so. Converting to ADF or Java is going to be time consuming and expensive, even when you use a tool like Evo.

I got to find out what the JHeadstart gang have been up to. I even managed to catch up with Wilfred and Grant today, so it hasn’t been a total loss.

I should have taken some pictures of our booth with my phone but I did not. Stacey, the marketing associate with us got some good pictures of it on her camera. I’m sure she’ll have those pictures up on the site sometime soon.

Tonight is the big Fat Tuesday on Wednesday bash, so that should be a fun end to trip for us. For Andrej, being an Oracle Ace Director, he gets to spend a few extra days exploring New Orleans, not a bad deal.

Hopefully our presentations will be up on the ODTUG site soon so that you can download them and take a look.

Now that I’m coming back from the conference, the next blog posts should have a little more meat to them. I think I’m about overdue for something technical.

One last thing before I forget, a picture of Andrejus during his presentation!

A lot of people ask us where the name Vgo Software comes from. (That’s pronounced Vee-Go Software in case you were wondering.)  Since I’m in Greece this week with a client and I haven’t posted anything in a while, I thought I would expound upon where our name came from.

Back in the day, we were just a consulting company. At that time I had come up with a prototype for what eventually became our Rev product. I remember writing an e-mail to my business partner about this prototype. While writing the e-mail I realized that I did not have a name for the project and started to think about what I would call it.

Earlier that day I had talked to a consultant that was working for us and who was a friend of mine. He told me that he had been experiencing bouts of dizziness earlier in the week and didn’t know what was causing it. After suffering for a couple of days without it getting any better he went to the doctor to see what the problem was. As it turned out, the doctor told him he either had a cancerous tumor in his ear or he had Vertigo.

Thinking about what to name the software, which was a code generator, I thought “Vertigo!” what a perfect name! It generates code so fast it will give you Vertigo. Well, I put that in the e-mail as the name of the prototype and the name stuck for a while but at some point before we actually released it somebody did a name search and determined that the name Vertigo was actually being used by another software company for another product.

About a week later we held our monthly staff meeting where we gather everyone from wherever they may be, talk about current company events, and have beer and pizza. We decided it would be a good time to come up with a new name (esp. after the beer part). After everyone throwing out various names for about an hour, we finally settled on a mutilated version of Vertigo, Vgo.

Well, Vgo eventually became our code generator, Rev, and the product built on top of that which was once referred to as Vgo4Oracle became Evo (anybody notice a pattern emerging?). Both products were part of the “Vgo Software Suite” of products and we eventually just started using the name of the software itself as the name of the company.

So, I get this all the time “Why should I convert my perfectly good Forms?”. The answer is you should if you have a good reason to. If you don’t, by all means stay there (until, of course, one day Oracle decides you will not have Forms at all anymore; around 1213 or so, and then you’ll need to do something). I see TON’s of blog’s about the topic. Mostly these entries are on Oracle-centric sites and are not, perhaps, as objective as they could be. So, here’s my opinion on the matter (as I find myself to be a relatively objective person).

Wait, before beginning, I need to pull out a blog-shaped soap box.

These efforts aren’t “conversions”. This isn’t a translation exercise. Meaning, if you think you can change from one computing architecture to a completely different one by pushing a button, you’re nuts. It’s just not realistic. From the outset of Vgo Software (and prior to that, NEOS) we used the word “evolution” or “modernize”. To reach a stage of evolution, you have to work at it to reach the full potential of the modernized state (whoa… I’m feeling a little Zen here).

Think about this, Oracle DBA’s out there: when you upgraded from v7 to v8 of the database, did you use consider the cool new features like partitions, a better cost-based optimizer (though, in my ex-DBA opinions, still not great then) or materialized views (I’m publishing my age here)? If you did, did you get all that stuff by upgrading? NO. You had to reconsider your applications using the DB and what impact that the changes would have on them. 

I shouldn’t mention that your manager wouldn’t give you time to implement any of the good stuff as I’m sure that wasn’t/isn’t common at all.

So, back to Forms and Java.  The people that should want to convert would be those folks who want to integrate applications in a standard way.  They want to move towards service orientation and can see integration across application silo’s.  These folks may want to move away from Oracle as an application solution and move toward open-source, allowing them to use a wide community of development resources.  Of course, Oracle has been making great strides as we can attest to. 

But why is Forms evolution hard?  It’s hard because there is alot to do to create a solid JEE app.  In a code translation (of which there are a large number), an engine maps each construct to a “Java equivalent” which may, or may not, be proprietary to the translator.  What you do in those cases is create at least 2 different source files (possibly 10 times more) for every Forms program unit, trigger, etc. creating a huge mess.  Maybe it works, most likely it will not, but then your stuck with 1 million source files and no way to maintain them.

We put in a lot of effort to try to allow people to clean up and consolidate code in forms applications (we’re the only one’s who do that, BTW) and even build customized classes from existing forms components.  Our last release allows you to do this across different forms applications, creating true enterprise-class applications and services.

There is also discussion about modernizing Forms apps by putting all of the PL/SQL in the form into the database (perhaps the re-surgence of mainframe computing is making it into the distributed database market).  This approach was taken by forward thinking companies in the mid-to-late ’90’s by taking core business rules out of their forms and wrapping them in CRUD procedures in Oracle to thin out the front end.  A good approach back in the client/server days.  In fact, I did that myself with a large annuities application.  But now you have application servers that run real Java; why would you want to isolate your business logic in a single database?  What about sharing that logic with other apps (yes, I know you can do that to some degree in Oracle)?  What about exposure as a web service from different platforms?  And how many PL/SQL programmers can be found to manage really large apps that stuff all of their logic in a database?  In my opinion, fattening the database isn’t a viable architectural solution in this day and age.  If you want to thin-out your front end, that’s great, just don’t dump all of it in the database. 

So, I’ve written this over a vast amount of time, being a poor blogger (Rob may suspend my blogging privileges after this release).  Maybe it’s insightful to you; therapeutic to me.

As you probably saw in Ernt’s earlier post, we exhibited at ODTUG Kaleidoscope this year. It was our first year at the show, but I don’t think it will be our last. To me the show was more valuable than Oracle Open World which we’ve exhibited at for the past 3 years. It may be that as a vendor, exhibiting at OOW is a necessity, but as a developer, exhibiting at the ODTUG show was much better.

What was most encouraging was being able to demo our products to a wide range of people who understood what we were talking about and what our products are trying to achieve. I believe that anyone who believes in code generation as a viable “enhancement’ to custom development should take a look at Rev and see what it can do. I was encouraged to speak to one person who said that he believed we are getting to the point where everything can be done by code generation. I certainly believe that any software project that persists data to a database can benefit from code generation.

Enough about Rev. We had the chance to demo Evo to a number of folks who had some great insight and advice. To me, that was what made the conference such a success. The ability to be able to network with such a great community of people who really want to see a product that can do things right was encouraging.

I had long wanted to speak with Wilfred van der Deijl about his solution to the ADF/Forms integration problem and get his impression on Forms to ADF conversions. At this conference I had the chance to do that. Even though I missed his presentation (the time had changed and I didn’t check the board), he was kind enough to stop by the booth and show it to us personally. It’s a great solution for a problem that we have been asked about many times. If you are into Forms or ADF developement, you should definitely check out his blog. It was nice to see from his blog that he believes we are on the right path.

Peter Ebell over at AMIS in the Netherlands stopped by. If you are into hardcore ADF development, checkout the AMIS blog where Peter is a contributor. Anyway, he stopped by to get a demo of our Forms conversions and hopefully will post his thoughts about it. We talked a lot about Forms Conversions, JHeadstart, and even Whirlyball.

I, unfortunately, did not have the time to attend any of the sessions I wanted to. In each case, when the time for one of those sessions rolled around I was engaged in a product demo or an interesting discussion with one of the attendees. I suppose it’s better to network at these things than sit in on sessions all day, but a nice mix would have been appreciated.

It was a great show and we all had a good time. Though I am not a NASCAR fan in particular, I did get to Daytona USA as guest of Oracle’s at the ODTUG party they held there, and though I was less than impressed, when I stopped by the following day as we were leaving Daytona and got a chance to check out the grandstands with some cars on the track, it was very cool. I don’t think I’ll be watching any NASCAR races on the tube at home, but if I get the chance to attend a race in person, I think I’ll take it. Just the sound of those engines as the cars go screaming by is quite impressive. Not quite as impressive as Evo or Rev, but impressive nonetheless