260appen.htm

You have probably seen more than a dozen articles, seminars and presentations about the Object Management Group’s Common Object Request Broker Architecture (CORBA) and Microsoft’s Component Model (COM) Object Model (COM).Unlike previous literature on this subject, however, this article does not compare the technologies in isolation or discuss the relative merits of interface versus implementation inheritance. Rather, it focuses on how CORBA and Distributed COM (DCOM) provide a solution for developing large-scale, business-critical applications, and how they assist in the deployment of these applications within the intranet, over an extranet, across the Internet or simply with a Web front end.

For the purposes of this article, we must first define what is meant by a "large-scale, business-critical application." Simply stated, any application that implements a critical business process within an organization—and as such, directly impacts that organization’s bottom line—is a business-critical application. Typical examples include the mortgage processing system at a mortgage lender, the claims verification system at an insurance company, or the inventory management system at a manufacturing plant. Effective, business-critical applications must also exhibit at least a majority of the following features:

Scalability: The ability to easily and quickly accommodate an increase in services, whether the increased demand is due to a tenfold increase in users, a twenty-fold increase in user data, or a hundred-fold increase in distance from users.

Reliability: The application needs to be available 24x7, which requires fault-tolerant features such as sophisticated error-handling and recovery, automated restarting upon improper termination, as well as automated failover to replicas in the event of catastrophic failure.

Security: Since business-critical applications handle company-sensitive information, they need to be able to authenticate the identity of users, control user access to particular operations, provide irrefutable evidence of their involvement in a transaction (non-repudiation), and prevent eavesdropping or tampering with any of the above.

Manageability: Like anything in life, you need to take good care of an application if you want it to perform optimally for as long as it is needed. This becomes much easier if the application is inherently manageable: i.e., it can be centrally configured and administered from a system management console, can provide usage and statistical information that can be used for auditing and performance tuning, and it can support versioning and revision control.

Before looking at how DCOM and CORBA assist with the above requirements, it is important to understand each of these technologies. Since there are numerous books and Web sites that do a good job explaining both DCOM and CORBA, this article will only summarize the key points of each architecture.

COM and CORBA both provide a framework for creating and using components that can interface with each other—as well as with other applications, libraries, system software and networks—in a standard, well-defined manner. While CORBA was designed from the ground up to support components that could exist anywhere on the network, the original implementation of COM ran on a single system. Distributed COM added the ability for COM components to interface across the network, using a remote procedure call (RPC) based on The Open Group’s Distributed Computing Environment (DCE).

CORBA generally uses the Internet Inter-ORB Protocol (IIOP) for communication between components, although it is possible to use the DCE RPC for this purpose. An essential part of both frameworks is the "value-added" services—naming, security, persistence and data access, events and transactions—they provide to components. Finally, while DCOM is a Microsoft technology that exists as a single implementation, CORBA was defined by a consortium of vendors called the Object Management Group, many of whom have their own implementations of CORBA and its associated services.

DCOM and its associated value-added services, including Microsoft Transaction Server (MTS), Microsoft Message Queue Server (MSMQ), Microsoft Cluster Server (MCS) and Microsoft Management Console (MMC), provide a set of products, libraries and SDKs for developing business-critical applications. The following section examines in detail how scalability, reliability, security and manageability are supported:

Scalability: Microsoft Transaction Server provides a set of DCOM interfaces and libraries that allow applications to easily scale as the number of users and user data increase. MTS provides automated thread management, which allows individual components to spawn multiple threads to handle increased demand without requiring developers to write tedious thread code. It also offers resource pooling and database connection multiplexing to more efficiently distribute user and data load across multiple replicated application components. This load balancing is limited to a single machine.

DCOM, however, does not provide a centralized naming service. This essential component of a scalable architecture lets users locate a particular application or component no matter where it resides in the enterprise. This allows the application to handle an increasing number of geographically dispersed users.

With NT 5.0, currently in beta, DCOM will gain the Active Directory Service Interface (ADSI), which allows components to seamlessly use a variety of existing naming services such as NetWare Directory Service (NDS), Lightweight Directory Access Protocol (LDAP) or even the Windows registry.

