Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Client/Server Architecture

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Client/Server Architecture

    ** This thread discusses the Content article: Client/Server Architecture **
    0

    Comment


    • #17
      Client/Server Architecture

      Heya Chris! Thanks for the encouragement. In the e-Deployment book, the controller was always RPG. The UI portion (or "view") was either a browser or a Java thick client, but the rest of the code was in RPG. PSC/400 is the commercial version of e-Deployment and it uses a single servlet to route the requests. The form parms are retrieved and used to update internal "record buffers", which can then be accessed by the original RPG program. In the case of a simple EXFMT, a buffer is sent from the program to the servlet, which converts EBCDIC to Java using the toolbox, and then displays the data via a JSP form. The data is read back in from the form and put back into the EBCDIC buffer, which is sent back to the program. Obviously, it gets a little more complicated for subfiles, and there are also considerations for things like message subfiles and informational data structures. The really powerful thing about this approach is that you can pass hidden fields from the program to the servlet, something which cannot be done with a screen scraper. As to thte technical issues of prgoram communication, I call an RPG program which communicates with the legacy application via data queues. I use the ProgramCall object with no PCML. I pass a data structure as the parameter and parse the EBCDIC buffer using the Java toolbox. Joe

      Comment

      Working...
      X