Recently I was speaking with an application developer who was facing a tough situation. He was being asked to create -- with fewer resources and less time to do so -- complex applications that are important to the functioning of the business. Clearly, he is not alone; many developers are in the same position. The rise of the Internet and hyper-tier computing distributed architectures (such as the Hurwitz Group's Hyper-Tier model, which I described in my April DBMS column--see page 10) have led business users to demand that even more functionality and complexity from applications be delivered in the shortest amount of time possible. It is my perception that the only way development organizations will keep the business users satisfied is to move to a component model of development.
Now, let me explain myself. Do I mean traditional, object-oriented development? No, rather, I am viewing components from a less granular perspective. Components are made up of business rules, application functionality, data, or resources that are encapsulated to allow reuse in multiple applications. The primary difference between this type of reuse and the traditional notion of reuse in object-oriented (OO) programming is the level of granularity required. In OO programming, objects are low-level constructs such as class libraries; reuse at this level is very complex to implement. Programmers have to understand the exact function that a particular library serves and use it appropriately.
In contrast, components are more likely to be large-grain services used in a variety of applications. A component might be a key algorithm for determining an interest-rate calculation. It is clearly defined, and developers can be alerted to use a specific component whenever they need to perform a certain function. Other components are those defined through ActiveX and Java. In these cases, the components are tied to interaction at the client level and can potentially call server-based applications and data.
If developers can build new components and reuse parts of applications they have already created, then applications can begin to emerge as assembly projects rather than elaborate, complex systems with a beginning, a middle, and an end. Components have the potential to redefine the applications development process, providing practical tools that will enable developers to succeed in a fast-paced Internet world that demands instant gratification.
The movement toward a component orientation is being driven by the rise of the Internet and the emerging distributed infrastructure. The Internet's increasing ubiquity has made it necessary to provide more people with more data from more sources. To be successful in this environment, developers must focus on creating flexible, scalable applications with large amounts of distributed processing. Component-based development is becoming increasingly popular as a way not only to create flexible, mission-critical applications but also to increase the productivity of the application development process through code and application piece reuse.
These productivity gains have disappeared, however, as developers attempt to stretch applications built with RAD tools into enterprise-scale mission-critical systems. The typical fat-client model does not work when an application is made accessible via a Web browser. Developers need not only tools that will help to speed the development process, but also tools that will change the model for applications development within an organization.
Both Microsoft Corp. and Oracle Corp. are moving toward a repository-based development model. Microsoft is using the repository developed jointly with Texas Instruments Inc. to transition Visual Basic into the distributed development paradigm at the enterprise level. (For more on Microsoft Repository 1.0, please see David Linthicum's column, Application Architect, on page 24.) Microsoft sees components, specifically ActiveX components communicating via DCOM, as its key to becoming a trusted provider of mission-critical software. Repository-based development is also central to Oracle's plans for Sedona. Unlike Microsoft, Oracle is pushing the CORBA standard through the use of IIOP and Java. Other tool vendors moving toward a component- and repository-based model are Compuware Corp., Intersolv Inc., Passport Corp., Prolifics, and Seer Technologies Inc.
Another issue is interoperability. The components a company builds may not necessarily work as expected with other components. Component testing has therefore become a crucial part of the development process. Developers need utilities for testing both visual and nonvisual components that may be scattered across the network at runtime.
Middleware is the hub of any component-based application. Unfortunately, standards for middleware are lacking, forcing users to choose among CORBA, DCOM, or a proprietary solution. While CORBA is a standard approved by The Object Management Group, the vendor specification DCOM is emerging as a de facto standard. Both technologies will remain viable, but I believe that DCOM will predominate because of industry support for ActiveX and OLE.
Pure object-oriented technology (OO) failed to fulfill its promises because those faithful to it never clearly articulated the business value of OO programming. They were never able to convince mainstream developers that mastering the complexities of OO was worth the substantial effort. Components will only be truly successful if developers aren't forced to learn a whole new style of programming. Tools such as Visual Basic, Delphi, and even packaged applications like SAP's R/3 are committed to making components an integral part of their development environments. Allowing developers to use familiar tools to create distributed components will greatly improve the likelihood of developers adopting this approach.
Successfully using components requires a long-term view of the development process. With components, applications will increasingly be modified, not replaced. As a result, analysis and design has become a much more important part of the development process. Users need to make sure that their development environment supports analysis and design functionality, either internally or through integration with vendors such as Platinum Technology Inc., Rational Software Corp., and Select Software.
Understanding the management requirements necessary for successful code and component reuse is more important than the selection of a development environment. However, developers should select an environment that makes the planning and implementation of a formal methodology easier. Features such as version control and team development are critical to success, and the development tool should support them in a repository-based development model.
The following recommendations will help organizations begin the process of leveraging components in the applications development process.