In-Depth

A Corba, DCOM primer

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.

Support for business-critical applications

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.

Support for Web 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.

Support for Internet/extranets

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.

Support for intranet apps

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.

Integrating DCOM and Corba to support real-world applications

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.

Most   Popular