Re: Why NOT the web?

[Pete Hall <pbhall@xxxxxxxxxxxxx>]

At 16:44 12/29/2004, Art Tostaine wrote:
> I've told them that the web is not for this kind of stuff, it's for
> customer service, inquiries, simple ordering, etc.
>
> They've asked me to tell them why.

I've done a couple of update apps that use a web interface. There are 
limitations. You have to lock everything that is read for update so nobody 
else can get and update it concurrently. At the same time, you have to 
ensure that people who simply close the browser window don't leave a lock 
that will prevent anyone from ever accessing the data again. Some 
reasonable time-out needs to be established for locks, and batches need to 
be time-stamped so that only the last requester can update. Of course, 
there is requisite notification message processing that goes along with that.

Since the data transfer rate on the net is unreliable at best, you need to 
keep batches to the bare minimum size, but still include enough information 
so you can do some of the inquiry and selection stuff with DHTML or client 
side XML template processing. Otherwise, every request requires a separate 
trip to the server. It's doable, but requires compromise and some serious 
up-front planning.

You probably only want to return the things that have actually changed to 
the server. If you're returning a variable number of data elements, you 
need to be a little creative. You can return an XML datastream that is 
built on the fly in a textarea, for instance, or with IE, if you're going 
through a Microsoft web server middle tier, you can actually send an XML 
document object, which works pretty slick.

To communicate with the AS400 database server with .NET, I recommend you do 
not use ODBC. There's way too much overhead. ASNA has a dynamite sockets 
server and a tool kit to use it from any standard .NET language. It even 
handles connection sharing, which means that every connection doesn't 
require a new iSeries job. They also have their AVR.NET product, which is a 
complete VB-like programming language and handles the whole communication 
thing very transparently (really). Failing that (it's not free), you could 
roll your own sockets interface. I've had good success with dedicated data 
server application programs on the AS400 that do the database retrievals 
and updates, and communicate with the middle tier via a tab/CR delimited 
stream. It's as efficient as can be. Don't forget that if you use some form 
of connection sharing (highly recommended), and more than one trip to the 
server is needed to transfer a single transaction due to batch size, you 
need to lock the connection until the request is complete, or somebody else 
could start retrieving a different batch in the middle of the transfer process.

What about privacy? My understanding is that anyone who wants to can sniff 
just about anything they like. Do you care? SSL is an option. I suppose 
stronger encryption is possible too. I'm still a virgin in that area.

I wouldn't say it can't be done, but in order to do it properly, you need 
to address all of the above, and like I said, it requires some compromise 
of function/performance. A high speed connection to the client workstation 
helps too.

Pete Hall
http://www.pbhall.us