Re: What makes Java so special?

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Tue, 18 Nov 1997 
11:09:25 -0500

> I guess I'm dense.
> This is an example... I have 2 database servers: an NT machine in 
> engineering, and my AS/400 over in corporate. I have a Java program 
> that uses data queues to talk to my AS/400 (for performance reasons),
> to get customer information, and I also need the same type of customer
> information from my NT box, are you saying I can use the same client
> without re-work to talk to NT?  Remember, the holy grail of portability
> is that I only have to test and debug once.

You are leaving out part of it. Data queues don't magically talk to data
bases. Something must read the data queue, an application. So, in your
example you have written two different host applications, one that uses
data queues and one that doesn't. Now you want the same client to talk to
both? 

If that is what you wanted, why did you write two different host programs?
Why not write them the same? 

Now, supposing that you went ahead and developed two different host
programs and wanted to build a client to talk to both. You would simply
write logic into your client to check for the existance of the queue, and
if it wasn't there use whatever the alternative method was. It's your
fault, after all, for not keeping the host side uniform.

By the way, the NT application could read and write a data queue via the
AS/400. So it could have an application on it identical to the one reading
the queue on the AS/400 but have it's data queue exist remotely (on the
AS/400). This wouldn't necessarily be a good performer, though.

> I think this emphasizes my point...  I can write a Java client and have it
> talk to any URL, no matter what platform serves that URL.  I can be sure
> of this because the only ways to talk to a URL are standard across all
> URL servers, right?  But I can talk to the AS/400 in a NON standard way:
> data queues.

Isn't a data queue just another URL?

> I'm not thinking about moving off the AS/400 so much as talking to
> multiple platforms with the same client; AS/400, NT, etc. 

But your example is one that doesn't take reality into consideration. You
could have a uniform interface, but you chose not to. Then, you are upset
because you can't have a client with a single interface. That just doesn't
make sense.

> This is the trap.
> If I "optimise" my Java code so it has acceptable performance on an
> AS/400, then I can't have the same tested and debugged app talk to
> another platform.  If I write my Java code using JDBC (or whatever
> acceptable standard to talk to all the other databases on the planet)
> then it doesn't run well on my AS/400.

Oh, Buck! That is just plain out of line! "acceptable performance"?! What
the heck are you talking about? JDBC works just as well or better against
an AS/400 as it does against anything else!

It just so happens that when you want to talk to AN APPLICATION on an
AS/400, there are choices you can make to create an asynchronous
request/response stream. One of the choices is data queues. Just because it
is faster than message queues doesn't have anything it the world to do with
JDBC. 

> If the AS/400 supplied industry-acceptable performance from the
> standard interfaces (ODBC, etc.) then this would be a moot question.
> As it is, who would risk writing custom code for a limited market?

Buck, this is simply argumentative. The AS/400 supplies acceptable
performance under industry standard conditions. You are obviously not
familiar with what data queues are used for and how they work. They are not
an alternative to JDBC.

You are comparing apples to oranges. You complain that the JDBC connection
isn't fast enough, but you haven't even seen it yet! You complain that it
doesn't provide industry standard acceptable speed, but there isn't an
industry standard to compare it with! What is the point?

> That's the idea...  Design the client once, test it once, debug it once
> and use it against what ever server my company owns.  

Don't write different host side applications. If the interfaces are
different, the client will need to be different. By the way, this works
that way even if the host side applications are all running on the same box
whether or not that box is AS/400 or NT or whatever. 

> This may not be important to some people, who will only develop
> Java clients to talk exclusively to an AS/400 server, but it's a
> show stopper for those developers who want to actually use Java
> across multiple platforms (and have acceptable performance.)

What benchmark are you using to determine acceptable performance?

> 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 MAJORDOMO@midrange.com
|    and specify 'unsubscribe JAVA400-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---