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: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.