Reliability: Microsoft Message Queue Server, Microsoft Cluster Server and MTS all help develop and maintain reliable applications. MSMQ allows applications to use reliable message queues for communication, thus providing features such as guaranteed delivery of object requests and disconnected operation. This means that even if the application server machine or network were to become temporarily unavailable, the object requests and operations would resume after recovery.

MTS allows applications to use distributed transactions to reliably update data across disparate data stores, while MCS automatically restarts applications and provides automated failover between server machines.

While Microsoft Transaction Server is now in its second version, both MSMQ and MCS are new technologies that have yet to be "battle-tested."

Security: NT LAN Manager (NTLM) and Microsoft Transaction Server authenticate users and authorize checking via access control lists (ACLs). The MS Crypto API provides data encryption and integrity to prevent eavesdropping and tampering, while the Authenticode SDK uses digital signatures to provide non-repudiation. The challenge is to get all of these pieces working together in a single solution.

Manageability: Microsoft Management Console provides a unified graphical user interface (GUI) for managing Microsoft Transaction Server- and MSMQ-based components. Features include centralized configuration and administration, as well as remote deployment of components. Microsoft Transaction Server gathers various statistics about applications under its control, including transactional outcome, mean time between object requests and overall activity level. This information can then be viewed in the Microsoft Management Console. However, the Microsoft Management Console is a brand-new tool; as such, its usability beyond the departmental level is questionable at this time.

While DCOM provides a rich set of tools and technologies for implementing the above requirements, there are two significant drawbacks to the technology. First, it is essentially a Wintel-only solution; even though DCOM is available on Unix from Software AG, the technology is at least one revision behind the Wintel release and does not offer key pieces such as Microsoft Transaction Server, MSMQ and Microsoft Message Queue. Second, many of the tools are very new and are still maturing in the enterprise space.

The value-added services provided by CORBA are collectively known as CORBA Services. Currently defined services in CORBA 2.0 include Naming, Events, Life Cycle, Persistence, Relationship, Externalization, Transaction, Concurrency, Property, Licensing, Time, Trader and Security. Of these, Naming, Events, Transaction, Trader, Security, Life Cycle, Concurrency and Externalization services are currently available from the major CORBA vendors, including Iona, Borland/Visigenic (now known as Inprise), Expersoft and IBM. The section below details how these services, in conjunction with the CORBA runtime, assist with scalability, reliability, manageability and security.

Scalability: The Object Activation Daemon (OAD) and the Implementation Repository (IR), both part of the CORBA runtime, allow efficient use of resources by only instantiating objects when required. The centralized Naming service provides location independence for applications and their users, while the Trader service allows more sophisticated component searches by providing a "Yellow Pages"-like model for registration. Static load-balancing among multiple replicas of an application is available via the Naming service.

Reliability is provided through the Transaction service, which supports an Open Group Distributed Transaction Processing (DTP)-compliant model for distributed transactions. While some of the implementations, such as Visigenic’s ITS are new, others, such as Iona’s OTM and Visigenic’s TPBroker, are based on industry-proven transaction processing monitors from Transarc and Hitachi. Proprietary extensions to CORBA from vendors such as Visigenic and Expersoft provide failover support for both application servers and server platforms.

Security: CORBA defines two security levels: Level 1 and Level 2. Level 1 allows an application that is unaware of security to participate in a secure domain. It provides user authentication, authorization via ACLs, data encryption and integrity, and optional non-repudiation.

Level 2 requires applications to be security-aware, thus enforcing stronger versions of the above security policies.

Some CORBA vendors, such as Iona and Visigenic, have provided a Secure Socket Layer (SSL) implementation of IIOP, called Level 0, that allows user authentication and data encryption. Level 1 implementations are currently available from Iona and IBM, and are based on DCE security. There are no Level 2 implementations currently available.

Manageability: Both Visigenic and Iona have sophisticated tools for centrally configuring and administering CORBA applications. Iona also allows CORBA applications to be centrally managed from any SNMP-compliant system management console, such as OpenView and BMC Patrol. The Transaction service collects various usage statistics— such as transactional outcome, mean time between requests and maximum load per component—that can be used for performance tuning, and provides extensive logging and auditing features.

While CORBA’s main strength is allowing developers to use best-of-breed services from different vendors, this capability is also its biggest weakness. It is very difficult, if not impossible, for example, to get one vendor’s security implementation to work with another transaction service. Since no vendor has a complete solution for addressing the above requirements, integration issues are introduced when CORBA is used to build business-critical applications.

