Re: SQL vs "native" I/O performance

Joe,

You have recently written about the following Java/AS/400 options:

<< 
 1. Java front end doing direct SQL calls
 2. Java front end doing direct native I/O calls
 3. Java front end talking via RMI to a Java server class using JDBC
 4. Java front end talking via RMI to a Java server class using native I/O
 5. Java front end talking via middleware to a Java server program using JDBC
 6. Java front end talking via middleware to a Java server program using 
native
 I/O
 7. Java front end talking via middleware to an HLL program using embedded SQL
 8. Java front end talking via middleware to an HLL program using native I/O
 
 There are other options, of course, but they tend to veer away from the
 client/server architecture.  Another thread can discuss why I believe so
 strongly that client/server is required for true distributed applications, 
while
 servlet technology is better suited for data collection applications (like 
order
 entry).
 
 Options 1 and 2 are out of the question for industrial strength applications
 because of the problems with distribution of business rules.  Options 3 and 4
 would be wonderful if the JVM was truly integrated into OS/400, but it isn't
 yet.
 
 That means we need to determine which of the other four options is the best.
 The answer may be "it depends on the application", but that simply means we 
need
 to spend a little more time defining the application.
   >>


By 'middleware' I take it that you mean non-Java middleware?

I agree with you that the road to 'industrial strength' AS/400 Java 
applications goes via industry-standard middleware.

However, I also feel the AS/400 still has somewhere to go before it can prove 
itself as a serious contender in the distributed systems arena. For example, 
the current implementation of MQSeries is behind the mainstream, CORBA 
support is still a twinkle in IONA's eyes (I never thought I'd pray for a 
company's financial health to improve...), even WebSphere is lagging,  and to 
add insult to injury IBM won't even explain why they have no plans to 
port/develop Component Broker to/for the AS/400. It's a great platform 
alright, but defending it in certain circles is a struggle. 

About your options, maybe the Java/other HLL choice has to do with how much 
re-write you are willing to undertake. For new development, Java should make 
more sense. If leverage of current investment  is paramount, keep current 
code. As for the native I/O(meaning DDM?)/SQL choice, there's the nature of 
the access (which you have already been taking Paul Comte up on - you've got 
guts!), but there's also the nature of the database. Some databases of my 
acquaintance wouldn't know 'normalisation' if it ran them over. DDM might be 
more suitable for them.

All the best,

Simone Joaquim
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@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
+---