From: Nathan Andelin

Joe P. wrote:
In the thin JSP architecture, you have a single servlet that converts
messages between EBCDIC and Java objects. That servlet is roughly
equivalent to the CGIDEV2 service program ...

The servlet you describe seems to be much more robust, and serve a
different purpose than CGIDEV2,

Not really. CGIDEV2 actually is quite robust, as it has to re-invent all of
the template caching and substitution that JSP has inherently built in. It
also has to parse out the HTTP request string to access user input.

The thin servlet model basically does much the same thing, except that it
allows application programmers to send entire data structures, which are
converted to beans (a bean being little more than a set of Java fields, such
as Strings and integers and so on).


but are you saying that under you're
architecture that developers would be using, but not changing,
recompiling, or inheriting from the servlet? If so, what would developers
be creating / maintaining? JSP's? XML mapping definitions?

Yup, that's pretty much it. JSPs and XML mapping. I actually have designed
two separate architectures: JAC (Java Application Controller) and RAC (RPG
Application Controller). In the latter, only the very thinnest servlet
layer is written in Java. The rest of the code (both application logic and
business logic) is written in RPG.

In the JAC design, the application control is written in Java; this allows
interface to advanced Java frameworks functions such as web services, mail,
and so on. In this design, the Java code accesses the business logic
through RPG servers. Interestingly, this design is actually the better
choice for people who don't want to learn any Java, because it's easy to
replace the Java application control code with EGL. The EGL can directly
call the RPG servers using EGL Records, which can also be dropped directly
onto JSF pages using the WYSIWYG designer in EGL.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.