But what services do DCOM and CORBA provide when applications need to be deployed on the Web, within the intranet, across an extranet or over the Internet?

Web-based means that the front end or presentation layer of the application is the Web browser. It does not necessarily mean that the application is deployed over the Internet. Many companies are starting to develop even LAN or intranet applications with a browser interface because it provides a simplified universal front end and ease of deployment. Typically, the front is developed using either regular HTML, or if it needs to be more sophisticated, using either JavaScript/Java or ActiveX. In either case, it is downloaded from the Web server and subsequently communicates with the application server using HTTP, IIOP or DCOM.

Over and above the requirements for all business-critical applications, Web-based applications should be able to run in both Internet Explorer and Netscape Navigator—on all major platforms. This is an important feature, because one of the main reasons for choosing a Web front end is its universal availability. It should also be quickly and easily downloadable from the Web server, without any complicated client-side installs. Finally, the application needs to be well integrated with other browser components such as forms and frames, and, if HTTP-based, with Web server components such as call-out facilities.

When developing Web applications, DCOM front ends in the form of ActiveX controls can run within Internet Explorer and, via a plug-in, within Netscape Navigator. Although the ActiveX controls can work on both Wintel and Unix platforms, they are platform-specific binaries, which means that different binaries are needed for each platform.

ActiveX controls can be packaged into compressed cabinet files for quicker downloads or installed seamlessly into the browser without user intervention. In addition, DCOM is available natively on all Wintel platforms, so that regardless of which browser is used, the application does not have to download the runtime services.

Furthermore, Microsoft’s Active Server Page technology allows the seamless integration of both HTML and ActiveX clients with DCOM application servers. It also allows DCOM services such as Microsoft Transaction Server and MSMQ to be used with Web-based applications.

Several vendors have developed a 100% pure Java implementation of the CORBA runtime and services. This means that Java-based front ends to CORBA applications can work on all major browsers and platforms.

Because Netscape Navigator is bundled with the CORBA runtime, front ends deployed using Netscape can be downloaded faster since they do not have to download the runtime. In addition, CORBA services are available as compressed Java archive or Microsoft cabinet files for quicker downloads from the Web server.

The Netscape Enterprise Server provides the Web Application Interface, which allows HTTP-based clients to communicate with CORBA application servers.

Business-critical applications that need to work across the public Internet or the semi-public extranet have several unique characteristics: They are typically deployed across great distances and often through several firewalls; and they can have either a Web browser interface or a typical client/server GUI. Yet despite the interface used, both Internet and extranet applications share the key requirements of "bullet-proof" security and firewall support.

Business-critical transactions executed over the Internet require additional security measures to ensure accuracy, confidentiality and credibility. These measures include: support for a public-key security infrastructure, such as SSL, which is able to deal with the unpredictable and anonymous nature of Internet users better than a traditional private-key system such as Kerberos; two-step verification of the user’s identity, based on both a password and a physical token such as a smart card (often called two-factor authentication); digital notarization of important transactions via a third party to ensure accuracy and timeliness; and integration of the Internet-specific security with the existing enterprise security infrastructure to ensure seamless, end-to-end security.

Most major corporations have a fairly elaborate firewall system in place to prevent unauthorized access to their intranet. Yet for those applications that need access to services inside the intranet this poses a challenge—many administrators are loathe to open special "holes" in their firewalls for business applications. A successful Internet-based application should be able to navigate its own firm’s firewall to call out to external business objects, as well as other firms’ firewalls in order to invoke their internal business objects.

DCOM currently provides two-factor authentication and Remote Data Service (RDS) support for Internet/extranet applications. Two-factor authentication is supported through public certificate and smart cards. Currently, there is limited support for SSL and its integration with NTLM security; however, this will be expanded to include SSL-to-Kerberos integration in NT 5.0.

Remote Data Service allows data access requests across the Internet to be tunneled through HTTP to allow firewall traversal. Full DCOM support for firewalls, in the form of HTTP tunneling, is planned for later this year.

Several CORBA vendors support both SSL and two-factor authentication in their implementation, although these features are still immature. Some, such as Iona and IBM, allow integration of their security solutions with existing DCE, Kerberos and RACF security.

