Database Development for the Web

Java will play a significant role as client/server applications move to the Web

OOPSLA'97 Midyear Workshop Birds of a Feather Presentation
~~see also Business Transaction Workshop Position Paper: Business Objects vs. Business Transactions
Lead article in WebApps, May/June 1997
Jeff Sutherland, Senior VP Engineering and Product Development
IDX Systems Corporation <jeff.sutherland@computer.com>


Objects and the Web

"The Web is considered at one level to be a web objects, although documents on the web are quite different in many ways from objects in traditional distributed object-oriented systems. Will the two models continue to coexist, interacting weakly in certain cases, or will the relationship between the two worlds become well enough established for them to be regarded as one?"
Tim Berners-Lee, Director World Wide Web Consortium
The World Wide Web exists because of object-oriented systems. Tim Berners-Lee was interested in hypertext systems at CERN in October, 1992. His boss said he could not justify any formal investment in a hypertext project, but that he was interested in the new Next machine and what it could do for CERN. If Tim would evaluate a Next machine, he could hack hypertext on it until Christmas. In one month, he had the first WWW browser and before Christmas the first editor to support creating content for his browser went live. The rest is history.

At a recent Object World Keynote Address, Berners-Lee pointed out that every group that tried to implement a browser after him took a year to do it. [Berners-Lee, 1997]. The uniqueness of the Next machine was the productivity of its visual environment for creating plug-and-play components. Without it, the Web would not exist in its current form.

Berners-Lee did not have a year to deliver a working system, and neither do most U.S. corporations in the Internet age. Little did he know, that he would be the first example of the Internet three-month product cycle. To live long and prosper in this brave new world, software developers will need to learn to deliver distributed object systems as fast as Berners-Lee delivered the first browser.

Most of us will not build Web-based distributed object systems with a Next machine, but we will deliver them with Java. Productivity will depend on using a development environment with the Next machine characteristics, a tight integration of a visual development environment with component generation facilities more sophisticated than applet builders, and seamless coupling with object/relational databases and other Internet technologies. This paper lays out the conceptual direction we are heading in building distributed object systems for the Web - the integration of Java, objects, databases, and the Web.

The Java Revolution

"A revolution has got to leave the world with a totally different view of itself -- its got to be a paradigm shift… When you've got a revolution like this, don't think about applets. We're talking about a situation where the whole content of your machine is going to have a totally different shape[to] it. As a result the whole society, the whole commercial environment around all software is going to look totally different. " [Berners-Lee 1996, Brickman 1996]

Java is the cleverest attempt at a Trojan horse yet. The Netscape browser grabs screen real estate, sort of like grabbing shelf space in the local supermarket, and Java delivers the goods right into the heart of Microsoft territory and breaks their lock on the desktop. No wonder Bill Gates announced a counterattack on Pearl Harbor Day last December. Internet World dresses him up as a WWII General and outlines his strategy in the March, 1996 article, "Microsoft Declares War." Gates portrayed Microsoft as the suffering, innocent, American people while Netscape is billed as an unfeeling Japanese air strike on Pearl Harbor. [Sutherland 1996]


"By the pricking of my thumbs, Something wicked this way comes, Open, locks, whoever knocks." [Watson 1996]


The Netscape/Java combination is the first credible strategy to free the software industry from the iron grip of Microsoft. As a result, every leading software and hardware vendor has rallied around Java and Microsoft has had to join the pack and support Java in Microsoft products. Every major C++ vendor will become a Java vendor to survive in the C++ marketplace. C++ currently owns about 42% of the market for development of object-oriented applications [Object Magazine, 1995]. In the future, a substantial portion of the C++ market will turn into a Java market.

The popularity of Java has a signficant impact on Smalltalk and C++ developers, because Java can be viewed as a crippled Smalltalk for C++ programmers. It avoids the complexity of C++ by introducing features which have been part of the Smalltalk environment for 20 years. More important, it can be seamlessly distributed over the World Wide Web. It is free, totally portable, runs on every major hardware platform, and is supported by every major hardware and software vendor.


