Grant,
> 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.
I agree - look at MSN's site - ODBC errors, etc. And this is a Microsoft
site using ASP! However, it goes both ways - there are good and bad web
applications, as well as good and bad C/S apps.
> 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.
The support costs for a mainframe solution would be too high - their old
system was mainframe! An integrated library system consists of searching,
front desk activity (issues, returns), plus all the associated backroom
activity (cataloguing, acquisitions, reporting, etc). It all adds up to a
lot of transactions per second!
> HTML is easy - it is the bits of Java, Javascript and DHTML etc that can
> cause problems.
The trick here is not to use fancy DHTML, etc. The javascript we use are
pretty basic - can be debugged even without the main web server. All you
need is a browser. We don't use DHTML - because we opted to use server-side
processing. One argument against using DHTML is it is not uniformly
supported and not supported by earlier browsers. When the project was
conceived, IE3 had just only hit the streets!
As a result of the decision, our web app can run on a multitude of different
browsers. One day, we might use DHTML, but I think Java looks a better
prospect. In any case, there is no need to debug the process all the way
back to the server. HTML is ASCII and this can easily be saved as a text
file for loading into the browser for debugging.
> 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>.
Most remote users can only come in on 14.4K modems. Seems to work for them
<g>. There are a few die hards that use 9.6K!
> 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...
Not if you design your server side correctly - sure HTML does not do fancy
UI stuff, but for all of our pages, HTML was more than enough. The only
reason we used Java was because of a contractual obligation. The same
operation can be carried out using plain old HTML.
> Ideal case I would have though for using low end PC's running Linux +
> Communicator. Of couse X-terminals may have been cheaper still...
Once again, it is part of the contract to supply them with new PCs. They
use the workstations for other uses, eg. MS Office. Linux and X-term for
Office, nah! I don't think so.
> No special handling to deal with external web customers having less
> bandwidth?
None. We sized the network from the beginning to cater for the extra
bandwidth. Other applications also use the network - by using TCP/IP and
HTTP, it meant that our apps were compatible. There was no need to
reconfigure firewalls, etc., because we use the standard port 80. And as I
have said before, the app works down to 9.6K.
> 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 -
How do you handle firewalls & security?
> 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.
Too right! Modem banks are a nightmare - and that's being kind on them!
Its the ISP's job and I prefer it stay that way.
> Shut down & start up IIs in less than a minute when it is carrying a
> load?
The beauty is IIS does NOT need to be shutdown! Keep the IIS running, shut
down our app, copy over the new files, restart the app. All done in less
than a minute (with the help of a little NT script).
> > remotely from Brisbane, and can also be done from anywhere else in the
> > world.
> hopefully not from a hacker... <g>
They have a system where the password changes every minute. There is a card
that displays the current password - and that is used to access the network.
Security is the client's domain - and they seem to have done a reasonably
good job on it. Of course, once on the internet nothing is 100% secure.
You can only try your best.
> 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.
If you design for the Web - you have to expect "statelessness". We store
all user data on disk, so it does not matter if the application was
restarted. Does not even matter if the network temporarily became
unavailable - it would recover once it is up again.
> Sounds nice - suprised you had to write it though as I thought Altavista
> would have handled it.
Not quite the same - Altavista doesn't allow you to place a reserve for a
book for example <g>.
> Why the full GUI in this case and not others?
That is a very good question. I guess the answer is because the rest of the
backroom modules are GUI (because they were developed way before the Web
applications), so to make this one Web wouldn't be very consistent with the
rest of them.
> 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.
Not everything is suited for a WebApp, that I would agree - like you say,
very complex UI. However, it might surprise you if you sat and thought
through what is and what isn't suitable. Most UI rich features can be
implemented on the server side - it will be different but not impossible.
> 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.
The good news is there *IS* a very good Web tool out there that handles all
of the above and more. It has its rough edges and is not 100% problem
free - but it is very useable and certainly made our job easier. Talk to
Peter H if you want more info. :). Saying that, I still feel there is room
for improvement. IMHO, the middlelayer tools market is not quite mature
yet.
Cheers,
Dennis.
-----------------------------------------------------
Dennis Chuah, BE (Hons) [mailto:[EMAIL PROTECTED]]
Manager, Product Development
Contec Data Systems Ltd. [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
