About the Component Object Model
The Microsoft Component Object Model (COM) defines a standard
way for software components to supply services to each other. Any PowerBuilder custom
class user object can be used as a COM object by providing it with
an execution environment, a registry entry, and optionally a type
library. Clients built with COM-compliant tools such as PowerBuilder and
Visual Basic can make use of the business logic in the COM object
by creating an instance of the object and calling the methods exposed
in its interface. Depending on the interfaces it supports, the COM
object may also be available to Java and C++ clients.
About PowerBuilder COM servers
PowerBuilder creates a single PowerBuilder COM server that contains
a PowerBuilder COM object for every custom class user object you select
when you build the project.
COM specifies how objects are created and destroyed, how their
interfaces are exposed, and how their methods are invoked. PowerBuilder COM
servers follow the COM specification; this means that from a client
perspective, the fact that a PowerBuilder COM object interacts with
a custom class user object (through the PowerBuilder virtual machine)
is transparent.
Comparing automation serversand PowerBuilder COM servers
PowerBuilder provides two ways to generate COM objects, in PowerBuilder COM
servers or automation servers. Both are accessible from wizards
and from the Project painter. PowerBuilder COM servers offer many
more features than automation servers.
PowerBuilder COM servers PowerBuilder COM servers can contain more than one custom class
user object. After you code the user objects, you use the Project
painter to generate a single self-registering DLL for all the objects.
You can also deploy the server directly to Microsoft Transaction
Server (MTS) if it is running on the build computer or create an
MTS package. PowerBuilder COM objects in a COM server can share runtime
sessions, and references can be passed between objects created from
the same COM client.
The COM server also contains an embedded PowerBuilder dynamic
library (PBD) file that contains compiled versions of all the custom
class user objects you selected and any dependent objects, as well
as registry and type library information.
Automation servers Automation servers built from a PowerBuilder custom class user
object contain only one object. After you code the user object,
you build a runtime library from the PBL that contains it and then
use the Project painter to create a registry file and optional type
library file. When you deploy the automation server, you customize
the registry file for the user’s computer and then run
the file to register the automation server.
You deploy the PowerBuilder virtual machine with both an automation
server or a PowerBuilder COM server, along with any other PowerBuilder runtime files
the server requires.
Dispatch, dual, and custom interfaces
Automation servers use a dispatch interface (also called dispinterface)
which allows users to invoke methods on the server using the Invoke
method of a standard COM interface called IDispatch.
COM servers can use custom or dual interfaces, which provide
better performance than dispatch-based interfaces. A custom interface
provides access to methods on the server via a virtual table (also
called VTBL or vtable) that contains pointers to methods in the
server’s interface. A dual interface enables the client
to invoke methods using IDispatch::Invoke or a virtual table.
For more information, see “Choosing a custom or dual
interface”.
Summary of differences between servers
The following table summarizes the differences between PowerBuilder automation
servers and PowerBuilder COM servers using dual or custom interfaces:
| Feature | Automation server (dispatch interface) | COM server (dual interface) | COM server (custom interface) |
|---|---|---|---|
| In-process server support | Yes* | Yes | Yes |
| Generated IDL files | No | Yes | Yes |
| C++ client support | No | Yes | Yes |
| Java client support | Yes | Yes | No |
| PowerBuilder client support | Yes | Yes | No |
| Visual Basic 4 client support | Yes | Yes | No |
| Visual Basic 5 custom interface support | No | No | Yes |
| Support for PowerBuilder structures as instance variables and method argument types |
No | No | No |
| Support for all C language data types | No | No | No |
| Support for an embedded type library | No | Yes | Yes |
| Self-registering servers | No | Yes | Yes |
| Support for DCOM # | Yes | Yes | Yes |
| Support for Jaguar CTS | Yes | Yes | No |
| Support for MTS | Yes | Yes | Yes |
| Requires separate proxy/stub DLLs | No | No | No |
| Requires PowerBuilder deployment DLLs (minimally PBVM70.DLL) | Yes | Yes | Yes |
| Requires deployment of application runtime libraries built in Library painter |
Yes | No | No |
* In-process server is the PowerBuilder execution
DLL (PBVM70.DLL)
# Requires use of surrogate host to house
the PowerBuilder execution DLL