Java is not Fully Baked Yet

Smalltalk is currently running in 15-20% of the production, object-oriented, client/server business applications [Object Magazine, 1995]. Most of the rest are C++. Java is running in about 0% of these applications today because it is not robust, performance is poor, and Java development environments are not ready for prime time. It is useful primarily for applets on Web pages and not much else. In current developments efforts for one of the leading Internet news providers, Individual, Inc., Java was used for building registration applets. Lack of tools, slow performance, and security restrictions prevented deployment of these Java tools on their Newspage sites.

While Java has been designed to deal with the security issues posed by the Internet, it cannot effectively deal with client/server development on corporate intranets. For example, consider the security restrictions that are built into the Java applet execution environment:

Consider one of the simplest of all client/server applications, updating a local computer clock to atomic time. I use a Java application, TickTock that calls the U.S. Naval Observatory atomic clock server (violating security restriction 1), evokes an operating system call on my local machine (violating security restriction 2), and writes the current time to my system clock (violating security restriction 3). This is one of the simplest of all client/server applications and it cannot be run as an applet.

Today, even Sun Microsystems does not recommend building major client/server production systems with Java. It's current perfomance and garbage collector limitations are similar to the first Smalltalks implemented in the 1970's. Nevertheless, Java currently stacks up pretty well against other major object-oriented languages. The table below originally appeared in "Smalltalk, C++, and OO COBOL: The Good, the Bad, and the Ugly" [Sutherland 1995].

The table is extended to include Java and has been critiqued by many members of the comp.lang.smalltalk, comp.lang.c++, and comp.object newsgroups. Despite isolated objections to particularly entries in the table, the ratings are adjusted to reflect a widespread consensus of opinion in the newsgroups. Java stacks up remarkably well for a new language.
 
 
ST
C++
OO
COBOL
Java
Flexibility 
Dynamic Binding 
1
2
2
2
 
Dynamic Classes 
1
3
1
2
 
Multiple Inheritance 
3
2
2
3
 
Roles/Interfaces 
2
3
3
1
 
Function pointers/lexical closure 
1
2
3
3
Ease of use 
Class Libraries 
1
3
3
2
 
Learning Curve 
1
3
2
1
 
Speed of Development 
1
3
2
2
 
Portability 
2
3
3
1
Support 
Tools 
1
1
3
3
 
Multiple Vendors 
2
1
3
1
 
Internet Aware 
3
3
3
1
Performance 
 
2
1
3
3
Risk 
Garbage Collection 
1
3
3
2
 
Memory Leaks 
1
3
1
1
 
Overwriting Memory 
1
3
1
1
 
Ready for Prime Time 
1
1
2
3
TOTAL 
(low means best) 
25
40
40
32
Table 1: Smalltalk, C++, OOCOBOL and Java: The Good (1), the Bad (3), and the Ugly (2)

Much of the leading compiler talent on the planet is currently dedicted to providing good Java tools, improving Java performance, giving Java a state-of-the-art garbage collector, and generally getting Java ready for prime time. As can be seen from the table below, with good tools, excellent performance, and a robust environment, Java will outrank Smalltalk as a software development language.


Can Java Help with the Software Crisis?

It is not news that there is a software crisis. The news is that it is getting a lot worse: Java does not produce any more functionality per line of code than C++ [Jones 1996]. It's automated garbage collection might reduce lines of code required by 40% [Object Magazine 1996]. The elimination of pointers in the language significantly reduces debugging time and eliminates memory leaks, producing more robust applications.

Recently, working with a Personal Software Productivity (PSP) seminar [Humphrey, 1996], I tried out Java development environments on the first exercise in Humphrey's PSP book. The task was to create a simple application using a link list to calculate the mean and standard deviation of a set of numbers. My goal was to do this exercise faster than the hour it took me to code it in Perl.

