ch01.htm

本书详述了VC++环境下网络化多媒体对象技术编程

size.
<H3><A NAME="Heading5"></A>Automation Servers</H3>
<P>Automation Servers are components that can be programmatically driven by other
applications. An Automation Server contains at least one, and possibly more, <TT>IDispatch</TT>-based
interfaces that other applications can create or connect to. An Automation Server
may or may not contain User Interface (UI), depending on the nature and function
of the Server.</P>
<P>Automation Servers can be <I>in-process</I> (executing in the process space of
the Controller), <I>local</I> (executing in its own process space), or <I>remote</I>
(executing in a process space on another machine). The specific implementation of
the server will, in some cases, define how and where the server will execute, but
that is not guaranteed. A DLL can execute as either in-process, local or remote;
an EXE can execute only locally or remotely. <BR>
<BR>
<IMG SRC="bar.gif" WIDTH="480" HEIGHT="6" ALIGN="BOTTOM" BORDER="0"></P>


<BLOCKQUOTE>
	<P><B>NOTE:</B> The fastest execution times are from Servers that are in-process
	to the Controllers using them. But remember that using an in-process Automation Server
	does not guarantee in-process performance. If an in-process Automation Server is
	created in one process space and then handed to a Controller in another process space,
	the Server becomes local and suffers from the same performance degradation as a Local
	Server. See Part II of this book for more information on process spaces and their
	impact on Server performance.

</BLOCKQUOTE>

<P><IMG SRC="bar.gif" WIDTH="480" HEIGHT="6" ALIGN="BOTTOM" BORDER="0">
<H3><A NAME="Heading6"></A>Automation Controllers</H3>
<P>Automation Controllers are those applications that can use and manipulate Automation
Servers. A good example of an Automation Controller is VB. With the VB programming
language, you are able to create, use, and destroy Automation Servers as though they
are an integral part of the language.</P>
<P>An Automation Controller can be any type of application, DLL or EXE, and can access
the Automation Server either in-process, locally, or remotely. Typically, the registry
entries and the implementation of the Automation Server indicate which process space
the server will execute in relation to the Controller.
<H3><A NAME="Heading7"></A>Controls</H3>
<P>ActiveX Controls are equivalent to what is referred to as OLE Controls or OCXs.
A typical Control consists of a UI representation both at design-time and runtime,
a single <TT>IDispatch</TT> interface defining all of the methods and properties
of the Control, and a single <TT>IConnectionPoint</TT> interface for the events that
the Control can fire. In addition, the Control may have support for persistence across
its execution lifetimes and support for various UI features, such as cut-and-paste
and drag-and-drop features. Architecturally, a Control has a large number of COM
interfaces that must be supported in order to take advantage of these features.</P>
<P>With the release of the new OLE Control and ActiveX guidelines for Control development,
a Control is no longer limited to the feature set defined in the preceding text.
Rather, the developer can now choose to implement only those features that are most
useful and interesting to users of the applications. The Control and Container guidelines
published by Microsoft list all the interfaces and their specific requirements. You
can find this information at the Microsoft Web site: <A HREF="http://www.microsoft.com"><B>http://www.microsoft.com</B></A>.</P>
<P>ActiveX Controls always execute in-process to the Container in which they reside.
The extension of a Control is typically OCX, but in terms of execution models, it
is nothing more than a standard windows DLL.
<H3><A NAME="Heading8"></A>COM Objects</H3>
<P>COM Objects are similar in architecture to Automation Servers and Controllers.
They contain one or more COM interfaces and probably little or no UI. These Objects,
however, cannot be used by the typical Controller application the way Automation
Servers can. The Controller must have specific knowledge of the COM interface that
it &quot;talks&quot; to in order to use the interface, which is not the case for
Automation interfaces. The Windows 95 and NT operating systems contain hundreds of
COM Objects and Custom interfaces as extensions to the operating systems for controlling
everything from the appearance of the desktop to the rendering of 3-D images on the
screen. COM Objects are a good way to organize a related set of functions and data,
while still maintaining the needed high-speed performance of a DLL. <BR>
<BR>
<IMG SRC="bar.gif" WIDTH="480" HEIGHT="6" ALIGN="BOTTOM" BORDER="0"></P>


