|
As more companies rush to make their presence known on the Internet, competition for attention is getting fierce. Along with that competition comes the requirement from Internet users that a Web site provide some useful features and not just canned marketing fluff. One of the best ways to provide functionality on a Web site is to enable interaction with users by allowing them to submit requests, query inventories, or some other sort of active use of a company database. One product that aims to enable that process is WebSpeed 2.0 from Progress Software. WebSpeed is a development tool that contains both a front-end development component and a transaction server for interfacing to a new or existing database. WebSpeed uses a scripting language for Web pages that hands off data requests to the transaction processor. The transaction processor in turn runs queries against either the accompanying Progress DBMS, or an existing DB2, Informix, Oracle, or ODBC-compliant database. The data returned is then formatted according to the HTML and scripting on the appropriate Web page.
In any type of transactional environment, two of the most important considerations are security and data integrity. These concerns are magnified when an application is moved to the Web because of the open nature of the Internet and the unpredictable behavior of those accessing it. Any development tool that attempts to play in that arena must not only be able to protect the data it manages, but also marshal transaction throughput in a scalable manner. This is exactly what Progress Software has emphasized in WebSpeed.
Installation of WebSpeed requires Microsoft Windows NT 3.51 or 4.0 (for Intel or Digital Alpha), Digital Unix 3.2F or 4.0A, IBM AIX 4.1, Sun Solaris 2.4 (for SPARC), HP-UX 10.01, SCO UnixWare 2.1, and a Web server that is ISAPI, NSAPI, or CGI 1.1 compliant. Additionally you will need at least 32MB of RAM, 120MB of free hard disk space, and a CD-ROM drive. Because the WebSpeed Workshop is browser based, you will also need Microsoft Internet Explorer 3.x, Netscape Navigator 3.x, or another Web browser that supports HTML 3.2, Java, and JavaScript. Unfortunately, the supplied development environment will not install under Windows 95. For this review, I used the Windows NT version of WebSpeed running on a Pentium 166 NT 4.0 server with 64MB of RAM. For the Web server, I used Microsoft's Internet Information Server version 3.0. This was an evaluation copy from Progress Software distributed on CD-ROM with all of the documentation as HTML files on the disk.
Installation and configuration of WebSpeed are very easy and will even begin automatically after insertion of the media CD if auto-run is enabled. Otherwise, only a call to the setup.exe file is required. Once the installation has begun, you will need to know the location and type of your Web server, the location of the deployment directories, and the language or languages to be used by the software. After installation there is a configuration program for the transaction server that can be used to turn the service on or off, set the location and behavior of the log files, set system properties, set debugging options, and add or delete services. See Figure 1.
If you want to work outside the browser-based WebSpeed Workshop environment, you can use other Web authoring tools as long as they support HTML 3.2 and JavaScript events, such as Microsoft FrontPage. This is useful if you want to do remote development work on a platform such as Windows 95 and then deploy the finished product to another platform. Other than completely moving away from the WebSpeed Workshop, you can also extend the Workshop by adding tools, such as the image mapping program Map This, and templates -- an excellent feature for corporate shops that will want to develop standards for the way applications are developed.
Developing with the WebSpeed Workshop is very similar to developing for any other CGI environment. See Figure 2. The entire interactive process is run by scripts that are embedded into standard HTML pages. The scripts used by WebSpeed are written in Progress's proprietary SpeedScript language. While the keywords and syntax of SpeedScript appear more closely related to a BASIC-style language than to the Web development languages of Java or JavaScript, the commenting and other such constructs are of the type used in Java or C++. While this can be somewhat confusing to start with, it does not take long to become accustomed to it. The WebSpeed Workshop can also be used to write VBScript or JavaScript code that lives in the Web pages and is executed by the browser, but that code will not interact with the WebSpeed Transaction Server.
Other helpful aids to learning and developing in WebSpeed are wizards that are included for building standard data entry and request screens. The wizards are only one of three different ways to create applications in WebSpeed. The first is the manual method of creating the HTML pages and the embedded script. While this allows the most control over what it going on, it is also the most time-intensive in terms of sheer coding. The second way to create an application is to concentrate on the SpeedScript coding alone. Using this method the scripts will then generate the surrounding HTML. While working in SpeedScript and not HTML might be an advantage, this method requires a more in-depth knowledge of the SpeedScript language. Finally, you can assemble an application out of WebSpeed objects. These objects will in turn be used to create framed pages that contain scripts and maps that detail the action and location of database items on pages within the frames. This is one of the fastest methods to get an application up and running while at the same time creating HTML and SpeedScript files that can be edited manually to customize the interaction or interface.
WebSpeed's architecture allows for the full range of database interaction that a robust front end or a serious DBMS, such as Oracle or Informix, would require. With full commit, rollback, and security available in the transaction server (not the RDBMS server), as well as connectivity to any ODBC-compliant DBMS, there is no fear of creating an application that will not perform or scale well to most any use. Also, because the real work of the application is done by the transaction server and the back-end database, not the user's browser, target platforms can be as varied in power and operating system as they really are on the Internet. The only requirement for the accessing terminal is a JavaScript-capable browser, and these can be found for nearly all machines from workstation to server to network computer.
When a database transaction is originated by a user through a Web browser, that request is intercepted by your Web server. The Web server, based on the URL and the embedded script, passes the request to a WebSpeed Messenger. The WebSpeed Messenger passes it to a WebSpeed Broker. The Broker then passes that request to an available WebSpeed Agent for processing. The Agent processes the query, retrieves the data, and passes the data back to the Messenger. The Messenger then provides the data back to the Web server which in turn serves the data and all formatting to users through their Web browsers.
The Messenger, Agent, and Broker are all part of the greater whole of the Transaction Server. The Transaction Server makes sure that requests go to available Messengers, Brokers, and Agents and that those processes that are completed correctly and then freed up and returned to the pool of available processes. It is also through this interaction that commits and rollbacks are performed and data integrity can be maintained. In the greater sense, it is this ability to spawn and govern multiple process for multiple requesters that enable the product to scale instead of becoming the bottleneck. While I was not able to test the transaction processing in a heavily loaded scenario, judging from the moderate loads I was able to obtain, the WebSpeed should scale as promised when teamed with the appropriate DBMS.
Finally, agent debugging is available, with full logging of all or filtered transactions. This can be set up through the configuration utility, the SpeedScripts, or system parameters.
As I was describing WebSpeed to some associates, I kept thinking that the product is really good at what it does, but what it does simply does not go far enough to make me really interested. I'd like the ability to do simple graphs, images, or other features that would really make use of the advanced features available in today's Web browsers. While WebSpeed covers a lot of ground by providing both the front-end design tool and the back-end transaction server, it seems that the strength of the server is in some ways mitigated by the lackluster presentation.
All-in-all though, WebSpeed is exactly what Progress Software says it is, "Proven, Powerful, Productive." For transaction processing in an Internet or intranet environment, WebSpeed handles itself excellently with all of the robust features that should be expected of such a system such as security, commit and rollbacks, and full data availability. The competition is stiff with similar products on the market such as Oracle's Commerce Server or Application Server and Microsoft's Transaction Server, but the strength and integration Progress Software's WebSpeed definitely make it worth a look.
Figure 2
The WebSpeed Workshop is the browser-based development environment used to create the screen and scripts for WebSpeed applications.
Michael Carnell is a systems engineer responsible for client/server and intranet development and serves as a consultant to Performance Systems and Training in Charleston, SC. You can reach him by email at carnellm@palmettobug.com, or visit his home page at www.palmettobug.com/carnellm.