RE: New Development Project - What to do it in?

I'm part of a team of about fifteen (15) people who are studying this very
question.  In fact we've been studying it earnestly for about four (4)
months.  The justification for so much effort on "what to do it in" is
because our plan includes replacing about 2,000 green-screen and other
programs in a full-service software application, which currently supports
thousands of public schools, nationwide.

We've settled on a browser as the primary client.  But we're still doing
some prototyping with Java applets, XML with Style Sheets and a JavaScript
runtime engine, as well as HTML.  We're currently supporting these prototype
efforts with both Relational-Web/RPG and Java Servlet/SQL database
interfaces.

In a project of this scope, perhaps more important than any particular
language or commercial IDE, is employing an architecture which separates
application components according to the user interface, database, and
application control logic.

We probably have at least 500 database maintenance programs to write.  A key
to our success will be coming up with a model that enables us to create
these programs quickly.  We're not using any commercial code generators,
here.

Tens of thousands of users will be supported by these programs.  Daily users
include students, parents, teachers, counsellors, accountants, bus drivers,
clerks, school administrators, district administrators, application service
providers who host multiple school districts on perhaps a single iSeries
server, and others.

In cases where multiple school districts are hosted on one box, the
"application execution environment" much connect the right user to the right
instance of the database.  We will be retaining the existing database.  In
this case multiple physical file members are used to record snap-shots of
the data according to fiscal year, and other parameters.

A member of our team coined the term "Application Execution Environment"
(AEE) to refer to a number of runtime features which will be shared across
all programs.  We need a common login/logout procedure, a shared menu
interface.  The interesting thing about the menu is that it varies according
to the "role" the user plays.  Any given user may play a number of different
roles, including being associated with more than one district or school.
The login procedures and menu system must support this.

All programs must share a few common data elements - user interface styling
preferences, for example.

It would probably be suicide to attempt this type of project using thick
client-server technologies.  The development, distribution, maintenance, and
support of a Visual Basic type client would kill us.

With this type of application, the runtime environment, productive
development models, performance, and scalability are paramount.  On the
other hand, when you're just playing around with your first GUI interface,
does it really matter what you "do it in?"

Nathan M. Andelin
www.relational-data.com