IBM's WebSphere Studio lets Web developers group their work into logical associations that are file-type-independent. As a result, a programmer can work on an electronic-commerce Web project and not spend time worrying about where to place Java files for the client, HTML pages or Java servlet code. The programmer can tell WebSphere Studio that these files are part of the project, and when a certain file or group of files is needed, he or she can check them out and start working on them.

I installed and tested an early beta (version 0.6) of WebSphere Studio on a server running Windows NT 4.0 SP3. Although it is in need of some improvement--especially in terms of a better source-control system--this software will save developers lots of time. Its servlet and JDBC (Java Database Connectivity) wizards guide you through the process of creating servlets with ease, and installation was smooth. Note, however, that WebSphere Studio does not handle spaces in the CLASSPATH environment variable, and the software does not tell you why it is failing to start. You can turn to IBM's support forum on the IBM Web site (www.software.ibm.com/websphere) for the necessary solution.

WebSphere Studio is a part of a larger offering from IBM. The complete solution includes Visual Age 2.0 for full-fledged enterprise Java development, a WebSphere Application server (includes the free Apache Web server) and NetObjects Fusion 3.0 for dynamic server-side development.

Working With Files During Web development cycles, developers typically spend a good deal of time managing files and devising associations among HTML code, the correlated Java applets, JavaBeans and servlets (Java applets that run on the server instead of the client). During testing, WebSphere Studio let me create what looked like a normal folder holding all files pertaining to my project. WebSphere Studio appears as a two-pane application: One pane lists the projects as folders in a hierarchical fashion, while the other contains the files that belong in the folders.

Source-code control is vital to any large coding project, but WebSphere Studio's implementation lacks critical features, such as the ability to tag individual changes in the files with comments, user ID and time stamp. This feature would let programmers reveal any recently introduced bugs. I also missed the ability to track multiple revisions of the same file, which would let a programmer revert back to an older (but trusted) copy of code.

WebSphere Studio lets you perform several operations on files, including checking them in or out. When you check out a file, you get exclusive write access to that file. A more advanced source-code-control system would not require exclusive write access and would merge changes from multiple developers. When you check in a file, the user changes are updated in the master repository and the file is made available to all other people working on the project. This lets groups who are working on projects share development files with ease.

To use this simple process, I selected the file and then clicked my right mouse button, which produced a context menu that let me check the file into the repository. You can perform this procedure at any level in the hierarchy, applying it to groups of files, one project or all projects. Checking out files was a similar process. Once I had checked out a file, it was locked and no other developer could write to it, thus guaranteeing synchronization.

However, it would be better if WebSphere Studio let multiple developers check out a file simultaneously, work on different parts of it, and then have the system merge their changes. IBM says that the final version of the product will let developers plug in an external source-code-control system.

Wizard Magic During testing, I simply clicked my mouse a few times to publish my project's output on a Web server. Initially, I published the project to my local machine to ensure a smooth process and then published it to a remote server. Publishing to a remote server occurs via an automated FTP session, so some minor setup was involved on the server side. There is no interaction between WebSphere Studio and the remote Web server; WebSphere Studio merely creates the appropriate hierarchy of files on the remote server. The product works with a variety of server hardware and software, as long as the server can handle incoming FTP sessions.

I liked using WebSphere Studio's servlet wizard very much. This handy tool guides you through the process of creating a servlet. In the lab, I ran the wizard, which let me choose a JavaBean for my servlet. I had developed a simple JavaBean (separately, using Symantec Corp.'s Visual Cafı) that performs some mathematical modeling on an array of integers. The wizard automatically figured out all the available public properties and methods and presented them in a checklist. After I checked the ones I wanted, the wizard generated an HTML page with submit and cancel buttons, as well as appropriate text boxes for inputting values required by the servlet.

WebSphere Studio also generated the servlet code and my own custom error message. So instead of having the user see a server configuration error if something went wrong during the servlet execution, I was able to include a more user-friendly explanation. With a few clicks, all code was published and I was running my first servlet.

WebSphere Studio also includes a similar wizard that is JDBC-aware. During testing, it let me perform SQL queries against a relational database. With this wizard, however, you must be familiar with Java and SQL syntax to completely specify your SQL Select statements.

Ahmad Abualsamid is a senior partner with 1Internet Corp. of Chicago. Send your comments on this article to him at ahmad@execpc.com.