Previous section.

Systems Management; Event Management Service (XEMS)
Copyright © 1997 The Open Group

Overview of the Event Management Service

General Model

Among the common goals of most systems management applications are to ensure the availability and reliability of the managed computing environment, while imposing a minimal amount of overhead onto the environment. To do this effectively, systems management applications have a requirement to be able to produce and consume large volumes of data that corresponds to important, time critical information about the managed environment.

An individual data entity corresponding to some information communicated from the managed environment to the management applications is known as an "event". The EMS described in this document defines the mechanisms necessary to generate and process events, thus enabling systems management applications to respond appropriately to changes in the availability and/or reliability of computing resources in the managed environment.

Today's commercial computing environments are characterized by both their distributed and heterogeneous natures. Typical environments are comprised of networks of a wide variety computer hardware and software produced by many different vendors, cooperating in some fashion to perform mission critical functions on behalf of end-users. As a result, systems management applications are required to manage a wide range of computing resources, and thus need to consume events produced by applications developed by several different vendors.

In order to enable the development of management applications that communicate and process the event information within a heterogeneous, distributed computing environment, the EMS API must be standardized. Developers of system resource monitoring services require a standard API for reporting the occurrence of events that must be processed by management applications, and management applications require a standard API for the consumption of events that may be generated by a wide variety of resource monitoring services.

This document describes both a general model for an EMS architecture, and a set of APIs tailored to mapping the general model to an X/Open compliant environment. While it would be ideal to have a single implementation that is appropriate for all computing environments, in reality different computing environments employ vastly different distribution mechanisms, and a single implementation is simply not feasible.

Part 2 of this specification describes the mapping of the EMS API to several implementations. This is meant to be a sampling of implementations. By agreeing upon the implementations for various spaces, for example, CORBA event service, implementors of event services and gateways will be able to create interoperable products.

The EMS provides reliable, in sequence, asynchronous notification of events. It is implemented as an intermediary layer between management applications and managed objects.

An event is a partially opaque object emanating from a managed object. The information (object) is partially opaque in so far as there is a standard header and an encoded data stream. The standard header provides the minimal amount of information that an EMS must be capable of filtering for any management application. The standard header also provides the minimum amount of information that an EMS must be capable of filtering for a managed object.

The EMS specification does not prescribe the mechanism used to locate Event Service instances either from a management application or managed object perspective. These relate to the given environment, for example, DCE.

The EMS specification does not address mechanisms for activating (or otherwise controlling) managed objects. These mechanisms may be incorporated into management applications.

EMS implementations operate within the security policy of the given environment. They do not implement a distinct security framework.


An X/Open EMS conforms to the conceptual model shown in Event Management Service: Conceptual Model .

Figure: Event Management Service: Conceptual Model

At first glance, the core of the Event Service looks very similar to a COSSES Event Channel. There are, however, some notable differences:

The security context is derived from the normal means, for example, set during logon or altered via system calls (setuid, setgid, etc.). Consumers, like the EMS, are both clients and servers. As a result authentication and authorization are performed for both the registration and the event flow. The difference between the Consumer and the EMS is that the Consumer does not perform the multi-level check on the contents of the event container.

The remaining sections of this chapter describe how the event services described in this specification would typically be configured, and how developers of software components that produce and/or consume events would integrate with this service.

The "Example" section (see Examples ) illustrates aspects of the EMS through the deployment and use of an intelligent agent.

Conceptual Flow

This section describes the flow through the EMS. There are several timeframes:

