OMI 1.0.8 (Beta) Release Notes
=======================
The sections below describe a new feature or a bug that was fixed in OMI 1.0.8 (Beta).

Important Notes:
==================================
    Providers should not perform blocking operations using the OMI Server thread, when
processing a call from OMI Server. Infinite waits, or sleeps, will block the omiserver thread
indefinitely.
    Indications should only be posted from a separate thread within the provider
(a "background thread"), and should not be posted using the OMI Server thread during
a call into a provider.
    OMI 1.0.8 Beta does not currently support UNIX variants from AIX, HP, or Solaris. This is
expected to be corrected before the final release of OMI 1.0.8.

Support for CIM Indications:
==================================
    OMI 1.0.8 enables providers to expose events using CIM Indications, and has added
support for the Subscribe operation initiated by OMI clients. See section 8.3.8 of the
OMI documentation for detailed information. Note that this implementation does not include
support for the full CIM Indication Profile (DSP1054), or for subscription persistence across
service restarts.

IMPORTANT: Indications should only be posted from a separate thread within the provider
(a "background thread"), and should not be posted using the omiserver thread during a call
into a provider.

    Providers may now provide the industry-standard events by posting instances of CIM_Indication.
A CIM Indication is a representation of an event in the managed system. Events may be related
to objects accessible in a CIM server, such as the creation, modification, deletion of or access to
an object, or execution of a method on the object. Such events are referred to as "Lifecycle
Indications". Events may also be related to the managed system, such as alerts or errors coming
from the hardware. These events are referred to as "Alert Indications".
    A CIM client can subscribe for receiving indications by providing the indication type and the
filtering expression, which selects events that will be delivered to the client. See section 4.7 of
the documentation for information on how to subscribe to both Alert and Lifecycle indications.
   

OMI enables provider-to-provider interaction using the MI API:
==================================
    The MI API now supports the full range of standard CIM operations for a provider to use
enabling them consume data exposed by another MI provider. The basic flow starts by using
MI_Application_NewSession to create a session for a set of operations, then using the
various operation-specific interfaces. The operations supported using the MI_ APIs include:
 GetInstance - MI_Session_GetInstance.
 EnumerateInstances - MI_Session_EnumerateInstances.
 CreateInstance - MI_Session_CreateInstance.
 DeleteInstance - MI_Session_DeleteInstance.
 ModifyInstance - MI_Session_ModifyInstance.
 Associators - MI_Session_AssociatorInstances.
 Invoke (method) - MI_Session_Invoke.
 Subscribe - MI_Session_Subscribe.

OMI now includes the NITS integrated testing system
===============================
    This is a new unit test framework written in C, and provided with the OMI package. The NITS
framework enables complex tests to be crafted, and enables simulating fault injection in the code.
NITS replaces the existing unit test infrastructure, and makes debugging, maintenance, and code
coverage testing significantly easier. The unit tests that ship with OMI 1.0.8 (Beta) use NITS.

There are detailed instructions in Appendix D of the OMI documentation that describe how NITS
may be used.

Bug: Invoke method fails on a Method with Embedded Instance parameter that lacked key values
=============================================================
Fixed the issue that, when calling icim on a method which takes in embedded instance as a parameter,
an error is thrown if the Key values were not supplied for the embedded instance.

Bug: Cross Namespace traversal for an association
=============================================================
OMI will now properly support an association query which traverses from one namespace to the other.
Previously, instances returned would be from the originating namespace, not the namespace identified
in the association query.