It is unusual to find a consensus among vendors of operating systems, development tools, and database products, but there is broad agreement that component-based development (CBD) is quickly becoming the dominant model for software development. In fact, when I asked representatives of Microsoft Corp., Sun Microsystems Inc., Symantec Corp., and Netscape Communications Corp. for their views on the future of software development, the unanimous answer was that CBD would soon become the standard paradigm for delivering both packaged and custom solutions. I then turned to the development community in an effort to learn whether these vendors were feeding me a line. Whether the developer was building a commercial product or a customized application, all responded with a resounding endorsement of CBD. If you have not yet begun to use CBD, there will be increasing pressure on you to do so; I'm feeling that pressure myself.
As a paradigm, CBD will supplant earlier programming archetypes, such as structured programming and object-oriented programming, as the approach most likely to yield significant productivity and reusability benefits. Its emphasis on iteration sounds the death knell for the traditional "waterfall" model of the entire development process. One of the reasons that CBD will gain broad acceptance is that it offers ways to address the complete range of software challenges, from operating system services to client/server development. Once you understand why everybody will be getting on the CBD bandwagon, you can turn your attention to how to take full advantage of it. You will need to change the way you design, build, and test solutions in order to adopt this paradigm effectively. Most significantly, you need to include CBD when planning long-term solutions to business problems.
CBD offers an opportunity to build architectures that will last well into the next century and promises ways to evolve solutions in the face of changing application requirements. In the marketplace, CBD -- along with the trend toward interorganizational computing over the Internet -- holds the power to open up opportunities for new and heretofore marginal tool vendors to make a significant impact on the development landscape.
The term "common infrastructure" refers to a widely accepted component architecture that many developers are accepting as the basis for CBD, such as Microsoft's ActiveX/COM architecture and JavaSoft's (a division of Sun) JavaBeans. There is not yet a widely accepted standards-based component architecture. (Although CORBA is the only standards-based architecture for object interoperability, its availability has not yet triggered a wide-scale development of CORBA compliant components.) I expect that JavaBeans, though a young technology, will ride the coattails of Java and gain wide acceptance. The forces that resist COM's hegemony have a lot to gain by supporting JavaBeans as a true multiplatform component standard that enhances Java's strengths. Recent announcements by vendors such as Netscape, Sun, Oracle, and IBM demonstrate that they are working toward this objective. All four vendors are working together to extend the JavaBeans component model by enabling them to interact with CORBA services and facilities.
Although many components are implemented as objects, a component does not have to be an object. A component only needs to package program functionality in a way such that the capabilities of the component are discoverable by the container during assembly and at run time. Thus a component need not be compiled and linked into a specific application in order for its publicly available capabilities to be used by that application. (An example of a component at the subobject level is the packaging of an algorithm, such as an interest calculator, as a component by defining public interfaces to the algorithm.) At the other extreme, it's becoming increasingly common to wrap entire legacy applications in component trappings to broaden access to the data they manage.
In several ways, CBD represents a right-sizing of object-oriented programming to the real world of business application development. The benefits of CBD play well to business managers. The buzzphrase "business process reengineering" has fallen out of vogue somewhat, but corporations continue to seek ways to improve their efficiency and their responsiveness to their customers. "Component think" enables IS designers to model processes and the links between them more effectively. Representing business processes with components, or collections of components, helps corporations rethink where links should occur and easily restructure information systems to mirror changes in those processes.
When you adopt CBD, you typically improve your development organization's ability to focus on business problems rather than on designing software architecture, and the choice of either ActiveX or JavaBeans largely defines the architecture. You gain access to a broad choice of development tools while you get a wide range of price points. It's quite feasible for an organization to use multiple tools (which support different programming languages) to implement different solutions, or parts of solutions, as interoperable components. This possibility enables the organization to optimize the match between business requirements and available skill sets.
Two key factors have combined to launch CBD into widespread acceptance. The first, the Internet, is the same one that is causing most of the upheavals in the development world. The Internet unleashes several influences. The most obvious has been the move to deploy business logic as applets that can run within a Web browser; components offer the only cost-effective way to deliver such browser-based applets. Less obvious but equally significant has been the impetus that Web architectures have given to the development of low-cost transaction and application servers. These need to be able to manage chunks of business logic that may have been developed in different programming languages. From a business standpoint, the imperative to use the Web as a way to eliminate barriers between interorganizational information systems is equally influential.
The second key factor is the maturity of the ActiveX/COM infrastructure, with the obvious support of virtually all development products, the success of the third-party controls market, and the resulting acceptance of CBD by the entire industry. Microsoft has advocated CBD for years, and the company's ability to drive the development marketplace ensures the primacy of the paradigm, if not of the ActiveX/COM architecture itself. We now find ourselves in a marketplace where commercial components that address a wide range of systems requirements are available at commodity prices. Components are moving off of the desktop and are beginning to play an important role in creating server applications, where they wrap specific business functions into reusable packages.
At the same time, packaged component vendors introduced components that were less visually oriented and offered more processing functionality. One such class of components wrapped the functionality of standard communications and networking protocols into a component with a defined set of properties and methods -- components that manage fax, MAPI, TAPI, SMTP, FTP, or HTTP sessions, for example. Another type of service-level component delivers the functionality of a database API as an ActiveX or JavaBean component; the foremost examples of these are Microsoft's own ActiveX Data Object and Netscape's forthcoming LiveWire database service.
In their next generation, components will encapsulate entire business entities and processes, administration of enterprise infrastructures, and operating system services. For example, you can write programs to administer Microsoft SQL Server by manipulating the properties and methods of its Distributed Management Objects (DMO). By providing DMO, Microsoft has effectively transformed the entire set of SQL Server administration facilities into components, enabling programs in any language that supports creation of OLE objects to perform those functions.
Microsoft's forthcoming Active Directory service will provide a single point of administration for all published Windows NT resources, such as files, peripheral devices, host connections, databases, Web access, users, and other objects and services. Active Directory components will facilitate development of directory-enabled applications by exposing the directory as a set of COM objects, which provide behavior as well as data. For example, an application can use an Active Directory PrintQueue object to retrieve data, such as characteristics of the queue, and also to pause the queue. Using Visual Basic code, this command is as easy as:
set MyQueue = GetObject("DS://Myco.Com/Division
/Product/Printers/MyPrinter")
MyQueue.Pause
Dim MyQueue as IOleDsPrintQueue
Similarly, service-level components are a key part of Netscape's Open Network Environment (ONE) initiative. Developers can access ONE services as standard JavaBeans, allowing them to be incorporated into applications using a JavaBean-compatible visual development tool. Both Netscape SuiteSpot 3.0 server and Communicator 4.0 client provide built-in services that developers can use in application development. For example, the database access service provides full-featured, native access to any major database, presenting it as a standard JavaBean that can be used regardless of RDBMS. You can embed the JavaBean in an HTML form and change its properties appropriately -- writing little or no code. Messaging Server 3.0 lets you write an application that sends a mail message using the SMTP protocol by setting the properties and events on a JavaBean.
Create a baseline application framework around a set of core services with enough functionality to support building a "recognizable" application, and then proceed in a controlled, iterative manner, with frequent builds of the entire application. Thereafter you can add or enhance components to provide additional packages of functionality. The Solar Turbines division of Caterpillar Tractor Inc. is taking a component approach to designing the person-machine interface that resides between engineers and turbine control systems. According to the Solar Turbines project architect Jack Hakim, CBD "facilitates structuring project development into a sequence of independent deliverables." Each deliverable is a package of defined functionality that can be accepted, tested, and managed in a repository.
Product architects for State of the Art Inc.'s Acuity Financials product and FlexiInternational Software Inc.'s FlexiFinancial products noted that CBD allowed them to move away from the traditional modular accounting system model, where processing functions are tied to a specific module like general ledger or inventory control. They are instead able to define components at the level at which users interact with the product, such as posting a journal entry or receiving goods into inventory. At deployment time, installers have a great deal of flexibility in combining these components to match organizational workflow. This architecture offers major benefits to accounting and ERP vendors, allowing the definition of an architecture that supports evolutionary enhancements at the component level by either the vendors themselves or third-party developers. FlexiInternational's director of product technologies marketing, George Dearing, pointed out that when you stop thinking in terms of an application, you get another benefit: the ability to organize your teams around common processes -- such as account validation, posting, or reporting -- rather than around traditional applications.
Adopting CBD presents an opportunity to reconsider the toolsets that your organization uses for the tasks of designing, building, and testing. Hakim recommends the component lifecycle management tools from Rational Software Corp.: RequisitePro for capturing requirements, Rose for design, and SQA Suite for testing. As part of its effort to improve support for CBD, Rational has added ActiveX support to Rose so that it can dynamically display an existing component's object model. With this feature, you can build and buy a collection of components and model how they should work together. To support the test cycle, Rational has improved integration between Requisite, Rational, and SQA: Requisite creates use cases for Rose as well as test requirements that can be loaded into SQA, and use cases created in Rose will drive the creation of test suites in SQA.
With CBD, you obtain a great deal of flexibility in your choice of programming tools and assembly platforms, which address a wide range of programming requirements and skill sets. Until recently, creation of COM components has required C++, but the newest releases of Visual Basic and Delphi extend this capability to more widely accessible 4GLs. The experience of developers such as Solar Turbines and State of the Art suggests that controls built using Visual Basic are comparable in size and performance with those built in C++. Hakim, a longtime C++ developer, claims that C++ is an advantage only for building controls that need to manage operating system- or hardware-based processes; for business logic components, C++ offers no advantages over Visual Basic 5.
As commercial products that are intended to serve as the cornerstone of businesses, accounting products must provide high reliability and good performance. Flexi's and Acuity's developers found that CBD imposes a new set of testing challenges. John Grant, architect of the Acuity product, suggests that components require a thorough white-box testing, with developers writing test harnesses to exercise each of the COM interfaces. By definition, components have well-defined interfaces, so it is relatively easy to create reusable test harnesses for individual components or groups of components and test all of their events and methods. Both Grant and Dearing suggest that you be prepared to make changes in component interfaces after discovering new requirements during your iterative development process. When you do, regression testing becomes extremely important; where hundreds of components touch a COM interface, changing one component necessitates that you retest your entire system extensively.
The Solar Turbines team built many of their components with the assumption that they or a third party would replace them with newer, more functional versions. In some cases, they knew that other companies were building components that were not yet ready for deployment. Since they needed immediate baseline functionality, Solar Turbines built versions that the company knew would be short-lived. Discussing the application requirements with third-party vendors and obtaining beta versions of their forthcoming controls allowed the company to build "interim" components with similar interfaces. Hakim points out that it's not absolutely necessary for homegrown components to have interfaces that are identical to those that will replace them. The COM specification allows for the replacement of a component with another that has a superset of its capabilities. In cases where component interfaces are slightly different, you can implement a shell component and map the property and method names of the replacement component to those of the original through the shell.
Microsoft is promoting the acceptance of industry-specific COM implementations, such as the OLE Process Control (OPC) standard for controlling manufacturing equipment. Microsoft developed this standard in conjunction with other industry representatives and has established similar initiatives in the healthcare, insurance, and retail industries. To the extent that they define common interfaces and specific property sets, these industry-specific COM implementations provide a reliable framework for developers. Solar Turbines has built its application in accordance with OPC. According to Hakim, adhering to a "secondary" standard virtually guarantees that components you build will be compatible with those that become commercially available later. He recommends using the OLE service model and industry-specific features as a means to maximize project efficiency.
The COM architecture yields mixed blessings for developers and the solutions that they build. Its biggest advantage is the momentum that has built up around it because of the ubiquity of COM infrastructure on the Windows platform. Another major advantage is the flexibility to produce and consume ActiveX components and automation servers with a variety of tools and languages. The introduction of Visual Basic 5, with its ActiveX control-creation abilities, creates a huge population of developers with the technical savvy to build business application components. COM's implementation as a system-level component model facilitates interoperability between disparate container applications as well. Most products that run as Windows applications, from productivity software to development tools and Web browsers, know how to interact with ActiveX components. Thus, ActiveX developers see an opportunity to write once and run in a Web browser, an application infrastructure, or a spreadsheet or word processor. Implementation at the system level, COM's major strength, also presents its most significant vulnerability. Using COM components requires a platform that supports them, and currently only Windows 95 and Windows NT support them effectively. Only within the past year have user hardware platforms become sufficiently powerful to allow widespread deployment of component-based applications. In fact, if my experience is any predictor, it is going to take more time before the people who actually must use these solutions will get the computer upgrades necessary to make it a pleasant experience. In an effort to broaden COM's platform reach, Software AG of North America Inc. is developing DCOM implementations for MVS and a variety of Unix platforms; Sun Sparc and Digital Alpha versions should be available by the time this article goes to press. The effectiveness of DCOM on these platforms remains an open question, as does the issue of portability of ActiveX user-interface controls to different platforms.
As young technology, JavaBeans comes to us full of promise. JavaBeans is a natural component architecture for the Java model of computing in which a Java Virtual Machine sits atop your native operating system and executes applications and applets delivered in bytecode form. Instead of relying on an infrastructure that is based on system-level registration and service providers, JavaBeans are simply Java classes that adhere to certain rules and expose their services via a standard set of Java classes. JavaBeans-enabled development tools and virtual machines must query JavaBeans and their associated BeanInfo classes directly to "learn" about their publicly available properties and methods. (For details of the mechanics of this process, see "JavaBeans in Action," Internet Systems, May 1997, page S9.)
Although JavaBeans offer a component model that will run on many computing platforms (that is, as soon as browsers and virtual machines support JDK version 1.1.1!), there is only one language for creating them. As support for the initial JavaBeans specification spreads, Sun will solidify specifications for enhancements and for Enterprise JavaBeans. The key enhancements will be the addition of a protocol whereby JavaBeans will be able to discover other attributes or services that may be available in its surrounding environment, the ability to create a Bean as an aggregate object that fundamentally is still an object with single inheritance but that can exhibit behaviors beyond those possible with single implementation inheritance, and drag-and-drop capability. Enterprise JavaBeans are being designed to serve as server-side components that are capable of managing transactions.
Tools for automating the creation of JavaBeans have been slow to appear; based on my discussions with product managers for Symantec's Visual Cafı Pro and Sun's Java Workshop, such tools are currently on the drawing board. Java-based development platforms are playing catch up with the richness of Windows-based development tools such as Visual Basic, Delphi, and PowerBuilder. JavaBean component assembly platforms such as Netscape's Visual JavaScript, Sun's Java Studio, Lotus BeanMachine, Borland's JBuilder, and a small host of others promise to provide sophisticated development capabilities with little or no programming -- but most of these products are just beginning to reach beta stability.
After platforms, it comes down to a language and tools decision. I'm having a great deal of difficulty deciding on which languages to use for developing a component architecture that transcends client and server processes. Java is attractive because it is powerful enough for implementing system services and is accessible to business component developers, enabling us to standardize on a single language platform and set of tools. If you go this route, JavaBeans will be your natural choice for a component model. The problem with this decision is that it would mean having to rewrite all of our processes and retool all of the developers to make them effective Java programmers. I am also concerned about losing the access to hardware and operating system services that you get with C++, although you only need it for a small percentage of your software. Interoperability with our partners' Windows products would also be a concern. The technology exists to embed JavaBeans in ActiveX wrappers, however doing so adds another layer of overhead to the COM infrastructure, which is already too heavy.
Certainly the momentum in the tools arena continues to push COM forward. Development tool vendors widely support ActiveX/COM, and the action is now moving into design, modeling, and repository management. Any serious component-based development effort is going to require such toolsets. Microsoft has worked hard to lay a foundation for third-party efforts to build such tools by promoting a repository management standard and supporting the effort to advance Unified Modeling Language (UML) as the basis for emerging component-design tools. Here too, Sun and other supporters of the JavaBeans architecture are playing catch-up, with products such as Sun's JavaPlan application-modeling and forward- and reverse-engineering tool, and initiatives such as Java Financial Object Exchange (JFOX), which is developing distributed object frameworks and tools specifically designed for the financial services market. DBMS will continue to offer analysis of these tools and of the role they will play in your adoption of component-based development.
Taking a component view of your application landscape will yield rewards, regardless of what platform you choose. In my work, I am finding it beneficial to diagram all of the systems -- which have been developed in a variety of languages -- as a collection of interrelated components. Doing so has given me the ability to reassess where specific functions should really reside. It has clarified how the overall architecture of our systems should manage intercomponent communications. Rewriting the system as a collection of independent components lets me have a small development team and reuse existing code in a way that I had not previously envisioned. This conceptual approach to system design and implementation is winning me over, and I expect it will win over a great many development organizations during the coming months and years.
What did you think of this article? Send a letter to the editor.