> Background:
<snip>
Nice to see a real world example. There are other real world web apps
around the place (try NZ real estate sites etc) that I have not been
impressed with. I even got a ODBC/SQL Server error message on the
www.searchnz.co.nz site last night.
> 1. Scalability. There are 16 TAFE institutes with
<snip>
> 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.
With 16 multiple processor servers + lots of clients running NT, would
the traditional library approach of a single AS400 or Sun + terminals
have worked out cheaper? I would have thought that a library search load
would have been quite low.
> 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.
HTML is easy - it is the bits of Java, Javascript and DHTML etc that can
cause problems.
> 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).
I like to at least test web apps on a 28.8 connection so 256kb even if
is not all yours is a luxury <g>.
> 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.
Gets back to my point - other than the simplest form based UI's, HTML
runs out of steam so you start needing Javscript/Java/DHTML etc...
> 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.
Ideal case I would have though for using low end PC's running Linux +
Communicator. Of couse X-terminals may have been cheaper still...
> 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.
No special handling to deal with external web customers having less
bandwidth?
> 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!
Er - no, 'other methods' that I have looked at all tend to use IP as
well so generally other methods still just require a fat pipe to the net
plus a small install to the users machine - ICQ is a perfect example. I
am currently dealing with apps that use x-modem sessions to companies
and hate having to deal with modem problems remotely - would never sit
down and design an app that required modem banks but some very large
companies (that shall remain nameless) still work that way.
> 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.
No argument there - in any app the aim should be to keep the UI
seperate. You still have to use seperate tools (Frontpage etc) in
developing your UI but the ncie thing is being able to hand over the UI
'now make it pretty' phase to graphic design professionals.
> 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
Shut down & start up IIs in less than a minute when it is carrying a
load?
> remotely from Brisbane, and can also be done from anywhere else in the
> world.
hopefully not from a hacker... <g>
> 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!
Sounds like you have done a good job on handling the issues, but not all
apps can be friendly on the web server being pulled out or be stateless.
> 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.
Sounds nice - suprised you had to write it though as I thought Altavista
would have handled it.
> 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.
Why the full GUI in this case and not others?
> 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.
Agreed.
> 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.
er - no, I would not 'rub off' using web apps but I would be very
careful about what sort of applications are suitable for the web app
approach. Certainly many data-entry or form style apps are very well
suited for even the traditional HTML form -> mail server approach but
complex apps where reporting, rich interactive UI & interaction with
other apps & devices is required are not good candidates IMHO.
> 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.
Agreed - I just think most 3+ tier tools are limited, expensive and/or
'hard' as there is no single tool for the job. Imagine if Delphi X
could spit out HTML/XML from forms, wrap all messaging to a (remote or
local) business logic layer and give full OODB back end independance.
- Grant
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
