<FlameInducingText>
Many are using XML 1.0 files as a format for this "thin glue".  Once your
app server can dish out these, you can transform them into HTML, WML or even
flat files.  They can be used by browsers, application servers, other
disparate systems, programming languages and scripting languages.  One
writes the server only once and all of your business rules are in a single
place.
</FlameInducingText>

I enjoyed reading Duane's guidelines and they show the benefit of separating
functionality.  Let a tool that is best at maintaining state and creating
HTML do that job.  Let a tool that is best at load balancing do that job.
Let a tool that is best at transaction processing do that job.  In this
case, it's the e3000.  Great stuff Duane.

Mark Wonsil
4M Enterprises, Inc.

Duane Percox Writes:

Excellent soapbox comments snipped...

With these issues raised, you are highly encouraged to build your production
HPe3k resident
web applications around the following basic guidelines:

** Host your web applications in the normal application account.

** The cgi you write should be thin "glue" that links the web transaction
from the web
    server to your web application. This is best done using message files or
other
    forms of IPC (inter process communication) available to developers on
mpe/ix.
    If your web server supports it, develop your "glue" as a callable
routine that
    is accessible by the web server without the need to create another
process.

** Isolate the particulars of the transaction source (web server in this
example) to
   the thin "glue". Keep all of this specific knowledge as far away from
your application
   code as possible.

** Think of your application as an "application server", which is waiting
for the next
    transaction. Your thin "glue" cgi passes along the web transaction and
waits for
    the result(s) which is passed along to the browser. If architected well,
this
    application server could also receive transactions from other sources
beside
    a web server. For each source, you would develop the thin "glue" which
connects
    the transaction source with your application server.

** Design your "application server" to have multiple instances (multiple
processes)
   of the server code to be able to handle lots of simultaneous hits at one
time.

** If you have any spare time, consider developing a way for the web
transaction to
   be sent to a completely different HPe3k system which is hosting your
"application server".
   This would allow you to distribute web application loads across multiple
systems.