📄 ch27.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<META NAME="Author" Content="Steph Mineart">
<TITLE>Ch 27 -- Distributed COM</TITLE>
</HEAD>
<BODY
BACKGROUND="bg1.gif" tppabs="http://pbs.mcp.com/ebooks/0672310228/buttonart/bg1.gif" BGCOLOR="#FFFFFF">
<P ALIGN="CENTER"><IMG SRC="sams.gif" tppabs="http://pbs.mcp.com/ebooks/0672310228/buttonart/sams.gif" WIDTH="75" HEIGHT="24" ALIGN="BOTTOM"
BORDER="0"><BR>
<BR>
<A HREF="index-3.htm" tppabs="http://pbs.mcp.com/ebooks/0672310228/index.htm"><IMG SRC="toc.gif" tppabs="http://pbs.mcp.com/ebooks/0672310228/buttonart/toc.gif" WIDTH="40" HEIGHT="40" ALIGN="BOTTOM"
ALT="TOC" BORDER="0" NAME="toc4"></A><A HREF="ch26.htm" tppabs="http://pbs.mcp.com/ebooks/0672310228/ch26.htm"><IMG SRC="back-1.gif" tppabs="http://pbs.mcp.com/ebooks/0672310228/buttonart/back.gif"
WIDTH="40" HEIGHT="40" ALIGN="BOTTOM" ALT="BACK" BORDER="0" NAME="toc1"></A><A HREF="ch28.htm" tppabs="http://pbs.mcp.com/ebooks/0672310228/ch28.htm"><IMG
SRC="forward.gif" tppabs="http://pbs.mcp.com/ebooks/0672310228/buttonart/forward.gif" WIDTH="40" HEIGHT="40" ALIGN="BOTTOM"
ALT="FORWARD" BORDER="0"
NAME="toc2"></A>
<H2 ALIGN="CENTER"><FONT COLOR="#000077">Charlie Calvert's C++ Builder Unleashed</FONT></H2>
<P>
<H2 ALIGN="CENTER"><A NAME="Heading1"></A><FONT COLOR="#000077">- 27 -</FONT></H2>
<H2 ALIGN="CENTER"><A
NAME="Heading2"></A><FONT COLOR="#000077">Distributed COM</FONT></H2>
<P>
<H3><A NAME="Heading3"></A><FONT COLOR="#000077">Overview</FONT></H3>
<P>The Distributed Component Object Model (DCOM) allows you to share objects easily
over a network. In this
chapter, you will see how to use BCB to implement DCOM. In
particular, you will see how to create two applications that can control one another
across a network and how to create distributed database applications. In the process
of describing this
technology, I will also show you how to create local OLE Automation
objects.</P>
<P>BCB and Windows NT 4.0 provide full support for DCOM. You can also easily add
DCOM client support to Windows 95. If you want, you can also add DCOM server support
to
Windows 95, though this option has some drawbacks and limitations.</P>
<P>The following subjects are covered in this chapter:
<UL>
<LI>An overview of DCOM technology
<P>
<LI>Some caveats and general comments about DCOM, including a brief overview
of competing
technologies such as DSOM and CORBA
<P>
<LI>Using <TT>TAutoObject</TT> to implement a DCOM server
<P>
<LI>Creating a DCOM client
<P>
<LI>Reviewing some key points about the Registry
<P>
<LI>Working with remote datasets
<P>
<LI>Using DCOM to access a database server on a different system without loading
any database tools on your current system
</UL>
<P>At the time of this writing, DCOM is not built into Windows 95, although it is
built into Windows NT 4.0. To add DCOM
support to Windows 95, you can download Windows
95 DCOM from the Microsoft Web server. You should start looking for it in the OleDev
section: <A HREF="javascript:if(confirm('http://www.microsoft.com/oledev \n\nThis file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address. \n\nDo you want to open it from the server?'))window.location='http://www.microsoft.com/oledev'" tppabs="http://www.microsoft.com/oledev"><TT>www.microsoft.com/oledev</TT></A>.
Alternatively, you can
purchase a product called OLE Enterprise (OLEnterprise) from
Borland.
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">What Is DCOM?</FONT></H3>
<P>Before I begin describing the fairly simple technical steps involved in implementing
DCOM, perhaps I
should talk about this technology from a high level so that all the
key ideas will be clear to everyone. If you already understand DCOM and just want
to see how to implement it in BCB, you can skip this section.</P>
<P>Distributed COM is important
because it allows applications to talk to one another
across a network. In particular, it allows you to share objects that reside on two
separate machines. You therefore can create an object in one application or DLL and
then call the methods of that
object from an application or DLL that resides on a
different computer.</P>
<P>DCOM is built on top of COM, which is the technology that underlies both OLE and
ActiveX. The relationship between COM and OLE is a bit confusing, and the boundaries
separating the two technologies seem to shift at times, depending on the vagaries
of the Microsoft marketing machine. In general, I can safely say that OLE is a subset
of COM. That is, everything that is part of OLE is also part of COM, but not
everything
that is part of COM is a part of OLE. Many people, however, use the words "COM"
and "OLE" virtually interchangeably, and indeed, the two technologies are
very closely bound together.</P>
<P>COM is simply a specification
for defining an object hierarchy. In particular,
it lays out a set of rules for defining objects that can be used across applications
and languages. DCOM extends this specification to allow objects on separate machines
to talk to one another.</P>
<P>One of the most important aspects of this technology is that it allows you to
distribute the load of a task across several machines. For example, if you have a
complex database query to run, you can use DCOM to ask an object on a separate machine
to run it. That way, your current processor will not have to expend any clock cycles
on the task, nor will any large database- related tools be loaded into memory on
your own machine. You are therefore free to continue playing DOOM or Quake while
your
server loses clock cycles and precious RAM to your background task.</P>
<P>You need to understand that the COM specification, as the name itself implies,
is really only a set of rules for defining an object hierarchy. These rules include
defining the
names and methods of many of the key objects in the hierarchy, as well
as the specific techniques for structuring the objects themselves. (When you think
of the definition this way, you might find some value in regarding OLE as an implementation
of
certain parts of the COM specification.)</P>
<P>The COM specification can be compared to the specification for other object hierarchies
such as VCL, OWL, or MFC. For example, all COM objects descend from a base class
called <TT>IUnknown</TT>, just as
all VCL objects descend from a base class called
<TT>TObject</TT>. COM supports polymorphism and encapsulation, and it uses a series
of unique interfaces to achieve the same ends as traditional inheritance in standard
object-oriented languages. Unlike
OWL or VCL, however, COM is not tied to any particular
language, nor is it bound by application boundaries.</P>
<P>In short, COM is an alternative to the VCL, OWL, or MFC that attempts to go these
object hierarchies one better by allowing you to use
COM objects across language,
application, and now even machine boundaries. As a result, you can write a COM object
in Object Pascal, extend it in BCB, and then use it in a third language such as Visual
Basic. You can call methods of the object from
inside a single application, from
one application that is calling into a DLL, or from one application that is calling
an object in a separate application. What DCOM brings to the picture is the capability
to call objects that reside in applications
located on separate machines. It allows
you to "distribute" the objects across the network. In particular, this
capability allows you to divide up the load of running a major task across several
machines.</P>
<P>If you already understand
COM, then you are ready to use DCOM without any further
work. DCOM works exactly the same way that COM works. You can, in fact, at least
theoretically convert existing COM objects into DCOM objects with no change to your
code. This system works great
between two Windows NT machines, but Windows 95 requires
that you switch from Share Level to User Level access, which might crimp your style
in some cases. In particular, User Level sharing requires that an NT machine or some
other source of user
access lists be available on your network.
<DL>
<DT></DT>
</DL>
<BLOCKQUOTE>
<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>You can switch from Share Level
access to User Level access via the Network applet found in the Control
Panel. To
then help configure your server, you can use the <TT>DComCfg.exe</TT> application
freely available from Microsoft's Web server.
<HR>
</BLOCKQUOTE>
<P>If you don't want to switch to User Level access, you can choose an alternative
that
will allow you to run DCOM as a client service on Windows 95 machines. In that
case, you need to add only a single new parameter to your calls into an OLE function
named <TT>CoGetClassObject</TT>. I'll explain more in the technical section of this
chapter.
<DL>
<DT></DT>
</DL>
<BLOCKQUOTE>
<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Consider these three points: n In
most cases, User Level access controls require that you have an NT machine in your
network. n NT machines
don't require any special configuration to be able to act
as a DCOM server. n You cannot remotely launch an OLE server that resides on a Windows
95 machine. The process must be in memory before you can call it. This is not true
of NT machines,
which can automatically launch a server if it is not already in memory.
The upshot of this point is that you can't set up a DCOM server unless you have an
NT machine on your network, and even under the best circumstances, a Windows 95 box
is
crippled as a server. Given these facts, I prefer to have the NT machine act as
my DCOM server and to let the Windows 95 machines act only as clients. When connecting
the two via DCOM for the first time, sign on to both machines with the same name
and password. The simplest way to do this is to create a new user on the server with
the same name and password you use on your Win95 box. Then sign on to the NT server
with this name and password and sign on to your Windows 95 machine with the same
name and password. Once you get things working this way, then you can try connecting
with more stringent security.
<HR>
</BLOCKQUOTE>
<P>The key point to grasp here is that DCOM is really nothing more than a new capability
added to the
already-existing COM technology. If you have working COM objects, upgrading
them to work with DCOM is easy.</P>
<P>At the time of this writing (February '97), DCOM has been working on Windows NT
4.0 for over six months, but Microsoft has only just
released DCOM for Windows 95.
Microsoft has stated that, in the future, COM and DCOM will be ported to other platforms
such as UNIX and the Mac.
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Why Is COM Controversial?</FONT></H3>
<P>Having, in a
sense, made the case for COM and DCOM in the preceding section, I
should perhaps step back for a moment and describe some competing systems. In this
technical chapter, I'm not interested in advocating any particular system. However,
describing the
current state of this technology is probably worthwhile so that you
can put this chapter in perspective.</P>
<P>COM is a Microsoft technology that is competing with similar technologies such
as CORBA and DSOM, which are created by other corporations
or groups of corporations.
Adherents of these alternative technologies can rally numerous arguments regarding
who implemented what first and who has designed the most sophisticated technology.
Furthermore, many people have invested themselves heavily
in technologies such as
OWL or MFC that can be seen as "competing," in some sense, with COM. OWL,
MFC, and the VCL don't have the same capabilities as COM, DSOM, OPENDOC, or CORBA,
but you still get a feeling that the technologies are to
some degree competing for
the mind share of contemporary programmers. There is no specific reason that you
can't use COM and VCL in the same program, and indeed that is the approach I take
in this chapter.</P>
<P>My point here is not to advocate any
particular solution, but only to make it
clear that this controversial topic tends to excite strong opinions. If you're considering
using COM in your projects, you might also want to look at CORBA and SOM. Conversely,
if you hear criticisms of COM
from other members working in the industry, you might
check to see whether they are so heavily invested in some alternative technology
that they are perhaps somewhat unfairly predisposed to be critical of COM and DCOM.
<H3><A NAME="Heading8"></A><FONT
COLOR="#000077">DCOM, IDispatch, Marshaling, and
OLE Automation</FONT></H3>
<P>BCB programmers can use the <TT>IDispatch</TT> COM interface to gain easy access
to the capabilities of DCOM. This interface is encapsulated inside the BCB
<TT>TAutoObject</TT>
class. If you understand <TT>TAutoObject</TT> and the theory behind <TT>IDispatch</TT>
and <TT>IMarshal</TT>, you can probably skip this section and move on to the next.</P>
<P>OLE Automation is a technique that allows you to
control one application from
inside a second application. In particular, it allows you to control an object placed
inside one application from the code of a second application.</P>
<P>The key to OLE Automation is a COM object called
<TT>IDispatch</TT>. All OLE technologies
are based on COM, and in this particular case the functionality behind OLE Automation
is implemented by <TT>IDispatch</TT>. In short, OLE Automation is really just a marketing
term for publicizing the
technology found in <TT>IDispatch</TT>. Or, more charitably,
OLE Automation is an implementation of the <TT>IDispatch</TT> specification.</P>
<P><TT>IDispatch</TT> is not difficult to understand, but it can be a bit awkward
at times to implement. To
help simplify the use of <TT>IDispatch</TT>, the VCL has
a class called <TT>TAutoObject</TT> that encapsulates all the functionality of <TT>IDispatch</TT>
inside an easy-to-use and highly leveraged technology.</P>
<P>In this chapter, I focus much of
the technical content on an analysis of <TT>TAutoObject</TT>.
However, you can automate any COM object, not just <TT>IDispatch</TT>. I have chosen
to concentrate on this one technology at the exclusion of others because it provides
a simple workaround
to the difficult problem of trying to marshal code and data back
and forth between two applications.</P>
<P>Marshaling is a COM-specific term for the technique used to transfer data or function
calls back and forth between two applications that reside
in separate processes.
For example, if you have to pass a parameter to a function between two applications,
you have to be sure that it is treated properly by both applications. For example,
if you declare the parameter as an <TT>Integer</TT> in
Pascal, that means you're
passing a four-byte ordinal value. How do you express that same concept in C? How
do you do it Visual Basic? The answers to these questions are expressed in COM by
a complex interface called <TT>IMarshal</TT> that is beyond
the scope of this chapter.
Indeed, <TT>IMarshal</TT> is notorious for being difficult to implement.</P>
<P>Here is how the Microsoft documentation defines <TT>IMarshal</TT>: "`Marshaling'
is the process of packaging data into packets for
transmission to a different process
or machine. `Unmarshaling' is the process of recovering that data at the receiving
end. In any given call, method arguments are marshaled and unmarshaled in one direction,
while return values are marshaled and
unmarshaled in the other." This is all
good and well. Unfortunately, as I stated earlier, the <TT>IMarshal</TT> interface
is very hard to implement.</P>
<P>If you're using a standard COM object, you don't have to implement <TT>IMarshal</TT>
because these interfaces will be marshaled for you automatically by the system. In
other words, if you're implementing an instance of <TT>IDispatch</TT>, <TT>IUnknown</TT>,
<TT>IClassFactory</TT>, <TT>IOleContainer</TT>, or any other predefined COM
class,
you don't have to worry about marshaling. Microsoft will take care of this job for
you. However, if you're creating a custom object of your own, you need to implement
<TT>IMarshal</TT> or come up with some alternative scheme.</P>
<P>Because of
the complexity of <TT>IMarshal</TT>, C programmers also generally choose
not to attempt an implementation of <TT>IMarshal</TT>. Instead, they rely on an intermediate
language called Interface Definition Language (IDL) that can be compiled into source
code by a Microsoft-created program called <TT>MIDL.EXE</TT>. The IDL is a special
language meant to allow people to define interfaces in a neutral language that can
be compiled into source that can be used by multiple languages such as Pascal, C,
and
Visual Basic.</P>
<P>In other words, you can theoretically write your COM object in C or Pascal, use
IDL to define its interface, and then use MIDL to turn that interface into a set
of files that can be used by any language. In other words, MIDL
automatically takes
care of the <TT>IMarshal</TT> business for you as long as you first describe your
interface in IDL.</P>
<P>This approach is quite reasonable, but I will not treat it in this current book,
in part because BCB does not ship with
MIDL. It is, however, available from the Microsoft
SDKs and may be freely available via their Web site. You should also note that Delphi
3.0 includes tools that automate this process without your having to learn IDL or
work with MIDL.</P>
<P>For now,
however, I will back away from both <TT>IMarshal</TT> (because it is
so complex) and MIDL (because it doesn't ship with BCB). This situation would appear
to leave no good way to handle DCOM, were it not for the power of <TT>IDispatch</TT>
and
<TT>TAutoObject</TT>. <TT>IDispatch</TT> is a COM interface designed to make
controlling one application from inside a second application easy. In implementing
this code, Microsoft provided an alternative means for solving the whole problem
of
marshaling data between applications. In <TT>TAutoObject</TT>, the VCL provides
a very simple means of using <TT>IDispatch</TT>.
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">Thinking About IDispatch</FONT></H3>
<P>Here is how Microsoft defines
<TT>IDispatch</TT>: "<TT>IDispatch</TT> is
a COM interface that is designed in such a way that it can call virtually any other
COM interface." In other words, if you put a COM object in an application, you
can call its methods from a second
application by using <TT>IDispatch</TT>. This
way, OLE Automation allows you to control one application from inside a second application.
(In particular, <TT>IDispatch</TT> was created to help make COM programming easier
from inside the limited
confines of a Visual Basic application.)</P>
<P>To understand why <TT>IDispatch</TT> works, you need to remember that marshaling
is taken care of for you automatically as long as you're using an existing COM interface.
In other words, you don't have
to implement marshaling for <TT>IDispatch</TT> because
it is a standard COM object, not a custom object designed by yourself or someone
on your team. <TT>IDispatch</TT> exists to allow you to call the methods of any legal
COM object. In other words,
it is designed to solve the whole problem of marshaling
data. As such, it is the perfect solution for BCB programmers who want to use DCOM
without engaging in too much manual labor.</P>
<P>Before closing this section, I should emphasize that you don't
have to use <TT>IDispatch</TT>.
If you prefer, you can use other predefined COM objects, or you can implement <TT>IMarshal</TT>,
or you can attempt to use MIDL. BCB has none of the limitations found in languages
like Visual Basic, so you don't need to
be confined to using <TT>IDispatch</TT> unless
you find its relative simplicity appealing.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">Using TAutoObject to Implement
a DCOM Server</FONT></H3>
<P>Now you're ready to move away from theoretical
issues and to concentrate instead
on technical matters. Ironically, the theory behind this technology is much harder
to understand than the technology itself. In short, in this section and the next,
I outline a simple technique for using DCOM that can
be used by any intermediate-level
BCB programmer.</P>
<P>You learned in the preceding sections that <TT>TAutoObject</TT> is BCB's wrapper
around <TT>IDispatch</TT>. <TT>IDispatch</TT> is the COM object that makes OLE Automation
possible. In this
section, I show you how to implement OLE Automation that works
not only between two applications, but also between two applications that reside
on separate machines.</P>
<P>If you go to the File menu in BCB and choose New, you can pop up the Object
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -