OOPSLA'96Business Object Workshop II

Integrating Object, Databases, and the Web

Jeff Sutherland, IDX Systems Corporation <jeff.sutherland@idx.com>
Published in Proceedings of OOIS'96.
Revised version published in SunExpert, Jan 1997. 
Corrections posted 21 Jan 1997.


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. The rules we're defining now -- the way you look at your system, the way you define protocols, the way objects talk to each other -- are defining what those possibilities will be." [Berners-Lee 1996, Brickman 1996]

Something Wicked This Way Comes

"By the pricking of my thumbs, Something wicked this way comes, Open, locks, whoever knocks." [Watson 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]

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 Can't Do Anything Really Useful 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 for cute applets on Web pages and not much else. In current developments efforts for one of the leading Internet news providers, Individual, Inc., Java is used for registration applets. Lack of tools, slow performance, and security restrictions have prevented deployment of Individual 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. 

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. I estimate that the Smalltalk community has about one year to respond to this problem. 



Dynamic Binding 
Dynamic Classes 
Multiple Inheritance 
Function pointers/lexical closure 
Ease of use 
Class Libraries 
Learning Curve 
Speed of Development 
Multiple Vendors 
Internet Aware 
Garbage Collection 
Memory Leaks 
Overwriting Memory 
Ready for Prime Time 
(low means best) 



Table 1: Smalltalk, C++, OOCOBOL and Java: The Good (1), the Bad (3), and the Ugly (2) 

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. 

Yet another computer language won't solve our software productivity problems. Only component based development with advanced development environments (non-existent in Java) 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 
Time to Market 
Other Costs 
Code Size 
Reuse Requirements 

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]. 

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 (see Figure 3). 


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 5: Applet/Servlet RMI Implementation

Current Impediments to 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 OMG standardization of a Business Object Facility [OMG 1996] is a core requirement for building standards-bases Business Object Architectures from Java components. During the next year, these standards should stabilized and robust tools for building Java applications will become available. 


Tools for integration of Java, objects, databases, and the Web are in a primitive state in 1996 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. Before 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.



Business Rules 




Client Applet 

Server CGI 


Perfomance Tools 


Client Applet 

Server Java API 


Performance Tools 


Client Applet 

Dynamic Client/Server Partitioning 


Component Technology Tools 


Applet sent to server 

Multiple Servers 

Multiple servers 


Table 3: Evolution of 3-Tier Web-Based Applications 

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. 


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> 

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

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. 

Object Magazine, 1996 (article on C++ garbage collection). 

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.) 

OOPSLA'96Business Object Workshop II