Re: What makes Java so special?

Buck

At 11:09 AM 11/18/97 -0500, you wrote:

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

This discussion is really important, IMO. We're dealing with this in just
our shop, not even out to the open market.

Naturally, if you need the same kind of info from your Unix box, you need
to rework the code, since Unix does not support, say, data queues. We're
talking desing strategies here. It depends what you need to do, what the
constraints are, etc. If performance is foremost, go for the solution that
optimizes the app for each possible backend system. Alternatively, fall
back to a standard that all systems recognize. In SQL, this could be
something like ISO-92 or whatever it's called. Then ODBC/JDBC would have to
be limited to the features of the standard.

A development product called Magic uses the first strategy. Of course it
took more development work. Isn't there some inverse relationship between
end-user simplicity versus developer effort?

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

It's a tradeoff—using common standards will probably result in some loss of
performance. But isn't this the case with all distributed computing (AKA
client/server)? But this still doesn't speak to the concept that the
_client_ will _run_ everywhere—i.e., it can execute, to a degree. There is
no difference here, as I see it, from VB apps that use record-level DDM
data access instead of ODBC or the Jet database engine. The client app that
uses record-level access will run on any Windows platform, but it'll fail
to run properly unless connected to the appropriate server.

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

Well, yes & no. A lot of what goes on in one of these apps will be the
same, viz., the presentation stuff. The connectivity stuff is probably best
put into some middle layer that handles only that. The problems you raise
are mostly eliminated if your Java app only presents data, and doesn't have
to handle everything. This is where 3-tier design comes into play.

The OSI 7-layer concept of application design helps me out a lot in
thinking of these problems. Also, some of the ideas from IBM in
distinguishing different kinds of client/server designs—they've identified
at least 5. None of this is monolithic anymore—we have to think in layers,
in separation of function.

>I'm going through all this because midrangers have spent untold
>hours debating the relative performance merits of Z-ADD vs SUB.
>Midrangers who write "standard" portable Java that talks to their
>AS/400 will not sit idly by when the performance of the application
>is... less than optimal.  They will certainly optimise for speed,
>and when that happens, their code will no longer be able to talk to
>any other servers.

Exactly—we're in a much larger world here, and any 400 programmer who does
not consider this fact is in trouble, as far as I'm concerned.

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

JMHO

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480


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