| ||
| ||
|
Object technology, a necessary but not sufficient condition for software reuse, requires an infrastructure that supports plug compatible Business Object Components for fast and flexible delivery of new or enhanced products to the marketplace. This paper is a retrospective view on key conceptual issues driving the standardization of a Business Object Component Architecture (BOCA) within the Object Management Group (OMG). The seamless integration of BOCA with the Unified Modeling Language (UML), a standardized Meta-Object Facility (MOF), and an emerging CORBA Component specification is essential to design-driven generation of runtime components into heterogeneous distributed object frameworks. BOCA standardization can enhance software productivity with plug compatible, reusable components, the holy grail of object computing.
The Object Management Group (OMG) Business Object Domain Task Force (BODTF) has been the focal point for standardization of a Business Object Component Architecture (BOCA). The emergence of this standard could have far reaching effects on worldwide software development. Priming this effort required joint work of the OMG BODTF, the Accredited Standards Committee X3H7 Object Information Management, and their joint sponsorship of the OOPSLA Workshop on Business Object Design and Implementation for the years 1995-98. Completing BOCA standardization required the united efforts of over 800 of the leading software development companies and user organizations worldwide--the members of the OMG.
This paper serves as a retrospective on some of the key conceptual issues driving BOCA standardization and the global effort to build a unified set of standards for component based systems throughout the software development life cycle. In mid-1998, BOCA is moving through the final OMG vote for adoption. Initial tools are available that will generate BOCA applications running in the IBM San Francisco Java Framework from an annotated UML design document. The same tools will generate Enterprise Java Bean and CORBA Component applications, as soon as frameworks for these emerging technologies become available.
The Object Management Group has chartered the BODTF to facilitate and promote:
The OOPSLA Workshop on Business Object Design and Implementation is jointly sponsored by X3H7 and the OMG BODTF for the purpose of soliciting technical position papers relevant to the design and implementation of Business Object systems.
The goals of the OOPSLA Business Object Workshop are to:
For many years members of X3H7 and the OMG BODTF have been intensely aware that the global market has become an highly 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. This awareness led these groups to join forces in 1995 to initiate a radical change in software development environments, a changed that would take years to specify and decades to implement.
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. The rapid adoption of the Internet since 1995 has accelerated the pace of software evolution dramatically and pushed it in the direction of global, distributed object computing, the target environment for BOCA.
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. In particular, if software implementation can be automated from design, change becomes easy, rather than difficult or impossible.
Reorganization of business processes is most effective when there is a well understood model of the existing business, an evaluation of alternative future models against the current business, and when a model-driven approach is used to realign the business strategy, processes, and technology. A multilayered, object-oriented blueprint of the enterprise can drive the refocusing, realignment, and reorganization of the business. Current attempts to implement this process under the rubric of business process reengineering (BPR) have been largely ineffective due to difficulties in changing monolithic organizations, processes, and information systems.
Figure 1: Hardware Price/Performance vs. Software Price Performance
Figure 1 demonstrates that enhancing the productivity and performance of integrated circuits (IC) has led to exponential growth in computing power over the past thirty years. This has been driven by "the observation made in 1965 by Gordon Moore, co-founder of Intel, that the number of transistors per square inch on integrated circuits had doubled every year since the integrated circuit was invented. Moore predicted that this trend would continue for the foreseeable future. In subsequent years, the pace slowed down a bit, but data density has doubled approximately every 18 months, and this is the current definition of Moore's Law, which Moore himself has blessed. Most experts, including Moore himself, expect Moore's Law to hold for at least another two decades."
Moravec has more recently observed that information handling capacity in computers has been growing about ten million times faster than it did in nervous systems during our evolution. The power doubled every two years in the 1950s, 1960s and 1970s, doubled every 18 months in the 1980s (Moore's Law), and is now doubling each year.
Custom chip development, which is largely software based, has followed Moore's Law due to the heavy capital investment in tools and technology common in the IC chip industry. However, this has not led to comparable gains in business application software development, largely due to the lack of automated software construction from design artifacts and failure to achieve large scale reuse of software components in business applications.
Understanding the reasons for rapid gains in hardware productivity clarifies the direction that application software development must take to achieve comparable results. The software productivity problem is a core issue for X3H7 and the OMG BODTF as they assess how to maximize the impact of software standards development on the worldwide business community.
Document X3H7-93-23, Objectives and Operations, provided guidelines for work of the X3H7 during the period 1993-96.
The majority of members of X3H7 are also members of the OMG and committed to seeing relevant standards implemented by industry bodies. Under the editorship of Frank Manola, the Object Model Features Matrix developed an analysis of issues involved in harmonizing object models. This showed that competing object models provided not only different structures, but often different semantics underlying the concepts that supported these structures.
Interoperability of object models requires understanding the structure and semantics of commonly used object-oriented frameworks and the interfaces between these development frameworks. Object models must interoperate within widely adopted frameworks and the number of frameworks should be few. An X3H7 consensus was reached in 1994 that 80% of new object-oriented development would be done in three application languages (Smalltalk, OO COBOL, and C++) and that these applications would communicate through a Business Object Request Broker to four external environments – X3H2 SQL standard databases, ODMG standard object databases, Microsoft's COM environment, and the OMG CORBA environment. Figure 2 illustrates the views of X3H7 at that time.
Figure 2. ANSI X3H7 Standardization Targets. 24 Sep 1994
The widespread adoption of the Internet since 1995 has only accentuated the need for interoperable, distributed object standards and added Java to the list of widely used development languages. One of Java's primary benefits is enhancing interoperability of distributed systems, a primary objective of X3H7.
Even before the rapid growth of the Internet, there was a consensus that application developers should be shielded from the details of these implementation environments. They should be able to use Object-Oriented Analysis and Design (OOAD) tools to build an application in a standard notation. OOAD tools should be able to import legacy models from CASE tools. The application model and all of its artifacts should be stored and versioned in an object repository and the runtime application binary objects should be generated from the repository to conform to standard component interface specifications. Request broker technologies should provide automated mapping between development frameworks. Figure 3 shows the X3H7 conceptual view of this problem.
Figure 3. ANSI X3H7 Standardization Targets. 24 Sep 1994.
X3H7 members participating in OMG and other standards bodies began driving the agenda of object model harmonization in multiple organizations. They were key technical contributors to the ISO standard RM-ODP, the distributed processing reference model that OMG technologies must conform with in accordance with agreements between ISO and OMG. They also agreed to co-sponsor, with the OMG BODTF, a Business Object Design and Implementation Workshop at the OOPSLA'95 Conference on object-oriented programming, systems, languages, and applications, in order to draw research contributions into the drive for common Business Object Component standards.
In 1994, Sutherland began discussing his findings on key issues in building life cycle object-oriented development environments for business objects within standards organizations, including the OMG Business Object Management Special Interest Group (BOMSIG, now BODTF). Simultaneously, Cory Casanave, now Chair of the OMG BODTF, edited the BOMSIG Business Application Architecture White Paper and later OMG Common Facilities RFP4: Business Object Facility and Common Business Objects.
Objects are not enough to gain the benefits possible with object technology. Only plug compatible, larger grained components can achieve a productivity breakthrough. Early adopters of object technology asserted that packaging software in object classes would allow software to obtain the benefits of Moore's Law seen in IC chip fabrication and 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. 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:
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 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.
As business models are renewed, software architectures must be transformed. A Business Object Component Architecture (BOCA) is an effective solution for dynamic automation of a rapidly evolving business environment.
Dynamic change requires reuse of chunks of business functionality. A BOCA 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 plug and play 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 Object Components are encapsulated with a protocol that allows efficient communication with other objects on the network.Work on the concept of Ensembles has shown that there is a minimal design specification for a plug compatible component.
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 (see Figure 4).
Figure 4: An Order Entry Business Object
To support plug-compatible reuse, a business component needs encapsulation in the following ways. 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 components or reuse will not be easily achieved. 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.
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 component.
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 5).
Figure 5: 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.
System evolution will invariably distribute these Business Object Components to maximize network performance and processor utilization, and to ensure proper control, integrity, and security of information. With the widespread adoption of standards-based Internet technologies, distributed object systems have become the norm. 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 Component system.
Figure 6: Application Business Object with Nested Client/Server Components
Business objects made up of nested components allow distribution of these components across a network. Figure 6 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 have taken 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. 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) 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 1 summarizes these benefits.
| Before | After | Improvement Ratio | |
|---|---|---|---|
| Process Steps | 52 | 3 | 17.3 |
| Staff | 7 | 1 | 7 |
| Time | 9 weeks | 9 min | 2400 |
Table 1: 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 use of Business Object Component design tools to assure success of Business Process Reengineering practice.
Despite isolated success stories, Brodie reported, after a survey of 201 distributed object computing (DOC) applications worldwide, that this technology is not and will not be ready for prime time until vendors can deliver standards based Business Object Component frameworks. "For the moment, DOC is in its infancy and does not meet industrial-strength requirements or the claims of its proponents… There are even very recent claims that a major breakthrough has occurred and that a DOC renaissance is upon us. Based on our experience, GTE has decided to halt the design, development, and deployment of DOC technology and applications. In part this relates to our recognition of the problems described... In part, it also relates to our pursuit of commercial off the shelf (COTS) applications for which the vendors are largely responsible for the issues raised... Following a significant study of and investment in DOC technologies and methodologies, we have concluded that the benefits do not currently warrant the costs to overcome the challenges described... The claims for increased productivity, re-use, and lowered costs cannot be achieved with other than very highly skilled staff who must work with immature technology and methods. We will continue to investigate the area and observe its progress and will be prepared to take full advantage of the technology when DOC is more mature. I look forward to a highly competitive market for the DOC infrastructure and highly competitive products."
Working with Capers Jones at Software Productivity Research, Sutherland did an analysis in 1993 using a database of thousands of projects on productivity of language environments. This study showed that 4GL environments were twice as productive in the real world as COBOL environments in a full life-cycle analysis.
Smalltalk had the capability of doubling the productivity of a 4GL environment, but only if 80% reuse was achieved. Since the average amount of reuse by Smalltalkers in the study was only 20% (not much better than C programmers at 15%) special tools needed to be used to enable this level of productivity.
In Figure 7 below, OOAD+ is an example of a tool that guarantees 80% reuse largely through automation, enables roundtrip engineering from design to code and back, is tightly integrated with user interface tools that allow nonprogrammers to develop user interfaces, and generates runtime components from design. Achieving these objectives, consistent with the X3H7 design targets noted previously in Figure 3, doubles the productivity of a Smalltalk environment.
The ORB bar in Figure 7 refers to an OOAD+ environment that automates the mapping between application objects and relation database storage of these objects. Sutherland observed that in multiple projects in heterogeneous business environments, hand coding object/relational mapping absorbed more than 30% of development resources.
Figure 7: Moore's Law for Software as projected in 1994
Sutherland estimated that by 1996, it would be possible to buy 50% of an application as off-the-shelf components, effectively doubling productivity. By 1997, early adopters would be buying 50% of the application as external components and reusing internally generated components for another 25% of the application, effectively doubling productivity on an annual basis, and beginning to achieve Moore's Law for Software. Brad Cox's vision of software as IC chips could be realized in such a component environment.
Successes in achieving these projections have occurred only on an isolated basis. At OOPSLA'98, Zincke gave an experience report showing a production system that was developed at the rate of 7.52 function points per person-day, an order of magnitude faster than industry average. Widespread achievement of these results has been limited by redeployment of software tools for Internet applications, effectively forcing the industry to repeat the lessons of the last decade of Smalltalk development environments, and the lack of standard component environments in which to build domain-based object-oriented frameworks.
By mid-1995, BOMSIG has completed its second revision of a Business Application Architecture, noting that "with a system comprised of a set of cooperative business objects, the outmoded concept of monolithic applications becomes unnecessary. Instead, your information system is comprised of semi-autonomous but cooperative business objects which can be more easily adapted and changed. This type of component assembly and reuse has been recognized as a better way to build information systems."
The consensus notion of a Business Application Architecture had evolved to what is now the standard three-tier architecture with Business Objects in the middle tier. A distinction began to be drawn between Business Objects as entities and Business Objects as processes (see Figure 8).
Figure 8: Business Application Architecture Revision 2. OMG 95-04-01
Towards the end of 1995, the Business Application Architecture concepts had evolved into the issuance of OMG Common Facilities RFP-4: Common Business Object and Component Interoperability Facility (later known as the Business Object Facility (BOF)). The thrust of the RFP was to begin to build a layer on top of the OMG CORBA infrastructure to enable a plug-and-play environment. Figure 9 became the central view of the problem:
Figure 9: Business Application Architecture. CFRFP-4, OMG 95-12-13
The CORBA infrastructure provides an environment for communication between distributed objects. However, 100% of a business application needs to be hand coded in this environment. It should be possible with a component architecture to buy 80% of the application components and only have to write 20% of the code. A Component Interoperability Facility would provide generic superclasses for business objects. Common business objects crossing domains would be standardized, and domain frameworks would be developed to use both the Common Business Objects and the Component Interoperability Facility (later the Business Object Facility (BOF).
At the end of 1995, OMG Domain Task Forces where created to emphasis the importance of user organizations and vertical domain software to the future of OMG. BOMSIG metamorphized into the OMG Business Object Domain Task Force (BODTF) with the authority to issue its own RFPs and Common Facilities RFP-4 evolved into BODTF RFP-1.
The leading response to the Business Object Facility portion of BODTF RFP-1 matured, after several collaborative efforts, into the Business Object Component Architecture (BOCA). At time of this writing, BOCA has been approved by the OMG Architecture Board and is in the voting process to become an OMG Adopted Technology.
In order to bring BOCA to the voting process, several phases of integration with and definition of other OMG standards had to evolve:
It was necessary to harmonize BOCA with parallel work in multiple areas:
Frankel notes that the following key points outline the relationship of BOCA and UML to CORBA:
Currently, software is available from Data Access Technologies that will generate business object components into the IBM San Francisco Project Java Framework. An annotated UML design autogenerates CDL and MOF metadata. These can be used to generate Java classes in IBM's proprietary framework. Enterprise Java Bean frameworks will be available soon and BOCA will generate Enterprise Java Beans code.
OMG ORBOS is receiving responses to the CORBA Component Facility RFP. Initially, the Gang of Four (IBM, Netscape, Oracle, and Sunsoft) proposed that this be JavaBeans based. Multiple competing proposals are now being reconciled. When the Component Facility is available BOCA will generate CORBA components.
The harmonization of multiple OMG Task Force standardization efforts in widely disparate technologies to provide a standard infrastructure for generation of business objects from design specifications is a monumental task. The OMG is the only organization on the planet that can mobilize the best technical resources from over 800 of the leading software vendors and user organizations worldwide to bring such an effort to closure in a two year time frame.
When this effort is complete, we will have a:
Tools will be provided to generate business systems from design into heterogeneous distributed runtime environments. This will position the software industry for the twenty-first century and launch the first global effort to break down the barriers to implementing Moore's Law for Software.
More articles by Jeff
Sutherland
More articles about Object
Technology