After several hours of working with Microsoft J++ and Symantec Visual Cafe, I gave up. Turning to Smalltalk, I completed it in half an hour. This made me suspect that the Smalltalk developers are the ones who understand how to implement development tools. Turning to Parcplace Parts for Java, I completed it in one hour by writing one method. The rest was point and click. The conclusion--Java's event model is weaker than Smalltalk and until it is fixed, even the best Java environment is not as good as Smalltalk. In addition, the Parts for Java metaphor is useful for applets or small components but does not scale up to large distributed systems. These differences are critical in an Internet product cycle of three months.

Yet another computer language won't solve our software productivity problems. Only component based development with scalable, advanced development environments can really help. We need enterprise solutions based on business object design and implementation [Sutherland 1995]. New approaches to software development and higher levels of engineering skill are required. Future enterprise solutions will be Web-based, but when will Java be able to support them?


Why Component-Based Development?

The global market has become an intensely competitive environment moving at an accelerating rate of change. Gradual improvements in productivity and enhancements in quality are no longer enough to maintain market leadership. Time to market of new products and rapid evolution of old products and applications are key success factors.

Accelerating product evolution requires reinventing the processes that bring products to market and eliminating processes that do not add value. Since modern corporations have embedded many rules and procedures for product delivery in computer systems, the software applications that run the business must undergo significant change. To gain the strategic advantages of speed and flexibility, corporations must remodel their business processes, then rapidly translate that model into software implementations.

Business Process Reengineering (BPR) sets the stage for continuous evolution of business processes to meet rapidly evolving business requirements. Implementation of software systems that support BPR requires Business Objects that can both simulate corporate procedures and translate smoothly into software objects. Well-designed Business Object implementations can be easily modified as the business changes.


Business Objects as Reusable Components

Early adopters of object technology asserted that packaging software in object classes would allow software to obtain some of the benefits of Moore's Law seen in IC chip fabrication [Cox 1986]. Some projects have achieved major productivity benefits. For example, a Maintenance Management System at General Motors originally written in PL/I was rewritten under EDS contract in Smalltalk and achieved a 14:1 increase in productivity of design, coding, and testing [Taylor 1992]. Detailed analysis of this project showed 92% fewer lines of code, 93% fewer staff months of effort, 82% less development time, 92% less memory needed to run, and no performance degradation.

While there are many isolated projects that used object technology to achieve dramatic productivity gains during the past decade, this success has not translated into broad improvements across the software industry. In 1995, META Group reported that, "despite the promise of reusable objects, most IT organizations have realized a scant 10%-30% productivity improvement from object technology (OT)." Failure to achieve larger productivity gains was attributed to:

While productivity gains from object technology in recent years have been limited, some companies have been able to achieve dramatic returns on investment by bringing products to market sooner, with the flexibility necessary for rapid tuning of the products to meet changing market conditions.

For example, a recent analysis of return on investment (ROI) from object-oriented development of robotics software by Marcam Corporation showed a $56.5M return on a $6M investment. Return was calculated by multiplying the value of an improvement by the estimated probability of its occurrence and dividing by the cost of the improvement. The following spreadsheet was generated [Software Magazine 1996]:
Perceived Advantage 
Advantage Improvement 
Probability of Occurrence 
Incremental Cost 
ROI 
Time to Market 
$100M 
.4 
$3M 
$37M 
Flexibility 
$100M 
.2 
$2M 
$18M 
Productivity 
$2M 
.8 
$300K 
$1.3M 
Quality 
$1M 
.9 
$200K 
$700K 
Other Costs 
$0 
-- 
$500K 
-$500K 
Code Size 
$0 
-- 
$0 
$0 
Reuse Requirements 
$0 
.9 
$10K 
-$10K 
TOTAL 
 
 
$6M 
$56.5M 
Table 2: MARCAM Return on Investment for OO Project (corrected)

Business Objects are designed to support a clearly defined relationship between BPR-defined business processes and software implementation of these components. Using an object-oriented development methodology yields quick time to market and good object-oriented design allows for rapid evolution of Business Objects in response to market conditions. The bottom line is that object technology is a necessary, but not sufficient condition for large returns on investment. It must be combined with focus on delivering Business Object Components that enable fast and flexible delivery of new or enhanced products in the marketplace.


The Need for a Business Object Architecture

