In-Depth

Raising Components

• By John D. Williams
• January 1, 2001

When object-oriented technologies first made their way into corporate IT operations, developers often struggled to integrate purchased libraries of objects into internally built systems. Name-space collisions were a common problem. Libraries at times had many internal dependencies that required the use of multiple imported objects when only one or two were available. Standards for interfacing objects were non-existent, so developers created their own interfaces—which may or may not have matched those used by specific vendors. Best practices did exist, but no widely accepted standards for those practices evolved. The promise of the technology was great for corporate developers. The reality was that the old ways were still best.

The evolution from object-oriented systems to component technologies was supposed to fix all these problems. The promise of reusable components would drastically cut the cost and time associated with developing corporate applications. Yet corporate developers must still ask the question: Are purchased components easier to use and integrate with homegrown components? The answer varies depending on the situation.

Being a longtime object and component developer, I expected several changes to come about with the increased use of components by developers in recent years. As the technology improved, I expected many of the past technical integration issues to be eliminated, or at least greatly diminished relatively quickly. Also, once the promise that purchased components are indeed easier to integrate and use was fulfilled, it was certainly reasonable to expect that the pace of development would accelerate significantly. As a corollary, one would expect widespread component development to substantially cut development costs. Once component development overcame these hurdles, I expected most of the remaining issues to be technology-centric.

These were my expectations, but what I found surprised me. While the expected issues were addressed, new ones had surfaced to take their place. Technology is no longer the primary roadblock to component development.

The benefits of components
Developers have spent the past few years debating the quality of today's development environments. Some veteran developers claim that environments have not changed much since the Smalltalk 80 platform inaugurated the earliest days of object-oriented development. Others say important improvements have been made that can quickly spread the cause of component-based development.

Through it all, for better or worse, observers say one thing is clear: There has been real change in the process and technologies used to build components. One of the clearest signs of this change is the spread of Microsoft Corp.'s ubiquitous Visual Basic language and toolset through corporate development operations.

Many developers have noted how easy Microsoft has made it to develop COM components using Visual Basic. And since Visual Basic is the single most popular development environment for corporate developers in IT shops of all sizes, development of COM components spread like wildfire throughout the 1990s.

While certain developers sometimes maintain that there is a need to move on to Microsoft's newer Visual C++ tools to gain the full functionality required in a COM component, Visual Basic for the most part still fits the vast majority of component development needs for operations that widely use COM technology. Visual Basic made it easier for most corporate developers to build with components right off the bat because of its use of "drag and drop" and visual construction techniques—quite revolutionary for desktop developers when they were first unveiled by Microsoft almost 10 years ago. Over time, Microsoft added various "wizards" to the tools to help users build multiple components simultaneously, a capability that has made it easier to incorporate purchased components into applications.

Component integration efforts have also expanded widely as more and more Java-based technologies find their way into corporate developers' toolkits. The top Java IDEs from companies like Inprise/Borland, WebGain and the Forté unit of Sun Microsystems Inc. have come a long way from the early "build a simple applet" days.

The key step in the evolution of the tools was simplifying the development of JavaBeans. The development of "wizards" and visual construction techniques helped Java developers in the same way that such techniques helped Visual Basic developers. Experience in building these GUI components laid the groundwork for new tools to aid in constructing more complex Enterprise Java- Beans (EJBs). Though Java IDEs have not yet achieved the overall ease of development seen in Visual Basic, these environments have become significant aids in component development and assembly.

The spread of both Microsoft COM and Java technologies has helped component technology address the long-standing challenge to the spread of object technology—the lack of industry-wide standards. The creation of COM and EJB standards has greatly simplified component integration. Furthermore, each of the standards allows developers to better address some of the old problems, such as dependency and encapsulation.

Components can do a better job of operating like true black boxes. They can also do a better job of eliminating hidden dependencies. This simplifies their reuse and helps developers avoid nasty surprises.

Requiring a developer to include many unexpected components in order to gain the use of the one they want is not "nice."

That said, one would expect components to support speedier development—and they do. For example, most IDEs come with a large set of GUI components that are de rigueur for any development environment. They have been so successful that no application developer builds proprietary GUI components anymore. The spread of third-party GUI components is perhaps the single best indication that purchased components can be integrated relatively easily with homegrown components. Components at the GUI level are often relatively simple to use, which has enabled the creation of what some market research firms say is a $300 million market.

