|
It depends on the architecture you choose to use, client/server or server/client. The version I just tested was the server/client version, where the program is written as a vanilla green-screen application, then a few mods are made to web-enable it. That's the revitalization technology for eDeployment, which is readily available on the website (http://www.java400.net/edeployment). This is the best technique for putting existing applications on the net. I web-enabled four programs, each with three different looks, in under 4 hours. The other way to design applications is client/server. This takes more work, and has to be designed from the beginning. It involves first developing a messaging infrastructure, then building basic business classes from there. For example, I've got CRUD servers for file maintenance and QUERY servers for complex queries. As to the portability issue, that's long been a red herring, for two reasons. First, if you're planning on moving to something other than an AS/400, then you've got much larger problems. I'm an unabashed AS/400 bigot, and I believe the AS/400 is the technology best suited for business logic processing. However, there may be times when at least some of my data is served by a different platform. In that case, if I design the business classes properly, it's quite easy to attach a different data source. While my current data sources are designed to access an RPG server, I'm planning on writing a set of classes to support SQL data sources as well. Once that's done, the entire architecture is entirely portable. However, there's a significant performance penalty to move to SQL from native RPG, so the first release uses RPG. Is the client/server stuff available? Yeah, a rudimentary version is available in the PBD classes. JDQM/400 is the data queue messaging package that underlies the client/server structure. But in theory, the idea is so simple as to be trivial: 1. The client sends a request to a data queue, with a client ID 2. The server reads the data queue and processes the request 3. The results are sent back to the client's response data queue 4. The client reads the data queue and processes the response I use an RPG program with a single parameter to do all the communication. The parameter is a data structure with (basically) client ID, server ID, opcode, return code and data. Over the years, I've refined this to support a highly flexible system, that includes segment codes and continuation codes for large, heterogenous messages, allowing messages of any length and multiple formats, but that's my specific architecture. You can easily roll your own. There should be no conflict on database access. Java is MUCH slower than RPG for any sort of business logic processing. Writing business logic of any kind in Java is a mistake, unless you plan on building an entire EJB-based system from the ground up. For most applications, a message-based architecture featuring a Java UI connected to RPG logic servers is far more efficient and more maintainable - it allows your legacy programmers to do the work they do best, making working business applications. You don't have to learn Java to write business logic. Joe ---------- Original Message ---------------------------------- From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com> Reply-To: JAVA400-L@midrange.com Date: Fri, 2 Mar 2001 07:53:08 -0600 >Do you have samples how you do IO and interface between a class and RPG, on your website or otherwise? Now I'm interested. :) I'm getting conflicting messages on how to do the DB access now, so I'd like to see both methods. If you use RPG for IO, I would assume that it makes the application less portable, though. Brad +--- | 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: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.