Both Iona and Visigenic allow HTTP tunneling of CORBA object invocations to traverse any firewall, albeit with an associated performance penalty. Iona also provides an IIOP-aware firewall extension called Wonderwall, which can monitor and control both incoming and outgoing CORBA traffic. While these features are currently proprietary, they are being standardized for Version 3.0 of the CORBA specification due later this year.

Intranet or client/server applications are optimized for use within an organization, have higher network bandwidth and little or no firewall restrictions. These types of applications can therefore be built with more sophisticated front ends, both in terms of user interface and functionality. User-interface requirements include rich graphics support and the ability to integrate the application with popular desktop tools such as Microsoft Office and Visual Basic. Sophisticated functional requirements might include local object caching and persistence, as well as a publish/subscribe capability.

DCOM applications can be built with sophisticated user interface and functional features. For example, every major development environment on Wintel supports the rapid development of graphical DCOM applications. There are also thousands of ActiveX controls available, either for free or for a nominal charge, that provide additional charting, graphing or industry-specific features. And because every popular desktop tool natively supports ActiveX, it is easy to integrate DCOM applications with these tools.

Furthermore, OLE DB and its associated Active Data Objects allow DCOM applications to support persistence, while MSMQ provides publish/subscribe capabilities.

On the other hand, CORBA applications can be integrated with desktop tools using a COM/CORBA bridge available from several CORBA vendors. CORBA services such as Event and Persistence can also be used to add publish/subscribe and persistence features to an intranet application.

After describing the different ways of deploying business-critical applications and the associated support available from DCOM and CORBA, what are the most common deployment scenarios in the real world? Not surprisingly, the answer is a combination of the above. Typical real-world applications often have a Web interface to either an intranet or an Internet/extranet application. Equally pervasive are client/server applications with a GUI front end. Less in demand are Internet/extranet applications with a non-Web front end. Yet neither technology provides a complete solution. However, if the subset each provides is inadequate for the required application, it is possible to integrate the two and thus get the best of both worlds.

There are two ways in which an application developer might want to integrate DCOM and CORBA. The first type of integration is useful for intranet or client/server applications. It involves building the application front end using DCOM/ActiveX and then integrating it with the back-end CORBA application servers using a COM/ CORBA bridge. By using ActiveX for the front end, the application has access to the rich intranet capabilities of DCOM, such as rich GUI controls and integration with popular desktop tools. By using CORBA servers, the application can be deployed across heterogeneous platforms, allowing it to scale more easily using CORBA’s centralized Naming service.

The second type of integration is useful for Web-based, Internet/extranet applications. A CORBA-based front end is a 100% pure Java applet that communicates via HTTP-tunneled IIOP with back-end DCOM application servers typically deployed within Microsoft Transaction Server. The routing mechanism that allows the CORBA applet to communicate with the MTS servers could either be a bidirectional COM/CORBA bridge or a custom solution. This integration architecture allows the 100% pure Java applet to run in any Web browser on any platform, a major requirement for Web applications. In addition, the Java applet can use SSL security and HTTP tunneling to access application servers through firewalls, thus allowing it to address major Internet requirements. At the same time, the application utilizes DCOM and Microsoft Transaction Server for its servers, thereby leveraging the manageability, transaction and thread support of Microsoft Transaction Server.

DCOM and CORBA both provide a solid infrastructure on which to build business-critical applications. While neither one offers a complete solution today for building every kind of business-critical application, there are scenarios in which each excels over the other. Which one you choose to use in your organization’s environment or whether or not you decide to integrate them will ultimately be dictated by how you plan to deploy business-critical applications, and by how important each of their associated requirements are to your company’s system.

Introduction	First Generation	Second Generation	Third Generation
Bob Jensen's Home Page	Glossary	ACCT 5342	Table of Contents

When InPower was deciding last year on a Web development package for building new versions of its human resources and payroll applications, it had considered products from Haht Software, Bluestone Software, NetDynamics, and Kiva Software.

InPower product developer Darien Belanger recalled being most impressed by the integrated development environment (IDE) and Web application server features in Bluestone’s Sapphire Web. But he wound up going with Kiva, a start-up later purchased by Netscape, even though Kiva’s product (now called Netscape Application Server) focused on the strength of the server itself and offered nothing akin to Bluestone’s IDE.

