Re[2]: What makes Java so special? -- JAVA400-L

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

I tried to tell you I was dense! <grin>
You're right!  The client talks to data queues, and so does the server, 
therefore you'd have to re-write the server to match the client's expectations.
I understand all that.  The answer is that I DON'T want to talk to data queues;
you do...   Here's a quote:

"Data queues are the preferred method for accessing AS/400s. They are
implemented on AS/400s as the interface between client applications (both
on the AS/400 and off) and server applications (both on the AS/400 and
off).."

and another:

"First, there are a couple of reasons for the Redbook to spend a lot of time
on Data Queues, one being that it is a topic you are not likely to find
covered elsewhere. Another reason that Rochester would like you to pay
close attention to those areas is ... so that you'll need an AS/400!

But this is not quite the same as platform dependance (it's just close)..
The application you are writing will not need to run on an AS/400, it will
just need one around to talk to. 

What you are given is a way to talk to an AS/400 in a native fashion. If
you have an AS/400 and you want to write to it's data queues, you can do
that with Java. But you don't have to. What would be a big mistake is for
IBM to NOT have a way to talk to AS/400s via data queues, as this is the
fastest way to converse with your AS/400. 

If you like data queues but are not happy with the idea that this might
someday mean that you would be tied to an AS/400, switch to MQseries, since
this is supported by IBM across many platforms and has a native Java
interface. But, it is not as fast as data queues.."

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

Oh, I completely agree:  that's why I wouldn't use data queues!

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

Again, this is new stuff to me...  I would argue that the answer is no.
I say this because any Java book on the market will explain how to
talk to a standard URL, but none mention data queues.

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

No, it doesn't.  I'm trying to explain my thoughts so we don't talk past
each other, so bear with me a bit...  I would only use JDBC for all Java
work, no matter what server I intend to talk to.  I would do this because
everybody, everywhere is doing this.  This makes JDBC a standard.

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

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

I was going by your repeated references to performance.
Remember, I am not experienced in this stuff:  I'm reading and trying
to learn as much as possible before jumping in...

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

Well I think we've found the issue.  I wasn't thinking so much about talking
to an application:  I was thinking about access to the database.  This is
where we've crossed our signals.  It's pretty obvious that if I want to put
a Java front-end on my Order Entry system that I'm going to need to
re-work some of that code on the /400.  Unless, of course, I directly put
the order records into my order database...

How will Java talk to, say, a Unix application?  They don't have message
queues or data queues...

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

Actually, I'm intimately familiar with data queues, and use them daily.
As for performance, I was using your quotes as a point of reference.
As far as an alternative to JDBC, if I understand the terminology
properly, JDBC lets Java read/write to the server's database.  I think
that I can put the data validation in a Java front-end by using JDBC
to read (validate against) the /400 database.  Likewise, I think I can
use JDBC to write my (now validated) data directly into my /400 
application's database files.  Add DB2 triggers and RI and I can
make my database reasonably solid.  This leans more into the
"where should I implement my business rules" area, which needs
to be addressed no matter what client we choose to work with.

That sounds like an alternative to using data queues to me...  
How *good* an alternative may well be the topic of another thread!  <grin>

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

I was using... well, you get the idea.

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

Again, I was thinking "talk to the /400 database" while you were thinking
"talk to the /400 application."  I understand how we got our signals crossed
now.

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

Aside from the previous, I'm using ODBC performance as a benchmark.

If I build 2 identical databases: one in lowly MS Access, and one on
my /400.   (I like to test my ODBC stuff at home, with my own PC on
my own time...)  The exact same app on the exact same PC will run
very well when I use the Access database in my ODBC driver.  When
I point to the /400 database, the speed is on the same order of
accessing a 5-1/4 floppy disk.  On a 510, that's unacceptable, 
especially when the "green screen" version is faster than EITHER
of the 2 GUI versions!

If the end user has any perception of slowdown when pointing to 
the /400 database with JDBC, I can tell you that they will deem
the performance to be unacceptable.  

Now, I know that my mileage may vary, and it depends upon
the application (both sides! <g>) so don't take me to task just
yet...

Thanks for the discussion!
How do you see JDBC performance vs. ODBC on your machine?

Buck "the greenhorn" Calabro
Commsoft

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