Aug 2000
	By Dr.Thomas J Mowbray

Many of us have serious misconceptions about the capabilities of current software approaches. Based upon surveys of corporate software projects in the United States, the realities of software development are as follows. [1] About one third of all software projects are canceled. Average projects expend twice as much budget and schedule as initially planned. After delivery, the majority of systems are considered unsuccessful because they have far fewer capabilities than expected. Modifying and extending systems are the most expensive cost drivers and very likely to create new defects. Overall, the outcome of filely all application software projects are stovepipe systems, brittle software architectures that under-perform on requirements. The Software Crisis The software crisis in corporate development became apparent decades ago, when procedural software technologies were popular. Subsequent, object-oriented approaches (such as the Object Modeling Technique) have been equally unsuccessful for corporate developers. These outcomes have been repeatedly confirmed by research. [1] Three key factors are exacerbating the software crisis:

• requirements change,
• commercial innovation, and
• distributed computing.

A significant part of the problem is rising user expectations. User requirements for systems have increased much faster than corporate developers' capability to deliver. Requirements changes are more frequent as businesses maneuver for competitive advantage with strategic corporate software.

Another confounding factor is the destabilizing force of accelerating technology innovation, both in commercial software and hardware platforms. Corporate developers have difficulty finding compatible configurations of software products, and are forced to upgrade configurations frequently as new products are released. Software maintenance due to technology upgrades is a significant corporate cost driver.

Distributed computing is an essential feature of many new applications due to predominance of the Internet and geographically diverse enterprises. Traditionally, software designers assumed homogeneous configurations, centralized systems, local communications, and infrequent failures. Today's highly distributed enterprises require heterogeneous hardware/software, decentralized legacy configurations, and complex communications infrastructure. The result is an environment with frequent partial system failures. Distributed computing reverses many key assumptions that are the basis for procedural and object-oriented software development.

The software industry has established object-orientation (OO) as the mainstream technology. OO is the technology adopted by new corporate development projects because OO is universally supported by software tool vendors. Masses of legacy programmers are training for object-oriented development (e.g. C++ and Java) as corporations create new strategic systems. Unfortunately, these developers and corporations are likely to become the next generation of disillusioned participants in the software crisis. However, the organizations that survive and thrive with this technology, must use it in sophisticated new ways, represented by componentware.

Componentware Resolving the software crisis requires fundamental changes in systems thinking, software processes, and technology utilization. The next major era of technology, The Componentware Revolution, contains key elements of the crisis solution.

The componentware approach introduces a set of closely interrelated techniques and technologies. Componentware introduces a sophisticated mindset for generating business results. These componentware elements include:

• Component Infrastructures
• Software Patterns
• Software Architecture
• Component-Based Development

Componentware technologies provide sophisticated approaches to software development that challenges outdated assumptions. Together these elements create a major new technology trend. Componentware represents as fundamental a change in technology as object-orientation and previous generations.

We will discuss these componentware technologies after a brief introduction to componentware's unique principles.

Components versus Objects

Componentware can be understood as a reincarnation of object-orientation and other software technologies. What distinguishes componentware from previous generations of technology are four principles: encapsulation, polymorphism, late binding, and safety. This list overlaps with object-orientation, except that it eliminates the emphasis on inheritance. In component thinking, inheritance is as a tightly-coupled, white box relationship that is unsuitable for most forms of packaging and reuse. Instead, components reuse functionality by invoking other objects and components instead of inheriting from them. In component terminology, these invocations are called delegations.

By convention, all components have specifications corresponding to their implementations. The specification defines the component encapsulation (i.e. its public interfaces to other components). Reuse of component specifications is a form of polymorphism which is strongly encouraged. Ideally, component specifications are local or global standards that are widely reused throughout a system, an enterprise, or an industry.

Componentware utilizes composition for building systems. In composition, we integrate two or more components to create a larger entity, which could be a new component, a component framework, or an entire system. Composition is the integration of components. The combined component acquires joint specifications from the constituent component.

