Title: A Component Roadmap
Question: Component-based development is a critical part of the maturing process of developing and managing distributed applications. Virtually every vendor is touting components as the best technique to address a wide spectrum of problems, from building graphical user interfaces to integrating large-scale, enterprise-wide applications. This report provides an introduction to components and component-based development. This report also analyzes the benefits of components, specifically how IT organizations can leverage components to meet changing business requirements and user demand for more responsive systems. In addition, it outlines the initial steps organizations must take to ensure the success of component-based development projects.
Answer:
Abstract
Component-based development is a critical part of the maturing process of developing and managing distributed applications. Virtually every vendor is touting components as the best technique to address a wide spectrum of problems, from building graphical user interfaces to integrating large-scale, enterprise-wide applications. This report provides an introduction to components and component-based development. This report also analyzes the benefits of components, specifically how IT organizations can leverage components to meet changing business requirements and user demand for more responsive systems. In addition, it outlines the initial steps organizations must take to ensure the success of component-based development projects.
Introduction
I have long encouraged modular application development that leverages previous IT investments, including software and training. We believe IT organizations can leverage components to successfully build modular, responsive applications. Component-based development has the potential to improve developer productivity, speed the development process, and result in the deployment of more flexible applications with a far higher level of quality. This modular approach to application development can also facilitate the practical reuse of existing legacy applications, including logic, data, and application services. Before these benefits can be realized, however, IT organizations must understand the implications of components and how their implementation will affect not only new development projects but also existing system infrastructures, the application development and maintenance process, and staff training requirements.
Defining Components
Let us divide the component world into two major categories: large-grained and fine-grained. Fine-grained components provide only a small piece of functionality and must work together with other fine-grained components to deliver a complete, recognizable function. For example, the individual elements that make up a graphical user interface screen - a button, a list box, or a dialog box are fine-grained components. (This view of fine-grained components maps directly to the more traditional definition and implementation of objects.) Multiple fine-grained components can be elements of a large-grained component.
Unlike fine-grained components, large-grained components encompass a complete piece of business functionality. An example might be a general ledger, an asset depreciation component, a letter of credit, a manufacturing work-in-process tracking module, or even an entire legacy application, such as an inventory tracking application. In short, large-grained components perform a complete, discrete business function.
I believe large-grained components have the potential to deliver greater productivity to developers than fined-grained components. This is primarily due to the higher level of abstraction large-grained components provide. By focusing on the component interface and not the inner workings of a component, application assemblers are able to build systems based on a thorough understanding of the business processes these systems will support. This is in contrast to strict object-oriented (OO) development in which developers must have an understanding of both the business processes and the inner workings of fine-grained components (or objects), including a detailed understanding of the underlying technology, the proper method of implementing the components, and the complex dependencies among various components.
Components Versus Objects - Multiple Interfaces Versus Multiple Inheritance
In addition to their level of abstraction, a crucial difference between objects and components revolves around inheritance. Objects support inheritance from parent objects. When an inherited attribute is changed in the parent object, the change ripples through all the child objects that contain the inherited attribute.
While inheritance is a powerful feature, it can also cause serious complications that result from the inherent dependencies it creates. These dependencies are a major reason why OO development has failed to live up to the hype and deliver on the promise of increased reuse. Applications that incorporate objects with strict inheritance models are extremely complex and difficult to model and test. In addition, OO development with strict inheritance requires organizations to impose an unrealistic level of discipline on developers to improve productivity based on reuse. Without this discipline, reuse falters because the applications and the inherent dependencies within them are too complex for developers to have a clear understanding of all the objects. If this is the case, it is difficult, if not impossible, for developers to recognize the objects' potential value in other applications or in different contexts within the same application.
In contrast to the multiple inheritance model of objects, components are characterized by multiple interfaces. For example, consider a customer management component. A sales automation system leveraging this component needs an interface that allows access to the customer name, contact history, phone number, and credit limit. At the same time, a shipping system using the same component only needs an interface that supports a limited amount of information exchange, essentially a name and address. By developing components with multiple interfaces, IT organizations can simplify the development process and facilitate reuse by supplying different departments and/or developers with only the information, services, or both, that they need to leverage.
Components effectively eliminate the problem of dependencies related to object inheritance. Instead, component interfaces act as the "contract" between the component and the application. The application has no view inside the component beyond the exposed interface. This provides IT organizations with the flexibility to update components while maintaining only the interface and behavior of the components. Organizations no longer need to be concerned with all the dependencies in an application that may lead to conflicts or software defects when one piece of the application is changed.
Exposed component interfaces also allow IT organizations to more effectively leverage previous IT investments. This is true for legacy code or even complete applications that were not originally intended to be reusable components. By wrapping this code or application to hide its inner workings, organizations can expose only the interface that different groups require.
Requirements of a Component-Based Architecture
The following section provides a detailed description of the key elements required in a component-based architecture (see Figure 1). IT organizations that implement this architecture will have the flexibility to add specific functionality and/or products as they are needed.
Figure 1 - A distributed, component-based architecture
A component-based architecture must include the following:
Multiple interfaces. Multiple interfaces allow the framework to support the variety of components and component models that developers need to simplify the delivery of a full range of business functionality to end users.
Repository. This is required to store and manage the components. It contains critical information - metadata - about the component and the interfaces. To add a new component, developers simply add the component's metadata and interface definitions to the repository. In addition to critical runtime support and component storage, repositories also provide a central location for managing and coordinating the development process. This includes requirement definition, application development, QA testing, and application deployment.
Middleware. This supports the translation that will be necessary among the various programming languages, platforms, and component models. An organization's components will be heterogeneous, built using different languages, run on different platforms, and based on different component interoperability models. Middleware also provides a single, coherent event model and method invocation technique. The event model describes how events are exchanged within an application; the method invocation describes how a method (or service) within a component is used. Middleware addresses one of the largest risk areas in large-scale development: integrating all the pieces of an application and using the same "language" to achieve this integration. Middleware becomes that de facto language and provides a common definition that reduces the complexity of developing within a component architecture.
Coordination logic. This rationalizes and controls the activities of all the components that an application requires to perform its work. I believe that a component architecture will achieve this significant task via a coordination logic service. Using any of a number of approaches - 3GL, 4GL, business rules, or, more likely, a workflow facility the coordination logic service will manage long sequences of events. I believe workflow facilities offer the strongest potential for coordination because they can best handle the very long (and often convoluted) sequences of events that characterize business processes. However, the key to the success of this approach is large-grained, abstract components with interfaces defined in terms of business functions (e.g., methods like "Create Order" or "Add Customer"), not IT functions.
Systems and applications management capabilities. This is handled through a component interface, which can provide the management instrumentation, monitoring, and reporting capabilities not routinely available in most existing code. Ideally, the management facility will also provide functionality for assessing the performance impact on IT systems when different components are invoked. This functionality is necessary to provide a characterization or detailed understanding of component-based systems. This understanding is achieved by isolating and measuring the performance of individual components within that system.
Existing code wrapped into components. This capability allows developers to incorporate legacy code, existing client/server applications, and even packaged applications as components. Wrapping turns existing code into a black box. Its functionality is invoked only through the defined interface. Developers expose the application's functionality through the component interface. A variety of techniques are available to wrap legacy applications and expose an interface, including using an existing API, using "screen scraper" technology, or interfacing to legacy middleware such as CICS.
Implementing a Component-Based Architecture
Once organizations understand the appropriate level of abstraction required within the components they are building, these organizations are faced with the challenge of building a component-based architecture. The key to successfully implementing this architecture lies in creating the modular framework that will enable all the different pieces to work together. Ultimately, an organization may be dealing with hundreds, if not thousands, of reusable components, including various middleware services, coordination services, and system management services. In addition to all the sound development practices IT organizations should normally pursue, I have identified three areas that require particular attention in the development of component-based architectures: modeling, configuration management, and testing.
Modeling. Data modeling is a standard part of most large-scale development projects. Increasingly, organizations are also creating object models. In the component world, however, two additional models must be created, the interface model and the component interaction model. The interface model will resemble an object model but without the inheritance aspects. The interaction model will more closely resemble a set of workflow definitions and rules that characterize how the system accomplishes its business functions. Once these two models are complete, developers can leverage their existing development tools and staff expertise to generate or write the necessary code.
Configuration management. This is the process of coordinating component usage throughout the entire application development effort. Unlike standard client/server applications being built today, a component application will consist of many independent applications assembled together into the component framework. Critical issues include the ability to easily version components and manage multiple instances with different versions of the same component. Consider the upgrade of a packaged application. For a period of time, both versions may need to exist while the functionality and data are migrated between versions. In a component-based environment, configuration management will be essential for ensuring availability and scalability.
Testing. IT organizations must also address the interaction of components within an application and the complexity and highly distributed nature of these component applications. Simple function and unit testing is not sufficient in the component world. Individual components should be thoroughly unit tested and debugged before they are declared ready for use in component-based development. In addition, developers need to test the end-to-end functioning of the application, which will entail multiple components working together, often across multiple platforms. Finally, to ensure successful deployment, developers need to test for scalability and load handling, and identify bottlenecks as usage increases.
Through attention to modeling, configuration management, and testing, developers can build a component architecture robust enough to handle critical business computing. Each component brings business functionality. When coordinated with other components, this functionality delivers the systems support that IT organizations will require to deliver applications that meet user requirements and support a company's business processes.
Conclusion
Components are not new, they are simply the embodiment of modular programming techniques. Since Microsoft first introduced the VBX component for Visual Basic, developers have used components to add sophisticated functionality to their GUI client applications. However, components can do much more than enrich a GUI. I view components as the means through which organizations can rapidly respond to changes in business processes and meet the demands of end users. This is achieved through high levels of reuse and modularization. To realize this payoff, organizations need to clearly understand the requirements for successfully implementing a component architecture. These requirements include technology and product support as well as improved support for managing the entire application development process.
My Books:
---------------
"DotComming The Enterprise"
Publisher: Penguin Putnam, Inc
Author: Lionel Lim, Dennis Lee
Availability: August '00
"Dot-Gone: The End of Business as usual" [Launching in Dec '00]
Author: Dr Michael W. Dula, Dennis Lee
Publisher: Addison Wesley, Longman Inc
Availability: Dec '00
"Banking on Java"
Author: James GoodWill, Dennis Lee
Publisher: Addison Wesley, Longman Inc
"Java For the Enterprise" Book now in third print...
Author : Dennis Lee, N. Shankar.
Publisher : John Wiley
"Java Programming for Notes/Domino 5"
Author: Dr Benjamin Lian, Dennis Lee [Sun Microsytems]
Publisher: QUE, Macmillan Computer Publishing
"Object-Oriented Programming and Java"
Co-Author: Dr Derek Kiong, Dr Danny Poo, Dennis Lee.
Publisher: Springer Verlag