|
|
Site Design and Automation Specialists |
When considering Web site automation, there are several critical questions to ask about the framework you eventually choose. Your automation options might start with the following, but the range of generic and tied middleware is growing at a rapid pace:
Before getting too deeply into your automation project, it is vital to evaluate your preferred options against the critical questions below. Because so many of the limitations and pitfalls of Web development only become obvious when a site is placed online and subjected to live traffic, it will save you no end of bother if you have solid answers to these questions FIRST.
Do you have to develop the CGI/ISAPI interface yourself? Is "save-state" built in? Are demos with source included? In other words, are you going to be given enough information and working code for your initial evaluation that you don't have to re-invent the wheel in order to even trial the framework?
Or will you have to throw those skills away in order to learn a completely new scripting or programming paradigm?
How rapidly is a single page generated? How many pages per second can the architecture support? How does it manage when that level is exceeded?
Are you limited to boilerplate database applications or can you bring in OLE, DCOM, etc? Are you locked into a single web interface or web server? Can you maintain your web application remotely? Can you build your own objects with their own custom behavior?
Is the HTML embedded in the program code, or vice versa, necessitating a high skill level to change either one? Are you forced to obtain unlimited SQL licenses? Is the cost of scaling to additional machines (to support higher traffic) clear from the outset?
What happens in a high traffic situation? Is there protection for your system resources or will the whole thing overload? Can you easily deploy it across several servers to support a significant growth in traffic?
If security is based on Cookies alone, how will you deal with people who don't accept them? If security is based on codes on the URL, how will you deal with people bookmarking URLs beyond the "front door" and coming back later? If security is based on IP#, how will you deal with surfers on AOL who may receive a new IP# between page requests? Is a knowledge of NT security required in order to protect the web site? Can you do more than just enforce NT security?
If you buy in to the technology, will you be alone? What other developers are using it? How responsive is the developer to changing trends in the industry? Are there high-end sites that have solved problems similar to yours? Are there training seminars?
Is there a high cost to getting started? Can you try it before buying?
Will your Web sites become an unmanageable agglomeration of interpreted scripts mixed with SQL and/or HTML, or will you be able to express and maintain the underlying logic clearly and cleanly in a fast, modern, extensible programming language?
Update April 8th: We have answers provided for WEBHUB at least -- in this 27K Word document.
on any of the above (and other site automation issues) is welcomed.
Development Director
South Pacific Information Services Ltd
Author of Climbing Out on the Web -- a Web Site Primer
 |
SPIS home page | WebCentre | SPIS Webview | SPIS WebWatch | HREF WebHub | All contents © Copyright SPIS Ltd 1996-7 |