As business models are renewed, software architectures must be transformed. A Business Object Architecture (BOA) is an effective solution for dynamic automation of a rapidly evolving business environment.

Dynamic change requires reuse of chunks of business functionality. A BOA must support reusable, plug-compatible business components. The two primary strategies now being used for implementing client/server systems to support reengineering of business processes are visual 4th Generation Languages and classical object technology. While both of these approaches are better than COBOL, neither of them can effectively implement Business Objects.


Building Business Object Components

A group of objects is the ideal unit of reuse. These groups of objects should behave as a higher-level business process and have a clearly specified business language interface. Business components are encapsulated with a protocol that allows efficient communication with other objects on the network.

Consider a typical client/server application like an order entry system. This system takes a Purchase Order as input and produces a validated order as output. The internals of this component should be a black box to the external world. The resulting order is input for another subsystem or, alternatively, an exception condition is raised if the Purchase Order is not valid for processing.

Figure 1: An Order Entry Business Object

To support plug-compatible reuse, a business component must be encapsulated in two directions. The external world must not know anything about component internals, and the internals must not know anything about external components, other than allowing interested objects to register for notification of specific events or exception conditions.

The internals of a business component are made of other encapsulated business components. For example, when a Purchase Order passes through the membrane of the Order Entry business object, an internal component must see it, validate it, look up customer information, inventory availability and catalogue pricing, and build an order that is consistent with business rules and procedures. Each of these tasks is accomplished by embedded components, many of them communicating with external data sources.

External databases must be encapsulated as Business Objects or reuse will not be easily achievable. There must be a database access component that causes values from any kind of database to materialize as objects inside the business component. Whether object-oriented, relational, or other database access is required, a set of class libraries designed to automate this interface will result in a major savings in development resources [Sutherland et al 1993]. Vendors producing products in this area include Persistence and Ontos for C++ systems. Riverton Software and Vigor Technologies have new products under development for the Visual Basic and Java environments.

An Order Entry business object will typically have multiple user interfaces. A clerk may be taking the order over the phone, entering purchase information, validating customer records and credit data, and reviewing an order for consistency and customer acceptance. Other users may require different presentation screens. User interfaces are difficult and time consuming to build at the code level. Today, much of this process can be automated. They should be encapsulated as separate objects that communicate by message passing to the Order Entry object. Failure to do this will limit reuse and waste valuable programmer time on laborious, time consuming maintenance tasks. Users should be able to create interface objects with simple object-oriented tools. Subsequently, the programmer should be able to easily snap user interface objects onto the Order Entry object.

A simple Order Entry client/server component has at least three large-grained components, one or more presentation objects, a business component that models the business process, and a database access component that shields the application developer from database access languages, database internals, and network communications.

Figure 2: Client-Server Component

Business Object programmers focus their efforts on building business components, or large-grained Business Objects, which can be easily distributed on the network.


Distributing Business Objects

System evolution will invariably distribute these Business Objects to maximize network performance and processor utilization, and to ensure proper control, integrity, and security of information. Business reengineering implies implementing a distributed environment where components encapsulating business functionality can be migrated to nodes on the network that allow maximum flexibility, scalability, and maintainability of a Business Object system.
Figure 3: Application Business Object with Nested Client/Server Components

Business objects made up of nested components allow distribution of these components across a network. Figure 4 shows the logical application as a coherent set of nested client/server components. Deployment of this large-grained object may include distributing subcomponents across multiple heterogeneous computing resources in dispersed locations. Thus, an application designed on one processor is scattered across a network at run time.

Developers of business information systems are beginning to take advantage of building applications with OLE components. At Object World in San Francisco, Allied Signal won the Computerworld Award for best object-oriented application of 1995 [VMARK 1995]. They reengineered the Supply Management Business Process that took 52 steps to purchase a single part, so it now requires only three steps to complete the same transaction. The old process required seven people and took nine weeks to produce an approved purchase order. The new Supply Management Specialist Tool (SMST), developed with the Object Studio [VMARK 1995] advanced development environment, allows one person to complete the same process in nine minutes for established suppliers with long-term agreements in place. In the case of new suppliers, where a Request For Quote (RFQ) is required, the process takes nine days.

In this example, cycle time of the process is reduced 2400:1 for established suppliers, and 5:1 for new suppliers. Cost reduction is operational staff is 7:1. The impact of improvement in business efficiency leading to greater customer satisfaction and resulting market share is far greater than any reduced costs in operations overhead or development time and is the prime objective for the use of Business Object design tools to assure success of Business Process reengineering practice.


A Web-Based Solution for Business Object Architectures

To enhanced competitiveness in an environment of accelerating change, businesses are turning to Web-based solutions for Intranet client-server applications. Some potential benefits are: Building non-trivial client-server applications on the Web requires more than HTML programming. Current approaches are not object-oriented, CGI invocations must return a new screen on every interaction and context is lost. Every CGI access reopens the database, dramatically reducing performance characteristics of the application. Working around these problems requires a high level of technical skill and significant development resources not normally available to corporate MIS shops.
Figure 4: Typical CGI-based Web Interaction

Current development in Internet companies is typically focused on an object-oriented implementation that improves maintenance and enables reuse. C++ CGI components are used to maintain open database connection for sessions, radically improving performance. Java applets communicate with the C++ components to maintain context between screen interactions.

Figure 5: Enhanced Java/CGI Implementation

The minimal environment needed for easily implement client-server applications on the Web includes:

Figure 6: Applet/Servlet RMI Implementation


Current Progress in Java Client-Server Applications

The lack of tools to simplify implementation of the architecture in Figure 5, is currently a major inhibiting factor for movement to Java-based client-server applications. The lack of a robust, bug-free Java integrated Java development environment is a second impediment. The third major handicap for building these applications is lack of a component based development environment required for building business object architectures.

Completion and industry acceptance of the evolving Sun Javasoft Java Beans Specification [JavaSoft 1996] is required for building standard Java components and Object Management Group (OMG) standardization of a Business Object Facility [OMG 1996] is a core requirement for building standards-bases Business Object Architectures from Java components. The Java Beans specification has stabilized and a recent OMG submission (informally called JBOF) of a Business Object Facility for building distributed object systems is promising [JBOF, 1997]. This proposal will have a concrete implementation in Java and serious developers should review how it handles business rules, events, roles, constraints, assertions, transactions--all the things that are requirements for large scale, distributed object systems.

Microsoft Leads the Charge

One of the most encouraging developments for building distributed object applications for the Web has been the synergy between Java and Microsoft's ActiveX strategy based on OLE/COM. It turns out to be as easy or easier to use Java for creating COM components as it is to use Visual Basic or C++. In fact, comments from Microsoft's COM architects at a recent Object World indicated that Java is becoming the language of choice for COM component implementation [1997]. Microsoft has enabled every ActiveX component to look like a Java class to a Java application and every Java class to look like an ActiveX component to a Windows application [Chapell 1996].

Java's implementation of garbage collection eliminates the need for reference pointer counting that is very tedious when building COM components in C++. It also hides some of the complexity of the COM interfaces. As a result, Microsoft is supporting seamless integration between ActiveX and Java.

Figure 7: The Environment We Really Need

This offers the opportunity to seamlessly integrate ActiveX and CORBA. If the vendors implement products properly, it should be possible to talk to the same component via DCOM or CORBA protocols.


Conclusion

Tools for integration of Java, objects, databases, and the Web are in a primitive state in 1997 and most corporations are unable to implement non-trivial Java client-server applications on the Web. However, evolution of Java tools is very fast and the component technology infrastructure needed to implement these applications will begin to become available in 1997-98. By the end of this century we will have the capability to move applets seamlessly from client to server, as well as from server to client, enabling a new generation of knowledge based application agents that surf the web (or the corporation) without human intervention.

