RE: Replacing IIS with iSeries 400 -- MIDRANGE-L

This depends on your architecture, Don.  A JSP is really a servlet - in
simplest terms, it runs on the host, formats HTML and outputs it to the
browser.  You can output JavaScript in the HTML stream, which can in turn do
some pretty fun stuff, but IMHO that's not a good design for any serious
business logic.

I'm not entirely clear on your requirements.  Client-side logic can entail
one of two scenarios:

1. Creating a "local" data image and updating it purely locally, and then
showing views of the local data to the end user (in the early 90's we coined
the term "detached processing" for this architecture).  This can even
involve a batched update back up to the host.

2. Interactive update of host data through logic on the client using an ODBC
bridge.

Personally, I won't do option two.  From what I know of IIS and RDS, if you
open an ADO to an OLE DB on the AS/400, you're directly updating data on the
host.  And even for temporary files you've got a whole lot of traffic going
on, and a bunch of overhead on your host.  It's just hidden from you as a
programmer, so it's not only slow, but you also have less control over it.
Other than that, how was the play, Mrs. Lincoln?

If this is your design goal, then I probably can't help much.


So let's assume you're doing option 1.  This is really a thick client
running in detached mode.

While there are applications where this is a good thing, there are
disadvantages as well.  Unless you are actually storing data on the local
hard drive, a failure on the client means you lose all work up until that
point, and workstations are notoriously less stable than AS/400's.  I'd be
interested in knowing more of your requirements here.

Anyway, if you're designing a true thick client interface, I'd be much more
likely to use a server on the host.  The server can be called directly from
the workstation, using sockets or IBM's Java Toolbox.  One call to the
server downloads the data, one call uploads it back to the host.  Editing
can be done at upload time or upon user request.  You have all the
capabilities of a true thick client application, but without being locked
into any particular transport mechanism.  You can even design this as an
applet, I suppose, if your clients refuse to install thick client software
on their PC.

In any event, you're now moving into an area where you're defining "how" you
want to do things, rather than what or even why, and so it becomes more
difficult to analyze.  Why do you want to have a "local" recordset that you
update?  Why not simply send update requests to the host?  As I pointed out
above, if you're using IIS RDS and ADO talking to an OLE DB source on the
AS/400, you're doing that anyway, except you're adding all the extra
overhead of ODBC, and you're tied to Microsoft's architecture.

Anyway, give me a little more idea of what your application needs to do, how
the users want to interact with it, and so on, and maybe I can make a better
recommendation.

Joe



> -----Original Message-----
> From: Schenck, Don
>
> Joe --
>
> Our operating condition: Our clients will ONLY use Internet
> Explorer 4.0 or
> higher. Nothing else.
>
> IF we use IIS and RDS, we can get a recordset from the server and do a LOT
> of database manipulation (adding, updating and deleting records) AT THE
> CLIENT without going back to the server.
>
> That's really nice.
>
> Can I do the same thing using XML and JSP with the 400?
>
> -- Don Schenck