RE: Java and CPU

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