Limitations

The following list indicates known limitations of Distributed SOM at the time of this release.

• Currently, objects cannot be moved from one server to another without changing the object references (i.e., deleting the object, and creating it anew in another server). This yields all copies of the previous reference invalid.

• The change_implementation method is not supported. This method, defined by the BOA interface, is intended to allow an application to change the implementation definition associated with an object. However, in DSOM, changing the server implementation definition may render existing object references (which contain the old server ID) invalid.

• Currently, DSOM has a single server activation policy, which corresponds to CORBA's "shared" activation policy for dynamic activation, and "persistent" activation policy for manual activation. Other activation policies, such as "server-per-method" and "unshared" are not directly supported, and must be implemented by the application.

  Since the unshared server policy is not directly supported, the object_is_ready and deactivate_obj methods, defined in the BOA interface have null implementations.

• If a server program terminates without calling deactivate_impl, subsequent attempts to start that server may fail. The DSOM daemon believes the server is still running until it is told it has stopped. Attempts to start a server that is believed to be exist results in an error (SOMDERROR_ServerAlreadyExists).

• Currently, file names used in ImplementationDefs are limited to 255 bytes. Implementations aliases used in ImplementationDefs are limited to 50 bytes. Class names used in the Implementation Repository are limited to 50 bytes. Hostnames are limited to 32 bytes.

• The OUT_LIST_MEMORY, IN_COPY_VALUE, and DEPENDENT_LIST flags, used with Dynamic Invocation Interface, are not yet supported.

• The Context::get_values method currently does not support the flag CTX_RESTRICT_SCOPE.

Other important notes concerning DSOM are documented in the "README" file in the SOMBASE root directory ($SOMBASE on AIX, and %SOMBASE% on OS/2 or Windows).