Hi Grant,
I think you and Dennis have managed to open an *interesting*
debate between you about the option of Web development for n-
tier apps. We've been doing serious Webapp development for
nearly four years now, but until today, I didn't realise just how
hard it was for us <g>.
I'm not trying to extracting the Michael -- we've avoided ASP,
COM and ActiveX the whole time because we settled early on
WebHub, but literally hadn't realised until now how signficant
some of the pitfalls we thus avoided have been for other
developers.
(Of course, someone else who uses ASP a lot may have a
different perspective from yours, so let's await that end of things
as well). But FWIW, here's a few relevant comments from our
experience:
> > 1. Scalability - just add another server if you need more
> > processing power)
> True in theory (though it raises other problems), but if you host on an
> ISP, are they going to add another box because your app kills the CPU on a
> web server with maybe hundreds of other clients running on it? Its
If your app is effectively supporting a serious amount of traffic
with a serious purpose, justifying the iron necessary to achieve
that is not normally an issue. Of course, it helps if your app is
intelligent about managing queuing and resource usage. We don't
have problems of that nature with WebHub, because it manages
queuing for us, and doesn't depend on a (potentially explosive)
threaded model to handle each surfer as they come along.
And Dennis' scalability criterion is an important one. With round-
robinning, multi-server/multi-app-instance support and other such
features, there are some truly remarkable scaling opportunities
attainable with good Web back ends, none of which depend on
the power of the PC on the client's desktop.
> thin client that can be tuned to be efficient on bandwidth. MS tend to
> recommend that you start with grunty box with plenty of RAM just to run
> IIs & serve (ASP) pages. Adding apps that crunch sound & graphics does
> not help, (from personal experience <g>).
Actually, IIS itself is a very low resource consumer. ASP, I
presume, must not be. But WebHub apps on IIS can operate on
low to mid-range boxes with very acceptable performance (about
50ms per dynamic page); always have done. Finally, of course,
*whatever* the nature of your app's development base, iron is
damned cheap these days <g>.
> > 2. Ease of debugging (if you send you data in ASCII format)
> I found debugging ASP/ActiveX/IIs/Java etc far harder than any Delphi app
> (including 'thin' Delphi apps that use COM).
I agree with you. Debugging all of those must be ultra painful,
especially as you have to shut down the server to update them.
But, you see, we've never had to do that <g>.
On the whole, though, I agree that debugging a Webapp is harder
than a regular GUI one -- the special nature of HTTP and its (non)
management of connections makes for some "interesting"
issues. Even dodging the things you listed above, and with
WebHub easing our way in several areas, I'd rate this as one of
the more expensive development issues. But Dennis' comments
are quite true in that the communication stream is easy to
intercept, check and interpret, far less so than (say) Midas
socket streams, or whatever.
> just adding extra languages is always going to make it harder
> than a nice integrated environment than Delphi.
I don't add any extra languages <g>. WebHub is Delphi, and
OOP through and through.
> As for IIs locking COM objects until you shut down the web server
> (unless you fight with MTS) - enough said.
Don't have that problem, as noted above.
> > 3. Really thin client - all you need is a browser
> I haven't tried IE5 yet but there is no way you can use the term 'thin'
I agree the browsers have gotten bigger, so "thin" is questionable
in that sense. But we (as policy), don't depend on "latest"
browser design for public web sites we make. Unless the client
overrides our recommendations, we try for generic pages, in most
cases supporting browsers as long ago and seemingly far away
as NS 1.2. I've never liked any of the MS browser line (IE5 has
*some* promise) but supporting them all is not a big problem.
With that in mind, being able to say "point your (existing)
browser at this URL, and the app will work", is *truly* thin in
several important senses. So long as their machine has the
power to run the browser, it has the power to do WHATEVER the
Web site is designed for.
> > 4. Extensibility - write a Java/ActiveX component for use
> > with the client browser
> Nice but I develop using Delphi not Java. ActiveX is a nice for some
I'm with you on that. But I see a future for Java applets (not so
much ActiveX) on the Web. ActiveX has a place in Intranets, for
which many of these "web as middleware" 3-tier apps are being
be developed, however. In other words, while there are solid
reasons why you or I might not download a browser automation
component in order to to use a public Web site, that doesn't
preclude their effective use for real-world solutions on dedicated
or high-bandwidth networks.
> ActiveX objects or plugins I generally don't bother. Thing that killed
> ActiveX as an option for me was that my app talked to a DB - therefore the
> client machine needed the BDE installed which defeated the entire purpose.
That depends, of course, on your choice of database, and
linkage. We run DB-manipulating Web sites and clients all the
time without the BDE, on either browser or server end. (Caveat:
we're not doing any writing to a DB on the *client* machine, but I
expect that's not what you intended to imply).
> Sure is easier to setup but when you say 'only needs a browser', you
> have to be careful about which browser as soon as you start using DHTML
> then you start excluding browsers pretty quickly (and a lot of people
> still use IE3 etc).
See my comments above. A nice thing about WebHub-based
HTML delivery (and possibly several other solutions) is that you
*can* repurpose/re-present the HTML either for a generic level of
browser support or for each surfer's specific browser version (if
you are prepared to go that far -- many sites are, but it's a
judgement call). Again, if we are talking a specific 3-tier
"solution", mandating a particular browser, or a particular set of
HTML capabilities regardless of browser make or version, is not a
big deal.
> > 7. Great reuse of code - just change the HTML to suit
> > different clients.
> True - but managing this can get interesting...
It can, yes. But it also means that (with the right separation of
logic from HTML), the client can maintain the look-and-feel-and-
extraneous content (e.g. explanations, policies, additional
content, whatever) of the app without recourse to re-
programming. Harder for them if using ASP, I admit, but it
basically falls right out of the WebHub design, for example.
> 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.
Not an issue with WebHub. (Hey, I know it sounds like a
commercial, but I *truly* haven't seen the disadvantages of
(?some?) ASP-type solutions and the advantages of WebHub
laid quite so bare before ).
> I think web apps have great potential, especially for certain classes of
> apps but I remain to be convinced that the tools are there yet.
You *may* have been looking at the wrong tools <g>.
That said, it's fair to say that you and Dennis seem to have been
shooting at different targets. I believe there is a difference
between a dedicated n-tier app designed principally for in-house
purposes (and hence with a *relatively* defineable/controllable
environment) and a public Web site. Dennis, I believe, was
discussing the former for the most part; at least, that was the
framework of the original question, no?
In contrast, you seem to be saying "it's too hard to create a full-
featured *public* three-tier type Web-based application" (hence
discussions of ISP hosting issues; browser size and choice,
browser automation and so on, as if the whole world HAD to be
the target user community, in contrast to the in-house scenario
noted above). Considering such public web site issues makes
your case quite supportable, although I hope my comments
above have suggested it is *not* necessary to put it straight into
the "too hard" box if you have the right tools...
For more on why *I* think WebHub walks around many of the
issues you presented, see my white paper at
http://www.href.com/webhub/white.html -- it's nearly two years
old, now, but 90% of the issues you raised are covered in it...
(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...)
cheers,
peter
============================================
Peter Hyde, SPIS Ltd, Christchurch, New Zealand
* TurboNote: http://TurboPress.com/tbnote.htm
-- small, FREE and very handy
* Print-to-Web automation http://TurboPress.com
* Web design, automation and hosting specialists
Find all the above and MORE at http://www.spis.co.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
