Re: Why NOT the web? -- MIDRANGE-L

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