Re: What makes Java so special?

Chris wrote:

>But you were trying to take my opinion and turn it into a development
>crisis? If I didn't want an AS/400 involved, I wouldn't use data queues
>(and I would probably have a different email address). Crisis solved!

Naaaaah.  I don't need another development crisis! <g>
Let me re-iterate:  I'm not advocating removing the AS/400,
I love my 400!  I'm talking about an environment where we want a single
Java client to talk to multiple server platforms at the same time, 
including my 400,  NT and some flavour of Unix.  It's this
_multiple platform_ support that drives the need for portability.

If your company will never, ever use any server except the AS/400,
then portability is a non-issue.  If your company ever buys someone
else; someone who uses Unix; and your Java front-end needs to
talk to THAT box, then portability is a tad more important to you.

That's my only point, really.



>> Data queues are an IBM platform specific extension to Java that exist 
>> to improve performance (see your quote above.)  Because data queues 
>> are not an industry standard, using them means extra work, which makes 
>> no sense (see your last sentence above.) 
>
>No, no, no! Data queues are not a Java item! Data queues are an existing
>interface on AS/400s. People use them all the time to talk between RPG
>programs, CL programs, PC programs, or any mix of the above. I get it! If
>you thought that Data Queues were just written for Java as a speed
>improvement then you might question why have them!

I use data queues on the 400 every day.
I know what they do on the 400.

I should have said that "Java talking to data queues are an IBM extension..."

>So, now you want to replace an AS/400 client. The server is fine but you
>want to give a GUI to the client side making the requests. Well, either
>your Java app supports data queues or you rewrite the server..

Very little AS/400 code is written along the client server model.
Much legacy code is some sort of batch entry (think about processing
payments) which validates the input, stores that input as a batch,
then runs a series of edit/update programs over that batch to update
the "real" database.

Newer code is a bit more dynamic (think about adding/updating a
customer master.)  Interactive program(s) run that validate user input
and immediately commit the changes to the "real" database.

True, modern client-server development would have me change
that payment processing application into an interactive client
that enforces the business rules, and commits the database changes
by communicating with the "batch processing" program via a data
queue.  The incremental (do the least work for the largest gain)
strategy has us leave well enough alone.

The market today demands a GUI for the front end even for these types
of applications.  The fastest way to do that is to simply replace the
"interactive" portion of the existing apps with some GUI (Delphi, VB,
Java) code that runs up on the PC.  This is the fastest way simply
because one doesn't have to re-write all the payment processing 
programs that are already tested and debugged.  Essentially, as long 
as the GUI can "CHAIN" to the 400 database to validate the customer info,
and it can "WRITE" records to the payment batch file, we've added
our GUI without a major re-write.

The AS/400 is the story of just how successful such an incremental
improvement strategy can be.  Many of us are running System/3
batch payment processing programs; the only change that we had
to make to them was to make DISK40 on the F spec into DISK, and
re-compile.  The AS/400 has "preserved our investment," so that
we didn't have to re-write to take advantage of newer technology, etc.

For us, the problem is not "So now we want to replace the AS/400
client," but it is "So now we want to have a GUI front end on our
software."  With this definition of the problem, would you agree that
straight JDBC to the database makes sense, rather than write<!>
/400 server code that uses data queues?

<I was comparing JDBC and data queues>

>But I don't see how you compare the two. JDBC is in effect an SQL call to
>your data base. Data queues are for inter-process communication. They
>serve different purposes. 
>
>What's better, a boat or a car? Doesn't it depend on what you are doing?

It certainly does, and that's quite a good analogy!
I hope that you can see where I'm coming from when I talk about
using JDBC instead of data queues...  There are (at least!) 3 points to ponder:

1. One client, multiple server platform: compatible communication method.
2. Upgrading legacy code vs. writing client/server from scratch.
3. Business rule validation: who does this? The client, or the server?
    If the client, then how do we protect the database from "other" updates;
    i.e. some user who uses Access and ODBC to update our database...

Thanks!

Buck Calabro

+---
| 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
+---