In-Depth

Tooling up for Components

• By Tony Baer
• June 18, 2001

With component-based development becoming today's hot buzzword, it is easy to forget just how recently this "plumbing" was developed. Just ask Countrywide Home Loans, the nation's largest independent home loan provider. When the firm began developing a loan origination application based on Microsoft OCX controls -- the forerunner of today's COM and DCOM component models -- it had to invent many of the basics. This included tasks such as reading and linking component interfaces, as well as maintaining database connectivity, all of which are taken for granted today.

What makes component-based development attractive to users is its potential to reduce application complexity and promote reuse. However, prior to the emergence of specifications from Microsoft Corp., Sun Microsystems Inc., Cupertino, Calif., and the Framingham, Mass.-based Object Management Group (OMG), the only choices available to application managers were inventing their own component models or relying on tool-specific ones.

Yet the new standards are just that -- new. For example, the Enterprise JavaBeans (EJBs) 1.0 standard supports traditional transaction models, but will not offer "entity" beans attuned to newer, object transactional models until an as-yet unscheduled upcoming release.

Nevertheless, the emergence of COM, Corba and various flavors of client- and server-side JavaBeans is happening not a moment too soon. Packaged applications are taking a larger bite out of internal development, with the market expected to double to $100 billion in five years, according to International Data Corp. (IDC), a Framingham, Mass.-based research firm. Theoretically, components should make internal development a more competitive option, with tool-makers taking notice. Most development tools now provide the ability to automatically generate COM, Corba or Java components, or at least develop interfaces to them.

Generating a standard component is only the first step, however. What about how the components should be bolted together? Without guidelines that define the relationships between various parts, conflicts might occur. In automotive manufacturing, for example, a wheel attached with a screw could be threaded into a dashboard with the same fitting. You probably would not want to drive such a car, however.

Translated into software terms, a component for a customer order credit limit and product paint color could sport compatible wrappers or interfaces, and their behaviors might not necessarily conflict. But could you imagine an application piecing them together without additional logic?

Not surprisingly, a growing number of tools are addressing the need to provide this elusive context. Some tools now bundle their own native repositories while offering grudging support of third-party repositories from Microsoft, Unisys Corp., Blue Bell, Pa., or other vendors. A few vendors, such as Select Software Tools Inc., Irvine, Calif., offer separate component manager products that document the components stored in those repositories. And other firms, such as Microsoft and Sybase Inc., Emeryville, Calif., bundle front-end and middleware components under a common umbrella.

UML-based modeling tools from Platinum Technology Inc., Oakbrook Terrace, Ill., Rational Software Corp., Cupertino, Calif., and Riverton Software Corp., Cambridge, Mass., are committed to generating not just raw objects, but components that are compatible with Microsoft, Corba or Sun standards. However, the most popular feature is the framework, a library of generic processes for functions such as workflow or system functions, such as mapping application functions to the operating environment. In some cases, frameworks are even going to the "next step" by including business templates that are almost applications in the raw.

Been there, done that

Component-based development did not dawn with COM/DCOM or Corba. During the heyday of two-tier client/server development, Forté Software Inc., Oakland, Calif.; Nat Systems, Paris; Magic Software Enterprises Inc., Irvine, Calif.; Netron Inc., Toronto; Progress Software Corp., Bedford, Mass.; Seer Technologies Inc., Cary, N.C.; Sterling Software Inc., Dallas; and Uniface Corp., now part of Compuware Corp., Farmington Hills, Mich., offered tools that supported multitier development. Because component and application communication standards had yet to exist, many of these tools devised their own formats to modularize code. Forté, for instance, built its own format and messaging infrastructure layered atop TCP/IP.

In most cases, these veterans are slowly embracing the new generation of DCOM/ ActiveX and Java/IIOP interfaces in order to protect their installed base. There is also the common refrain that open systems standards take time to achieve the robustness of their proprietary counterparts. For example, while Forté offers the necessary interfaces, it still claims that its
proprietary format offers superior multithreading and application messaging capabilities, and in the long run, may offer DCOM/Corba/JavaBean bridges.

Other vendors have added component-based development capabilities to tools built initially on Case and entity-relationship modeling foundations by extending their meta models to support component specification. Sterling's Cool:Gen product, for example, now generates Microsoft COM components.

But there are vendors that are reticent about supporting the new generation of de facto component standards. Netron maintains a proprietary "frames" architecture that relies not on distributed object request brokers (ORBs), but on traditional CICS-style transaction monitors. Like many tools on the market, Netron provides "frameworks" consisting of groups of generic functions, such as SQL call generation, reporting and Cobol screen painting. While Netron has not yet generated COM or Java components, it promises to do so in the future.

Suites anyone?

Microsoft and Sybase are among the best examples of vendors trying to be almost all things to some people. Microsoft's Visual Studio 6.0 -- which despite its release number is actually the second release -- combines all of Microsoft's development tools. It includes languages, an HTML application builder, a transaction server, a distributed application "wire" analysis tool, a lightweight version of the Rational Rose modeling tool and several component management tools built around the Microsoft Repository. Like Microsoft Office, Visual Studio features toolbar-level integration of a collection of separate tools that can generate -- what else -- COM components automatically. Although data modeling and testing are notable omissions, Visual Studio is one of the broadest component development environments available -- that is as long as you are content working only in a Windows environment and with COM component models.

For its part, Sun has unveiled Java Studio, which includes a visual development tool, a UML modeler and configuration management. It also offers Java Workshop, which provides GUI testing capabilities and will eventually include a load-testing element. Java Studio currently supports Java- Beans, but is still working on EJB support. Of course, you can develop and test all you want, as long as you are working on a 100% pure Java virtual machine environment.

