Silly questions time:

What are WANs? I know they are Wide Area Networks, but are they like LANs? On LANs you can usually have a program on a server and run that program from a workstation.

You see we will soon get a question if we can run our OI app on a WAN. The WAN of that potential customer connects departments all over Norway. Their technical staff have not yet contacted us. So far we have just spoken with a less technical person who thinks that an app on their WAN must be client-server like, with separate modules for each department, communicating via TCP/IP.

I could of course wait until I know more, but I think I'd like to learn more about OI apps on WANs anyway. Any developers out there with any knowledge and experience?

- Oystein -

Hi Oystein,

I am currently developing an app that is supposed to run on a WAN. Basically you can think of a WAN as a REALLY slow LAN. The speed depends on how much money you want to pay, but generally they run at 128-256K. Compare that with the 10MBps of a LAN, an you will see that running your executable from a server does not make sense.

As far as I am concerned I narrowed it down to 2 solutions :

1. Put the OI executable on each client and leave only the data tables on the remote server

2. Use the internet/OICGI/Javascript to create HTML based data entry screens

The first solution lets you use your existing code, however should there be any upgrades, you will need to upgrade each client individually.

The second solution is the best for a TCP/IP WAN, but it has the disadvantage that HTML is not as feature-rich as a Windows GUI. You can do a lot with JavaScript but it means learning a whole new skillset aside from OI. The good news though is that the OICGI gateway works like a charm, and you can get HTML forms that read/write from the database in minutes. It takes hours afterwards to make them pretty and add bells and whistles though…

Hope this puts you on the right path.

Dave Pociu

d.pociu@snet.net

Dave,

Thank you very much for your reply.

1. Put the OI executable on each client and leave only the data tables on the remote server

Excuse me for needing this to be spelled out. What are the differences between this mode of running, and doing it the conventional way with the executable on the server?

- With the executable on the workstation the executable (etc) doesn't have to be loaded to the workstation, right?

- And a network product becomes a necessity, else way too much network traffic would be generated for a WAN if it's got such low transmission rates as you say.

- And of course there is the disadvantage you mention about each executable having to be upgraded separately.

But else? Will the app have to be specially designed? And what about doing the same on a LAN? Is that commonly done?

2. Use the internet/OICGI/Javascript to create HTML based data entry screens

I'm working on a web based version of the app and I think I know approximately what is involved with this your second alternative. Even if what I'm working on is strictly read only.

- Oystein -

Oystein,

Looks like you got the picture.

Yes, you try to avoid downloading the executable over a slow connection, therefore you put it on the client.

Yes, you absolutely need a network product when you distribute the app like that.

I don't think you need any design changes in your app, unless you can think of ways of minimizing the number of database accesses ( stuff you're not really concerned with on a LAN)

As for the Web interface, if your users can live with that, it might be the best WAN solution.

Dave Pociu

d.pociu@snet.net

We support a number of sites running across WANS. These vary from 64k to 512k in bandwidth, and run several protocols to support other applications and technologies, for eg AS400.

When we first started with WANS we were shocked at the performance levels we were achieving. Clearly, every bit of I/O has to be justified and this is where we focused our attention. Take the good old XLATE statement. What does it do? Each XLATE does an OPEN statement of the table. Then it does a whole lot of other stuff to do with caching and then finally does a READ (if the row is not in cache). Very expensive. Try it: Take a file with 50,000 rows. Compare the time it takes to read a column from each row with an XLATE. Then swap it for a READ. Then try it on a WAN.

We ended up with our own versions of XLATE and OPEN which improved performance substantially. Though this was all for our WAN users, it helped the LAN users as well by reducing traffic on (A) the server and (B) the network.

If you give a bit of thought to this, check your code out and if necessary streamline it, then you will find OI works quite acceptably over a WAN.

Nick,

Thanks.

Perhaps I simply have to run a trial at the customer, and see how the app performs.

- Oystein -

View this thread on the forum...