Re: What makes Java so special?

>> >But again, JDBC and data queues are two different things. Meant to handle
>> >two different issues. If I have an application running on a host machine,
>> >and I want to talk to it, what value has JDBC got for me? 
>>   
>> You're very, very right.  That's *your* situation.  
>> *I* haven't got any server apps running on my AS/400 except the database 
>itself.
>
>Then you have no apps to talk to. Then you are faced with a full rewrite, or
>modifying one of your maintenance apps to accept a request from a data queue
>instead of a screen. 

One alternative is to take the interactive maintenance program, write it in
Java and use ODBC to read/update the database.  That can be hairy
because then the business rules move from the server to the client(s).
However (there always is one, eh?) this leaves the core database intact
while getting GUI on the desktop.  We're currently doing some of this
with Delphi, which works OK because almost all the client PCs are
W95 units.  However, if we were to do it in Java, we could then execute
the same client code, talking to the same server (AS/400) on Sun PC's
for the engineering department.  I don't think Delphi will run on Unix today.

>> How did you carry your systems from "original" batch-driven code to 
>> Client-Server code so quickly?  Or am I really the only AS/400
>> programmer left who has batch-driven application logic?  This is
>> important in a Java thread because the basic design tenets have to
>> be established, at least in my case.  I can hardly believe that all 
>> those S/36 shops re-wrote all that batch code when they bought
>> their shiny new AS/400.  
>
>So quickly? I've been using a client/server model since before the AS/400
>was introduced. But not on everything! Only where I thought it made sense or
>was necessary. By the way, if you are "batch driven", that is another issue
>you can address without rewriting. 

So you personally don't have much old code you have to deal with?

>> 3. Core database files and logic are implictly designed with batch timing
>>     in mind.   Tough to simply transition a part (say, the A/R Inquiry) to 
>C-S
>>     when the database itself is updated after hours.  
>
>Hey, if you are happy with the existing logic, leave it alone! I am NOT
>trying to tell you to use data queues. I am pointing out that they are not
>evil. 

Oh, I understand that!  Like I said before, I use data queues for interprocess
communication on a daily basis.  I rather like them!

Whether *I* am happy with existing logic or not is a moot point.  Until the
end-user's management agrees on a re-write, I can't spend hundreds of
hours to add an incremental mod and "by the way, re-write the entire A/R
so it meets modern design standards."  Believe me when I tell you that
I WANT TO, but I can't.  You know, and I know and secretly, THEY know
that one can't readily make changes to fragile, old designs without
breaking something every time you touch it.  We all know that we'd
get lots more mileage out of a newer design, but they really don't want
to spend the money until they have to.

>If your existing batch update process is fine with everyone concerned, leave
>it alone. Write a client that creates records in the same files that your
>existing data entry apps do, and process the entries in batch. 

That's basically where we're headed.  The big questions revolve around
the database design: 
1. How are we going to secure it?
2. How will the business rules be enforced?
Both questions impact the existing green-screen applications because if
that old code doesn't check for I/O errors, RI/Triggers will result in "white
messages."  Ditto for security.

>All I am trying to point out is that data queues are not a flaw in Java.
>They are not an evil destroyer of object oriented coding. They are just
>another tool with a time and a place for use. There are existing situations
>where using a data queue is called for. If yours is not one of those
>situations, don't use them. 

Yup!  My particular interest in all this was the HOW of integrating Java
and really old legacy code.  As part of that, I was trying to asses what
"portability" meant in the larger picture of a multi-vendor, multi-platform
client and server environment.  It seems pretty fair to say that:

1. Java provides client-side portability.  I can run my Java app on 
    multiple client machines.
2. The *server* provides server portability, in that if I write to some
    industry standard (say ODBC or RPCs) to send/receive data, then that
    client interface will talk to many servers.  If I write to a non-industry
    standard (say data queues) to send/receive data, then that client 
    will only talk to the specific server that supports that interface.
3. OO design has many new tenets that need to be understood; old
    "procedural" paradigms are hard lessons to undo.
4. It will be a very difficult job to carry legacy databases and applications
    into the client-server environment.  

>But all things have trade offs. Batch processing means updated balances
>aren't ready right now. Interactive processing means that each client must
>be responsible for maintaining data integrity. 

You said it, brother!

Buck Calabro
Commsoft

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "JAVA400-L@midrange.com".
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---