Building Scalable Applications with Windows NT and DCOM
With the release of Windows NT 4.0, Microsoft has
provided a new set of technologies and services for
developers to build multi-tier, intranet, and Internet
applications. Windows NT 4.0 delivers the core of these
capabilities via the Distributed Common Object Model
(DCOM). As DCOM is an extension of COM, a brief
discussion of COM is in order.
Applications that run on Windows 95 and Windows NT
have protected memory spaces. This ensures that one
application cannot access the memory occupied by another
application. While, in general, this is an appropriate
model, there are reasons to provide a level of communication
between applications. This communication level is provided
in Windows 95 and Windows NT via COM. COM provides
the protocol allowing one application to interact with another
application on the same machine. The figure below depicts
the COM architecture.
COM architecture
Now that COM has provided the ability to communicate
with another application running on the same machine,
the next step is to provide the ability to communicate
with an application running on a different machine within
the network. This is essentially what DCOM provides. The
figure below graphically represents the DCOM architecture:
DCOM architecture
DCOM has many benefits to an organization beyond simply
providing the ability to create networked applications. The
section below will point out some of the benefits of DCOM,
and continue with a discussion of some of the areas where
DCOM can be enhanced with other tools.
- Language Neutrality
If an application is written with Delphi, it can be called and
used from a Visual Basic application. This insulates the
developers from being locked into one tool, allowing them to
select the best tool for the job.
- Connection Management
DCOM uses a reference counter to determine how many clients
are connected to a particular server. Thus, when a new
client is added to the list, the counter is incremented, and
conversely, when a client disconnects from the application
server, the reference is decremented. When the reference
counter goes to zero, the application will close. When an
application server is not already running, DCOM will launch
the application and set the reference counter appropriately.
If a client is to disconnect without decrementing the reference
count, there must be a way for the server to automatically
decrement the reference count. This is accomplished by the
server "pinging" the client. If the server fails to "ping" the
client three successive times, the connection is considered
closed and the reference count will be adjusted.
- Multiple Interfaces
DCOM is primarily implemented through the use of
interfaces. Interfaces are the exposed methods and properties
of a particular object. There can be many interfaces to
the same object. This provides the ability to customize an
object without necessarily redeveloping it. This becomes
especially important when the object requires additional
functionality that only a subset of the clients require. In
this situation, the developer can use the same implementation
with different interfaces. One interface can provide the base
set of functionality; the other can provide the enhanced
functionality. This can be accomplished even though the actual
implementation may be exactly the same.
- Integration with other network protocols
Because DCOM is based on simple TCP/IP and RPC
protocols, application servers can be called from anywhere
on the Internet using basic TCP/IP or other TCP-based
protocols (such as PPTP (Point to Point Tunneling Protocol))
for dial-in users, or HTTP for Internet users. By supporting
the lowest level of network interoperability, DCOM's
network communication is transparent to the applications.
This provides many different network options to the
developer in deciding the best connectivity for the application.
Now let's take a look at some of areas of DCOM that could
benefit from the addition of other tools.
- Location Independence and Load Balancing
The concept here is that the client application doesn't care
where the application server is located, only that it can
connect to it. Because DCOM is geared towards
networked applications, the only criteria is that the
application actually exist on the network. The way a client
machine "finds" an application server is by locating the
appropriate registry entries in the client's registry file.
Simply changing the registry information from Server A
to Server B will cause the client to load the application on
Server B. When an application has many users, they can
be divided into groups of users. For example, Group 1 could
be using an inventory application server that is running on
Server A while Group 2 can use the same application but
running on Server B. By doing this, the load can be balanced
across machines.
This type of load balancing is called static because the users
always connect to the same server machine, no matter
how many users are connected. This is fine for simple
situations, but most of the time the load needs to be balanced
dynamically. Considering the above example, let's add a
more realistic complexity. At certain times of the day,
Group 1 requires much more use of the application server.
At that same time, the needs of Group 2 are low. If static
load balancing is used, Server 2 will be quite under-utilized,
while Server 1 is over-utilized. If there were a way to
dynamically shift some users from Group 1 to Server 2 instead
of Server 1, based on the existing network traffic for each
server, the overall utilization would be balanced across the
two servers, resulting in better performance.
DCOM alone does not address dynamic load balancing. It
does, however, recommend that developers create a reference
object to handle this application requirement.
Borland has developed such a reference object-the Business
Object Broker
technology in Delphi 3 Client/Server and
Borland MIDAS. Click here for the white paper
titled "An overview of Borland MIDAS."
- Fail-Over and Fault Tolerance
DCOM provides basic support for fail-over with the "pinging"
facilities. Essentially, this means that if an application server
fails for any reason, DCOM will attempt to restart the
application. While this is an important feature, it doesn't
resolve issues where the application server can't be restarted
due to a variety of reasons, including network failure, hardware
failure, application failures, etc.
In Microsoft's white paper on DCOM, "DCOM Technical
Overview," the recommended solution to a true fault-tolerant
application system is described as follows:
"DCOM makes it easy to implement fault tolerance. One
technique is the referral component introduced in the
previous section. When clients detect the failure of a
component, they reconnect to the same referral component
that established the first connection. The referral component
has information about which servers are no longer available
and automatically provides the client with a new instance of
the component running on another machine."
While DCOM provides the infrastructure to build such a
system, it has not been implemented in DCOM proper. With
the Business Object Broker
and OLEnterprise, Delphi 3
Client/Server and Borland MIDAS users have such a referral
component. This application service works as described above.
- Database Integration
To understand database integration issues, we can study the
basics of DCOM. DCOM is based on remote procedure calls
(RPCs). There is a limitation in RPCs, such that a limited set
of supported datatypes exists. These datatypes are the simple
types (e.g., integers, strings, arrays, binary, etc.). What
is not supported is the transfer of complex datatypes, such as
objects. While data from a database typically falls into
the simple data type category, the data sets themselves do not.
Some vendors have approached this issue by returning arrays
of the simple datatypes, one array for each column. While
this technique transports the data, the data-awareness is
lost in the translation. There needs to be a mechanism that
distributes a set of database data (datasets), allows the user to
browse and modify that dataset, and allows the user to post
those modifications back to the middle-tier business object and
ultimately to the database.
In addition to returning the data from the database, there is
also an issue with the business rules. A basic function of a
database server is data integrity and validation. If an
application server only sends the data from the database to
the client, then one of two things will occur. If the
developer does no additional coding in the client to prevent
obvious data integrity violations, the end user will only be
informed of that rule violation after they have posted the
data back to the application server or the RDBMS. This
results in an unfriendly user interface and unnecessary network
traffic. The alternative is to reprogram the rules into the
client portion of the application. This, however, has other side
effects. If the rule changes, the client portion needs to be
updated. While this appears as a simple step, when there are
many different client applications that need to be rebuilt and
many client machines to reinstall the software, this is actually
a complex and time-consuming process.
Both of these database integration issues are solved with
the use of Borland's Remote DataBroker and ConstraintBroker
technologies within Delphi 3 Client/Server and Borland MIDAS.
Summary
Microsoft's implementation of DCOM has made a great step
towards the effort of multi-tier computing. However, there
are additional challenges left unsolved by Windows
NT 4.0 and DCOM. These areas include load balancing,
fail-over, fault tolerance and database integration.
Borland's Delphi 3 Client/Server and Borland MIDAS products
address these areas with technologies such as the
Business Object Broker
, Remote DataBroker and
ConstraintBroker. Click here for the white
paper titled "An overview of Borland MIDAS."
Return to MIDAS Home Page