"It looked like with Bluestone we were going to have to go off the edge of what the GUI environment would allow us to do, and we’d have to drop down into hand-coding anyway," Belanger said. "So we figured, if we’re going to get down and dirty, let’s get down and dirty."

His decision illustrates the division between development environments and application-serving environments for the Web. Developers custom-built the first Web applications on a foundation of Perl scripts or C programs that executed on the Web server, which treated browser requests as command-line input, processed database commands, and formatted results in HTML.

Vendors such as Bluestone, NetDynamics, and Haht then began offering packaged solutions, each providing both visual tools and a server that addressed many common requirements for Web applications. At first, these application servers seemed to be little more than mere runtime outgrowths of the tools, but as the industry shifted its focus to more scalable and reliable Web applications, they acquired a more distinct identity.

Microsoft is a special case, essentially offering an assortment of technologies bundled into Windows NT. Most other vendors offer portability between NT and Unix and varying degrees of support for the enterprise Java standards from Sun. However, there are still few standards that would let developers make their software portable between application servers from different vendors.

"Right now, these things are seriously proprietary, and there’s no way you can even think about transporting an application from one to another," InPower’s Belanger said. That troubles him, because "these products may have a tendency to come and go, and I’ve got to be able to change horses."

Belanger said he understands why vendors are reluctant to let their products become commodities, but hopes nonetheless that their professed support for Enterprise JavaBeans—or EJBs, the Java world’s answer to portable server components—will prove sincere.

"Today, they have to pay lip service. Within the next year, I think, they will have to start really being somewhat credible," he said.

Tim Jones, a Web developer for NationsBanc Montgomery Securities, has similar concerns about his firm’s portfolio management system, which uses the NetDynamics server. But Jones believes he has protected himself by designing a Java front end that treats the NetDynamics server as a replaceable data source. He uses the NetDynamics IDE to map relational database tables into data objects, but otherwise tries not to rely on it too heavily.

Both Belanger and Jones are using Symantec’s Visual Caf? for Java development, and each said they were taking a closer look at WebLogic’s Tengah as an application server. WebLogic, which does not offer its own tools, has created a series of JavaBeans that developers can load into popular Java IDEs and use to program Tengah.

"That’s the best approach I’ve seen yet," Jones said. "It makes sense, because there’s no way the app server vendors are going to be able to give you the same feature set that a dedicated IDE vendor will."

Another product taking a relatively open approach is Oracle Application Server, which the company is designing not only to run code generated by Oracle’s Developer/2000 and JDeveloper tools but also to execute Perl scripts and CORBA components. But according to Zona Research analyst Martin Marshall, Oracle is still struggling to deliver all the pieces of this architecture and has so far failed to drum up any excitement in the market.

Products that provide a tight link between one IDE and one application server can make creating Web applications easier for customers that want to focus on business logic rather than base-level programming, Marshall said. Getting locked into a particular IDE may not be too high a price to pay, particularly if the tool makes it simpler to create the kind of transactional applications required for Web commerce, he said.

"Transactional capability is such a gnarly thing to start with that you need all the programming ease you can get," Marshall said.

Enterprise JavaBeans offers a transactional application server equivalent of the "write once, run anywhere" promise of Java, but how well the vendors will implement the specification—and how much the market will demand such portability—still remains to be seen, Marshall said.

Frederic Bonnard, product manager of Netscape’s application server group, said support for the standard will arrive in an early 1999 release of Netscape Application Server. It’s a natural extension of the open application server approach that started with Kiva, he said.

"What really matters when you have EJB is the quality of your EJB server," said Bonnard.

NetDynamics marketing vice president Vic Morris said his firm will support EJBs by the end of this year, and that many customers already use third-party Java tools in conjunction with the NetDynamics server. "NetDynamics Studio is really designed to generate the data access piece of the application," he said.

But Roland Archer, president and CEO of Haht Software, doesn’t necessarily see Java standards providing all the answers. "EJB is one level down from the issues we address. In addition to the database access, we do things like manage all the links on your site."

Archer is open to supporting other application servers if that’s what the market demands, and Haht did create a version of its system that runs in conjunction with the Oracle Application Server.

"If the application server eventually becomes standardized, we will support that," Archer said. "But today that’s not one of the standards our customers care about. They care about Unix and NT, COM and CORBA, Java and Visual Basic."