There are a number of examples available that demonstrate how to use the OpenFusion CORBA services. A brief description of the following services is given below, along with links to their examples:
The OpenFusion Naming Service is an implementation of the OMG's Naming Service Specification. It provides a mechanism to associate meaningful names with an object. Clients can use the Naming Service to locate these objects by name within a CORBA environment. After a client has located an object its operations object can be invoked.
The Naming Service is provided with an optional Load Balancing mechanism which allows multiple names to be bound to the same object. The implementation is layered on top of the Java Naming and Directory Interface (JNDI). The OpenFusion JNDI Service Provider may be accessed independently of the Naming Service.
The OpenFusion Trading Service is an implementation of the OMG's Trading Service Specification. It is a sophisticated mechanism for locating server objects based on a description of requirements, rather than simple names. Objects register their services with the OpenFusion Trading Service, specifying a set of property values that describe the service they are offering. Clients can then use the OpenFusion Trading Service to locate an object that provides a required service based on these property values. The OpenFusion Trading Service matches the required service property values with those registered by the objects.
The OpenFusion Notification Service is an implementation of the OMG's Notification Service Specification and is an extension to the OMG's Event Service. The OpenFusion Notification Service is a powerful mechanism for asynchronous delivery of events from supplier objects to consumer objects. The service supports quality of service for event delivery and connection reliability. Event consumers can filter events based on a standard constraint language.
The OpenFusion Log Service is an implementation of the OMG's Telecom Log Service Specification. Log objects are consumers of events. Log objects store events that fulfil some constraint expression (a filter). The Log Service extends both the Event and Notification Services.
A log is an event channel (that is, log records are recorded by sending events to the log). Incoming log records are in turn filtered, written to a log store, and forwarded to interested log consumers. A log is therefore an object that supports log-and-forward functionality.
The Log Service supports easy management of logs in addition to the basic logging functionality. A log factory serves as a collection manager for log objects and generates log-generated events on behalf of all the log objects it is managing. The log-generated events include alarms when the log sizes increase certain threshold values, status changes, etc.