If the components have matching specifications for client calls and services, then they can interoperate with no extra coding. This is often called plug and play integration. At run time, when executed at runtime, this is a form of a late binding. For example, a client component can discover a component server through an on-line directory, such as the CORBA Trader Service. With matching client and service interface specifications, the components can establish a run-time binding to each other, and interact seamlessly through the component infrastructure.

In a perfect world, all components would be fully conformant with their specifications and free from all defects. Successful operation and interoperation of components depends on many internal and external factors. Safety properties can help because they can minimize entire classes of defects in a component environment. As society becomes increasingly dependent upon software technology, safety has become a serious legal concern and one of the most important areas of computer science research.

For example, Java's garbage collection feature guarantees memory safety, or freedom from memory deallocation defects (which are problematic in C++ programs). Other kinds of safety include type safety (guaranteed data type compatibility), and module safety which controls the effects of software extension and component composition.

Component Infrastructures

The componentware revolution has already arrived in the form of component infrastructures. Major platform vendors have bet their futures on componentware product lines. In particular, Microsoft, Sun Microsystems, IBM, and the CORBA consortia have established significant componentware infrastructures through massive technology and marketing investments.

These component infrastructures (Microsoft COM, Sun Enterprise Java Beans, and CORBA request brokers) are dominant infrastructures for overlapping industry segments. Microsoft COM on the desktop; Java for cross platform applications; and CORBA for corporate networks and the Internet. Interestingly, these technologies are also mutually interoperable, with Microsoft, Sun, IBM, and others supporting the CORBA Internet Inter-ORB Interoperability Protocol (IIOP) for Microsoft COM and Java Remote Method Invocation (although Java works equally well with CORBA). In the following paragraphs, we'll compare these infrastructures briefly.

Microsoft has been promoting the Component Object Model (COM) and follow-on products for several years. COM is a single-computer component infrastructure. OLE and ActiveX define componentware interfaces based upon COM. In theory, the Distributed Component Object Model (DCOM) extends the capabilities of COM over networks and the Internet. With these technologies, Microsoft has funded a major corporate strategy promoting a worldwide migration to componentware over the past five years. Future Microsoft plans indicate that it will continue its componentware initiative for the forseeable future.

The DCOM Disaster

Benefits CORBA