We can take the integration of purchased GUI components as a given. But what happens with a move to more complex components? A developer at one company, who requested anonymity for himself and his company, said he recently used five purchased domain-level components to build a new product. These components amounted to about one-half of the firm's system code, and the company believes that its development time was cut in half by integrating these purchased components into its own software. This is not the only company experiencing these kinds of benefits. Middle-tier and domain components are becoming more readily available. The companies that have been able to use them are experiencing significant productivity gains.

The growth of the component market bears this out. According to a study by GartnerGroup, a Stamford, Conn.-based research and consulting firm, the market for pre-built components will grow from $1.4 billion in 1997 to more than $8 billion in 2002. Gartner also predicts that by 2003, at least 70 percent of all new applications will be assembled primarily from components. Does this prediction make sense? Charles Stack, president of Cleveland-based Flashline.com Inc., which runs a so-called component marketplace, said his company has experienced exponential growth selling packaged components during the last year and a half. Much of the recent growth has come in the EJB arena as the J2EE Java standard pushed by Sun Microsystems and many of its Java allies has stabilized.

Clearly, today's IT market demands much more than GUI components from suppliers of packaged systems. Thus, a slew of developers are moving to build and sell higher level middle-tier and domain-level components and frameworks.

E-commerce frameworks, such as those from San Jose, Calif.-based BEA Systems Inc., are in great demand. Middle-tier frameworks for integrating systems are also a hot ticket item. Horizontal domains, such as logistics, are seeing an increased demand for purchased components because of their use in e-commerce systems. Unfortunately, there is little available in the way of domain frameworks for vertical markets. This is starting to change, with some frameworks starting to appear for the insurance and financial industries. Flashline.com's Stack noted that, on the whole, demand still far outstrips the supply of available components.

The challenges
Though observers say component-based development is spreading through IT development organizations, some critical barriers to more widespread adoption remain. Even as we conquer many of the longtime problems of object technology, new ones emerge to challenge the use of components. Developers face many technical issues, as even greater challenges arise as the move to component-based development forces changes in terms of development approaches and corporate cultures.

During the past few years, the architecture of software systems has become more and more complex. Corporate developers have moved from building monolithic and client/server applications to building distributed n-tier systems that can take advantage of the World Wide Web. In the new environment, developers must create systems that are far more scalable, robust and amenable to change than ever before. The rapid changes have significantly complicated corporate application development. Business logic has been moved to middle-tier application servers, which are often difficult to use and add complexity to both development and the supported infrastructure. Furthermore, the use of application servers can add significant costs to the development and deployment of applications. Though the use of application servers can easily be justified by directly addressing important scalability issues, their cost and complexity does make component adoption more problematic for IT organizations.

Component development is also impeded by the dearth of tools that fully support the front-to-back testing and deployment of distributed n-tier applications. Additionally, licensing policies can hinder component adoption. In many e-commerce applications, developers look to create systems that have automatic failover and recovery. However, organizations do not look kindly on having to pay twice for components that are running on a single machine at any one time. The pricing models of many component suppliers has yet to catch up with the realities of an e-commerce architecture.

Cross-platform incompatibilities have long been the bane of application developers. In order to avoid these types of problems, many companies pick one specific technology as their official component technology. But the reality is that no matter which technology a company chooses, another incompatible technology will somehow find its way into the organization.

At some point, an effort will be started that aims to let incompatible technologies communicate. This is often true when an organization uses one technology to develop applications, but finds it necessary to purchase another technology to use in a specific project. Current technology bridges are often wretched affairs that are difficult to use and lack even adequate performance. Underlying fundamental differences in component architecture are generally the chief cause of such problems. Still, at their best, current tools usefully provide only one-way, limited transfers of information.

On the EJB side, there are additional problems with application server incompatibilities. It is great that the J2EE specification allows users to create and work with standard EJBs. But attempts to make an EJB run on application servers built by multiple suppliers will likely be a very frustrating experience for developers.

To make matters worse, most application server providers do not want cross-server compatibility, arguing that proprietary technologies can provide significant added value to users. They believe their "unique" features give their server a distinct advantage in the marketplace.

Such philosophies, which remind observers of Unix systems suppliers of a decade ago adding value while abandoning standards, limit component suppliers to delivering their EJBs on only one or two specific application servers. Experts predict that in the coming few years, a consolidation wave will hit the application server market, cutting it from more than 50 today to only about a half dozen. The top-tier application server providers will initially benefit from the lack of compatibility, while the others will have to find a new line of work. Clearly, both end users and component vendors would benefit from cross-server compatibility. Extensions to the J2EE standard could improve compatibility despite the efforts of suppliers, say observers.

