Handbook of Object Technology

Advertisement: Become a VoIP agent or a VoIP reseller by getting wholesale rates on internet calling. Using VoIP service will get you low rates on all your calls.


• The "Handbook of Object Technology" is a mega project that consists of close to one hundred contributed articles from the Who's Who of Object Technology.
• The "Handbook of Object Technology" is a comprehensive and complete reference for the subject areas related to the disciplines that encompass Object Technology. In a single volume, this handbook contains topics that cover every aspect of this technology, such as methodologies, languages, standards, frameworks, databases, metrics, development environments, and more. See Google book search.

Jeff Sutherland, Scrum, Inc. <jeff.sutherland@computer.org>

Introduction

Underlying Principles

Technological change goes through periodic acceleration as a result of convergent discoveries. The pattern is the same for the adoption of eyeglasses in the 11^th century as it is for the invention of the computer in the 20^th century. It typically takes multiple inventions to enable a new technology and 20 to 30 years for acceptance and adoption. The personal computer, the mouse, the graphical user interface, the Ethernet, and the first widely used object-oriented language were all invented at Xerox Parc in the early 1970’s [Kay, 199?]. The Internet was developed in the 1960’s and by the mid 1970’s many government agencies, universities, and research facilities where connected to what was then called ARPAnet [Sterling, 1993]. A design which led to TCP/IP was proposed by Vint Cerf and Bob Kahn in 1974 and the hypertext concept was created by Ted Nelson in the same year [Nelson, 1974].

By the time these technologies had incubated for 20 years, it was evident in the early 1990’s that the major thrust of computer-human interaction approaching the millenium was the use of hypermedia systems to augment the human mind, much as the telescope and microscope had augmented human vision [Sutherland, 1991]. All that remained were the triggering mutations required to cause an evolutionary explosion of distributed object-oriented, graphical, hypermedia systems on the Internet. These mutations occurred in 1993. They were the Web browser, Java, the first computer language designed for dynamic distributed of objects on the Web, and Business Objects, an approach to reengineering distributed software applications to support global reengineering of corporate organizations.

Best Practices

The Java Revolution

The popularity of Java has a significant 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 that 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 and Production Systems

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 very few 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:

• A Java applet can communicate only with the server that distributed the applet to the client machine.
• A Java applet cannot evoke an executable on a client machine.
• A Java applet cannot write to ROM or disk on a client machine.

Java’s current perfomance and garbage collector limitations are similar to the first Smalltalks implemented in the 1970’s. Nevertheless, Java compares well to other major object-oriented languages. Table 1 has been critiqued by 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.

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.

The Software Crisis

It is not news that there is a software crisis. The news is that it is getting a lot worse:

• It costs $70B/yr to maintain 10B lines of legacy code in the U.S. alone [Lerner 1994].
• 31% of new projects are canceled at a cost of $81B [PC Week 1995].
• 52.7% of projects are over budget for a $59B loss [PC Week 1995].
• Developer productivity has dropped 13% since 1993 [Yourdon 1995].
• The ratio of best to worst organization software productivity has widened from 4:1 in 1990 to 600:1 in 1995 [Yourdon 1995].

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.

Business Objects and Business Process Reengineering

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:

• Data-centric, task-oriented application development
• Methodologies and cultures that do not promote reusability
• Few linkages between BPR-defined business processes and IT support initiatives [Meta Group 1992]

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]:   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 Internet provides the first global infrastructure for rapid implementation of these capabilities.

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 4^th Generation Languages and classical object technology. While both of these approaches are better than traditional COBOL software development, neither of them provides adequate support for implementation of 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 will take an order over the phone, enter purchase information, validate customer records and credit data, and review 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 can 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 can create interface objects with simple object-oriented tools. Subsequently, the programmer can 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

  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.

  Table 3: Reengineering a Purchase Order Component
 

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:

• Thinner clients
• Reduced network costs
• Automated software distribution
• Lower development and maintenance costs
• Transparent portability dramatically reduces complexity
• Simpler technology for MIS to implement
• Infrastructure for distributed business object architecture

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:

• Remote method invocation across the network, dramatically simplifying programming
• Java Applets or Servlets can initiate action (pull and push technology) and peer to peer communication is supported between applets and servlets. A simple example is the need for a servlet stock ticker that can update browser applet.
• Servlet/JDBC optimization of database performance and simplification of object to relational table mapping.
• Database connections automatically held open for session and proper management of multiple simultaneous connections to the database.

 

 

Figure 6: Applet/Servlet RMI Implementation

Research Issues and Summary

The lack of tools to simplify implementation of business object systems on the Internet/Intranet, is currently a major inhibiting factor for movement to Java-based client-server applications. The lack of a robust, bug-free Java integrated development environment is a second impediment. The third major handicap for building these applications is lack of a component-based 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 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.

ActiveX/CORBA Harmonization

One of the most encouraging developments for building distributed object applications for the Web is the emerging 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, Microsoft’s COM architects state that Java is becoming the language of choice for COM component implementation. 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 support for 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, it is possible to supply seamless integration between ActiveX and Java components. If the vendors implement products properly, it will be possible to talk to the same component via DCOM or CORBA protocols.

Most CORBA compliant, ORB vendors deliver the capability for DCOM clients to access CORBA objects on the network. This is a primitive capability compared to two-way interoperability between DCOM and CORBA. In 1997, only one vendor provides full interoperability. Users must be knowledgable and careful when selecting CORBA middleware to ensure that required capabilities are supported.
 

  Figure 7: The Environment We Really Need

Conclusion

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.

References