Re: What makes Java so special? -- JAVA400-L

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Fri, 21 Nov 1997 
09:30:42 -0500

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

Well, I've seen a lot of uses of the C/S model, because it is usually the
best way to reuse code. But I don't think it's useful to argue whether
there is a lot or little of it. I think my point on is is that this model
is one reason that it is necessary for IBM to provide native interfaces
within Java. 

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

Some "unmodern" client-server developers used similar methods for
communicating with a batch processing program from the client app in the
past. For instance, I write an RPG application for entry of bill payment
information. Let's say this is for the a local phone company. Operators key
payments and I update the data base with this info. Now, the phone company
decides to allow bill payments all over town.

So, if I was smart and communicated my payment requests to a server app
from my client app (even though both are green screen and on the same
machine) then I can put some 400s around town with data queues back to the
central site and everyone is happy. Then, the same phone co. wants to put
in an ATM type payment center. The interface is written on a PC, and drops
the data into the queue. Now, it appears that I am a modern client server
genius, but I am really just a mainframe programmer that wasn't too stupid.

Then along comes Java, and IBM starts telling us at this phone company that
this is the wave of the future and we should switch all our programming
efforts over to that environment. Now, if IBM says we have to scrap
everything and start over, I think we say, "No." But if IBM says it works
just fine within the environment we have created and we can do incremental
implementation, then we look to see if there is an advantage and if so we
prepare for the move.
 
> 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.

I don't want to get into a debate over system design, so for our sake here
let's just say that it's okay for one shop to do things one way and another
shop to do the same thing differently. Now, some shops might feel that over
time they will same time and effort if not everyone is allowed to chain to
master records for update. Maybe they have a turnover on programmers and by
the time they discover file contention problems the guy who created them is
gone. 

A shop like that might want the clients to submit a request on a queue, and
wait for a response on another. 

Or, here is maybe an example it is easier to get behind, let's suppose your
application needs to authorize credit cards. Maybe the program that talks
to the credit auth facility needs to have a queue of requests so that it
can auth them one at a time. Your clients (green screen or not) might need
to be sticking their requests on a queue. So, you can choose message queue
or data queue. 

It might be foolish of IBM to take away that choice. 

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

Well, that would depend.

Although PC front ends are more dependable than they used to be, and
although the JVM on the Java workstation is supposed to be wonderful and
reliable and all that, I am still pretty much a coward at heart. 

I don't like to distribute any processing that my data base might depend on
for integrity. If I give the client the right to lock a record in my data
base, I could be screwing myself to a wall. 

Of course, SQL update requests come in from the client and are executed
(locks and all) at the sever, so I could do that, but that means the client
didn't know whether or not the data had changed.

Well, I guess there is a little preference there. I'd like to see it on the
server. But, I can see that I could write the client to issue an SQL
request that could very well be safe. Part of that would be the ability to
detect a record change during the update request and I don't know how to do
that with SQL.

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

How so very true. Possibly, these considerations are a reason why MQseries
has been so popular with those who adopted it. This gives you the
opportunity to impose server based control on the data base with multiple
platform support. After all, I would feel a little more secure knowing that
I only granted read authority to those Access using guys and all updates
were going through integrity checking. 

I advocate the use of data queues because I have been so succesful with
them and I don't see any reason to move any host applications to machines
without data queues. But I certainly understand people developing a new
application shying away from their use if they don't know what future they
have. 

> Buck Calabro
 

Chris Rehm
Mr.AS400@ibm.net

How often can you afford to be unexpectedly out of business?
Get an AS/400.
+---
| 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
+---