Configuration of an EMS
The configuration of EMS involves loading the package, allocating the repositories, and implementation setup. Subsequently, this EMS must be registered with other EMS instances. This will control the forwarding of events, etc. A security context must be created for this EMS. The implementation will provide the default set of event schemas. These are stored in the consumer/supplier registry. The configuration process will also instantiate the namespace (registry) for the basic event types.
Configuration of a Supplier
The configuration of a supplier involves loading the package, adding the supplier to the consumer/supplier registry, updating the namespace for the events provided by the supplier, and establishing the security context for the supplier.
Authorization of a Consumer
A consumer must be registered with the consumer/supplier repository before the consumer may use the EMS. The registration defines the events that the consumer may receive. This provides the security context for the consumer. Registration may also involve the definition of space constraints for the user. The constraints may encompass the filter repository and the event repository. The consumer may be limited to a fixed number of filter groups or event delivery space.
Establishing Filters
The consumer registers filters with the EMS. A filter consists of a filter group. A filter group is a set of filter lists. A filter list is a set of filter expressions. Each filter expression represents a logical expression. An expression consists of the name of an event attribute, a logical operator, and a value. A set of filter expressions represents a logical anding of the members. So, the logical result of a filter list is true if all of the filter expressions are true. Filter lists are combined to form filter groups. The filter lists are ored within the filter group. Hence, the logical result of a filter group is true if any of the associated filter lists are true. When applying filters, the event channel assumes that all attributes in the event schema have values.

Interfaces are provided manipulating, querying, and administering filters. Consumers are not required to use filters. The effect of not using a filter group is the reception of all events consumer is authorized to receive.

Supplier Connections
A supplier connects to the EMS at supplier start-up. The bind operation includes arguments for the reflecting hints to the supplier. To receive hints a supplier would operate as both a client and a server. The server side would respond to the hints, while the client operations are used to connect and disconnect from the EMS as well as to send events to the EMS. A supplier is not required to accept hints. Even if the supplier provides the server interface, it is not required to act on a hint. The current hints that may be received by a supplier are the number of consumers for an event type. This may be used by a supplier to (de)activate sending events to the EMS. Each change in the number of consumers of an event type causes a hint to be sent to the supplier. The hints are reference counts.

The EMS applies an authorization filter to the supplier. A supplier may only insert event types for which it is registered. A supplier may be permitted to insert any event type registered in the EMS. This permits generic suppliers, for example, gateways among EMS instances.

Consumer Connections
A consumer connects to an EMS to receive events. When the consumer connects, it indicates the recipient of the events. It also indicates the type and quality of service. The type of service is either the push or pull model. The quality of service controls the EMS delivery semantics. This is a hint to the EMS. It may not support quality of service levels. At a minimum, an EMS implementation must support reliable, in sequence delivery.

The normal sequence of operations by a consumer are:

From time to time administrators may want to audit the repositories and registries. EMS is designed to be maintenance free, but occasional cleanup is inevitable. Administrative activities include:


The EMS performs fan-in and fan-out operations. It receives events from suppliers. It supplies events to consumers. The EMS must perform these operations in an efficient, reliable and secure manner. The combination of basic operations and the constraints under which they must be performed lead to the general model given at the opening of this chapter.

A number of components may be gleaned from the general model. They are:

Event Services API Overview

The EMS API can be divided into several interfaces grouped by function. The different interfaces are:

The Registration interface allows registration with EMS for applications that are not suppliers or consumers. The Event Type interface provides support for manipulating the Event Type Database. Event filters can be created using the Event Filter Interface. The Supplier interface allows suppliers to both register and send events to the EMS. The Consumer interface provides consumer setup routines and consumer registration routines. The EMS Management Interface allows management applications to administer the EMS databases, as well as the event service itself.

