Re: Web enablement options (previously private)

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>

> I'm not very familiar with Net.Data so I can't comment on
> the comparison, but AFAIK there is no "cache" per-se in IIS
> so ASP pages would always be read into memory.

My understanding is that ASPs are processed by a COM component that reads,
parses, and interprets the VB script found in the page.  That component
supplies a runtime environment for the script.  It is separate from IIS, but
uses ISAPI to interface with IIS.  I'd bet that COM component has some
internal storage for cached pages, similar to Net.Data.

> I have no problem reading data from tables on
> the AS/400 in ASP via ADO and SQL statements (select xxx
> from yyy where zzz)

That's a good use for scripting technologies, in my opinion too.

> However, I draw the line at any serious business logic or any
> updates (add/change/delete) of any kind.

That's good too.  For one thing, a lot of business logic mixed with HTML
leads to code that's hard to follow, and maintain.

> In all those cases we call stored procedures on the AS/400
> that are actually just RPG programs. These stored procedures
> are called from the ASP.

That sounds interesting.  How is it done?  Other ASP programmers who I know
like to create their own COM components for business logic.  It's separate
from the ASP, but is activated from the ASP, and runs under Windows.

> My ASP programmers are responsible for simple select queries
> and more importantly, making the site look pretty. They needn't
> concern themselves with the details of the business logic...

That's a good division of skills.

> On the flip side, my AS/400 programmers must concern themselves
> with these business-critical operations, but they could care less if
> the customer name was in red or green, bold or underlined, in Arial
> or Times New Roman.

Very good division of skills.

For robust, highly-interactive applications, my preference is to give the
business programmer a little more control.  The HTML page doesn't call the
RPG program.  The RPG program writes the HTML page.  A subtle difference
that puts the business programmer in the driver seat.  The HTML guru still
designs the user interface, but passes it to the business programmer to
implement.

Nathan M. Andelin
www.relational-data.com