A Corba, DCOM primer
- By Imran Sayeed
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
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
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,
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
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
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
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
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.