Plug-in Framework

Introduction to Plug-ins, Modules and Messages

Plug-ins

A plug-in is a package that implements a defined API that will perform credentials management or related tasks on behalf of Network Identity Manager.

The Network Identity Manager architecture is message based. The core of each plug-in is a message handler. The plug-in integrates with the application by subscribing to, and handling specific types of messages.

The plug-in message handler runs in its own thread and receive asynchronous messages. There are exceptions, such as when one plug-in requires another plug-in to handle a specific message before it can handle the message. In addition, during certain operations that require user interaction, each plug-in can delegate code that will run in the main application thread (the user interface thread) to process window messages.

Modules

One or more plug-ins can be bundled together into a module. A module is a dynamically loadable library which exports a specific set of callbacks. Currently, the only two required callbacks for a module are :

For more information about how a module is structured, see Structure of a module .

Messages and Message Queues

An integral part of this framework is the messaging system. Most of the communication between the Network Identity Manager application and plug-ins is conducted through passing messages.

A message has a type and subtype and is denoted in this documentation as < message_type, message_subtype>. For example, when a plug-in is loaded, the first message it receives is < KMSG_SYSTEM, KMSG_SYSTEM_INIT >.

Each thread in the application, specially threads that were created for individual plug-in messages handlers, has an associated message queue that stores and manages all the messages that have been sent to subscribers in that thread.

The most common recipient of a message is a message callback function (see kmq_callback_t ). The message handler for a plug-in is one such example. A message callback function receives the message type, subtype and two optional parameters for the message.

Any acceptable recipient can subscribe to broadcast messages of any type. Once subscribed, whenever a message of that type is broadcast, the message will get queued on the corresponding message queue. Then, one of the dispatch functions can dispatch the message to the correct callback function. (see kmq_dispatch).

Next Module Manager ...


Generated on Fri Aug 3 08:27:13 2007 for Network Identity Manager by Doxygen 1.5.2
© 2004-2007 Massachusetts Institute of Technology.
© 2005-2007 Secure Endpoints Inc.
Contact khimaira@mit.edu