If the pure Microsoft or Sun solutions are too restrictive, Sybase's Enterprise Applications Studio provides a more agnostic alternative. It consolidates its PowerBuilder and Java tools with the Jaguar Transaction Server that supports COM, C++ or Java components, a light version of the Riverton HOW modeling tool, and a development copy of its mobile database (SQL Anywhere). The Sybase offering might provide a migration path for classic PowerBuilder fat client applications, but PowerBuilder developers will have to be patient. Jaguar will not support PowerBuilder objects until next year.

A framework in every pot

Next to component, "framework" is probably the most overworked term in application development today. And virtually every tool supplier claims to offer one.

At their core, frameworks are pre-built system services that allow application components to work with operating systems, visual environments and data sources. The goal is to avoid the need for developers to reinvent some of the basic plumbing, a critical productivity requirement that keeps development teams focused on what counts: business logic. Providers such as Blueprint Technologies, McLean, Va., Persistence Software Inc., San Mateo, Calif., Riverton Software and Template Software Inc., Dulles, Va., deliver varying combinations of services, such as transaction state maintenance, database mappings, application logic mapping, and partitioning and process monitoring. Riverton backs this up with a UML-oriented modeling environment, while Blueprint Technologies relies on Rational Rose for application models. Platinum, meanwhile, is building a framework for component development based on the Catalysis methodology.

Most of these tools also offer business logic builders or templates. For instance, Blueprint Technologies and Template are planning business logic frameworks for specific vertical industry sectors. In some cases, these frameworks could morph into packaged applications in the rough that could stand on their own or fill the gaps not covered by popular enterprise resource planning (ERP) packages, such as SAP's R/3.

Scalability hurdles

One of the major issues when scaling up component-based applications is delivering robust back-end services. Distributed applications require more complex back-end services than simply connecting to a database. For instance, a simplistic view of a distributed securities trading application would replace monolithic logic with the following process: A trading order component would invoke a customer credit history component, which in turn invokes credit threshold components. However, each of these components might be based on different servers. Therefore, there has to be a way for "disparate" components to talk to and invoke one another.

One approach is a transaction server that coordinates the messages sent back and forth. Providers such as Microsoft and Sybase promote their bundling of native transaction servers with development tools. This is based on a traditional, transaction processor monitor view of the world that regards messages as transactions, not necessarily as objects.

The other approach is the object request broker model that involves multiple, individual interactions between distributed
objects. Surprisingly, Scotts Valley, Calif.-based Inprise Corp., which offers a spectrum of development tools (JBuilder, for example) and ORB middleware (like its Visi- Broker ORB, which the firm added as part of its Visigenic acquisition), has not yet added any integration between those products. Conversely, New York City-based Prolifics Inc., which offers only development tools, provides interfaces to Microsoft Transaction Server (MTS) and the Tuxedo transaction monitor from BEA Systems Inc., Sunnyvale, Calif. Prolifics will also add support for BEA's new M3 Object Transaction Manager.

Of course, the choice of transaction server vs. ORB as a back-end strategy for building an engine capable of supporting high-throughput applications is a philosophical debate. ORBs are the purer, but less mature view. Proponents claim distributed object-oriented approaches are, in the long run, more scalable as they avoid the use of monolithic transaction monitors or servers that limit flexibility, and threaten potential bottlenecks and single points of failure. Transaction processing promoters respond that their scalability and robustness is proven. Object transaction monitors theoretically combine the best of both worlds, but BEA's M3 product is barely a few months old.

Another approach to the problem is taking the well-worn technique of caching inside the component itself. Persistence Software uses this method, and has developed an application server that caches frequently used logic and data to minimize database I/O for EJB and C++ components.

The other side of the scalability issue is deploying components. Admittedly not a showstopper for small applications, the issue becomes more critical to high-throughput applications as they are likely to be more complex and involve larger populations of components. Repositories and component managers take care of half the equation: They store and organize components, but few, if any, are capable of deploying them at runtime. When large numbers are involved, it becomes necessary to ensure that the right versions of the components are deployed at the right time.

InLine Software Corp., Sterling, Va., has proposed an interim solution. A meta data modeling tool that acts as the bridge between Java development tools and application servers can extract EJB archive files characterizing business functions and convert them into eXtensible Model Interchange (XMI) files, a spin-off of the eXtensible Markup Language (XML). At runtime, XMI files are loaded into a temporary repository. Nonetheless, InLine admits that this is not a long-term substitute for a real, permanent repository.

Loose ends

Testing, however, remains the Achilles' heel of component-based development. Automated tools still tend to focus on aggregate behaviors, such as how well the screen navigation works and how well servers can handle the logical processing loads. For instance, Mercury Interactive Corp., Sunnyvale, Calif., recently added the capability to test DCOM calls on MTS. Meanwhile, Rational has consolidated its various load and screen testing tools from SQA, Performance Awareness and other acquisitions into the Darwin Performance Studio.

But as organizations deploy larger applications involving larger groups of components, only careful design can prevent components from being deployed with overlapping or conflicting functionality. Today's automated testing technologies can test DCOM or JavaBean wrappers, as well as perform data-driven regression tests to check the soundness of the logic under stress. However, they cannot look under the hood to judge whether a customer component identifying a customer might overlap with a credit history component that duplicates customer information functions.

Testing is but one of a number of issues that impact component development. The most effective means for scaling up component-based applications remains a topic of debate. And, of course, the issue of how standard "standard" components will be remains. For instance, could a developer of a back-end COM business component be confident with generating applications in the COM-compliant language or tool of their choice?

There is little question that components are in most developers' futures. But for all these questions, there is currently only one sure answer. In the world of component-based development, waiting for solutions remains a virtue.