WebSphere Studio (WSS) is IBM’s flagship Web application development tool. With WSS, you can manage HTML, image, sound, Java applet, Java Server Page (JSP), Java servlet, and other files that provide an application’s user interface and some or all of its business logic. WSS contains built-in tools to design HTML and JSP pages, including tools to edit scripts and graphic images. WSS connects to VisualAge for Java (VAJ), which is included in the product package or other Java integrated development environments (IDEs) for developing servlets and for more complex Java coding. Figure 1 provides a complete list of the tools packaged with WSS.
You can use WSS for a wide range of Web applications, from simple Web sites comprising interlinked HTML pages to complex, dynamic Web sites that use scripting, servlets, and JSPs. The WSS Workbench (Figure 2) provides the central environment from which a Web page designer or a Java developer checks out application files and launches the appropriate editing tools to modify application components. When an application is ready for deployment, the responsible person uses the Workbench to copy the necessary application files to appropriate target directories — a process called publishing in WSS. Once an application has been published, it can be made available on the Web via an HTTP server and, if the application uses servlets or JSPs, a Web application server.
Using WSS, a development team can create Web applications to be deployed with IBM’s HTTP Server and WebSphere Application Server (WAS) products or with other vendors’ comparable products (e.g., Microsoft’s IIS HTTP server, BEA’s WebLogic application server). Although WSS has a few built-in options that relate specifically to WAS, nothing significantly limits WSS-built applications to WAS or makes WSS necessarily the best development tool for applications deployed on WAS. WSS has a definite Java bias, which consequently means it isn’t a good choice for Web applications based on Microsoft’s Active Server Page (ASP) and Common Object Model Plus (COM+) platforms.
Managing Projects with the Workbench
Each Web application is typically organized as a WSS project; however, a project can include multiple applications or a portion of an application. Each project contains a tree of folders; the folders in turn contain the application’s files. A project is stored as a directory on the development system, and project folders are subdirectories under the project directory. You manage project folders and files — moving, deleting, and renaming them — from the WSS Workbench File view, which is the left pane in Figure 2.
WSS has a simple, built-in check-out/check-in facility that lets multiple developers work with a shared set of files and reduces the chances for conflicting file changes. To archive multiple versions of the files and use more sophisticated revision tracking, WSS also supports the version control systems (VCSs) listed in Figure 3. (There are some limitations to this support that you should examine if you plan to use a VCS.) When you work in the File view, WSS lists all project files and displays a red check mark beside those files that are checked out to you; a gray check mark indicates a file checked out to someone else. You can revise only those files you’ve checked out. When you check out a file, WSS copies it to a work directory on your system, and this is the copy you modify.
To create a new project, you select File and New Project and assign a project name and directory to hold the project. You can select a project template from the WSS Template directory, and WSS will copy the project template’s folders and files to your project. WSS supplies two simple templates, but you can also add your own. The WSS package includes the NetObjects Fusion product as an alternate way to create a new site using one of NetObjects Fusion’s templates. NetObjects Fusion also offers a popular set of graphical tools for constructing Web sites and designing Web pages. IBM apparently included a copy of this product to augment the features in WSS. Although the combination of products offers a lot of functionality, using both NetObjects Fusion and WSS requires learning two completely different interfaces and sets of editing tools.
Once a project exists, you can add new elements (i.e., files) to the project using one of about two dozen skeleton files shipped with WSS. For example, to insert a new HTML page, you can select the Blank.html skeleton file. You can also add your own skeleton files.
WSS has two wizards that let you quickly generate simple, SQL-based data-access pages for a project. More important, these wizards provide a fast way to generate servlet and JSP code you can cut and paste into more complex applications. These are basic wizards, so for most applications, you’ll also need to use VAJ or another Java IDE to complete the servlet code. Likewise, you’ll need to work with Page Designer (discussed later) or another Web page layout tool to create more sophisticated JSPs for presenting the data.
You can also use the Import wizard to copy files from an existing Web site by supplying its URL. The wizard attempts to crawl the site’s links and copy both HTML and other files. Of course there are technical (and legal) limits to what you can obtain from an existing site, but this is a helpful tool.
Another tool available from the WSS Workbench is a source-level debugger for servlets and JSPs running on a remote WAS installation. This feature even lets you compile JSP files on your local system so you can step through the actual JSP source rather than through the Java source created when WAS translates the JSP file at runtime.
A typical Web application has numerous links among its files, such as a link from a page to an image file displayed on the page or a link from one HTML page to another. Figure 4 shows 10 link categories that WSS recognizes, including custom links you create. The WSS Workbench Relations view, which is the right pane in Figure 2, shows links for a selected file (e.g., top.html). These links include links from other files (to the left of the selected file) and to other files (to the right of the selected file). Each link displays an icon that identifies its type. If you move the cursor over a link, WSS displays the type of link (e.g., embedded link) on the Workbench status line. You can follow a chain of links by clicking the plus sign (+) beside any linked-from or linked-to element to display all that element’s links. Clicking the minus sign (–) beside an element backs up in the current chain of links to the previous element. You can also use toggle buttons at the extreme right of the Workbench window to control which of the 10 link types are displayed in the Relations view.
Navigating links among a project’s files is helpful, but the most valuable aspect of WSS link management is that links are automatically changed when you move a referenced file from one folder to another. As I’ll cover in a moment, this capability also supports a very flexible approach to publishing a project.
WSS includes several other useful link-related features. You can select a file in the File or Relations view and then click a menu item to produce either a URL or complete HTML anchor tag string in the Windows clipboard. This string can then be pasted into a Web page that you’re editing with Page Designer to avoid errors caused by hand typing URLs. You can also analyze your entire project to produce a report of all broken links and "orphan" files (ones that have no links pointing to them).
When you’re ready to deploy a WSS project, you can do so with one click. Before you publish, however, you first define one or more publishing stages. A publishing stage essentially specifies the directory and file structure on the system that will serve the HTML, JSP, servlet, and other files. Figure 5’s right pane shows the Publishing view. By default, WSS provides Test and Production publishing stages for a project. Although initially the publishing stages have the same folder structure as the project itself (i.e., as shown in the File view in the left pane), you can rearrange a publishing stage’s structure, and WSS will keep track of the correspondence between a file’s location in the project and its location in the publishing stage. You can also use a variety of options to modify the effective URL for any file in the publishing stage. Once you’ve set up your publishing stages, the publishing step itself makes all the necessary translations of links in the project files to logically equivalent links in the deployed (i.e., published) files. Because you can define multiple publishing stages, it’s possible to deploy to a variety of test and production environments without having to make manual modifications to your application code. This feature is almost an essential requirement of any Web application development tool used for complex applications.
As valuable as this feature is, you should be aware of a limitation in the current version. WAS uses a URL aliasing mechanism called a Web path. This mechanism is WAS’s own approach to decoupling a logical identifier for an application resource (e.g., a servlet) from its corresponding file name and directory location. Unfortunately, WSS’s automated link support doesn’t handle WAS Web paths. IBM says this support will be added in the next release, but for now, there’s no good workaround, and it’s quite cumbersome to manage Web aliases manually.
There are many other useful publishing options, including the ability to specify that certain files or types of files (e.g., .java source files) should never be published. You can also place the cursor over any file in the Publishing view to display the URL that will be used for all links to the deployed copy of the file.
Editing Project Files
In the Workbench, you double-click a file to edit it. The file’s extension determines which program WSS launches to edit the file. Figure 6 shows the WSS defaults, which you can change.
As this list demonstrates, WSS doesn’t set up VAJ as the default Java editor because it’s not tightly integrated with WSS, as is the Page Designer and a few other tools. There are some hooks in WSS that let you use menu options to import and export .java and .class files between VAJ and WSS. To use this feature, you must have VAJ 3.0 installed, and you must be running the VAJ Remote Access Tool API. Using VAJ, check-in and check-out is controlled by the VAJ repository (or a VCS used by VAJ). WSS essentially works with copies of the files exported from VAJ, which should be treated as read-only files within WSS. I won’t go into VAJ’s capabilities in this article, except to highlight that WSS itself doesn’t provide any substantial Java editing tools; IBM supplies VAJ for that purpose.
Web Page Layout and JSP Support
Page Designer (Figure 7) is the WSS tool to edit HTML pages and JSP files. As you would expect, Page Designer lets you work with a WYSIWYG design tool (the Normal view) or directly with HTML, which you display by selecting the HTML Source tab near the bottom of the window. Page Designer keeps the WYSIWYG representation and the HTML source in synch as you work with either representation of the page. A third tab, Preview, displays the Web page as it would appear in whichever browser you’ve installed (e.g., Internet Explorer). Note that the Page Designer Preview tab doesn’t actually run servlets or JSPs; however, a preview function in the Workbench will preview the full application once it’s been published so it can be run on a Web application server.
I don’t spend much time with HTML editing tools, so I can’t assess Page Designer compared with other tools such as Macromedia’s DreamWeaver or Microsoft’s FrontPage. Page Designer includes numerous features and supports a wide range of HTML capabilities, including tables, cascading style sheets, and frames. Working with Page Designer’s layout interface was straightforward, and despite my limited experience laying out Web pages, I was able to add a wide variety of design elements without much difficulty.
I was mainly concerned about Page Designer’s support for JSP, which is the crucial meeting point for Web page designers and Web application Java developers. A JSP includes HTML, JSP-specific tags, and embedded Java code. When a JSP is run, the Web application server (e.g., WAS) translates the JSP source into Java source code, compiles the Java source code into a Java servlet, and invokes the servlet. An essential development technique with JSP is for an application servlet to create a JavaBean, put data results intended for display into the JavaBean, and then run a JSP that accesses the JavaBean. The JSP source includes calls to the JavaBean’s methods to retrieve values that are displayed on the page. (For more information about the role JSP plays in Web applications, see "A Guide to IBM’s Application Framework for e-Business," March 2000.)
The intermingling of HTML, JSP tags, and Java can get quite burdensome to code directly, so it’s important for a JSP editor to provide dialog boxes and other graphical tools to manage JSP source, just as WYSIWYG layout tools simplify working with HTML. Page Designer includes dialogs to prompt for attributes on JSP tags (e.g., jsp:useBean). In some cases, these dialogs include browsers to select an appropriate item (e.g., a JavaBean property) from a list. Page Designer also provides dialogs for setting document-level JSP elements, such as the URL for a custom tag library. The WSS Workbench has a helpful tool to create a JSP code snippet that loops across a JavaBean, which returns a database result set and puts the contents in an HTML table. The Workbench tool generates this snippet in the Windows clipboard, so you can subsequently paste it into a JSP that you’re editing in Page Designer.
If you understand JSP tags and embedded Java coding fairly well, Page Designer’s support is adequate to ease the job of developing JSPs. The biggest help comes from the various dialogs reminding you of the elements that can be specified for each tag. However, in my assessment, the tool doesn’t yet make JSP editing simple enough for someone lacking JSP tag and basic Java coding skills. For example, once you’ve pasted in a generated JSP code snippet to put JavaBean contents in an HTML table, Page Designer’s table tool doesn’t fully integrate the JavaBean’s properties into its layout dialogs. For some changes to the table, this requires you to directly edit the HTML, JSP tags, and/or Java source code rather than make changes with the table tool. This isn’t a fatal flaw in Page Designer, but don’t expect a Web page designer who’s new to JSPs to effortlessly start using your application’s JavaBeans in the pages he or she designs.
The WebSphere Studio 3.02 package provides a lot of functionality, particularly when you consider all the additional products that are shipped with the main WSS product. The abundance of separate products and tools takes some time to absorb, especially since many tools overlap, such as NetObjects Fusion and the WSS Workbench and Page Designer. It would be helpful if IBM integrated more of the "add-on" functions directly into WSS and improved VAJ’s integration in the Workbench.
Unfortunately, the documentation is perhaps one of the product’s weakest aspects, so learning how to use WSS effectively isn’t easy. The product’s Help dialogs are generally just reiterations of dialog fields’ labels, and the Studio Guide contains scant information and is poorly indexed (there’s not even an index entry for "Tables"). The Web-based library of documents isn’t much better — the documents are incomplete and, in some cases, out of date. The lack of current and complete documentation gives a bad impression of what is otherwise a useful product.
My experience thus far with WSS has proved the product to be generally solid; the only tool that presented a problem was the Applet Designer, which I’ve locked up repeatedly. The product was responsive during page layout and other operations. However, the lack of support for WAS Web paths creates a significant deficiency and makes using the WAS Web application model frustratingly cumbersome. IBM needs to fix this quickly. As a Java programmer, I was impressed with the JSP support, although there’s a lot of room to make this part of Page Designer more suitable for less-technical Web page designers.
Overall, WebSphere Studio 3.02 is a Web application development product that merits serious consideration. I can’t say it’s a "slam dunk," but if IBM can fill in a few gaps, enhance the integration, and provide complete, up-to-date documentation, WSS should be one of the leading contenders in this arena.
Paul Conte is a senior technical editor for NEWS/400 and president of PCES in Eugene, Oregon. Paul provides educational and consulting services in SQL and Java application development for the AS/400. You can reach him at (541) 344-2552 or email@example.com .
|WebSphere Studio 3.02 Product Information|
Price: $479 per developer
Platforms: Windows NT Server 4.0 (with Service Pack 3) or Windows 9x
Requirements: Intel Pentium processor, 32 MB of memory, and 180 MB of free disk space
First Look: WebSphere Studio 3.02