Abstract

Internet/intranet application development has all the right elements for an object-oriented meta-environment. But how do you develop and balance this world of HTML pages, GIF images, Java applets, and SQL code? Wallop Software's Wallop WorkShop may be your ticket to easier Web site construction and management. (2,300 words)

By now, the principles of object-oriented programming are well known and represented in popular technology, such as C++, Java, and NEXTSTEP, as well as emerging standards like CORBA. Programmers use models like these to represent what happens to objects inside programs. But what if you were to use object class definitions to represent programs themselves, as well as other things in a software development environment? This is an idea that has been floating around the software engineering research community for several years now, but it has never been embodied in any mainstream software environment -- until now. Wallop WorkShop, from start-up company Wallop Software (Foster City, CA), finds the right set of circumstances to make the concept practicable.

In the late 1980s, object-oriented programming became firmly entrenched as the most important new methodology for creating software. Early experimental languages, like Simula from Norway and CLU from MIT, had given way to practical implementations like Smalltalk-80, C++, and Objective-C. Objects were on the brains of the majority of computer science students and researchers, many of whom were also studying software development technology.

Therefore it wasn't surprising that some of them came up with an idea that, in retrospect, seems fairly obvious: Why not represent the various kinds of entities in a software development environment as instances of object types? They -- yours truly was one of them -- began to try to figure out what methods and attributes would be right for object type definitions called, for example, SourceCode, ObjectCode, Compiler, and Linker.

One of the things we did to legitimize this concept was to look at existing, successful software development methodologies and extrapolate object class definition schemes from them. For example, if you looked at Unix environments and the C language, you would get very basic types like CSourceCode, ObjectCode, and Executable. The type CSourceCode would have methods called Edit and Compile, and perhaps others like Lint and Profile. Then maybe CSourceCode could be defined as a subtype of SourceCode, which in turn would have other subtypes like C++SourceCode or AdaSourceCode. And so on.

What good would a scheme like this do? In general, one of the main advantages of any object model is that it promotes quicker, easier construction of new software and changes to existing systems. Ideally, if we could synthesize a type definition scheme that was flexible and that captured the right set of characteristics of all objects in software development environments, then we would have the basis for a "meta-environment," a tool for constructing environments that can adapt to changing requirements.

For example, we could use the existing supertype SourceCode to make it that much easier to integrate new languages into our environment; just create a new subtype and implement any necessary methods. Or, if our language of choice has a new compiler that we want to use, we could simply "plug it in" as the implementation of the method Compile for our language. Ultimately, we could also use an object model to help create sophisticated tools that automate formal software development processes, such as "transformational" software engineering -- roughly, automatic creation of software from written requirements specifications.

Overcoming obstacles
This meta-environment type model looked nice on paper, but it had a number of obstacles to practical implementation. The most important of these is a sort of paradox. Clearly, such a scheme would be most valuable in environments for large-scale software engineering, where the most benefit can be derived from software process definition and automation. However, such situations usually have a more important requirement: stability. It is impossible for a group of dozens or hundreds of engineers, who are working on projects with years-long durations, to produce high-quality software when the environment they are trying to use is in flux.

Therefore, the best place for a meta-environment is at a very large software engineering organization with stringent requirements for software quality -- perhaps a defense contractor or a telecommunications company. Companies like these can use such a tool throughout the organization to implement well-defined development processes and to build environments that are tailored to specific situations. Indeed, much of the research into what I'm calling object-oriented meta-environments has been targeted towards this type of organization. Unfortunately, however, that's not exactly a huge installed base.

The other disadvantage to using an object-oriented meta-environment on such a large-scale is that, as with any large object-oriented system, a lot of work must be done to set it up with the right object types and implementations. The benefits of a meta-environment are even further removed from developed software than those of the programming language tools in an environment. It's that much harder for organizations to justify the effort and expense necessary to set up a meta-environment.

At the other end of the complexity spectrum -- small development projects, small groups of engineers -- object-oriented meta-environments are overkill. Rigid development processes are nowhere near as necessary when you have three or four developers who are all working in the same language (not to mention in the same room). And today's language tools, like NEXTSTEP, Microsoft Visual C++, and Java tools (Java WorkShop and Symantec Cafe), are far more tightly integrated than 10 years ago, when make and GNU Emacs on Unix were the closest things many people had to an integrated environment.

