The DSOM implementation has the following extensions and limitations in its implementation of the CORBA specification:

• As just described, the current release of DSOM supports a simple server activation policy, which is equivalent to the "shared" and "persistent" policies defined by CORBA. DSOM does not explicitly support the "unshared" or "server-per-method" server activation policies. Policies other than the basic activation scheme must be implemented by the application.

• DSOM provides null implementations for the object_is_ready or deactivate_obj methods, defined by the BOA interface for the unshared server activation policy.

• DSOM does not support the change_implementation method, defined by the BOAinterface to allow an application to change the implementation definition associated with an object. In DSOM, the ImplementationDef identifies the server which implements an object. In these terms, changing an object's ImplementationDef would result in a change in the object's server ID. Any existing object references that have the old server ID would be rendered invalid.

  It is possible, however, to change the program which implements an object's server, or change the class library which implements an object's class. To modify the program associated with an ImplementationDef, use the update_impldef method defined on ImplRepository. To change the implementation of an object's class, replace the corresponding class library with a new (upward-compatible) one.

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

• The SOM Object Adapter (SOMOA) provides a method (change_id) to update the ReferenceData associated with an object reference created by the create call This is useful if the information which describes the object must be changed without invalidating copies of the existing object reference. CORBA defines no such method; change_id is an extension to the standard BOA methods.

• The SOMOA provides some specialized object reference types which, in certain situations, are more efficient or easier-to-use than standard object references.

• DSOM supports the SOM extension to IDL that allows method parameters that are pointers. Structure, sequence, and array parameters may only contain pointers to objects (not arbitrary types).

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