| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Services Supported

In this section we will look at the services supported. The tables in the following pages have been organized first around the general headings I have used for the types of service and second around the service names I have used in this book so far to show the functionality of DCOM. In the following lists, I have described Software AG’s and Digital’s approaches separately.

Communication-level services

Table 11.3 Communication-level services
Service | Supported?
--- | ---
Pack/Unpack | YES (including “custom marshaling,” though a developer is recommended not to use it)
Translate Data formats | Generally yes, although these early releases are having difficulty with Microsoft’s Unicode. Use standard marshaling (not custom marshaling)
Buffer packing | YES
Session management | YES
Network calling | YES
Transmission coordination | YES
Fault handling | YES
Triggering | YES
Context bridging | NO
Broadcast/Multicast (Outgoing Interface) | Not clear at the time of writing
Memory Management | DCOM FTE contains an implementation of a subset of the Microsoft Windows NT Kernel services (Win32 service routines). This implementation provides the basic memory management services required for the DCOM FTE runtime environment on Unix.

Management layer services

Table 11.4 Management layer services
Service | Supported?
--- | ---
Threading | Digital-Is using the underlying DCE thread service to support multi-threading on the OpenVMS platform. Their Unix port is based on the Software AG version for Unix and as such will mirror the approach used by them.
| Software AG-DCOM FTE contains an implementation of a subset of the Microsoft Windows NT Kernel services (Win32 service routines). This implementation provides the basic threading services required for the DCOM FTE runtime environment on Unix.
Security | Digital is using the GSSAPI interface to DCE security to provide security services on OpenVMS. But, they also aim to enable a developer to use NT security.
| The user will be able to log on using NT users and passwords and authentication will be achieved via the NT host. Access control is likely to prove more difficult and Digital envisages that two sets of identifiers may be needed for the Windows NT and the OpenVMS platform because it is difficult to combine Access Control Lists.
| Software AG is also using a third-party Security Service Provider.
MTS | Not supported by Digital or Software AG
MSMQ | Not supported by Digital or Software AG

Translation services

In the following table we have not included an entry for ADSI and LDAP as this is covered by the next table under the heading of Directory services support.

Table 11.5 Translation services
Service | Supported?
--- | ---
OLEDB | Not supported by Digital or Software AG. Both Digital and Software AG will be able to provide support, however, for structured storage (see chapter on OLEDB).
OLEMSGing | Not supported by Digital or Software AG.

Other services

Software AG is providing a Registry which can be edited using a “regedit” tool or a tool called the “sermon” tool. Both tools are provided with the Mutant.

The Registry edit tool is a Motif application with a similar look and feel to the Microsoft Registry editor and is GUI based. The sermon tool is a command line application which can be used to operate and monitor the registry service itself at runtime.

Table 11.6 Other services
Service | Supported?
--- | ---
Administration | Digital is porting the Windows event logger and providing tools to help with administration. But administration will not be of the entire configuration of Windows NT and other platforms. Thus no unified centralized administration tools will be available.
| Software AG’s tools are also not capable of supporting the entire configuration; they are platform specific.
Directory | Digital will be supporting the Registry. A Digital group is looking at the developments in the Active Directory.
| Software AG is supporting the Registry. More details are provided below.

Software AG supports both a disk-based and memory resident registry. When the configuration is started, a utility loads the registry from disk or creates it automatically using default settings. It then checks on a regular basis to see if the memory resident registry has changed, and if it has, the disk-based registry is updated. The utility also creates a backup of the disk file. The Registry provided on the Solaris platform is a multiuser registry.

We will be seeing in the chapter on Directory services that DCOM uses a component called the SCM—Service Control Manager—to handle requests for components on other platforms. This SCM keeps a list of the servers actually running in a table—called the Running Object Table. Software AG has implemented both the SCM and the ROT. Any machine wanting to run a server application must have these services on it. The SCM on the Unix machines can offer its services to both applications on Unix and applications on Windows NT—so the two types of SCM do talk to each other to find a component.

Previous | Table of Contents | Next