<B>Special Feature:</B> Components: Today’s Application Elements

• 11/04/1998

The mix of object/component building blocks keeps getting more complicated. ActiveX, COM/DCOM, COM+, JavaBeans, Enterprise JavaBeans (EJB), CORBA components, and more. An organization could get serious application frustration from such a mix.

The proliferation of components reflects the surging popularity of component-based development. In component-based development, programmers build new applications by snapping together existing components and objects, either previously built or purchased off the shelf, that work together to perform the function of the application.

Components are discrete pieces of code. They can be as small as an element of a Windows dialog box or as large as an entire legacy CICS transaction application. To ensure that components work with other components within the application developers build components in compliance with a component object interoperability model, such as COM/DCOM, Java Beans/EJB, and CORBA, which specifies interfaces and defines how properties and attributes are presented. More recently, component models have been extended to include object broker middleware, which enables components to find and request services provided by other components, and provides key application services itself.

The idea of snapping components together is very appealing. To build a new application -- say, a banking application for use over the Internet, -- the developers take an account component and a customer component and a debit object and a credit object and a component for this and a component for that, and mix them all together. At deployment they throw in an application server or object request broker (ORB) that will pass messages among the various components, and, presto, you have a functioning application. You can open an account, add money, withdraw money, and do whatever else is needed.

While the idea of snapping components together sounds easy, it is actually quite difficult. In the best of circumstances, serious programming in C++ or some other object/component language is required.

Component-based development was much simpler when developers created client-centric client/server applications. Here the programmers dropped in VBX and later OCX components to enhance the application. The component might add a nifty wrinkle to the standard Windows list box or provide video viewing and editing capabilities within the application. As long as all the desktop client systems are Windows machines -- which is a pretty good bet --the use of components in client-side applications is simple and generally straightforward.

The emergence of the Internet and three-tier/multitier Web-based computing, however, has greatly complicated the component-based development picture. Now, components do much more than enhance Windows clients. They provide extensive server-side functionality. In this new enterprise development environment, components that provide complex functionality come together at run time, find other components across the network, and cooperate to perform the work of the application. Throw in the multiplatform nature of the server side of enterprise, with Windows NT and a variety of Unix servers as well as legacy back-end systems, and a variety of component interoperability models offering varying degrees of compatibility, and you have a recipe for trouble.

Today, developers attempting to build multitier, component-based enterprise applications face a number of bewildering decisions: which component model -- COM/DCOM/COM+, Java/EJB, CORBA; which language -- C++, Java, Visual Basic; and which application server or object/component middleware – Microsoft Corp.’s Microsoft Transaction Server (MTS) or CORBA.

The latest entry is Microsoft’s COM+, the next version of COM. COM+ will combine existing services, such as MTS and Microsoft Message Queue (MSMQ), with a set of COM-based component services designed to run on NT. "Using component services, developers will conceivably be able to create distributed transaction-based applications from COM components that can be managed in a unified way," according to Dave Kelly, vice president of application strategies at the Hurwitz Group (Framingham, Mass). COM+ is Microsoft’s response to EJB and CORBA.

"This can be very confusing. These technologies [COM+, EJB and CORBA] are not really interoperable, although they are slowly getting to be more interoperable," says Karen Boucher, vice president, Standish Group, a research firm based in Dennis, Mass.

Making matters worse, these technologies are all at different stages of maturity. "Some are not quite there yet," observes Richard Pledereder, technical director/Web computing and product group at Sybase Inc. (Emeryville, Calif., www.sybase.com). JavaBeans, for example, are pretty well-established, but EJB technology is still new. ActiveX and COM are well established, but COM+ is only in beta testing.

Developers, however, can simplify things by breaking the choices into two camps, Microsoft or the rest of the world. The Microsoft camp embraces ActiveX components based on the COM/DCOM component interoperability model, which will soon evolve into COM+. Microsoft’s MTS is the application server that provides the component brokering and middleware services. The other camp has embraced JavaBeans and EJB as the component model and CORBA as the object broker and services middleware.

The two camps are coming together but not fast enough or tightly enough to help developers now. "COM+ will be more like CORBA in that it supports inheritance, which DCOM couldn’t do, but you are still talking about totally different application programming interfaces and communication protocols," explains Standish Group’s Boucher.

"Java Beans and EJB share the same component model, but EJB adds enterprise services that business applications need," contends Onno Kluyt, senior product manager/Java component architecture at Java Software, a division of Sun Microsystems software Co. These services include transaction context services or security services.

The CORBA crowd, led by the Object Management Group (OMG), is closely paralleling the services provided by EJB. "It is not yet one-to-one, but there are very close relationships between CORBA and EJB," notes Kluyt. For example, there are mappings between services, such as the Java naming interface and the CORBA naming service.

The Microsoft components today, on the other hand, aren’t technically objects. Rather, they present a series of interfaces to which developers write their functionality. The lack of a distinct object isn’t any problem within the Microsoft environment, but it makes integration between Microsoft components and Java/CORBA components awkward at best. With COM+, Microsoft appears to be adopting a more object-based approach to components.