<BLOCKQUOTE>
	<P><B>NOTE:</B> Automation Servers can also benefit from COM interfaces. These servers
	are known as dual-interface Servers. The <TT>IDispatch</TT> interface of the Automation
	Server also has a companion COM interface describing the methods and properties of
	the Object. Automation Controllers such as VB can take advantage of these dual interfaces
	to provide even greater performance when using the Server. The one drawback to dual-interface
	Servers is that they are limited to the set of data types supported by OLE Automation
	when defining methods and properties.

</BLOCKQUOTE>

<P><IMG SRC="bar.gif" WIDTH="480" HEIGHT="6" ALIGN="BOTTOM" BORDER="0">
<H3><A NAME="Heading9"></A>Documents</H3>
<P>ActiveX Documents, or DocObjects as they were originally called, represent Objects
that are more than a simple Control or Automation Server. A document can be anything
from a spread- sheet to a complete invoice in an accounting application. Documents,
like Controls, have UI and are hosted by a Container application. Microsoft Word
and Excel are examples of ActiveX Document Servers, and the Microsoft Office Binder
and Microsoft Internet Explorer are examples of ActiveX Document Containers.</P>
<P>The ActiveX Document architecture is an extension of the OLE Linking and Embedding
model and allows the document more control over the container in which it is being
hosted. The most obvious change is how the menus are presented. A standard OLE Document's
menu will merge with the Container, providing a combined feature set; whereas an
ActiveX Document will take over the entire menu system, thus presenting the feature
set of only the document and not that of both the Document and the Container. The
fact that the feature set of the Document is exposed is the premise for all the differences
between ActiveX Documents and OLE Documents. The Container is just a hosting mechanism,
and the Document has all of the control.</P>
<P>Another difference is printing and storage. An OLE Document is intended to be
a part of the Containers Document that is hosting it and, thus, is printed and stored
as a piece of the host Containers Document. ActiveX Documents are expected to support
their native printing and storage functions and are not integrated with the Containers
Document.</P>
<P>ActiveX Documents are used within a uniform presentation architecture, rather
than within an embedded document architecture, which is the basis for OLE Documents.
Microsoft Internet Explorer is a perfect example of this. The Explorer merely presents
the Web pages to the user, but they are viewed, printed, and stored as a single entity.
Microsoft Word and Microsoft Excel are examples of the OLE Document architecture.
If an Excel spreadsheet is embedded in a Word document, the spreadsheet is actually
stored with the Word document and is an integral part of it.</P>
<P>ActiveX Documents also have the added capability of being published as Web pages
on the Internet or on a corporate intranet. Imagine an in-house tracking system for
purchase orders run from the same Web browsers that are used to connect to the Internet.
<H3><A NAME="Heading10"></A>Containers</H3>
<P>ActiveX Containers are applications that can host Automation Servers, Controls,
and Documents. VB and the ActiveX Control Pad are examples of Containers that can
host Automation Servers and Controls. The Microsoft Office Binder and the Microsoft
Internet Explorer can host Automation Servers, Controls, and Documents.</P>
<P>With the decreasing requirements defined by the ActiveX Control and Document specifications,
a Container must be robust enough to handle the cases where a Control or Document
lacks certain interfaces. Container applications may allow little or no interaction
with the Document or Control they host, or they may provide significant interaction
capabilities in both manipulation and presentation of the hosted component. This
capability, however, is dependent upon the Container hosting the component and is
not defined by any of the Container guidelines as being required.
<H2><A NAME="Heading11"></A>From Here...</H2>
<P><A HREF="ch02.htm">Chapter 2</A> takes a slightly more detailed look at the specific
ActiveX and OLE technologies available and how best to apply them to your requirements.


</BODY>

</HTML>