× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> Shailesh wrote:
> I want to keep my business logic completely in RPGLE
> using DB2/400 as the database. My problem is that I need
> browser based screens and I am not able to decide whether
> I should use Java or CGI to handle browser requests.

Good morning, friends,

Model-View-Controller design is recommended by experts for robust,
change-resilient applications.  Model represents code that implements
business logic and database I/O.  View represents code that implements the
user interface.  Controller represents code that ties model and view
together.  Controller manages the interface.

I'll share my opinion of the best way to implement MVC Web applications
under OS/400.  One reason why green-screen programs have been so successful
is because the code is structured around a read loop.  To implement MVC
design, my suggestion is that controllers be written as ILE servers
(implementing something of a read loop).  The HTTP server simply passes
requests to them.  Most of the time they wait on a queue.

Implement the model code within an ILE service program.  Statically bind the
controller to that service program.  Static binding between two ILE
components is the most efficient, flexible interface possible.  It's also
the easiest to implement.  It's basic ILE 101.

Use templates to separate client-side HTML and related code from server-side
modules.  Manipulate the templates from the controller, again via calls to
generic bound subprocedures, to produce dynamic pages.

Scope the controller to handle multiple types of requests pertaining to an
application.  Resources shared by multiple types of requests are allocated
only once.  Global variables are available in static storage.

Since an application of this design may support any number of concurrent
users and handle as many types of requests as pertain to the application,
use a server-side session component to save an restore client state.

It may be possible to implement controller and view under Websphere or
Tomcat.  But it seems that programmers face a number of issues in the
attempt.  The interfaces get complicated.  Static binding between controller
and model is not an option, for example.  Performance becomes a concern.
Unnecessary code required to parse messages between model and controller
components.  Control logic is divided between a Java component and an ILE
component.  A single, appropriately-scoped controller is the ideal.

If I were to divide my time between the attempt to master both RPG and Java,
it would lead to a mediocre level of competence in both.  On the other hand,
it's hard to contain my enthusiasm for both ILE and RPG.  In my opinion,
they have more long-term potential under OS/400.  Java is not a business
language.  And it's database interfaces are too complex.  The most crucial
part of a business application is the database.  The best way to interact
with the database is via RPG.  And the best way to link with RPG components
is via ILE.  Third party ILE components and frameworks that extend it's
native capabilities will propel RPG into the future.

It's hard for me to listen to many of the problems that get raised on this
list.  Many would never arise if the basic application design were in line
with these suggestions.  I don't mean to sound arrogant.  If I can help, I'd
love to.

Nathan M. Andelin
www.relational-data.com








As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.