RE: Database Maintenance Models

> Servlets are multi-threaded.  That's the whole idea.

More precisely, Servlet containers are multi-threaded, placing the burden on
Servlet and framework developers to synchronize their methods.  If one (1)
Servlet is responsible for database inquiry and maintenance for so many
files, supporting so many users, wouldn't that be a serious bottleneck for
high-volume sites?

> So you've got a non-Java, non-servlet technique that
> builds a specific set of HTML based on your business
> requirements.  That makes it inappropriate to this
> list.

Fine.  But we're developing Servlets too, and they need to support the same
UI requirements.  Some of my peers are fairly purely Java programmers.

The RPG code I shared was more applicable to the RPG vs. Java discussion a
few days back.

> So if you have modeled this using any of the standard
> modeling tools, I think the resulting UML would be a
> great addition to the discussion.

UML discussions tend to become too theoretical.  In contrast, if one shows a
picture of a typical database maintenance activity, folks can more easily
comment on useful or possibly missing features.

The term "model" fits a number of contexts.  I picked it up from colleagues
who were developing under this approach twenty years ago, long before OO
languages became prominent.  In this context, it defines a technique where
fixed, base functionality is encapsulated, and extended via program code,
but doesn't precisely follow strict OO interfaces.  It's geared toward
procedurally oriented languages.  It's an alternative to code generators,
and meta-data driven utilities.

Models apply to situations where large-scale applications are being
rewritten, involving hundreds of database maintenance programs.  Is this
topic outside the scope of the Java community?  Will Java ever be extended
to Financial and Accounting systems, Manufacturing Systems, and so forth?

Nathan.