Corporations that take advantage of Business Object Architectures will significantly shorten product cycles and Java will play a major role sometime before the year 2000. Consulting groups that use Business Objects will significantly underbid their competition and deliver new systems on time and under budget. Because a Business Object Architecture will allow software to change as rapidly as the underlying business processes, corporate viability will be enhanced by early implementation. Laggards will pay the price. They are already easily outmaneuvered in the marketplace by enterprises embarked on large-scale implementation of global distributed object systems based on Internet technologies.

Acknowledgements:

Joaquin Miller (Chair of the ANSI X3H7 Object Information Management Committee), Cory Casanave (Chair, OMG Business Object Domain Task Force), are commended for their ideas and support of the OOPSLA Business Object Workshop where many of these ideas are continuously refined. Charlie Kindel (formerly Senior Architect, Microsoft COM Group) was helpful in clarifying the integration of Java and ActiveX.


REFERENCES

Berners-Lee, Tim. The Axes of Revolution. JavaOne Keynote slides. JavaOne, 1996 <http://java.sun.com/java.sun.com/javaone/keynotes/TBL/9605JAVA/slide1.htm>

Berners-Lee, Tim. Of Webs and Objects. Object World Keynote Address, Boston, 6 March 1997.

Brickman, Gary. News & Comment from JavaOne. JAVA JOURNAL, 1996 <http://www.gamelan.com/pages/javaone/javaone_article4.html#web>

Chappell, David. Understanding ActiveX and OLE: A Guide for Developers and Managers. Microsoft Press, 1996.

Cox, Brad. Object-Oriented Programming: An Evolutionary Approach. Addison-Wesley, 1986.

Javasoft. Java Beans Specification, Version 0.30. Sun Microsystems, 3 September 1996. <http://splash.javasoft.com/beans/>

Jones, Capers. Programming Languages Table Monograph, eighth edition. Software Productivity Research, 1996. <http://www.spr.com/library/0langtbl.htm>

Lerner, Moisey. Software Maintenance Crisis Resolution: The New IEEE Standard. IEEE Software11:65-72, August 1994.

META Group, Inc. Making the Case for Use Case. Advanced Information Management, File 324, 13 February 1995.

Mike Spertus. Garbage Collection in C++. Object Magazine 5:6, Feb 1996.

Object Magazine. Executive Brief: Objects important to redesign, O-O 4GLs outracing Smalltalk? Object Magazine 5:3:10 (June) 1995.

Object Management Group. Common Facilities RFP 4: Common Business Objects and Business Object Facility. OMG TC Document CF/96-01-04 <http://www.omg.org/cftfrfp4.htm>

PC Week, 16 Jan 95, p. 68

Sutherland, Jeff. Road Kill on the Information Highway: JavaDay. Homepage.Journal, February 1996. <http://www.onemind.com/roadkill.html>

Sutherland, Jeff. Smalltalk, C++, and OO COBOL: The Good, the Bad, and the Ugly. Object Magazine, 1995.

Sutherland, Jeff et al. (Eds.) Proceedings of the OOPSLA'95 Workshop on Business Object Design and Implementation. (In press)

Sutherland JV, Pope M, Rugg K. The Hybrid Object-Relational Architecture (HORA): An Integration of Object-Oriented and Relational Technology. Proceedings of the 1993 ACM/SIGAPP Symposium on Applied Computing, Indianapolis, 14-16 Feb 1993. Deaton E et al (Eds) ACM Press, pp 326-333.

Taylor, David. Object-Oriented Information Systems: Planning and Implementation. John Wiley & Sons, 1992, pp. 320-322.

VMARK Software. Allied Signal Company wins the Computerworld Object Application Award at Object World. Press Release, 21 August 1995. (http://www.vmark.com/whatsnew/presrel11.html)

VMARK Software. Object Studio Product Literature, 1995. (http://www.vmark.com/products/objstud/objstud.html)

Watson, Lyall (quoting William Shakespeare). Dark Nature. Harper Collins, 1996.

What's the ROI on Objects. Software Magazine, May 1996. (Note that there are errors in the ROI calculation which have been corrected here.)

Yourdon, Ed. Ed Yourdon's Guerilla Programmer, July 1995 (No longer published. Back issues available from Cutter Information Corp.)