EMS Registration
The EMS registration routines allow clients, or users of the event service to both obtain a `handle' to access the event service, as well as register with the event service how they intend to use it.

An event service handle is required to perform any operation with the event service. These operations can be event type operations, event filter operations or event management service operations. The following routines allow EMS clients to register with EMS:


Register with the Event Service.


Unregister with the Event Service.

Another type of registration requires consumers and suppliers to register with the event service to tell the event service that they are consumers or suppliers as well as what type of consumer or supplier they are. These routines are described in the supplier and consumer sections.


Conceptually, events consist of two objects. There is a base object (header) for all events. Optionally, there may be a derived object for the event.
Event Header
The event header contains the following information:
Event Data
The event data object contains the details of the event. This object is mapped by an Event Schema introduced in the next section. Event data can be self-describing; that is, it may consist of a sequence of anys.Itmaybeacomplexstructure.


Schemas are required for all typed events. The amount of information given in the schema may vary. Schemas are used to support filtering. Schemas are retained in a Schema Database. This database may not be required for all implementations. For example, it may be that a CORBA implementation uses the implementation repository for schema information.
The EMS Event Type Interface
All events processed by EMS have an event type. Event types can be either generic, or defined by an event type schema.

EMS keeps a database of event types which consists of event type schemas. Routines are provided to manipulate the event types in the event type database.

The following routines summarize the EMS Event Type Interface:


Add a new event type schema to the Event Type Database.


Delete an event type schema from the Event Type Database.


Get an event type schema from the Event Type Database.


Get a list of event type schemas from the Event Type Database


Free the list of event type schemas.


Filters are used by suppliers and consumers to control which events get sent through the event channel. EMS supports the concept of two stage filtering. First stage filtering is applied to the supplier before receiving an event in the EMS. Second stage filtering is applied by EMS before forwarding events on to consumers.

The EMS API supports the second stage filtering, and provides routines to manipulate the EMS Event Filter database.

The following routines summarize the EMS Event Filter Interface:


Add a filter to the Event Filter Data base.


Append filter expressions to the Event Filter Database.


Get the contents of an event filter.


Free the storage used by an event filter after a get.


Delete a filter from the Event Filter Database.


Get a list of the names of all filters in the Event Filter Database.


Free a list of filter names.


Get a list of all the filters in the Event Filter Database.


Free the list of filters.

Event Channel

Conceptually, an EMS consists of a pair of event channels for supplier to consumer flow. One of the event channels connects the supplier with the EMS. The other event channel connects the consumer with the EMS. Logically, the EMS indicates to the supplier that the event has been received after it has been made persistent (assuming that there are consumers for the event or the EMS does not perform this optimization), insuring that the event is not lost during the transfer. Likewise, once the consumer indicates to the EMS that it has received the event, the EMS removes the event from the persistent store.

A channel pair provides a means of decoupling consumers and suppliers. In addition, it provides a mechanism for fan-in and fan-out of events.


EMS consumers are both clients and servers. The EMS consumer interface provides support for the steps required to implement an event consumer. A routine is provided to perform consumer setup, ems_consumer_start, and consumer cleanup, ems_consumer_stop. These routines should be called when a consumer starts, and before consumer shutdown. After setup is complete, then a consumer must register with the EMS, and set up any filters that it wants to use to control which events get forwarded to this consumer.

The EMS maintains a consumer database to keep track of all registered consumers. Registering and unregistering with the EMS adds and deletes consumers to and from the database.

Two types of consumers, to correspond with the OMG Event Service Model, are supported, a push consumer and a pull consumer. A consumer would use the appropriate registration API to designate which type of consumer is desired

The following routines summarize the EMS Consumer Interface:


Called to start an event consumer.


Called to stop an event consumer.


Register a push consumer.


Register a pull consumer with the Event Service.


Unregister a consumer with EMS.


Add a filter name to a consumers event filter group.


Delete a filter name from a consumers event filter group.


Get the list of filter names that comprise a consumers event filter group.


Retrieve consumer registration information associated with a consumer handle.


Used by pull consumers to get an event from the event management service.


Used by pull consumers to get an event from the event management service, but not block waiting.


The EMS Supplier interface allows suppliers to send events to the Event Service. First stage filtering would be applied before making any EMS interface calls sending any events from the supplier to the event service. Note, the EMS will not accept event types from a supplier that the supplier has not registered.

The following routines allows suppliers to send events to the EMS:


Send an event to EMS.


Register a hint callback for the supplier. This requires the supplier to be both a client and a server.


Register a push supplier with the EMS.


Register a pull supplier with the EMS.


Unregister a supplier with the EMS.


The event service also provides a management API to allow administration of the event service as well. The management routines allow manipulation of event service attributes, and the consumer database. The EMS Filter Interface and Event Type Interface could also be used to administer the Event service, but those interfaces can also be used by suppliers and consumers.

The following routines summarize the EMS Management Interface:


List all hosts running the event service.


Free the host list.


Lists attributes for a specific EMS.


Free a list of ems attributes.


List consumers registered with EMS.


Free a consumer list.


Alter the permissions of a subject with regard to a security object.


Add a subject to the EMS. The subject may act as a consumer or a supplier or both, based on the read/write permissions given on the call.


Remove a subject from the EMS.


Given a principal, return the EMS defined subject.


Delete a filter name from a consumers filter group.


Add a filter name to a consumers filter group.


Get the list of names in a consumers filter group.


List suppliers registered with EMS.


Free a supplier list.


Delete a supplier from the Supplier Database.


Retrieve a list of events that have not been delivered to interested consumers.


Free the undelivered events in the list for interested consumers.


Delete an undelivered event from the EMS Event Log.


Establish the forwarding of events described in a filter group from a given EMS to another EMS.


An event management system is a fundamental component. It is used in conjunction with management applications leveraging its services. Together these provide the basis for maintaining service availability by:

  1. Giving timely warning of impending problems (for example, file capacity thresholds).

  2. Notifying system administrators of failing processes and system components.

  3. Quickly identifying root causes to problems in increasingly complex systems.

  4. Automatically fixing problems before service levels are degraded.

  5. Integrating application-specific event mechanisms so system correlation can be done at a higher level (for example, network outages are the root cause of many application errors; and the administrator needs his attention drawn to the root cause).

Key attributes of the EMS are:


Since event management applications are responsible to notify any system and network problems to responsible operators, the management application itself as well as the underlying event services must be absolutely reliable. The following issues outline the areas that must be addressed by an EMS implementation:

No Loss of Events

EMS implementations are responsible for all events from the point in time the events are sent by a supplier until they are received by all consumers registered for notification of the respective event. Implementations must guarantee reliable delivery of all events from suppliers to consumers; in case the network connection to consumers is down, local buffering must be applied to enable later retransmission of events.


Since an EMS is responsible for the delivery of problem notifications to a management application, it is essential that an appropriate mechanism is provided for the monitoring of EMS and the underlying components it depends on. In case of any failure, consumers must be notified of the failure in order to enable them to react appropriately.

Stable Processes

The stability of processes is an issue that applies to all pieces. However, due to its importance to applications that depend on event services, an implementation must be extremely robust even in moments of high network or CPU load on the local machine. Since event services is required in such exceptional states, this must be reflected in the robustness of its implementation.


The EMS, optionally, uses security facilities in two distinct means. The EMS can use the security framework of the underlying system to obtain the principal name. The principal name may in turn be used to determine access permissions to EMS constructs, for example, the filter repository or event types. The access permissions to EMS constructs represents a multi-level access security model.

The EMS may use an external security mechanism to control the consumer's or supplier's ability to register (bind) with an EMS. Given a security principal, the EMS may recognize permissions for specific objects. For example, a supplier may only be permitted to insert a specific event type, or a consumer may only be permitted to view certain event types. If multi-level access is not available, then an EMS implementation may be configured such that all users of the specific EMS have the same permission sets for all objects. Expanding upon this, a set of EMS instances may be configured for a given node, where each instance supports a specific set of users.

The EMS will operate within the security framework of the host environment. It is paramount that an implementation work within the host security mechanism. Security policies can be quite complex. The use role-based security schemes compounds the situation. For EMS implementations to have wide acceptance, they cannot insist upon using private security mechanisms.

The manifestation of a security policy is transparent to consumers and suppliers. The use of the security contexts of the consumers and suppliers, assists interoperability and usability. The sole adapter to be used for an EMS may be the authorization implementation for the vendor's abstract authorization class.

The use and understanding of a security architecture does not depend on a full-understanding of the underlying object implementations and interactions of the Event Service, consumers, and suppliers. The conceptual model for the use of security with the EMS is depicted in Security Service .

  1. The security context is derived from the normal means, for example, set during logon or altered via system calls (setuid, setgid, etc.).

  2. Consumers, like the EMS, are both clients and servers. As a result authentication and authorization are performed for both the registration and the event flow. The difference between the Consumer and the EMS is that the Consumer does not perform the multi-level check on the contents of the event container.

Figure: Security Service
The conceptual role of security for the DCE-based EMS is summarized as follows:

  1. Neither consumers nor suppliers are aware of, that is, need code to support, a security mechanism. They simply inherent the security context of their logon group.

  2. The EMS requires object level security granularity, that is, multi-level security. As a result, it must perform authorization checks for consumers and suppliers.

  3. The administration functions are not depicted in this view. They are deemed to be outside the scope of the EMS specification.

  4. The EMS specification is written in accordance with the proposal put forth in GSSAPIEXT to the extent that the latter provides specifications for multi-level access. For example, from the perspective of a DCE-based EMS, the calls to the ACL manager to determine whether a consumer (or supplier) has permission for a given operation on a specific event type (that is, a specific object) are:

    It is not clear whether GSSAPIEXT provides this support or has left it as an implementation specific aspect of security.

Changes in a principal's security profile may affect their ability to participate as a consumer (or supplier) either during or across conversations.

Global Namespace

The global namespace from a security perspective is concerned with the transfer and/or conversion of a principal's security context within/across security domains.

The namespace affects consumers and the EMS.

The namespace is transparent to suppliers and the EMS.

Security context transfers must be capable of mapping the principal and the principal's attributes, for example, PACs for DCE-based security.

The mapping transformations must be two-way, since the information flow is both from the consumer to the EMS and vice versa.

The event flow (from the EMS to a consumer) does not require multi-level security at the consumer side.

Security Objects

There are two types of security objects in EMS. Both types are controlled by permission sets. The first type of security object concerns manipulation of EMS attributes, and EMS Databases. Here is a list of the EMS security objects of this type.

controls access to the event service.

controls access to the Event Type Database.

controls access to the Filter Database.

controls access to the Consumer Database.

controls access to the suppliers Database.

The second type of security object concerns manipulation and access to objects inside of the databases. These objects are classified by category.

controls access to a given event type in the Event Type Database

controls access to a given filter in the Filter Database

The remainder of this section describes what operations can be controlled on each security object.

Event Service Attributes Security Object
The ems-server security object controls access to the event service and its attributes. The two permissions on this security object are:

modify this security object.

read or get the attributes for an Event Service.

write or modify the attributes for an Event Service.

Event Type Database Security Object
The event-types security object controls access to the Event Type Database. The permissions associated with this security object are:

modify this security object.

delete an event type from the Event Type Database.

insert or add an event type to the Event Type Database.

read or get an event type schema from the Event Type Database.

Filter Database Security Object
The filters security object controls access to the Filter Database. The permissions associated with this security object are:

modify this security object.

delete a filter from the Filter Database.

insert or add a filter to the Filter Database.

read or get a filter or the list of filters from the Filter Database.

Consumer Database Security Object
The consumers security object controls access to the Consumer Database. The permissions associated with this security object are:

modify this security object.

delete a consumer from the Consumer Database.

insert (by registering) a consumer in the Consumer Database.

read or get a list of consumers, or a specified consumer's filter group from the Consumer database.

modify a consumers filter group.

Supplier Database Security Object
The suppliers security object controls access to the supplier Database. The permissions associated with this security object are:

modify this security object.

delete a supplier from the Consumer Database.

insert (by registering) a supplier in the supplier Database.

read or get a list of suppliers from the supplier database.

Event Type Security Objects
The event type object security object controls access to a given event type in the Event Type Database. An security object of this type is created for every Event type in the Event Type Database. The permissions associated with this security object are:

modify this security object.

delete this event type from the Event Type Database.

read or get the event type schema for this event type from the Event Type Database.

Filter Security Objects
The filter object security object controls access to a given filter in the Filter Database. A security object of this type is created for every filtering the Filter Database. The permissions associated with this security object are:

modify this security object.

delete this filter from the Filter Database.

read or get the filter expressions for this filter from the Filter Database.

write or append a filter expression to this filter in the Filter Database.

Network Communications

Authentication is provided by the environment.

Security context support is provided by the environment.

Data encryption support is provided by the library. In a OMG CORBA environment, for example, this would be provided by the object system.

Encryption is at the conversation level and not at the object level. This eases the administrative burden in the sense that encryption semantics can be defined at the communications layer. The EMS need not be aware of the encryption mechanism.


Many of the initial suppliers for the EMS are likely to be legacy applications with EMS wrappers. These suppliers are expected to emit text based data. The exchange of textual data as the content of events introduces a number of problems:

Solutions to these problems (from the perspective of wrapped legacy systems) are limited. Internationalization of textual data usually leads to rewriting sections of the original application. Here is a partial list of changes:

For suppliers built for the EMS, there are data types for all transmitted information, including constructed types for multi-byte and UCS character sets. While this does not eliminate the problems associated with unsupported character sets, it does provide reasonable semantics for failures due to this condition. Hence, sending textual data (for example, message inserts for file names) in its specific character set mapping may permit the consumer to see a message in part, even though specific inserts might not be viewable.


Any two implementations of the EMS API described in this specification will be interoperable. Consumers and suppliers would be capable of connecting to and operating with any conforming EMS. For implementations utilizing the same transport, for example, CORBA V2, the implementations are directly interoperable. For implementations utilizing different transports, they interoperate through a bi-directional gateway.

An Event Service maintains one or more repositories. The composition of these repositories is beyond the scope of this specification. The interfaces to these repositories is in the administrative domain.

Different Event Management Applications

Since event management applications are consumers receiving events via the registration APIs, standardizing these APIs, as well as the common event format, address this particular requirement.

In particular this means, that regardless of the implementation of the EMS, the event management application of choice can be used for further processing and presentation.

Different Event Protocols

This is probably the most important interoperability aspect. Basically it addresses the need to integrate:

As stated at the beginning of this section, gateways are used to provide interoperability across event service implementations. The EMS APIs are compatible at the source level. Suppliers and consumers built for different EMS implementations may be connected to a given EMS via adapters. The idea is to implement a protocol independent interoperability layer connecting the different worlds. See Managed Node .

Figure: Managed Node

The translator modules establish access to the different event worlds by translating the particular event format (for example, SNMP trap) into the common standardized format, and vice versa.

The protocol independent layer establishes the access to the event service, utilizing the standardized event creation and registration APIs. With that layer it's possible to centrally manage events from different protocols, and to communicate between different event service implementations (DCE vs. OMG).

Interoperability of EMS Implementations

The previous section alluded to a general model for interoperability EMS implementations. Specifically, there is a general requirement for bi-directional interoperability between implementations. Interoperability: Protocol Independent Channel depicts the desired situation with respect to interoperability, using a CORBA-based and a DCE-based implementation as a prototypical example. The solid lines depict components that are easily conceivable using existing technologies. The dashed lines depict the components that must be established using a solution to the interoperability problem described in this section.

Figure: Interoperability: Protocol Independent Channel

Interoperability: Protocol Independent Channel is undoubtedly a simplification of a complex problem that plagues the industry. But it provides a logical view of what is needed to solve interoperability. In general, some component is needed to translate events produced by a supplier using one transport to events that can be consumed by another transport event consumer, and vice versa. Such a component is purely logical, and may in fact be implemented using one to several processes.

As mentioned in the previous paragraph, the protocol independent event channel depicted in Interoperability: Protocol Independent Channel is purely logical, and several vastly different implementations are imaginable. Probably the simplest, although not necessarily the most efficient, implementation would be to start with an environment that supports both implementations. Then, a component could be implemented that is both a consumer and a supplier. This scenario is depicted in Interoperability: Dual Environment Channels .

Figure: Interoperability: Dual Environment Channels


An example using the intelligent agent serves to demonstrate use of many of the EMS methods. The idea is that a client (a consumer) sends an agent to a node to manage a resource. The client must be authorized to perform this function and an agent manager must be presumed to exist on the target node.

The process flow is then:

  1. connect with the agent factory

  2. set up the transfer of initialization information

  3. transfer the agent and applettes

  4. set up the supplier with the EMS

  5. set up the consumer with the EMS

  6. start the supplier

  7. send completion status to the consumer with a reference to the EMS conversation.

Initial Connection Flows

  1. Connect to the agent manager factory on the destination node. The factory needs to know the event recipient, quality of service, and the agent. The factory returns an object reference for the agent.

  2. The agent may consist of several applettes. The agent and each applette is shipped to the factory. The factory sets up the agent environment, insuring that it can be restarted in the event of a failure.

Setup the Supplier with the EMS
This work is performed by the factory.

  1. Use ems_register() to bind to the EMS.

  2. Use ems_event_type_add() to add the event type, the identity of the agent in this case.

  3. Use ems_mgmt_add_supplier() to add the agent.

  4. Use ems_mgmt_add_supplier_of_event() to connect the agent to the event type as a supplier.

  5. Use ems_unregister() to disconnect from the EMS.

Setup the Consumer with the EMS
This work is performed by the factory.

  1. Use ems_register() to bind to the EMS.

  2. Use ems_mgmt_add_consumer_of_event() to permit the consumer to receive events of the given type. This method should not fail, because the factory used the EMS to ensure that the consumer could utilize this facility.

  3. Use ems_filter_add() to indicate that the consumer is to receive all events from the agent.

  4. Use ems_unregister() to disconnect from the EMS.

Start the Supplier

  1. The factory for the intelligent agent has placed the agent and the applettes in a directory. In addition to the executables, the factory has placed state and context information in the directory.

  2. The factory activates the agent in the context of the directory it previously built. The agent executes with the security credentials and permissions of the consumer.

The Supplier

  1. The agent executes with the directory created by the factory as its current working directory.

  2. The agent does not know the difference between the initial invocation and an invocation after a failure, for example, power outage.

  3. Use ems_push_supplier_register() to bind to the EMS.

  4. For each event to be sent, use ems_supplier_send().

  5. Before terminating the agent, use ems_supplier_unregister() to remove the conversation with the EMS.

  6. Set the conversation state to completed. The conversation manager will remove the files and directory information.

  7. Conversation manager remove supplier.

Conversation Manager Remove Supplier
The conversation manager cleans up after the agent, removing it from the EMS.

  1. Use ems_register() to connect to the EMS.

  2. Use ems_mgmt_delete_supplier_of_event() to disassociate the agent from the event type.

  3. Use ems_mgmt_delete_supplier() to remove the agent from the EMS.

  4. Use ems_unregister() to disconnect from the EMS.

Conversation Manager Remove Conversation
The consumer normally asks the conversation manager to clean up the agent and perform associated housekeeping tasks when it no longer wishes the agent to exist at the given node. The steps it follows are:

  1. locate the directory for the agent

  2. conversation manager remove supplier

  3. conversation manager remove consumer

  4. conversation manager remove event type

  5. remove the agent directory and its contents.

Conversation Manager Remove Consumer
Here, the conversation manager is removing the association between the consumer and the event type.

Use ems_mgmt_delete_consumer_of_event() to remove the association between the consumer and the event type. This has the side-affect of removing all undelivered events of this type for this consumer.

Conversation Manager Remove Event Type
Here, the conversation manager is attempting to remove the event type. This method will fail when either there are undelivered events of this type, or the event type does not exist.

Use ems_event_type_delete() to remove the event type. ,HU "The Consumer" This section chronicles the flow of the consumer, when the event recipient is the consumer.

  1. Initial connection setup.

  2. Use ems_consumer_start() to connect or reconnect to the EMS. The library determines whether it is an initial connection or a reconnect based on the input argument. The library returns the object reference representing the conversation.

  3. Use ems_consumer_handler_register() to present a method to receive event notifications to the EMS library.

  4. Use ems_push_consumer_register() to set the EMS library notification mode.

  5. Use ems_consumer_stop() to disconnect the conversation. The conversation is effectively terminated by interrupting delivery of events to the consumer.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index