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.
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.
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:
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.
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?
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.
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:
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]:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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.
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.
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.
Business Object programmers focus their efforts on building business components, or large-grained Business Objects, which can be easily distributed on the network.
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.
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.
The minimal environment needed for easily implement client-server applications on the Web includes:
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.
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.
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.
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.)