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

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Wed, 3 Dec 1997 
14:02:32 -0500

> >> If my Java code talks to some AS/400 specific widget, then it's not
> >> portable. If it's not portable then I can't very well re-use it, no matter
> >> that the byte code can be  interpreted by another hardware platform.
> >
> >The point is, yes you can. 
>   
> This is the bit that I can't follow.
> I can't test it on my PC (P75, 24 meg RAM) because IBM's VA-Java
> insists on 32 meg of RAM.  
>   
> I have 2 identical databases, or, more accurately, I have one database
> spread across 2 machines.  One is an AS/400 and one is an NT server.
> The AS/400 contains name and address information for end-users,
> and the NT box has name and address information for vendors.
> Here's what I *thought*  I had to do to use data queues to communicate 
> from the Java client to the AS/400 (please excuse the terminology...):
> 1. In the Java client, call a routine that sends a request to the data queue
> 2. In the AS/400 server, receive the DTAQE, query the DB and send the
>     results back to the DTAQ
> 3. In the Java client, call a routine that reads the DTAQE, parses the
>     results and displays them.
> Did I miss something?

Well, yes and no. You need to send and receive stuff but you don't call a
bunch of routines. Probably you say "name userName = new name(dQServer);"
   
> Now, my Java client's routine is writing to/reading from a data queue.
> How can I use this identical code to get the exact same information
> from the NT server?

Probably you say "name vendorName = new name(nTServer);"

Now, what that means is you have written code that includes constructors
which handle both data queue based servers and NT servers. Or, you can use
sQLServers if that's what you want. Anyway, now all your code works fine and
if you move the AS/400 data base to a NT server or vise versa you have the
methods already in place to handle it. 

But the question, Buck, is what the heck are you talking about? You have,
for some reason, created two different server interfaces and are now
wondering why you must write different code for them. Second, your complaint
was that you couldn't re-use the client. The client can move to any Java
compliant platform and talk to the same hosts it always talked to. 

What is the part you can't grasp here? 
        1. What kind of host interface has no bearing on the 
           portability of the client.
        2. The platform the client is running on has no bearing
           what kind of host can be contacted.

If you create two different host interfaces, you will create two different
client access methods. If you write these into your client, then the client
can go anywhere and talk to both hosts.

> >No. As long as the code is 100% Java, you can choose your client platform.
> >The nit you are picking has to do with choosing to talk to a specific
> >server. There is no requirement to.
>   
> In theory I guess I don't need to talk to a server, but where do I get my
> data from if I don't?

I think the point was "specific server". In other words, you keep choosing
to write server specific code, and then are faulting Java's lack of
portability (which really doesn't have anything to do with the server)
because you now need to write client code to talk to the interface you
wrote. 

I just wanted to point out that you could have simply chosen to use a common
interface.

> >Some people might not want to just toss out all they have running right now
> >and rewrite it.
>   
> You and I couldn't agree more!
> I only wonder how many people are actually running Client-Server code
> where the client and server communicate via data queues.   I've got
> a huge number of "old style" applications, and a mere handful of
> client-server ones...

Perhaps you conceptualize client-server as something it isn't. For instance,
our application uses a server application for processing all printed
documents which are printed by events (because the people who are keying
those events might not feel like waiting for some other task to occur). So,
when an even occurs, the event program issues a notice in a data queue. 

We have a server application that monitors and processes entries in that
queue. This is client-server processing although all the apps are green
screen host based programs. If we decided to rewrite a couple of these apps
as PC based and we wanted them to be able to issue event notification it is
likely we would choose to have them place notification in the data queues,
since there really isn't any reason to rewrite the print server side. 

I think this is more common that seems on the surface.

> We have literally tons of legacy code that were written before
> the client server model became fashionable.  Even now, there are
> thousands of AS/400 shops that are using the older model to write
> applications.  These folks *are* starting from scratch when it comes
> to GUI/Client Server code (which is what I meant...)

No they aren't, Buck. None of them is in a position where they are looking
to just throw everything away and start fresh. 

Rather, there may be many of them want to change a client front end, but are
interested in keeping the current reliability as well as continue to use
existing batch processors, report printers, etc.

That's why whatever tool they choose will need to be able to deal with the
components they still 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
+---