Nevertheless, the meta-environment idea remains attractive -- as long as the circumstances are right. As you might suspect, the right set of circumstances is a happy medium between the small and the huge. Specifically:

1. The environment has to contain a number of different development technologies that is big enough to make an object model worthwhile, but not so big as to make the task of setting it up onerous.
2. The technologies must be in flux, with new ones being added and existing ones being refined on a regular basis, resulting in the need to add new capabilities to the environment easily.
3. There must be a need to get the various technologies in the environment to work together, something that a good object model also helps promote.

Enter the Web
Internet/intranet application development definitely has the right set of circumstances for an object-oriented meta-environment:

1. Development technologies for Internet/intranet development are multifarious but finite. The set includes the client development languages HTML and Java, ActiveX, Perl, the dominant language for writing CGI scripts, SQL for writing server-side database code, plug-ins like Adobe Acrobat Amber, and Live3D/VRML and GIF/JPEG image tools.
2. These technologies are very much in flux, with "standards" being updated and new languages being introduced at an insane pace.
3. More and more developers need to integrate several of these technologies into nontrivial Internet/intranet applications.

For example, let's say a financial services firm wants to develop an application that allows users to search for stocks based on certain characteristics of their performance and then call up research reports about the selected companies. Such an application has several components: the basic Web pages contain HTML; the user's query interface is written in Java; the Java applet generates SQL code that accesses a relational database through the Java Database Connectivity (JDBC) gateway; queries return a list of matching companies; another Java applet lets the user select one of these and call up a research report that exists in the form of an Adobe Acrobat document.

This application involves several different kinds of development objects: some HTML pages, maybe a few GIF images, a couple of Java applets, a few pieces of SQL code, a set of database table definitions, and a collection of Acrobat files which could reside on multiple machines. Among other things, how do you organize all of it and keep track of dependencies between pieces?

Wallop ahead
Wallop WorkShop can provide many of the answers. Wallop WorkShop is a tool for developing and managing Web sites that is similar to products like Netscape's LiveWire Pro and O'Reilly and Associates' WebSite Professional, but has more features for supporting large-scale software development. It is a set of tools based on an object-oriented meta-environment that has built-in object types for Web application development technologies such as those mentioned above. WorkShop runs on Windows 95 and Windows NT, but it can be used with any type of Web server that is accessible on a LAN.

As you would expect, the set of object types in Wallop WorkShop is fully extensible through inheritance. This means, for example, that you could create a subtype of the HTML code type for an HTML database template type like Oracle ActiveHTML or Sybase web.sql, or you could create an entirely new type for, say, a new audio file format. The set of default types supplied with Wallop WorkShop includes interpreted Web language types (HTML, JavaScript, VBScript, and Perl) and types for audio and graphic elements (WAV, GIF, JPEG, and BMP). Notably missing -- for now -- is Java (as opposed to JavaScript, the interpreted Java-like language from Netscape), for reasons that will become clear shortly.

All of these types have sets of useful attributes and methods. Attributes include many that you would expect, like pathname of the file, size, creation date, and date of last modification. There are also some other useful ones, such as pointers to other objects that the given object refers to (ascendants), or objects that contain references to the given object (descendants). "References" can be hyperlinks (URLs) in HTML files, REQUIRE references in Perl scripts, and so on. The beauty of the object model is that each object type can have its own implementation of a method for finding references within an object of that type. For HTML code the method simply scans the file for <A HREF> tags. Java, however, is a compiled language, and it's harder to parse compiled byte-code to get this information. That's why Wallop doesn't support a Java type yet.

Wallop WorkShop supports multi-developer projects by allowing users to check objects out for editing and check them in again when finished. When you check an object out, WorkShop launches the authoring application of your choice. In other words, the object types include an attribute for "authoring tool." You can select authoring tools for object types in much the same way you would select helper applications for MIME attachments in Netscape Navigator or many e-mail packages. Many types of Web-related objects have several legitimate choices for authoring applications. For instance, you could author HTML using Netscape Navigator Gold, Microsoft FrontPage, or Adobe PageMill. You could also create GIF images with any one of several image editors. Once again, WorkShop's object model facilitates this feature; these authoring applications are simply implementations of the "author" method for the given types.