Systematic reuse
Organizations are also struggling with the problem of keeping tabs on a growing number of components that are both internally developed and packaged. Even if that problem is solved—and it can be—developers must also figure out how and where to best apply specific components for specific projects.

Several consultants have started pushing developers to a corporate reuse center model, which many contend would pay for itself in the long run by helping development teams select and apply purchased and homegrown components effectively. Unfortunately, many organizations have no idea how to effectively implement such a model. The common corporate idea of reuse is the opportunistic sharing of code among programming buddies. This may include the creation of a library where each developer can contribute his or her favorite code. The end result of such an approach is oftentimes a landfill full of code refuse, not reuse.

Let me say just two words to point you toward a practical solution to the problem: systematic reuse.

At the very least, you need a repository to help you manage the components you purchase and build. Princeton Softech Inc., Princeton, N.J., sells a tool called Component Manager that can help users categorize and manage components. It can serve as a repository for reusable components and will work with any type of component. Flashline.com Inc. has the Flashline Component Manager, which can integrate with a Java IDE or may be used as a standalone repository. It is available as a download from Flashline.com. It also ties into Flashline's testing and certification services, as well as their component marketplace.

The question of trust also remains a major issue for developers looking to purchase packaged components. Based on past experience, many developers demand assurances that the components they buy are good. Can they trust it? This has long been a central issue for reuse, a key reason that object and then component-based development has been so slow to take hold in IT development organizations.

When a reuse center is established, it can test and certify internally developed components before they are published to the development teams. And what about purchased components? One approach is to use an independent third party to test and certify components for the open market. Experts envision a system that is somewhat similar to the Underwriter's Laboratory (UL) model used to certify electrical devices. Flashline.com has started to offer testing and certification services, but it remains to be seen if developers would take seriously a program run by a firm that also sells packaged components. Many experts maintain that a testing and certification process must be independent of a single supplier to be effective.

The biggest challenge facing the effort to integrate purchased and homegrown components is the lack of a methodology for building components and component-based systems. While I did not expect this to be the biggest issue, many companies simply have not created or implemented a methodology that can help build component-based systems. Companies are spending significant monies on component development environments, application servers and outside components to take advantage of the promise of component-based development. Developers in these companies may also learn a basic technology, but building a distributed n-tier application with that technology remains beyond their grasp. It is difficult to integrate purchased and homegrown components when you cannot build a basic component-based system. Some companies have already given up on components for this very reason. Clearly, those who can help firms implement a practical component methodology have an abundant business opportunity.

Questions
While researching this article, I looked for instances of different component technologies in the marketplace. COM, JavaBeans and EJB were the big winners. Component frameworks based on Cool:Gen from Computer Associates International Inc., Islandia, N.Y., are available for the insurance and financial markets. One surprise was the lack of discussion about CORBA components. It is true that this component specification built by the Object Management Group (OMG), Needham, Mass., is new, but I expected to hear someone talk about exploring or adopting it. Nary a word was heard. Perhaps it will be a case of too little too late.

At one point, many observers expected Java would revive an interest in CORBA. This may have happened, but current talk simply centers on the J2EE standard. CORBA has not received the uplift many hoped for from Java and EJBs.

So what is next for pre-built, packaged components? Clearly, this market is in a rapid expansion phase. One or two years ago, you would have had to spend a lot of time with IT departments explaining what components were and why they were good for you. Such explanations are no longer necessary for most IT development managers. Many users now know what components are, and must spend much of their time trying to figure out how to move to this technology.

The time is right for those who can help firms make this move, as well as for those who want to develop components for sale. Suppliers must quickly move beyond selling GUI components and develop middle-tier and domain components that can help firms build complex systems. The demand for such components remains much greater than the supply.

On the EJB side, expect a market shakeout among application server vendors. Many would benefit if the market could agree on a level of server compatibility. Unfortunately, it appears that the game of server dominance is the one that will be played out in the market. Expect to see top tier vendors such as Microsoft, IBM, BEA, iPlanet and perhaps one or two others survive and thrive.

Challenges remain in the integration of purchased and homegrown components. Yet we are much further along than we were in the object technology days. Development can be faster and more cost-effective for those who know how to build component-based systems. IDEs have also improved significantly during the past few years. Several of the old compatibility dragons have been slain. Higher levels of functionality are now available as off-the-shelf purchases. Still, the work is not complete. Our greatest challenges are twofold. We need to help firms learn how to develop component-based systems successfully, and we need to expand the market of available components rapidly. By overcoming these challenges, we can help developers rapidly deliver real value to their firms.