RE: Where are all of the /400's going.

> From: Nathan M. Andelin
>
> My idea of data is what you put in a database, records and fields.  In my
> experience, the amount of data used for marketing and public awareness is
> minimal.  Are you thinking otherwise?  Or would you agree that there is a
> desire to protect the vast majority of data?

I agreed with you 100%, Nathan, until I started actually implementing real
world web environments.  In fact, the term I have been forced to use (at
least until someone comes up with something more palatable) is "web
presence".  Every one of my clients has had a far broader picture of their
web presence than what I thought it would be when I first started
implementing their web applications.

For example, most sites have things like mission statements and client case
studies and referals and "in the news" pages, and the clients want all of
this to interact seamlessly with whatever AS/400 application they are
planning on enabling.  They already have style sheets and logos and banners
and color schemes, and they probably have invested a good chunk of change in
their corporate look and feel.  This is the primary reason I've focused my
efforts over the last 18 months on servlets and JSP.  If you happen to
remember before that, I was a huge thick client advocate, because Swing is
to my mind a better application niterface than HTML.  But in order to
integrate with an existing web presence, I had to bite the bullet and learn
how to work and play with browsers (I don't consider applets a reasonable
alternative, either, but let's not rehash that particular argument in this
thread).

None of the existing stuff belongs on the AS/400, since it's really just
static data, and let's face it, DASD on the 400 is a couple of orders of
magnitude more expensive than what I can get in the store.  Even if I build
a completely raided system and include a redundant machine for failover,
it's still going to be far less expensive to do it with a *nix or even a
Windows box than with AS/400 disk.


> I agree that CPU is priced at a premimum on the 400.  On the other hand,
> take into account opperational efficiencies.  Web applications and static
> pages often share common graphics, style sheets, and other types of files.
> It's easier to manage that on a single server as opposed to dividing it
> between two servers.
>
> The management argument works both ways.  I've listened to IIS / FrontPage
> Webmasters argue to deploy Web applications on an Intel server
> for the same
> reason.  Maybe they simply don't know the 400, and don't want to
> learn about
> it.  Maybe the Webmaster resists having to ask for authorization to set up
> directories in the IFS.  Just another hassle, in his mind.

I agree that there is a management issue, and that issue is easier to
address when you force everything onto a central server.  In fact, I'll
remember to take that into account when I propose architectures.  The
tradeoff will be directly related to the amount of static data that needs to
be served, and the logistical requirements of keeping two separate sets of
control data.  The control data is, as you mentioned, the style sheets and
graphics, although it can be argued that there's nothing stopping an AS/400
application from using a style sheet or image served from another machine.
In fact, I think it's Akai that makes a business out of being a
high-bandwidth graphics server for otherwise low-bandwidth web sites.


> Once you divide data and applications across platforms, watch the
> political
> turf wars erupt.

The cleanest break is the division between static and dynamic data, the
fuzziest between secured and unsecured dynamic data.  Anonymous access to
mission critical data is always problematic, and each client I think needs
to make that call themselves.  I think that whatever architecture you use
should be able to handle either host-based or staged data.



> My question is whether [router] <==> [firewall] <==> [400 http server
> configuration] <==> [application level security] <==> [object level
> authority] is sufficient?  It seems to me that such a
> configuration already
> provides 5 layers of protection?

I'm not sure about this.  You're correct, of course, in your assessment.
And as long as someone implements all those layers properly, it's a good
solution.  Rememeber, though, that the original comment that started this
whole thread was the "requirement" to allow anonymous FTP to the host (or
FTP with hardcoded user ID and profile, which is essentially the same
thing).  That blows right through all five of your layers.

Joe Pluta
www.plutabrothers.com