HI all,
While browsing around I totally by accident ran into the X-Works
site today and started looking at their document that compares
X-Works CGI vs. 'Ole/DDE' solutions.
http://www.x-works.com/oledde.htmReading this document almost made me laugh - these people obviously
have no clue about how some other solutions (they mention FoxWeb,
but I suppose some of this would also lump in Web COnnection and
ASP etc.) work.
Just to clarify this misinformation I'm going to bring this up here
in public, because this type of crap is just unacceptable to be
put out as the law of the land.
Channels of OLE/DDE have another fundamental defect -- an OLE server serves one reqest from one channel at a time. It cannot do true parallel processing. In contrast, multiple instances of X-Works server program can serve multiple requests at the same time. That is, ten instances can server ten CGI requests at the same time. As a result, X-Work has 10-30 times better throughput than OLE/DDE based solutions. This is ridiculously wrong. First off all tools (including FoxWeb
which seems to be the scapegoat in the document) can run multiple
simultaneous requests. Web Connection uses a pool manager for this
or file based messaging with multiple preloaded instances. All tools
use a small connector app (WWWC uses ISAPI or CGI, X-Works CGI,
FoxWeb CGI or ISAPI
Performance 10-30 times compared to what? I'd love to run a
benchmark on this and see this thing bite it - no CGI application
will outperform an ISAPI application under anything but mild load.
And the last statemnet (10 instances) assumes unlimited server
resources. 10 simultaneous instances will not provide 10 much less
30 times better throughput than 1 instance. In fact 10 instances
will probably perform worse in a pure request count test than a
single instance on a single processor box.
X-Works has no huge hidden runtime, while OLE/DDE depends on some ?huge runtime (400+K). X-Works is under 1/10 the size of OLE/DDE based solutions. As a result, X-Works is intrinsically faster than any OLE/DDE based solutions. X-Works can deliver a lot more throughput than OLE/DDE based solutions. See Heavy traffic test .
While it may be true that an executable loaded is 1/10th of the size
than an application that uses COM or DDEe, the author obviously
doesn't understand that the COM/DDE runtimes only load once and
then stay loaded. A CGI executable reloads on *every single hit*
that uses that item. Starting a process, no matter how slow is one
of the slowest and most resource intensive operations an operating
system can perform. An ISAPI extension on the other hand loads
into memory and then stays loaded along with any runtimes.
OLE/DDE is designed to be a general purpose facility, not for web specific communications. It has a lot more overhead and complexity than X-Works, which specifically designed for the web. The overhead and complexity of OLE/DDE makes it not only slower, but also less reliable. A debugged X-Works application runs for months under heavy traffic without any problem, while other products (such as FoxWeb) need daily attention.
I love the way the starting statements are supposed to prove a point.
First off tools like Web Connection don't have to use COM for
messaging. As a pure ISAPI extension the ISAPI extension is just
as small as the CGI executable *and* it doesn't have to reload on
each hit. However, the reverse is true - in WWWC I can run either
using file messaging or COM and COM operations happens to be
considerably more efficient in request processing.
I don't know what mecahnism X-Works uses to communicate data to the
server application, but it has to use something (files, pipes,
shared memory) and all of those mechanisms have implied overhead
involved in them. COM happens to be very efficient in passing
messages - in fact they're more efficient than say named pipes and
in some instances even shared memory.
Reliability is a ridiculous point as well. I have several COM based
Web applications running that are serving upwards of 500,000 COM
VFP hits a day and the app runs for weeks on end without anybody
touching it - execpt to update code (which is why I say every few
weeks). It is true it takes some tuning to do this, but the problem
tends to be the Web server (IIS) and not COM or any other mechanism.
OLE/DDE based solutions require complicated channel and error management, while X-Works avoids all these. X-Works is a lot cleaner and simpler. Some products claim as advantages of their OLE/DDE error and channel management. It is like to add a fifth wheel (and all easy maintenance facility for the fifth wheel) to a car and claim advantage of the fifth wheel. The truth is that the fifth wheel should not be there at all. A four-wheel car is much lighter, faster, and easier to drive.
I don't know what this means really. I guess this is related to
FoxWeb and it's channel setup. But this is not required and certainly
not somethig that WWWC does. Because we're daling with a large
Executable (a VFP application) servers must be kept alive and the
VFp server must run some mechanism that can accept the messages
that the CGI/ISAPI application sends. Just because x-Works abstracts
this doesn't mean it's not happening. In WWWC the same abstraction
occurs, but it's still there regardless behind the scenes.
Running as NT service. VB/VFP is designed to be desktop applications. But, they can run as NT service through SRVANY.EXE (from NT resource kit). It is a stretch for some products to claim that they make VB/VFP run as NT services.
Well, here's one I can agree on. Running as a service is highly
overrated especially for Web apps. However, with COM you can configure
your objects to run before logon so you don't even neeed a service
to get that functionality - it's all controlled through the Web
service instead.
Some products add another layer of password verification (in addition to web server authentication). This is not necessary and only add to maintenance work. (X-Works pass authentication information from web server to VB/VFP. )
This is a feature??? This is part of the HTTP protocol and I would
hope every tool that claims to be a Web backend provides support for
this.
