What I Learned on my Vacation - Part II - Web Application Design

What I Learned on my Vacation
Part II - Web Application Design

Well, this particular topic is huge and fuzzy, believe me.  Remember when
you has to choose between page at a time and a fully loaded subfile?  Or
maybe decide between a logical file or an OPQNRYF?  There were good reasons
for each, but usually you could decide which one to use based on either past
experience or some pretty good technical reasons.  For example, the decision
on the subfile was pretty much determined by the number of records you would
be loading, and the logical vs. OPNQRYF choice was often one of flexibility
versus speed.

But sometimes the question wasn't so clearcut.  There were multiple ways to
attack a problem, and each had advantages and disadvantages.  Should you
write a CL to submit itself, or did you write a second CL?  On the one hand,
you had only one source member, on the other hand you had simpler code.  Did
you put the prompt in the CL or in a separate RPG program?  Well, today it
might be good to use a CL, it's quicker, but tomorrow you might need more
capabilities, and adding code to CL is not as easy as in RPG.  What to do?

Well, multiply this by about an order of magnitude to get an idea of the
complexity of web application design.  CGI or servlets?  Javascript or
applets?  Frames or no frames?  Data queues or sockets or JDBC or XML?  NT
front end or WebSphere on the AS/400?  The options quickly become
overwhelming, and the problems are only multiplied by the fact that you're
dealing with an evolving technology on multiple platforms with no clear
standards.  Aieee!

What I've found is that web application design is at heart an issue of
encapsulation.  Break your application into different pieces, and then use
the best technology for each piece.  And don't forget to take into account
the skill set of your particular organization.

To that end, I've come up with what I consider to be a pretty decent design
strategy.  I recognize that it may not be the best solution for everything,
but it's at least a good beginning - a base to work from.

1. Components.  These components are a little different than the components
I identified for WebSphere, but the idea is the same.  For a typical
business application, I find the following components are needed: business
logic, application control, user interface and middleware.

1A. Business logic.  By far the easiest piece to build, although it may not
seem so at first glance.  The reason I think it's the easiest is because the
platform and language decision is crystal clear to me: RPG on the AS/400.
Nothing beats it.  So, I've decided that all my business logic will be
encapsulated in servers written in RPG on the AS/400.

1B. Application control.  A trickier piece, perhaps, because my personal
choice is servlets, which requires knowledge of Java.  However, the amount
of Java required is not nearly as overwhelming as it might be.  By
developing a goodset of middleware (which I'll discuss in a moment), I've
found that you can write powerful application servlets with very little Java
knowledge.  The trick is to design a consistent, simple interface from your
servlets to your business logic.

1C. User interface.  This is where it gets dicey.  I may not make a lot of
friends here, but I've found that JavaServer Pages used in conjunction with
frames and some simple Javascript makes a very powerful user interface.
Frames allow you to segregate your navigational aspects from the rest of
your website, and allow you to easily intersperse static HTML pages with
dynamic content.  One frame can be dedicated to navigation, and can be used
to trigger either static or dynamic content in your content frame.
Javascript is a very powerful tool to allow communication between the
frames, and you don't need a lot of it.  And finally, by using JavaServer
Pages, you can write simple pages whose content changes by program control
without having to add lots of logic to the pages themselves.

1D. Middleware.  Sometimes I feel like a lone soul shouting into the dark
night on this one, but I'm totally convinced that for intra-application
communications (that is, communication between components of a single,
integrated application) that message-based client/server processing is the
way to go.  The communication layer between the servlet and the RPG servers
should be a simple yet robust message-based communication layer that uses a
predefined message structure.  Communication between the user interface and
the servlet should be with Java beans, and in fact should be done via
self-formatting widgets.  The servlet populates the bean, and the JSP calls
widget methods which return formatted widgets.  Of course, the formatting
should be flexible and under the covers should conform to some of the
standard O-O techniques, but that's something to discuss another day.


2. External communication.  This is a different issue, and I didn't put it
in my component list because it's far more complex and to my mind less
defined.  At this time, I'm seriously researching the ramifications of XML,
and I think there are a lot of powerful concepts there.  XEDI, the merging
of XML and EDI, offers a very attractive prospect of combining the soft
(that is, extensible) definition capabilities of XML with an immediate
connection to the existing EDI standards.  I plan on keeping a close look on
this one, because I see a big future here.


So, what have I learned?  I've learned that you can design a very powerful
web-based application with a few simple components:

1. A simple message-based client/server architecture for encaspulating your
business logic.

2. Classes that convert between the HTTP data stream and the message-based
protocol of the server.

3. Servlets that use those classes to provide an interface between the HTTP
requests from the user and the servers on the AS/400.

4. A standardized frame-based web interface, using Javascript and JavaServer
Pages to present the widgets from the servlet.

I've managed to put together an entire framework of these pieces that works
pretty well, and I'd be happy to share my experiences.  My hope is that over
the next few months I can build a prototype application for people to look
at.  If you've got any suggestions as to what that should look like, please
let me know.


Joe Pluta
Moderator in Moderation

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