Chip wrote...
>As with a lot of things I can be quite dense. For the life
>of me, Java in an industrial environment seems to be a
>solution in search of a problem. There are those who have
>done some nice things with Java, would you share some
>of your hard earned wisdom as to the whys, hows and what
>you got out of it?
Okay, I guess it's my turn to "bite" ;-)
I don't think that Java is a solution in search of a problem.
Let me share a real-life example, if the German Response Center
qualifies as "real life" ;-)
We are using a client-server application for handling patch tape
requests. In the past this was a Motif GUI client (written in C)
that the RCE ran on his or her workstation to enter patch as well
as cutomer information. The client program talked to custom server
jobs on our patch machine to access two TurboIMAGE databases, one
with patch information (read only), the other with patch request
information (queue of pending and completed tape creations). The
submitted patch requests would then be worked out at a dedicated
terminal, running a VPLUS program for creating tapes, letters and
labels.
I'm attaching a GIF with an overview picture of the above. (*1)
As more and more RCEs were using PC's instead of Unix workstations,
the Motif based solution became a little bit inconvenient (you had
to launch some kind of X display server on the PC, eg Reflection X,
before being able to run the Patch Order Client). Moreover, Y2K was
coming closer, and I did not really want to dive into the C source
code of Motif client or server jobs, both written by someone else,
to find or even fix potential Y2K issues. I am not a fan of C and
have never written a Motif GUI program, so you get the idea ;-)
So I decided to write the client part from scratch, using Java.
The GUI is based on Swing (Java Foundation Classes), access to the
TurboIMAGE databases is via the HP JDBC driver for IMAGE/SQL. The
latter also made the custom server jobs on the 3000 side obsolete.
The Java client program resides on a Samba share, so that the PC
users don't have to download updates when I roll out new versions.
The attached GIFs show an overview and a few screenhots. (*2)
Why Java? Well, I didn't want to use Visual Basic, because I am
neither familiar with it, nor did I want to be tied into Windows
or Microsoft's update-games (cost? compatibility?). I also didn't
want to buy a lot of tools. Java on the PC was free, HP JDBC was
free, and I could even find a free Java IDE at www.netbeans.com
to make the GUI design somewhat easier (although coding calls to
the javax.swing.* is not impossible to manage).
Oh, and considering that me and my fellow RCEs have to support
Java and JDBC for the 3000, this would also make a nice exercise
to get familiar with it. Furthermore, I didn't want to end up
being the only one who is able to troubleshoot or support the GUI
client, so Java seemed a better choice than VB, Delphi or RPG ;-)
Notice that I am not using Java *on* the 3000 here, just *with* it.
Does it work? Yes, we're using it since about half a year ago.
The old Motif is still available, so it was a "soft migration",
not a "magic monday". It was my first program with a GUI beyond
a handful of buttons or input fields. It was also my first JDBC
program using write access and transactions. Looking back, it
was probably "large enough" to be useful, and "small enough" to
be manageable while learning the various language features and
API packages.
And next? Well, the VPLUS program that is used to work out the
submitted patch tape requests might benefit from a GUI evolution,
too. This would also provide a chance to try a Java GUI talking
to a native server process (eg Transact, COBOL, Basic, CI) on the
MPE side (you cannot issue a STORE command via JDBC ;-) Another
idea might be a "patch shopping cart" web application that can
be run inside a browser (with or without Java applet parts)...
We'll see.
Lars "your milage may vary" Appel
____
(*1) Just kidding, no attachment, ListServ would strip it ;-)
(*2) Just kidding, no attachment, ListServ would strip it ;-)
|