The object types, and their attributes and methods, provide the framework for a set of visual tools that make Internet/intranet development seem almost as tractable as C development with make and SCCS were in the good old days. The most interesting of these is Relations Views, a graphical representation of your entire Web site, which shows all references (as above) between objects, in a manner similar to Netscape's LiveWire Site Manager and O'Reilly's WebSite. Relations View keeps track of both internal and external links as your Web site changes.

WorkShop also includes a Deployment View that defines three stages of deployment -- development, test, and production -- and lets you define and manipulate configurations of files at each of those stages. The main advantage to this scheme is that it lets you move from one stage to the next with one operation. Wallop provides a Deployment Wizard that does this painlessly. The Deployment Wizard checks each object that is moved to deployment and finds its descendant objects (i.e., other objects that contain URLs or other references to the object). Then it automatically changes the pathname in the descendants so they point to the deployed object, and it redeploys the descendants as well. This function can be a lifesaver.

At the same time, I could easily see making this set of stages extensible beyond the given set of three. How about multiple test phases (e.g., unit and integration), multiple deployment stages (external versus intranet), etc.? What about parallel versions of the production Web site? This will become more important as Web applications become more complex.

The other major WorkShop tool is the Database Manager, a set of tools for building Web pages that interact with relational databases. Currently, Database Manager uses ODBC for database connectivity. Future releases will use native drivers for the major relational database vendors. Database Manager comes with a set of HTML templates for canonical database interactions (query, insert, update, etc.) and visual tools that populate those templates with the appropriate forms and generate the appropriate CGI scripts. These are largely redundant with database vendor-supplied tools like Sybase's web.sql. However, WorkShop Database Manager's visual interface gives you a handy way of viewing database tables so you can see what information is available. This is useful when designing Web pages that use data from a pre-existing database.

Wallop WorkShop includes many other useful tools. One is a mass-scale search-and-replace function that allows you to do text replacements across an entire Web site. I imagine that the developers at Wallop thought of building this feature when the company changed its name (from the original NetBuild to Wallop) and they had to update their own Web site!

Overall, Wallop WorkShop breaks new ground in the area of development tools for the Web because it is the first tool to apply features from large-scale software engineering to Web site development. Wallop recognizes that Internet/intranet application development is quickly becoming as complex as any other type of client-server project, and it understands that Web technologies have unique requirements that aren't met in any existing development tools. In particular, it has leveraged the object-oriented meta-environment model more highly than anyone outside of the huge-scale CASE-tool arena. As the Web and its constituent technologies evolve, and as Web applications become even more complex, Wallop should find it easy to add the right features and carry its customers along. In short, Wallop is entering as a major, high-end player in this exploding market.

Bill Rosenblatt is an Enterprise IT Architect at Sun Microsystems, where he specializes in media technology. Reach him at bill.rosenblatt@sunworld.com.

Bill Rosenblatt is the author of Learning the Korn Shell and a coauthor of Learning Gnu Emacs and Learning the Bash Shell. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

What did you think of this article?
-Excellent! -Okay -Poor -Too long -Just right -Too short
Comments:

• ActiveX plug-in http://www.ncompasslabs.com/
• Adobe Acrobat Amber http://www.adobe.com/acrobat/3beta/
• Java WorkShop http://www.sun.com/developer-products/java/
• Netscape's LiveWirePro http://home.netscape.com/comprod/server_central/product/livewire/ livewire_datasheet.html
• Netscape's Live3D/VRML http://home.netscape.com/comprod/products/navigator/live3d/index.html
• O'Reilly and Associates' WebSite Professional http://website.ora.com/wspro/
• Sybase's web.sql http://www.sybase.com/products/internet/websql
• Symantec Cafe http://cafe.symantec.com/index.html
• Wallop Software http://www.wallop.com/
• Wallop WorkShop http://www.wallop.com/products/default.htm
• A list of other Client/Server columns in SunWorld Online.

If you have problems with this magazine, contact Webmaster@sunworld.com
URL: http://www.sunworld.com/swol-09-1996/swol-09-cs.html
Last updated: 1 September 1996