To get the components to work together across the two camps, developers are turning to a variety of products, called bridges, that provide interoperability. For example, First Union National Bank (Charlotte, N.C.) created two enterprise CORBA components, Customer Central, which provides access to the bank’s legacy customer information system, and Document Central, which generates a variety of standard bank documents. The bank’s developers now build end-user applications that take advantage of these server-based components.

The bank’s users, however, work primarily on Windows desktop systems and run Visual Basic applications. To enable Visual Basic applications to work with the CORBA components, the bank turned to a component bridge, Object Bridge from Visual Edge Software Ltd. (St-Laurent, Quebec, www.visualedge.com). The bridge is a Windows DLL that makes CORBA components look like ActiveX components to the Visual Basic application, explains Bill Barnett, manager/distributed application technologies for the bank.

When developers were building two-tier, client-centric Windows applications, where the presentation and application logic resided on the client, the choice of COM or CORBA was the proverbial no-brainer. The organization got COM as part of Windows. Developers readily took advantage of it, plugging in a variety of VBX, OCX and ActiveX components.

Now that organizations are building multitier, Web-enabled, enterprise applications using server-side components, the choice is more difficult. Even though the organization has a massive installed base of COM-enabled Windows desktops, EJB or CORBA components may be the preferred solution. The choice revolves around enterprise scalability, multiplatform server environments and enterprise services.

In these three areas, the current Microsoft component offerings, COM/DCOM combined with MTS fall short. The Microsoft solutions are still overwhelmingly Windows- and Windows NT-oriented, despite efforts to extend ActiveX/COM to other platforms. Many organizations are not convinced that Windows NT can yet deliver the enterprise scalability of Unix servers. And even if NT did, these organizations already have large installed bases of Unix database and application servers, which they are not likely to abandon soon, if at all. Finally, many developers feel the COM-MTS combination is quite immature in terms of services. They prefer the CORBA offerings.

For example, the Sabre Group (Fort Worth, Texas) opted for CORBA components when it built its CargoNet application, an enterprise airline warehouse management and cargo logistics application that involves real-time messaging. Users working at Windows workstations will access the application, which is built in C++ using CORBA components. It currently runs on a Windows NT server with its Oracle database also running on an NT server.

"We could have done this using COM and DCOM, but the API is quite complex and you have to have a strong commitment to the Microsoft environment," explains Sundar Swaminathan, senior manager. Although the organization runs this application in a strictly Microsoft environment now, "we did not want to be bound to the Microsoft environment," he adds. If the organization opts for Unix servers down the road for greater scalability, it will not have to rebuild the application.

Similarly, Xerox Corp. in Rochester, N.Y., opted for Java applets and CORBA components when it built its self-service human resources application, called PeopleNet. Through this application, employees can enroll in benefits programs, sign up for training, and do other human resources administrative chores from their desktop via the corporate intranet. Although the vast majority of Xerox workers, about 37,000, use Windows desktops, the application relies on Oracle database servers running on Unix.

"We don’t have COM on our servers. We would have had to move to NT servers," explains Jim Johnson, architecture manager, Xerox human resources information technology group. The organization decided that adding NT into its existing server mix just to get COM didn’t make much sense when CORBA was readily available.

Microsoft is hoping that COM+ will be able to compete against EJB and CORBA or at least happily coexist. "Until COM+, you are faced with two really different component models, and it is a real pain to try to use both at the same time," Standish Group’s Boucher says. Whether COM+ will make a big difference has yet to be seen. "It is difficult to judge at this point. COM+ may be little more than a name change," suggests Kluyt.

One thing is certain: The choice of component models is only going to get more complicated, at least in the short term, as developers balance platform, scalability and services requirements. In the longer term, an acceptable level of interoperability will have to emerge if component-based development is to truly deliver on its promise of snap-together applications. --Alan Radding is a freelance writer, based in Newton, Mass., specializing in business and technology. Contact him at [email protected].@@SR

=

Component Object Model (COM)/Distributed COM (DCOM) evolved from Microsoft’s object linking and embedding (OLE) technology. COM allows components to interact within a Windows application. DCOM is intended to provide COM capabilities for Windows components distributed across the network. COM/DCOM relies on Microsoft’s Transaction Server to provide the necessary business services required for effective distributed component-based Windows applications.

COM+, the next evolution of COM, provides a distributed object architecture and a set of business services. COM+ is designed to provide capabilities for the Windows platform similar to Enterprise JavaBeans and CORBA.

JavaBeans/Enterprise JavaBeans (EJB) is an object-oriented component interoperability model for components built using Java. Enterprise JavaBeans will provide an extensive set of business application services, similar to CORBA. EJB and CORBA are moving on rapidly converging tracks. Beans run on any platform that has a Java virtual machine.

Common Object Request Broker Architecture (CORBA), developed by a consortium of companies under the umbrella of the Object Management Group, provides object/component interfaces and services for component interoperability across heterogeneous systems and languages. CORBA components can be built using a variety of object-oriented languages, including C, C++ and Java.