Folks,
I think Peter Hyde has briefly explained the virtues of Web development
using Web Hub. I would like to approach it from another perspective. I am
going to use a real example, case study if you like - and I will not mention
tools except for Delphi and Java.
Background:
The project is an integrated library system. It was installed on the TAFE
(Oz equivalent to polytechs) Queensland network and services the WHOLE
Queensland state. The network is an intranet on a WAN, with some relatively
slow links (256Kb). The product is in use by all TAFE academic libraries.
There is a TAFE campus on EVERY major town and city in Queensland.
Searching the library catalogue is done via web access.
Size:
There are 16 institutes, each with one or more campuses, with a total of 48
campuses. Each campus has anything from 5 to over 30 workstations, which
may comprise of staff and public terminals. In addition, the catalogue is
accessible over the internet through a firewall / gateway scheme.
1. Scalability. There are 16 TAFE institutes with autonomous libraries.
Each have their own web server. The load is therefore divided into 16.
Each server is sized according to the expected load, plus some slack. All
are multiple CPU machines, and each normally run at about 30% load during
busy periods. Furthermore, should any one the institutes run out of
processor power, the design made it quite simple to add another server box
to handle the extra load. Given the connectionless model of the web, it was
possible to use round robin to even out the loading.
2. Ease of debugging. Because HTML is text, it is relatively easy to debug
problems. Application level debugging is done without leaving the Delphi
IDE. There is no need to step through complex SQL, triggers, etc across
different platforms to debug.
3. Really thin client - all you need is a browser. The web interface is
compatible with browsers from NS2 through NS4, IE3 through IE5. This about
covers all browsers there is out there. Not tested on WebTV though.
Anyway, if we did not use the Web model, it would have been impossible to
support so many clients on a WAN with speeds down to 256Kb (non dedicated).
4. Extensibility - write a Java/ActiveX component for use with the client
browser. While we did not use ActiveX, we did have a Java applet that did a
few nice UI things. The main thing is the Java applet was physically
separate from the main application - they did not depend on each other!. A
change to the HTML is all that is needed to add the Java applet.
Furthermore, the users have the choice of using the applet or straight HTML.
5. Ease of setup - everything is setup on the Web server - the client only
needs a browser. The public terminal workstations are installed with NT4
workstation using ZAK with MSIE3 as the shell. One configuration suits all.
The staff terminals are done with NT4 workstation, with MSIE3 installed as
standard. Once again, one configuration suits all. There were a total of
about 500 workstations rolled out! Some staff have opted to install
Netscape and they could do so and still access the catalogue.
6. No need to write another module for "web access" to your product.
Because the access to the catalogue is already web, it was quite simple to
open that access to the internet. This is especially important for
Queensland because of the number of students who live out at remote areas.
They are already on the internet, so to access the library catalogue, they
only need to point their browser at the web server. Other methods would
involve dial-ups and installation of expensive modem banks - not to mention
the software to drive them!
7. Great reuse of code - just change the HTML to suit different clients.
The HTML was customised to suit the TAFE needs, without the need for any
change in the Delphi code. As a matter of fact, we have other sites that
use the same Delphi code, but with different page layouts. Some work and
administration, but it is certainly easier than custom client applications,
packages or similar schemes. BTW, custom client apps are even more
difficult to administer.
Grant said:
> Mmmh - one of the problems we found was trying to figure out a
> way of doing updates on a 24/7 web app. You can down the web
> server but with HTTP being stateless, things can get difficult
> determining if you are pruning off users who are about to post.
With our system, we can do upgrades while the system is live. All we need
to do is to down the old version, copy over the new version and start it up.
This all takes less than a minute to achieve. The upgrading is done
remotely from Brisbane, and can also be done from anywhere else in the
world. Should the web application be down in the middle of a post, the user
gets a reply with a friendly message that basically says, "Please wait while
the application is being upgraded". There is a timed event that causes the
last post to be re-requested - so nothing is lost. At the timeout, the
client gets put back to where they were. Stateless HTTP was actually an
advantage for us! Data about the individual user is stored on disk, so it
did not matter if the app was upgraded. The best thing about upgrading is
the web server is never downed!
Peter said:
> (And heck, we haven't even discussed non-HTML (full-GUI) client
> solutions that employ HTTP and tools like WebHub supporting
> the server middleware! Maybe Robert Loof will chime in with
> something on that...)
We designed a Gateway web server that allows a client to simultaneously
search the 16 sites. It uses HTTP to talk to the web servers, collates the
replies and sends that back to the client browser. This module is unusual
in the sense that it is a WebServer that uses HTTP to talk to other
WebServers.
There are other Delphi apps within the suite of library system modules that
talk to the web server using HTTP. For example, one of them allows the
cataloguer from one institute to search the catalogue of another (remote)
institute (using IE), select a record for download into the local catalogue.
This module is a full GUI client, that embeds IE.
The best thing about developing the above two modules is there is no need to
modify code in the existing catalogue searching module. We only need to
modify the HTML. This is *REAL* reusability and extensibility.
Conclusion:
While it wasn't 100% plain sailing for us, choosing the web model did make
it POSSIBLE and EASIER. I do not know what Grant's experience is with
traditional n-tier development and deployment, but given the above case
study, it would be silly to rub off using the web as the middle tier.
Regardless of which tool you choose (and do choose carefully), the web is a
very powerful tool and I see it replacing traditional n-tier client/server
methods. It is not hard and certainly not impossible. If you haven't used
it, you don't know what you are missing.
Now ... on with the next project ...
Regards,
Dennis.
-----------------------------------------------------
Dennis Chuah, BE (Hons) [mailto:[EMAIL PROTECTED]]
Manager, Product Development
Contec Group International. [http://www.contecds.com]
tel: +64-3-3580060 ext-775 fax: +64-3-3588045
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
