ActiveX Interface for ObjectStore

Chapter 4

Distributed OSAX Object Servers

An OSAX object server can be used
in many different configurations, including local and distributed configurations. In local configurations, the database, object server, and application all execute on the same computer. In distributed configurations, these components execute on two or more computers cooperatively on behalf of a single user.

In distributed configurations, the object server initially resides on a remote computer, the server host. There are three basic mechanisms that a client might use to access the object server:

The advantages and disadvantages of these configurations are:

Web server accesses local OSAX object server:
Protocols

HTTP to access Web pages InProc COM within server
Advantages

Supports all Web browsers.

Access to very large centralized databases.

Centralized database can be easier to update and administer.

High-performance data access on server side.
Disadvantages

User interface is restricted to HTML constructs.

Applications with extensive computation requirements must perform them on the server (where the data is), instead of distributing burden to clients.

Protocols

DCOM
Advantages

Access to very large centralized databases.

Centralized database can be easier to update and administer.

Easy to blend client-side and server-side computation.
Disadvantages

Performance 100 to 10000 times slower than InProc DCOM; requires careful design of object server interface.

Network must pass DCOM protocols.
Client accesses remote object server:

The appropriate configuration for a given application depends on the application requirements for interactive performance, database size and administration, network scale, and platform independence.

Using Object Servers with Web Servers

An OSAX object server and database can be accessed directly from an Active Server Page using the Microsoft Active Server. Simply place a named reference to the object server class on the page. Then use the server's scripting capability to access the database contents and format them into HTML content.

The following example shows the body of a Microsoft Active Server page that formats the contents of the Books example database as an HTML table.

<OBJECT RUNAT=Server ID="osBooks"
                                CLASSID="CLSID:84858E05-533D-11D0-8771-000000000001">
</OBJECT>
<H2>ObjectStore OSAX Books Example - Microsoft Active Server</H2>

<% Set osDatabase =
                  osBooks.ObjectStore.OpenDatabase("D:\ODI\OSAX\Examples\Books\Books.db") %>

<TABLE BORDER=2>
<TH>Title<TH>Author
<% Set B = osDatabase.Value("Books", osBooks.CBookElt) >
<    Do  >
<       Author = B.Book.Author.Name  >
<       Title = B.Book.Name     %>
<TR><TD><%=Title%><TD><%=Author%>
<%     Set B = B.Next  >
<     Loop While Not B Is Nothing   % >
</TABLE>
<%  osDatabase.Close    %>

Accessing Networked Object Servers Using DCOM

 An OSAX object server can be accessed remotely from a DCOM client with no changes to its implementation. Only the registration of the object changes, on both the client and server.

It is important to note that DCOM performance is dramatically slower than InProc COM performance. This significantly affects the design of an object server and its clients. An InProc COM client might reasonably perform computations directly on ObjectStore objects and properties, because of the high performance of object access in that configuration (millions of accesses per second). A DCOM client should minimize interaction with the object server by performing more computation on the server side, because of the poor performance of object/method access in that configuration (hundreds of accesses per second).

DCOM Client Configuration

You can access an OSAX object server remotely from a DCOM client. Register the class and indicate its location on a named remote server. There are several ways of accomplishing this, depending on the client environment:

In either case, the desired registry information for the class must not include the LocalServer32 or InProcServer32 keys, and must include the AppID key and the associated RemoteServerName.

Troubleshooting DCOM

Here are a couple of potential problems using DCOM, and how to solve them.

Problem
Application name does not show up in dcomcnfg control panel.

Solution
Make sure there is an AppID key associated with the object server's CLSID in the registry (reregister with the osaxout utility).

    [HKEY_ROOT_CLASSES\CLSID\{clsid}]
    "AppID" = "{clsid}"


[previous] [next]

Copyright © 1998 Object Design, Inc. All rights reserved.

Updated: 03/18/98 13:56:17