Unfortunately, DCOM is a technological disaster of such proportions that only Microsoft could fund its continued existence with favorable public relations. A key problem with DCOM is its security model, which was not architected into the technology prior to massive commercial deployment on Microsoft operating systems. For security and other reasons (e.g. system management support), DCOM is not recommended for use on the Internet, nor is it suitable for distributed enterprise systems. These and other DCOM limitations are supposed to be addressed by Windows 2000 and COM+ (DCOM's successor), which are likely to stabilize by early next century. The DCOM disaster has not influenced Microsoft's strong support for componentware technology.

DCOM's misfortunes have yielded significant benefits for CORBA vendors. At one time, Microsoft's DCOM was considered an insurmountable competing technology to CORBA. Vendor groups were terrified about the future prospects for CORBA.

With increasing industry skepticism about DCOM and other proprietary middleware, CORBA has become the uncontested market leader for distributed computing. CORBA's is the only adopted technology for distributed computing that supports multiple programming languages and multiple platforms. SIDEBAR END

Sun Microsystems invention of Java is a continuing evolution of programming language features, infrastructures, and related class libraries. Java technology has created tremendous industry excitement and support from independent developers. The extensions for Java Beans and Enterprise Java Beans establish an evolving component model that rivals COM and ActiveX in the cross-platform application space. Enterprise Java Beans and the IBM San Francisco project are using Java Remote Method Invocation (RMI) for distributed computing, one of several proprietary infrastructures available to Java programmers. While proprietary Java infrastuctures do provide convenience for programmers, they lack one key capability: interoperability with other programming languages. This may be a serious limitation for corporate projects because it hampers legacy integration and cross-language development which is commonplace for server applications. Another, more subtle issue, is that Java application programming interfaces (APIs) are not standards. For popular technologies like JDBC, vendors often customize the APIs as they create their value-added versions of the Sun reference technologies.

The Common Object Request Broker Architecture (CORBA) is an open-systems standard for distributed infrastructure supported by multiple vendors, industry consortia, and formal standards bodies. [2] Recently, there has been a surge in CORBA licensing in corporate development organizations with a surprising array of Fortune 500 companies adopting CORBA for enterprise projects, including banks and manufacturers. From its inception CORBA has supported both object and componentware models. With today's CORBA products supporting multiple component interfaces in a single encapsulated servlet, CORBA is an ideal infrastructure for componentware development involving heterogeneous hardware/software, multiple programming languages, or distributed computing. Recently, CORBA has been extended to support the capabilities of message oriented middleware and domain-specific API standards (healthcare, manufacturing, financial services, and so forth). Just like any other technology, CORBA products do have limitations (e.g. memory leaks, conformance, performance). However, for a standard established in 1991, it is amazing how well the CORBA architecture has weathered cataclysmic innovations in other technologies and emerged ever stronger (e.g. Java and the Internet).

Componentware infrastructures are having a significant impact on software development. In many respects, these infrastructures are well on their way to becoming mainstream development platforms. Because all of these infrastructures are becoming interoperable (through CORBA IIOP), there is a well understood relationship between infrastructure models. Their similarities are much greater than their proprietary differences might imply.

Infrastructure selection is one of the most discussed, but least important, aspects of implementing componentware. For corporate developers, the most critical issues are confronted well after infrastructure selection. These issues include: how to master designing with the technology, how to architect systems, and how you coordinate your development efforts. These areas are covered by the next three sections on Software Patterns, Software Architecture, and Component-Based Development.

Software Patterns

Software patterns comprise a common body of software knowledge which can be applied across all component infrastructures. The most famous category of software patterns, called design patterns, comprises proven software design ideas which are reused by developers. [3] Other important categories of patterns include analysis patterns and antipatterns. [1] Analysis patterns define proven ways of modeling business information; that can be directly applied to the modeling of new software systems and databases.

Software patterns are a necessary element of componentware. The development of new, reusable components requires expert-level quality of design, specification, and implementation. Proven design solutions are necessary to establish successful component architectures and frameworks for families of applications. Often, there are too many variables to take chances on unproven design concepts.

The popularity of software patterns can be explained as a response to the practical shortcomings of object-orientation. Antipatterns explain the common mistakes that people make when developing object-oriented software systems (as well as other types of systems). Much more is needed than basic object-oriented principles to build successful systems. Design patterns explain the additional, sophisticated ideas that are required for effective software designs. Analysis patterns present the sophisticated ideas necessary for the effective modeling of concepts and data.

It is still commonplace in software development, to reinvent design ideas, incurring the risks and delays of trial and error experimentation. If fact, most software methods encourage reinvention as the normal mode of development. Considering the challenging forces of requirements change, technology innovation, and distributed computing, we consider reinvention to be an unnecessary risk in many circumstances. This comment is especially applicable to the development of components, where the costs of defects and redesigns can affect multiple systems.

Altogether, software patterns can be described as knowledge reuse. It is interesting to note that most patterns are considered as simple as commonsense by expert-level developers. However, for the majority of developers, patterns are a necessary part of technical training that can help them to achieve world-class results.

Software Architecture

Software architecture concerns the planning and maintenance of system structure from earliest system concept, through development, and operations. Good architectures are stable system structures which can accommodate changes in requirements and technologies. Good architectures ensure the continuous satisfaction of human needs (i.e. quality) throughout system lifecycles.

Reusable components are examples of good architecture. They support stable interface specifications, which can accommodate changes due to reuse in many system contexts.

Software architecture plays an important role in component design, specification, and use. Software architecture provides the design context, within which, components are designed and reused. Components have a role in predetermining aspects of software architecture. For example, a component framework may predefine the architecture of a significant portion of a system.

One of the most exciting aspects of software architecture for componentware is supporting distributed project teams. A software architecture comprises a system specification that enables parallel, independent development of the system or its parts. A proper software architecture defines computational boundaries (i.e. API) that divide the system into separate testable subsystems. These subsystems can be outsourced to one or more distributed project teams.

Component-Based Development

Component-based development is software development with a difference. Many process aspects are reused, such as iterative, incremental development. The primary componentware difference is the specialization of technical roles. [2] Three key componentware roles are software architect, component developer, and application developer. These differ from object-oriented approaches which promoted notions of all-purpose programmers, committee-based design, and architecture after-the-fact.

A typical leadership team for a project comprises a software architect and a project manager. The architect works in conjunction with management to make key technical decisions, those with system-wide impact. The architect is responsible for technical planning of the system, and communicating these plans with developers. Since the architect coordinates system-wide design decisions, many other technical decisions are the responsibility of developers. To be effective, the architect must have the highest levels of experience and technical training; with outstanding skills in design, specification-writing, and spoken communication.

The best component developers are also the most talented programmers. They design and program the building blocks from which the application will be constructed. The architect defines the major boundaries behind which component-based services will be provided. Reuse of pre-existing components is evaluated with respect to an organizational software repository. For new component requirements, the component-developers design and construct new software, updating the organizational repository. Typically, components will implement the horizontal functions and lower-level aspects of the system, reducing the need for application developers to reinvent these capabilities. Component developers make intensive use of software patterns, applying several overlapping patterns to each component design and implementation.

Application developers are responsible for integrating components and implementing the vertical requirements of the system, including user interfaces. They apply preexisting components to the solution of application-specific problems. Application developers must communicate with end-users have some domain expertise.

Generally, component developers use systems programming languages, such as C++ and Java, while application developers use scripting languages, such as Javascript, TCL, Python, and Visual Basic. Systems programming languages allow more control of low level issues, but are more difficult to use for application-building. Scripting languages provide a higher level of abstraction, with a corresponding reduction of up to 8:1 in lines of code needed to implement a given requirement, compared to systems programming languages.

Summary

The Componentware Revolution is the next major software technology trend. In many ways, it has already arrived, and is readily available for commercial exploitation. This revolution is actively supported by major vendors, including Microsoft, Sun, IBM, and the CORBA vendor consortia

. The most important aspects of componentware are not the choice of technologies, but how these are applied. Successful adoption of componentware must include the reuse of software patterns, the planning of software architecture, and the establishment of component-based development teams.

The Componentware Revolution is an exciting opportunity to avoid the inadequacies of outdated software approaches. Componentware enables you to survive and thrive when facing the challenges of requirements change and rapid commercial innovation. Componentware delivers the benefits of software reuse and enables outsourcing to distributed project teams.

References

[1] Brown, W.J., R.C. Malveau, H.W. McCormick, and T.J. Mowbray, ANTIPATTERNS: REFACTORING SOFTWARE, ARCHITECTURES, AND PROJECTS IN CRISIS, John Wiley & Sons, 1998. (ISBN 0-471-19713-0)

[2] Mowbray, T.J. and W.A. Ruh, INSIDE CORBA, Addison-Wesley, 1997. {ISBN 0-201-89540-4)

[3] Mowbray, T.J. And R.C. Malveau, CORBA DESIGN PATTERNS, John Wiley & Sons, New York, 1997. (ISBN 0-471-10611-9)

[4] Mowbray, T.J. And R. Zahavi, THE ESSENTIAL CORBA: SYSTEMS INTEGRATION USING DISTRIBUTED OBJECTS, John Wiley & Sons, New York, 1995. (ISBN 0-471-10611-9)