PrismTech

The OpenFusion Naming Service is a leading implementation of the OMG CORBA Naming Service (NAM) standard.

• [+]Overview

  The OpenFusion Naming Service is a highly scalable and robust implementation of the CORBA Naming Service specification and provides a 'white pages' object directory. It supports the Interoperable Naming Service (INS) extensions to provide a URL-type naming scheme. The OpenFusion Naming Service also integrates with JNDI and LDAP directory services. Support is also provided for load balancing with customizable algorithms. The Naming Service can also be optimized via configurable caching policies. Naming hierarchies can also be imported and exported via XML.

  

  
  The architecture of the OpenFusion Naming Service is shown in the figure. The OpenFusion Naming Service also supports load balancing extensions which allow multiple objects to be bound to the same name in the naming hierarchy. A load balancing algorithm will determine which object reference is returned as a result of a lookup operation. The Naming Service will support a number of standard load balancing algorithms, including random, round-robin, active, and first-bound. The algorithm used is configurable via the service configuration tool. Custom load balancing algorithms can also be developed and configured using the same tool.

  The OpenFusion Naming Service can be administered via a GUI based management tool that is integrated into the OpenFusion Administration Manager. The tool allows users to define the location and configuration of a service. On startup, the configuration tool can be connected to any of the service instances and can 'read' the service configuration and status information, displaying it to the user.

  Two editions of the OpenFusion Naming Service are available enabling users to select the level of functionality that most closely matches the real requirement of their application. The following versions of the OpenFusion Naming Service are available:

  Standard Edition - this is our base version of the product, it is highly scalable and fully compliant with the OMG's COS Naming Service Specification.

  Advanced Edition - extends the Standard Naming Service Edition by providing support for advanced features such as load balancing.

• [+]Datasheet

  The fundamental, scalable Object Directory for distributed systems. A scalable object directory designed for enterprise systems. It provides support for JNDI and LDAP, allowing it to integrate existing disparate systems (CORBA and J2EE) and databases. It also supports service federation, clustering, and replication for scalability and availability.

  When to use the Naming Service

  System resources, at the most basic level in object-based systems, are identified by an object reference, which will not bear any relationship to the type of the resource (e.g. a bank account). The Naming Service allows useful, understandable names to be associated with resources, holding these in an easily navigable structure of related names and naming contexts. An application can therefore use the Naming Service to find a particular resource by a simple name, rather than via a complex object reference.

  In a banking application, the name given to a checking account object registered with the Naming Service might be the name of the account owner. The Naming Service will then allow a user to perform a query based on the account name, returning a reference to the matching Checking Account object. Administrators can add or remove references from the Naming Service, for example new accounts, new account owners (even new banks!) and so on, building up a very flexible and accurate model of the system.

  In telecoms, each underlying network element in a large-scale system will typically have a unique name related to the element type and physical location. By registering (binding) these names into the Naming Service, network management applications can then later query the Naming Service to get the appropriate reference to interrogate, for example, a faulty switch. The Naming Service provides an open, standardized naming repository which means that applications can discover objects without needing to know their physical location or underlying reference.

  The OpenFusion Advantage

  The OpenFusion Naming Service is a highly reliable, scalable, performant, flexible and interoperable implementation of the OMG's specification - the premier implementation available today. It helps users build and apply large-scale naming schemes.

  PrismTech's OpenFusion naming service is the ideal basis on which to build an open, standards-based object naming scheme - it is currently being used in large-scale, mission-critical applications in the telecoms, finance, travel and other sectors, giving our customers a firm basis upon which their systems can expand and adapt to future demands.

  Technical Features

  PrismTech's OpenFusion Naming Service is a full implementation of the latest OMG specifications, including the interoperable naming service extensions. Key system requirements such as reliability, scalability, flexibility and interoperability are built into the product by specific features such as naming federation, naming context persistence to relational databases and LDAP interfaces to the EJB™ world through JNDI, and multi-threading. In addition, the Naming Service benefits from OpenFusion's powerful plug-and-play architecture.

  Reliability

  • Automatic garbage collection of expired names
  • Configurable caching policies
  • Support for service replication over multiple databases
  • Automatic server failover mechanisms

  Scalability'

  • Naming federation over multiple hosts facilitates load balancing and performance tuning
  • Naming context persistence to LDAP and commercial databases via optimized stored procedures
  • Automatic service activation on demand
  • Set of standard and customizable load-balancing policies
  • Multi-threaded implementation

  Flexibility

  • Tools to export and load naming definitions to and from XML files aids service replication.
  • JMX / SNMP-based monitoring.
  • Dynamically update service configuration properties without the need to re-start service.
  • Secure access to service via pluggable authentication and authorization modules.
  • Powerful GUI-based management tools

  Interoperability

  • Interoperation and federation with other compliant Naming Services.
  • JNDI interface to allow EJBs to get references to CORBA objects and vice versa.
  • Multi-platform support - Unix and Windows NT, ORBs and application servers

  Benefiting from OpenFusion's Plug-and-Play Architecture

  OpenFusion’s unique strength comes from an innovative architecture that guarantees high flexibility through a plug-and-play layer and industrial strength through common scalability and performance-oriented functions.

  All key resources required by the OpenFusion Naming Service are accessed through generic "plug-in" sockets. This enables complete flexibility through the use of connectors provided with OpenFusion or customizations using open APIs.

  • Configurable qualities of service (QoS) for JMX / SNMP-based monitoring.
  • Powerful GUI-based management tools to connect and configure and administer object groups.
  • ORBs: JacORB 1.4, 2.1, 2.3; Borland VisiBroker 5.2, 6.1, 6.5; Iona Orbix 6.1
  • Databases: Oracle; Sybase
  • Operating Systems: Solaris 8, 9, 10; HP-UX 11i; Red Hat Enterprise Linux 4; Windows XP, 2003
  • JVMs: JDK 1.4, 1.5, 1.6
  • Other plug-ins provide access to leading system management , licensing, security and diagnostic products.
  • Open architecture for easy addition of new plug-ins to other products.

• [+]FAQs

  1. What is the Naming Service?

  The Naming Service is a simple mechanism to associate meaningful names with an object, and then use those names in a lookup facility. For example, in a Banking application, the name given to a Checking Account object registered with the Naming Service, might be the name of the account owner. The Naming Service will then allow a lookup based on the account name, returning a reference to the matching Checking Account object.

  2. Why should I use the Naming Service?

  One of the issues facing all CORBA developers is 'How do I find the objects within my system?'. The Naming Service is one of the preferred mechanisms of exposing objects for others to find. The Naming Service supports a hierarchical name space, similar to that used by file systems on Unix and Microsoft Windows operating systems. This allows you to create 'folders' (called naming contexts) that contain other 'folders' and objects. The Naming Service is often compared with the telephone white pages, in that objects register themselves by name so that other objects can locate them. Together with the Trading Service (which is comparable with the telephone yellow pages), these two services are the preferred ways to locate objects and bootstrap a distributed application. The Naming and Trading Services can be resolved in a standard way via the ORB runtime system i.e. using the resolve_initial_references( ) operation.

  3. What functionality is in the latest version of the Naming Service?

  Version 4.x of OpenFusion contains the following functionality:

  • Full implementation of the OMG's Naming Service specification, including naming trees, naming contexts, tree navigation, binding and name retrieval.
  • Full implementation of the OMG's Interoperable Naming Service (INS) specification.
  • Ability to reference naming data via the COSNaming or JNDI interfaces.
  • Configurable caching and purging policies.
  • Automatic garbage collection.
  • Service replication across multiple databases.
  • Deployment in clustered server environments for load balancing and failover. A number of default load balancing policies are included.
  • Highly performant and scalable multithreaded implementation.
  • Persistence of naming data to commercial databases.
  • Dynamic instrumentation of binding, unbinding and rebinding counts.

  In version 4.x the Naming Service has had improvements made to its reliability, availability and scalability.

  Additional configurable parameters have been made available to allow users to dynamically tune the caching and load balancing operations of the OpenFusion Naming Service. These are:

  • Read cache maximum / minimum size.
  • Load balance enable.
  • Load balance object activity check timeout.

  The load balancing API is also available so that users can configure their own load balancing algorithms. These parameters provide more flexibility allowing users to configure the Naming Service for maximum scalability and performance.

  Support for database connection pooling has also been added which allows database persistence schemes for the naming tree to be reliably and flexibility deployed.

  Support for JDBC 2.0 drivers in latest versions of databases (Oracle, Sybase, Informix,
  SQL Server) has been added to take advantage of new features in JDBC 2.0 such as
  two-phase commit.

  A number of additional features have been provided to significantly improve the performance of the Naming Service. These include:

  • Speed improvements with write cache.
  • Optimize get (implicit list into cache).
  • Improved multi-user access, more robust implementation.
  • Improvements to leaf creation algorithm data.

  The above work to significantly improve performance when navigating the naming tree, binding objects, and working with cached data.

  Support has also been added for the latest POA ORBS.

  4. How do you specify the names in the Naming Service?

  The Naming Service provides a straightforward mechanism to support name-to-object associations. The association between a name and an object is termed a name binding. Name bindings are, in turn, collected into sets called naming contexts. A naming context is set of name bindings where each name is unique within that context (although the same name may appear in other naming contexts). Each name binding refers to another naming context or to a CORBA object. Multiple names can be bound to the same naming context or object.

   

  

   

  The Naming Service allows users to create, modify and examine name bindings within a naming context. The service also supports operations to create new naming contexts as well as destroying them when they are no longer required. Finally, the Naming Service provides support for enumerating the contents of naming contexts.

  5. What is the difference between the Naming Service and the Trading Service?

  The Naming and Trading Services are very similar in the services that they provide. These two services are the preferred ways to locate objects and bootstrap a distributed application. However, they do offer different levels of service. The following table illustrates these differences:

   

  

   

  As the table shows, the services provide similar functions (i.e. locating objects), but they do it in very different ways.

  6. Where does the Naming Service store data persistently?

  The OpenFusion Naming Service is built on the OpenFusion Server Framework, which provides support for plug-in persistent storage modules. This allows the service to be configured to provide persistent storage in the way that you want it. For example, the Naming Service is supplied with two 'default' plug-ins; file and JDBC. The former saves the Naming Service data to a file (the data is serialized) and the latter uses JDBC to store the data into a relational database. However, other database plug-ins will be available, including ones for Oracle, Sybase, and Microsoft SQL Server databases.

  7. How do I configure the OpenFusion Naming Service?

  The OpenFusion Naming Service can be configured using the OpenFusion Administration Manager. This allows you to specify the persistence mechanism (file, JDBC, specific database type, etc.), diagnostic logging options, client location options, etc. The Administration Manager is an intuitive GUI-based tool, that provides a common configuration point for all of the OpenFusion J2EE and CORBA Services.

  8. What is LoadBalancing and why would I use it?

  Load Balancing allows multiple objects to be bound into the same name within a naming context. This is useful because you could bind a number of replicated CORBA servers into the same name. The Naming Service will return one of these CORBA services according to the LoadBalancing algorithm supplied by the user. This means that if a server is in use a lot the load can be shared between a number of different servers. The default algorithms supplied by OpenFusion are:

  • Random
    • RoundRobin
    • FirstBound
    • Random_Active
    • RoundRobin_Active
    • FirstBound_Active
    • Random_RemoveCurrent
    • FirstBound_RemoveCurrent
    • Random_Active_RemoveCurrent
    • The mechanism supports plugins thereby allowing users to write their own algorithms when the default algorithms are not sufficient.

  9. How do JNDI and the Naming Service interoperate?

  The OpenFusion Naming Service is layered on top of the Java™ Naming and Directory Interface (JNDI) JNDI is an API that provides naming and directory functionality to applications written in the Java™ programming language. The JNDI is defined to be independent of any specific directory service specification, so clients may access a variety of directory services in a common fashion.

  This picture shows the layering of JNDI with OpenFusion.

   

  The JNDI architecture consists of the JNDI Application and Programming interface (API) and the JNDI Service Provider (SPI). The JNDI API allows Java applications to access a variety of naming and directory services. The SPI allows arbitrary naming and directory service providers to allow their implementations to be accessed from the client Java™ application. These service providers map through the generic calls to the specific implementation e.g. to an LDAP server. OpenFusion has its own Service Provider that implements the javax.naming.Context interface. This allows basic operations such as adding a name-to-object binding, looking up names, removing bindings, creating and destroying subcontexts etc.

The OpenFusion Notification Service is a leading implementation of the OMG CORBA Notification Service (NOT) standard. 

• [+]Overview

  PrismTech's OpenFusion Notification Service is the world's most widely deployed implementation of the CORBA Notification Service. The Notification Service provides a sophisticated enhancement to the Event Service and provides guaranteed event delivery semantics and event filtering capabilities. OpenFusion Object Services are unique in that they connect to all leading Object Request Brokers (ORBs).

  

   The OpenFusion Notification Service is a powerful mechanism for sending event notifications between applications in distributed and heterogeneous systems.

  The OpenFusion Notification Service provides the ability to:

  • Transmit events in the form of a well-defined data structure.
  • Specify constraints on events through the filtering mechanism.
  • Produce and consume events on demand.
  • Configure wide range of quality of service properties at different levels of Notification Service Architecture.
  • Partition easily an event domain into logical groups that communicate using federated event channels.

• [+]Datasheet

  Powerful, event driven communications for distributed systems

  PrismTech's next-generation implementation of the Object Management Group's CORBA Notification Service, OpenFusion Notification Version 4 is a sophisticated event-driven messaging system supporting both guaranteed message delivery ('store-and-forward') and content-based routing.

  

  Version 4 offers dramatically increased message throughput and improved scalability over PrismTech's market-leading Version 3 release. Together with enhanced management facilities and a modular architecture, Version 4 provides great flexibility for systems designed to grow with business needs.

  When to use OpenFusion Notification

  Use OpenFusion Notification when you have to solve any of the following problems:

  • You want to exploit the flexibility of the message oriented paradigm in a standards-compliant way
  • Your applications must handle thousands of events per second between multiple suppliers and consumers
  • Your applications need guaranteed once and only once delivery of events
  • You need to route messages based on their content
  • You need sophisticated control of your messaging software
  • Your applications are deployed in diverse hardware and software environments.

  OpenFusion Notification can be used in a huge range of applications across all industry sectors. For example, in Telecoms, a common application of OpenFusion Notification is in network management. Alarms and other information produced by switches are sent as messages to alarm management applications and other interested users. Neither the switch manager nor the receiving applications have any direct connection to each other, so they can concentrate on their core tasks without worrying about alarm propagation, receipt nor confirmation. OpenFusion Notification takes care of message delivery and propagation - a fire-and-forget strategy.

  In Finance, when a stock feed application needs to connect individually to its client (who may not all even be on-line at any one time), real-time performance suffers and the activities of one client could have direct bearing on all the others. When OpenFusion Notification is used, this restriction is removed and performance is maximized.

  The OpenFusion Advantage

  OpenFusion Notification is the industry's most widely used implementation of the OMG's Notification Service Specification. Version 4 builds on the performance, scalability, reliability and flexibility of Version 3 to offer up to 20 times the throughput combined with superior scalability.

  PrismTech's OpenFusion Notification is the ideal basis on which to build an open, standards-based communication infrastructure. It is currently in use in large-scale, mission-critical applications in the defense, aerospace, telecoms, finance, and other sectors, giving PrismTech customers a firm base from which their systems can expand and adapt to meet future demands.

  Technical Features

  PrismTech's OpenFusion Notification Version 4 is an implementation of the OMG's Notification Service Specification Version 1.0.1. It supports the features most used by OpenFusion customers, including the following:

  • Full Implementation of Generic, Structured and Sequenced Events
  • Full Implementation of the Push model of Event Delivery
  • Event filtering using the Extended Trader Constraint Language
  • Customized filters in the Java™ language

  Version 4 supports many of the Qualities of Service defined by the OMG, including:

  • EventReliability (Best Effort and Persistent)
  • ConnectionReliability (Best Effort and Persistent)
  • Priority
  • Timeout
  • OrderPolicy (Anyorder, FifoOrder, PriorityOrder, DeadlineOrder)
  • DiscardPolicy (Anyorder, FifoOrder, PriorityOrder, Deadline Order, LifoOrder)
  • MaximumBatchSize
  • PacingInterval
  • MaxEventsPerConsumer
  • The AdminProperties MaxQueueLength and RejectNewEvents are supported.

  Based on customer feedback, PrismTech has incorporated a number of additional qualities of service, including:

  • MaxInactivityInterval
  • MaxMemoryUsage
  • MaxMemoryUsagePolicy
  • MaxReconnectAttempts
  • ReconnectInterval

  OpenFusion Notification supports channel federation and the Event Type Repository and provides both command line and GUI-based management tools.

  Benefiting from OpenFusion's Plug-and-Play Architecture

  OpenFusion's unique strength comes from an innovative architecture that guarantees high flexibility through a plug-and-play layer and industrial strength through common scalability and performance oriented functions.

  All key resources required by the OpenFusion Notification Service are accesses through generic "plug-in" sockets. This enables complete flexibility through the use of connectors provided with OpenFusion or customizations using open APIs.

  • Configurable qualities of service (QoS) for JMX / SNMP-based monitoring.
  • Powerful GUI-based management tools to connect and configure and administer object groups.
  • ORBs: JacORB 1.4, 2.1, 2.3; Borland VisiBroker 5.2, 6.1, 6.5; Iona Orbix 6.1
  • Databases: Oracle; Sybase
  • Operating Systems: Solaris 8, 9, 10; HP-UX 11i; Red Hat Enterprise Linux 4; Windows XP, 2003
  • JVMs: JDK 1.4, 1.5, 1.6
  • Other plug-ins provide access to leading system management , licensing, security and diagnostic products.
  • Open architecture for easy addition of new plug-ins to other products.

  Performance and Scalability

  In tests, OpenFusion Notification Version 4 has been shown to outperform other Notification Service implementations in many configurations. In terms of throughput and scalability, Version 4 offers performance that is many times greater than OpenFusion Notification Version 3 and is suitable for the most demanding applications.

• [+]FAQs

  1. What is the Notification Service?

  OpenFusion Notification is PrismTech's implementation of the OMG's Notification Service Specification, version 1.0.1.

  The OMG Notification Service is itself an extension of the earlier OMG Event Service which defined a mechanism the allows objects to communicate in a decoupled manner. The Event Service defines the notion of suppliers and consumers of events who are connected via a channel.

  The Notification Service extends the Event Service in a number of important ways:

  • It enables events to be transmitted in a well defined structure in addition to the generic and typed events supported by the Event Service.
  • It enables clients to specify exactly the events they are interested in by attaching filters to channels.
  • It defines a number of qualities of service that can be configured by clients to tailor the operation of the service.
  • It defines an optional event type repository which facilitates the formation of filter constraints by end-users.

  2. What is new in Version 4 of OpenFusion Notification?

  OpenFusion Notification V4 has been entirely re-architected with a new modular design to provide unique levels of throughput in a scaleable CORBA enterprise messaging solution. Throughput rates up to 20 times those achieved by Version 3 have been measured in benchmark tests. Further improvements in the scalability of the product have also been achieved through the highly efficient use of threads combined with optimised persistence mechanisms.

  The version 4 release of OpenFusion Notification Service implements the Object Management Group's Notification Service Specification, Version 1.0.1. The functionality provide includes:

  • Generic, Structured and Sequenced Events
  • The 'Push' Delivery Model
  • Event filtering using the Extended Trader Constraint Language
  • Notification Service Qualities of Service, including
    • Event reliability
    • Connection reliability
    • Priority
    • Timeout
    • Order Policy and Discard Policy
    • Maximum Batch Size
    • Maximum Events per Consumer
  • Admin Properties Max Queue Length and Reject New Events

  In addition, Version 4 supports a number of the PrismTech Additional Qualities of Service and the PrismTech GUI and command line management tools.

  3. When should I use OpenFusion Notification?

  Use OpenFusion Notification when you have to solve any of the following problems:

  • You want to exploit the flexibility of the message oriented paradigm in a standards-compliant way
  • Your applications must handle thousands of events per second between multiple suppliers and consumers
  • Your applications need guaranteed once and only once delivery of events
  • You need to route messages based on their content
  • You need sophisticated control of your messaging software
  • Your applications are deployed in diverse hardware and software environments.

  OpenFusion Notification can be used in a huge range of applications across all industry sectors. For example, in Telecoms, a common application of OpenFusion Notification is in network management. Alarms and other information produced by switches are sent as messages to alarm management applications and other interested users. Neither the switch manager nor the receiving applications have any direct connection to each other, so they can concentrate on their core tasks without worrying about alarm propagation, receipt or confirmation. OpenFusion Notification takes care of message delivery and propagation - a fire-and-forget strategy.

  In Finance, when a stock feed application needs to connect individually to its client (who may not all even be on-line at any one time), real-time performance suffers and the activities of one client could have direct bearing on all the others. When OpenFusion Notification is used, this restriction is removed and performance is maximized.

  4. What is the difference between the Notification Service and the Event Service?

  The OMG Notification Service is a powerful mechanism for sending event notifications between applications in a distributed and heterogeneous environment. The Notification Service is an extension and replacement of the original Event Service. It provides backward compatibility with the Event Service and maintains an architecture that allows easy partitioning of an event system into logical groups that communicate using federated event channels.

  The Notification Service overcomes a number of limitations with the Event Service. An important extension is the support for event filtering where both structured events and any type events can be filtered using a powerful generic constraint language. Although filters can apply to any part of an event, consumers will typically filter on the filterable body of structured events, which contains a sequence of name/value pairs.

  In order to constrain the implementations of the Notification Service specification, a large number of configurable QoS properties are supported. These can be divided into reliability, queue management, event management and event batch management. The Notification Service supports coarse or fine-grained QoS settings as different QoS properties can be applied all the way from the channel level down to individual events.

  The Notification Service also informs event suppliers and consumers about changes to the event types required or offered by a channel. The channel obtains information about the event types implicitly via filter objects or explicitly from the connected consumers and suppliers. Intelligent supplier and consumer can use this offer and subscription information to limit the amount of events. An optional part of the Notification Service specification is the event type repository. The repository contains event types and all the filterable properties required for each event type. The repository supports inheritance and import relationships between event types and all information in the repository can be queried and modified at run-time. The event type repository serves two distinct and important purposes. First of all, it is a powerful way of maintaining an evolving set of event types while a complex distributed system is being constructed. More importantly, for systems that evolve during their lifetime, the event repository is a mechanism for new event suppliers and consumers to add additional event types or obtain information about the properties of existing types.

  In conclusion, the Notification Service is a powerful event mechanism for distributed systems that directly supports important properties such as flexibility, scalability, and extensibility. With support for different communication models, event filtering, a wide range of QoS properties and the event type repository, the Notification Service covers a very wide range of distributed application requirements - and makes it an obvious candidate for the event notification component of distributed systems.

  5. What are the Quality of Service properties defined by the Notification Service?

  Configurable QoS properties are an important feature of the Notification Service. An implementation of the Notification Service is not required to support all the different QoS properties described in the specification, but an implementation that does will cover a wide range of application requirements. There are six categories of QoS properties:

  A. RELIABILITY

  The Notification Service supports two aspects of reliability:

  Event Reliability - Events can be delivered according to a best effort policy where no guarantees about delivery are made. Alternatively, guaranteed delivery is supported where events are be kept in a persistent store until they have been successfully delivered to all connected consumers.

  Connection Reliability - Connections to event suppliers and consumers can have a reliability of best effort when the Notification Service regards connections as transient and failure to deliver or receive an event will (perhaps after a few attempts to re-connect) result in disconnection. Alternatively, connections can be made persistent, when a supplier or consumer will not be disconnected until the target object no longer exists.

  B. QUEUE MANAGEMENT

  The Notification Service supports a number of QoS properties related to queue management. Queue management can be based either on the current number of events in a queue or the current memory usage of the machine on which the Notification Service is running.

  Maximum queue size - Rather than just leaving the problem of internal buffer overflow as an implementation detail, the Notification Service supports configuration of the maximum number of events that will be stored on behalf of consumers.

  Delivery Policy  - The delivery policy defines the order in which events are delivered to event consumers. The Notification Service supports a number of policies including FIFO, priority, and time out.

  Discard Policy - If an event queue is exhausted, discard policies such as FIFO, LIFO, priority and time out are supported. Also, the Notification Service can be configured to discard new events.

  MaxUnacknowledged - This affects DeliveryQueues. MaxUnacknowledged is the number of unacknowledged events after which event delivery to an attached listener should halt pending the next acknowledgment.

  MaxMemoryUsage - This setting is used on Event Channels. MaxMemoryUsage is similar in purpose to the property MaxQueueLength, except the size of memory is controlled rather than the number of events. MaxMemoryUsage takes a value of type ulonglong which represents the number of bytes after which attempts should be made to limit memory usage using the current usage policy, which in turn is controlled using the property MaxMemoryUsagePolicy.

  MaxMemoryUsagePolicy - This setting is used on Event Channels. MaxMemoryUsagePolicy is the policy by which memory usage is controlled when MaxMemoryUsage is exceeded. It can take one of three values:

  • PurgeEvents - if this value is set, then whenever an event is received that takes memory usage above MaxMemoryUsage then that event will be added to the internal queue of the appropriate event channel as normal. Then, in a manner that mirrors discard behavior, the event at the back of the queue will have its data purged from memory. If the event has best-effort delivery semantics then it is effectively discarded and all its used memory should be available for recovery by the garbage collector. However, in the case of a persistent event a placeholder will remain in memory so that the data can be reloaded from persistent store when required. Hence, in the case of a persistent event not all of the used memory is freed so total memory usage will continue to increase. The rate of increase will be greatly reduced however, making this an appropriate policy for dealing with bursts of event delivery.
  • DiscardEvents - if this value is set, whenever an event is received that takes memory usage above MaxMemoryUsage threshold, an event is discarded according to the current discard policy.
  • RejectEvents - if this value is set then whenever an event is received that takes memory usage above MaxMemoryUsage threshold, an org.omg.CORBA.IMP_LIMIT exception is thrown.

  C. EVENT MANAGEMENT

  A number of QoS properties related to event management can be set. As mentioned in the previous section, these QoS properties should be set in the variable header of a structured event:

  Start time - An absolute start time can be set for each event. An event will not be delivered to any consumer connected to an event channel until the start timer expires.

  Time out - A relative time out value for an event can be specified. Alternatively, an absolute stop time can be used. Events will be removed from any delivery queue when the stop timer expires. When events are delivered according to the time out policy, events with the shortest relative time out value will be delivered first.

  Priority - The priority of events can be specified. This QoS is used for queues with a priority delivery or discard policy.

  D. BATCH HANDLING

  In relation to sequence type consumers where events are delivered in batches, a few additional QoS properties are provided:

  Maximum batch size - The maximum number of events that a sequence type consumer wishes to receive at a time.

  Pacing interval - The maximum time a sequence type consumer will wait for events to be collected. If fewer events than the batch size are available when the pacing timer expires, the Notification Service just delivers whatever events are available.

  E. THREAD MANAGEMENT

  ThreadPolicy  - This QoS can be set at the channel level in order to specify the threading policy that should be used when the Notification Service is delivering events to push consumers. The OpenFusion® Notification Service supports two settings, namely ChannelThreadPool and ThreadPerProxy. The ChannelThreadPool policy uses a thread pool per event channel. This should be used for large numbers of consumers in order to limit the number of concurrent threads that are executing within the Notification Service. The ThreadPerProxy policy creates a single thread per push consumer. This will give good performance for small numbers of consumers. The default policy is ChannelThreadPool.

  ThreadPoolSize - This QoS determines the maximum thread pool size. Note that this QoS can only be used when the ThreadPolicy is set to ChannelThreadPool. This QoS property should be set when a large number of consumers are connected in order to limit the number of concurrent thread executing within the Notification Service. The default pool size is zero which means that one thread per proxy will be created.

  ThreadIdleTime - This QoS sets the maximum time that a thread will be idle before terminating. This setting should be used in systems where events are sent in bursts. Using this QoS will cause the Notification Service to be responsive at peak times (by dynamically allocating threads up to the ThreadPoolSize) but at the same time release memory resources at times when the event rate is very low. The unit for this QoS is 100 nanoseconds and the default value is zero, i.e. threads will never time out.

  As with filters, the QoS properties can be applied in the context of logical groups. As an example, the initial QoS properties of an event channel object will apply to all the administration objects that are subsequently created by the channel. However, fine-grained QoS is also supported, e.g. different delivery or discard policies can be specified for individual proxies.

  Notification Service vendors can have additional QoS properties as value added features of an implementation. An important property of the Notification Service is that this can be done without introducing incompatibilities. The QoS interfaces have operations for negotiating and obtaining the QoS settings supported by a particular implementation.

  F. BACKWARDS COMPATIBILITY

  Two QoS properties have been added to enable clients to behave as specified in earlier versions of the OMG Notification Service Specification:

  DisconnectCallback - This affects all proxies. If it is set to true (the default) then when a proxy's disconnect method is called, then the disconnect method on its connected client will also be called. If it is set to false, then a proxy's connected client will not have its disconnect operation invoked when that of the proxy is invoked.

  AlwaysPull - This affects EventChannels. If it is set to true (the default), then events will be pulled from connected pull suppliers regardless of whether any consumers are currently connected. If it is set to false then no events are pulled unless there is at least one push consumer attached, or at least one pull consumer that is currently attempting to pull an event.

  6. How do the Reliability QoS properties affect the event delivery?

  The Notification Service treats the reliability of specific events, and the reliability of the connections which provide a transport for events between clients of the notification channel and the channel itself, as separate issues, and therefore defines two separate QoS properties to represent them: EventReliability and ConnectionReliability.

  Each of these properties can take on one of two possible numeric constant values: BestEffort or Persistent. The meanings associated with the settings of these properties are inter-related, and are defined below.

  EventReliability=BestEffort & ConnectionReliability=BestEffort:

  No specific delivery guarantees are made. In the presence of failures, the event may or may not be received by each of the consumers, and a given consumer may receive the same event multiple times.

  EventReliability=BestEffort & ConnectionReliability=Persistent:

  The notification channel will maintain all information about its connected clients persistently, implying that connections will not be lost (logically) upon failure of the process within which the notification channel is executing. Any clients who connect to the channel using persistent object references may fail, but unless these object references raise an OBJECT_NOT_EXIST exception, the channel will continue to retry using them. Clients which then re-instantiate objects with these references will (logically) reconnect to their associated proxies. The channel will not, however, store any buffered events persistently. The implication of this combination is that upon restart from a failure of the notification channel server process, the channel will automatically re-establish connections to each of its clients, but will not attempt to retransmit any events that had been buffered at the time the failure occurred.

  EventReliability=Persistent & ConnectionReliability=BestEffort:

  This combination has no meaning and need not be supported by a conformant Notification Service implementation.

  EventReliability=Persisent & ConnectionReliability=Persistent:

  Each event is guaranteed to be delivered to all consumers registered to receive it at the time the event was delivered to the channel, within expiry limits. If the connection between the channel and a consumer is lost for any reason, the channel will persistently store any events destined for that consumer until either each event times out due to expiry limits, or the consumer once again becomes available and the channel is subsequently able to deliver the events to all registered consumers. In addition, upon restart from a failure the notification channel will automatically reestablish connections to all clients that were connected to it at the time the failure occurred.

  7. What is the Event Type Repository?

  The event type repository contains meta data about event types. For each event type, the repository will contain information about the properties of an event. Because the repository was specifically designed to fulfill the requirement of verifying filter constraints, the repository only contains information about the properties in the filterable body of a structured event. The diagram below shows the UML model for the event type repository.

   

   

   

  The repository is a singleton that supports a number of event domains and contains a number of event types. An event type in turn has a domain, a name and a number of properties. Event types can inherit or import the properties of other event types. The model in the diagram is mapped to IDL using the Meta Object Facility, i.e. the interfaces automatically have reflective capabilities.

  Event type inheritance means that all the properties in the super type will also be present in the sub type. It is not possible to create an inheritance relationship between two event types if a property name is defined in both event types. Event types can also be imported. This does not create an inheritance relationship but all the properties of the imported type will be present in the importer type. Property names may overlap but only if the type associated with the property is the same in both the imported and importer event types.

  An important property of the event type repository is the ability to modify the event types and the relationship between event types at run-time. This allows applications to evolve over time, e.g. an application can create a new event type with additional properties that inherits from an existing event type. New applications can take advantage of the additional information, while existing applications process the event according to the old set of properties.

  As the event type repository is populated, it will contain the properties that are expected for the event types used in a distributed application. It is possible for clients to look up event types and investigate what properties are available for filtering. Thus, event suppliers can find out what properties are expected in the events they produce and consumers can use the repository to create meaningful constraint expressions for event filtering.

  8. What are filters used for?

  Filters are a means to reduce the number of events received by a consumer to only those that are of interest. For example, if a consumer has connected to an event channel that is forwarding alarm events, the consumer will receive every event that is published to the event channel unless it uses a filter to remove the unwanted events. The filter contains a constraint, which must be evaluated to TRUE for the event to be forwarded to the consumer. In the example of alarm events, the filter could be 'severity > 4'. This would filter out all events that have a severity property of 4 or less, leaving only the most severe alarm event messages to be forwarded to the consumer.

  Filters rely upon properties in structured events for filtering. The format of a structured event is:

   

  

   

  You can also filter events by advertising subscription types. This is like a primitive filter that only applies to the domain name and type name in the fixed header of structured events.

  9. How do I specify a filter?

  Filters can be attached to either proxy objects or administration objects. There are proxy objects and administration objects for both event suppliers and event consumers.

  Filters can be attached to proxy consumers, proxy suppliers, supplier administration objects, and consumer administration objects. This provides a very flexible system for specifying filters for groups of consumers, or for individual consumers.

  A filter contains a constraint, specified in the Extended Trader Constraint Language. The constraint is evaluated every time an event is received by the object that the filter is attached to e.g. a consumer proxy object. If the constraint evaluates as TRUE, the event is forwarded to the next object in the delivery chain. If the constraint evaluates as FALSE, the event is not forwarded.

  More details of filtering and the constraint language can be found in the OpenFusion Developer's Guide.

  10. Can I specify my own filter processors?

  The OpenFusion implementation of the Notification Service allows you to implement your own specialized filter and mapping filter object that may, for instance, support a different constraint language. To provide a filter, you must provide an object that implements the Filter interface (or in case of the mapping filter, the MappingFilter interface). Because the functionality for managing constraints is generic, you may wish to extend the OpenFusion filter implementation and only re-implement the match operations. The OpenFusion filter implementation is located in a Java™ class called com.prismt.cos.CosNotification.FilterImpl.

The OpenFusion Log Service is a leading implementation of the OMG CORBA Log Service (TLOG) standard.

• [+]Overview

  The OpenFusion Log Service is the premier implementation of the OMG specification for Logging in a CORBA system. Based on the 'tried and tested' OpenFusion Notification Service, it is not only highly reliable and performant, it is also extremely flexible and provides essential system manageability and control functionality. As a log object is also a Notification Service event channel, log records can be filtered before they are forwarded to log consumers. This mechanism allows the application generated log messages to be 'content-routed' to consumers.

   

  

   

  The OpenFusion Log Service also supports X.735, which is a CCITT recommendation for a log control function. It also includes a number of important extensions providing extra levels of performance and interoperation with other systems, such as a structured log - which dramatically improves log store query times.

  Included in the features supported by OpenFusion Log Service are:

  • Persistent log records
  • Data dissemination through log forwarding
  • Log record filtering
  • Support for QoS associated with the Notification Service.
  • Plug-and-play architecture.

• [+]Datasheet

  A robust, performant, and flexible Logging Service for sophisticated, distributed CORBA Systems. A distributed "log-and-forward" capability. It records events of interest in a log file (or database) and then sends the event notification to all interested parties (e. g. a System Administrator ). The Log Service can also be used to provide an audit trail within a system, recording all activity that takes place.

  When to use the Log Service

  Logging is a well-known but fairly undefined and broad computing concept. The functionality of logging software ranges from simple data acquisition to suites that support instrumentation, collection, interpretation and presentation of data. While simple log systems can be very generic and support a wide range of applications, complex log systems (or monitoring systems) are typically very domain specific.

  Logging is used in control and telecommunications to supervise system components. These systems are inherently distributed with components spread across a plant or located in inaccessible or remote areas. While distribution provides features such as fault tolerance and improved performance, the potential error situations are more frequent and complicated. Logging is therefore an integrated part of system operation.

  Application developers use logging while building software systems to generate low-level traces and messages that contain detailed information about program execution. This information is typically used for debugging but in order to facilitate system maintenance, logging of this kind of information will continue as the software system is deployed in order to be able to analyze failures.

  Although log systems can be very diverse, the collection part of log systems is typically generic. Collection can be divided into three separate tasks. First, data must be acquired from components. This step requires that components have been properly instrumented and a transport facility is available. Second, data is filtered to reduce the amount of information. Finally, data is disseminated to interested parties.

  The OpenFusion Advantage

  The OpenFusion Log Service is a highly reliable, scalable, performant, flexible implementation of the latest OMG specification. The Log Service also supports X.735, which is a CCITT recommendation for a log control function. It also includes a number of important extensions providing extra levels of performance and interoperation with other systems, such as a structured log - which dramatically improves log store query times.

  PrismTech's OpenFusion Log Service is a premier implementation of the OMG specification for logging in a CORBA system. Based on the 'tried and tested' OpenFusion Notification Service, it is not only highly reliable and performant, it is also extremely flexible and provides essential system manageability and control functionality.

  Technical Features

  PrismTech's OpenFusion Log Service is the premier implementation of the latest OMG specification, including log record acquisition, log record storage, data dissemination (log forwarding), and management and querying tools. Because the Log Service is based on the OpenFusion Notification Service, it supports the log record filtering and all qualities of service (QoS) associated with the CORBA Notification Service. In addition, the Log Service benefits from OpenFusion's powerful plug-and-play architecture.

  Log Types Supported

  • Basic - event unaware i.e., saves the log record information to the log store, log forwarding is not supported.
  • Notification - stores the log record information to the log store, log records are forwarded to any interested consumer.

  Scalability

  • Log channel federation over multiple hosts - facilitates load balancing and performance tuning.
  • Log record storage to commercial databases via optimized, stored procedures.
  • Structured log records to increase log store query performance.
  • Clustering to support load balancing and fail over.
  • Transactional log records which help ensure business integrity.

  Flexibility

  • Publish-subscribe (multicast) log record dissemination - log records can be sent to a number of interested consumers.
  • Content-based log record routing via a flexible filtering mechanism - using the standard Notification Service filter language, SQL92, or custom in-process filters.
  • Secure access to service via pluggable authentication and authorization modules.
  • Powerful GUI-based management tools to configure log store administrative settings and QoS

  Interoperability

  • Interfaces to the OpenFusion CORBA Notification Service
  • Multi - platform support - Unix, Windows NT and application servers

  Benefiting from OpenFusion's Plug-and-Play Architecture

  OpenFusion's unique strength comes from an innovative architecture that guarantees high flexibility through a plug-and-play layer and industrial strength through common scalability and performance-oriented functions.

  All key resources required by the OpenFusion Log Service are accessed through generic "plug-in" sockets. This enables complete flexibility through the use of connectors provided with OpenFusion or customization using open APIs.

  • Configurable qualities of service (QoS) for JMX / SNMP-based monitoring.
  • Powerful GUI-based management tools to connect and configure and administer object groups.
  • ORBs: JacORB 1.4, 2.1, 2.3; Borland VisiBroker 5.2, 6.1, 6.5; Iona Orbix 6.1
  • Databases: Oracle; Sybase
  • Operating Systems: Solaris 8, 9, 10; HP-UX 11i; Red Hat Enterprise Linux 4; Windows
  • JVMs: JDK 1.4, 1.5, 1.6
  • Other plug-ins provide access to leading system management , licensing, security and diagnostic products.
  • Open architecture for easy addition of new plug-ins to other products.

• [+]FAQs

  1. What is the Log Service?

  The Log Service is a generic service that can be used to record, filter and disseminate logging information in any CORBA system. This is an important facility for fault-tolerant distributed systems as logging is used to generate low level traces and messages that contain detailed information about program execution. This information can be used for debugging but as the software is deployed the Log Service can be used as an aid to system maintenance.

  The OpenFusion Log Service is built on the Notification Service model to disseminate log records whilst adding administration, query and management functionality. Log records can be sent to interested consumers but are also stored using a wide range of persistence mechanisms. Each log record contains a unique record identifier, a time stamp and data of type any.

  2. What specification does the Log Service use and where can I obtain it?

  The Log Service is a domain service that has been submitted to the OMG by the Telecom Task Force. A copy can be obtained from the OMG website at:
  http://www.omg.org/technology/documents/formal/telecom_log_service.htm

  3. What are the types of Log that can be created?

  Suppliers deliver log records to interested consumers. A log will store received log messages before sending them to all connected consumers. There are five different log types.

  Basic Log - which is used by clients which are unaware of events. The client needs to interact directly with the persistent log record storage to obtain the information from the log. A basic log supports operations for setting and getting log attributes as well as writing, querying and deleting log records.

  Event Log - This includes all the functionality of the Basic Log but also enables clients to create log records by sending events. Log records are put in the persistent store before being forwarded to clients.

  Typed Notification Logs -This has the same functionality as the Notification log but allows the events that can be sent to be user defined.

  Notification Logs - The Notification Log includes all the functionality of the Event Log. It has a number of additional features including support for an elaborate QoS framework, support for event filtering and the sharing of offered and subscribed event types.

  Typed Notification Logs - This has the same functionality as the NotificationLog but allows the events that are sent to be user defined.

  4. What are the different states that are supported by a Log?

  A log supports the concept of operational and administrative states. The operational state can be either enabled or disabled. A log is disabled when the maximum size of the persistent log record storage has been exhausted. The administrative state can be set to either locked or unlocked by a client. A log will not write any more records when it is disabled or locked.

  The event and notification style log also supports a forwarding state. The forwarding state can be either on or off. If the state is off the log will not forward events. The operational and administrative states have no effect on event forwarding.

  The availability status determines whether or not the log is full and available. A log is available when the administrative state is unlocked, the current time falls within the scheduling times and the operational state is enabled. A client can set the maximum size of the log record storage. The "log full" action can be specified to either wrap or halt. If the log is set to wrap the log will never become full since old records are deleted to make space for new ones. If set to halt the log will change its availability status to "log full" when the persistent storage is exhausted.

  Clients can further define any number of capacity alarm thresholds. These values instruct the log to emit an alarm when the size of the persistent log record storage crosses a certain threshold. The log service also supports log record lifetime allowing a client to set a timeout value after which the log can be deleted automatically.

  The Log Service also allows clients to configure the times at which the log is active. These times can be specified using a start and stop time or by using week-masks to define which days and which hours of these days the log is active. A log will not write records to the persistent store unless it is active.

  5. What are the different operations that can be done on the Logs?

  A log factory supports creation of log objects. There is a log factory for each of the five different log types. A factory is also a collection manager for log objects and clients can retrieve all log objects created by a factory.

  Finally, the event and notification style log factory "is a" consumer administration objects, i.e. the factory behaves like the consumer side of an event channel. The log factory will emit certain log-generated events on behalf of all the log objects created by the factory object in question. The log service defines the following log-generated events:

  • Object creation and deletion: These events are emitted when a new log object is created or when a log object is destroyed.
  • Capacity alarm threshold: This event is generated when the size of the persistent log record storage crosses one of the capacity threshold values defined for the log.
  • Log attribute value change: Emitted when a log attribute changes value. The log attributes include log full action, maximum log record size, scheduling times, the log filter or threshold values.
  • Log state change: Emitted when the administrative, operational or forwarding state changes.

  The basic log factory is event unaware in a similar manner to the basic log and log-generated events will not be emitted from this type of factory. The notification style factory supports the consumer administration interface from the notification service and clients can thus filter on log-generated events using the extended trader constraint language.

The OpenFusion Trading Service is a leading implementation of the OMG CORBA Trading Service (TRADE) standard. 

• [+]Overview

  The OpenFusion Trading Service is a full service implementation of the CORBA Trading Service specification. The Trading Service provides a sophisticated 'yellow pages' style object directory that supports complex look up queries.

  

   The service can be federated for scalability and availability. Service types and offers can also be imported and exported via XML. The architecture of the OpenFusion Trading Service is shown above. The OpenFusion Trading Service can be administered via a GUI based management tool that is integrated into the OpenFusion Administration Manager. The tool allows users to define the location and configuration of a service. On startup, the configuration tool can be connected to any of the service instances and can 'read' the service configuration and status information, displaying it to the user.

• [+]Datasheet

  A highly flexible method of registering and finding resources in distributed systems. A flexible mechanism for locating resources based on a description of requirements rather than by simple name matching. The resources are located by queries on the Trading Service, with support for complex queries. The Trading Service also provides a dynamic, load balancing mechanism that is essential for large systems.

  When to use the Trading Service

  In large-scale object-based systems, an application may not know the reference to a particular system resource, such as one unique printer. However, it may know the required type and condition of any available resource (e.g. any color printer with less than three print jobs in the queue) it needs to carry out a job. Using the Trading Service, the application can submit a query of arbitrary complexity, and the Trading Service will match this with available resources and return an appropriate reference. The application can then invoke the required operations on the resource. Often, when system resources are routinely added or removed, the Trading Service is the only efficient means by which applications can easily access the full, current range of resources across the system.

  In e-commerce applications, a fundamental workflow involves clients querying a remote system to find the services (such as pricing models, databases, ticket availability, etc.) they require. The clients certainly don't know the direct object references within the system, but they do know what sort of service they want. The Trading Service is a natural way of facilitating this interaction. The e-commerce vendor registers and de-registers services with the Trading Service on an ongoing basis as products or features are added or revised. Customers can then submit queries via the Trading Service to find the exact product or information they require.

  In finance, a huge number of different algorithms for risk assessment of an impending transaction may be available across the system. The dealer can submit a query to the Trading Service to find and invoke the particular type of risk application required for the deal at hand, without needing to know where the application is physically located on the network.

  The OpenFusion Advantage

  The OpenFusion Trading Service is a full service, highly reliable, scalable, performant, flexible and interoperable implementation of the OMG's specification - the premier implementation available today. It helps users build and apply truly flexible schemes to dynamically manage system resources.

  PrismTech's OpenFusion Trading Service is the ideal basis on which to build an open, standards-based resource management infrastructure - it is currently being used in large-scale, mission-critical applications in the Telecoms, Finance, Travel and other sectors, giving our customers a firm basis upon which their systems can expand and adapt to future demands.

  Technical Features

  PrismTech's OpenFusion Trading Service is a full service implementation of the latest OMG® specification, including support for all five interfaces, and a full service type loader and repository. Key system requirements such as reliability, scalability, flexibility and interoperability is built into the product by specific features such as trader federation, service type persistence to relational databases, and multi-threading. In addition, the Trading Service benefits from OpenFusion's powerful plug-and-play architecture.

  Reliability

  • Automatic garbage collection of expired service offers
  • Automatic server failover mechanisms

  Scalability

  • Trader federation over multiple hosts - facilitates load balancing and performance tuning
  • Service type persistence to commercial databases via optimized stored procedures
  • Automatic service activation on demand
  • Multi-threaded implementation

  Flexibility

  • Full service type loader and repository support provided.
  • Tools to export and load service type definitions to and from XML files - aids service replication.
  • Complex service querying using a powerful constraint grammar.
  • Support for user-configured service type plugins to obtain optimum performance for queries on a particular service type.
  • JMX / SNMP-based monitoring.
  • Dynamically update service configuration properties without the need to re-start service.
  • Secure access to service via pluggable authentication and authorization modules.
  • Powerful GUI-based management tools.

  Interoperability

  • Interoperation and federation with other compliant Trading Services.
  • Ability to invoke Trading Service as an EJB entity bean.
  • Multi-platform support - Unix and Windows NT, ORBs and application servers.

  Benefiting from OpenFusion's Plug-and-Play Architecture

  OpenFusion's unique strength comes from an innovative architecture that guarantees high flexibility through a plug-and-play layer and industrial strength through common scalability and performance-oriented functions. All key resources required by the OpenFusion Trading Service are accessed through generic "plug-in" sockets. This enables complete flexibility through the use of connectors provided with OpenFusion or customizations using open APIs.

  • Configurable qualities of service (QoS) for JMX / SNMP-based monitoring.
  • Powerful GUI-based management tools to connect and configure and administer object groups.
  • ORBs: JacORB 1.4, 2.1, 2.3; Borland VisiBroker 5.2, 6.1, 6.5; Iona Orbix 6.1
  • Databases: Oracle; Sybase
  • Operating Systems: Solaris 8, 9, 10; HP-UX 11i; Red Hat Enterprise Linux 4; Windows XP, 2003
  • JVMs: JDK 1.4, 1.5
  • Other plug-ins provide access to leading system management , licensing, security and diagnostic products.
  • Open architecture for easy addition of new plug-ins to other products.

• [+]FAQs

  1. What is the Trading Service?

  The Trading Service is a sophisticated mechanism for locating server objects based on a description of requirements, rather than simple names. Objects register their services with the Trading Service, specifying a set of property values that describe the service that they are offering. Other objects can use the Trading Service to locate a server that provides a required service, based on these property values. The Trading Service matches the required service property values with those supplied by the servers when they registered.

  2. Why should I use the Trading Service?

  We often locate resources by searching for them not by their name, but by searching for a resource that can provide a particular service to us. For example, we look for a builder who can repair the roof, or for a printer that can print a document in color, or for a telephone service provider with cheap long distance calls. Rather than searching through the telephone white pages until we happen upon a building firm we recognize, we reach for the yellow pages and call on a business listed in the Building section. The Trading Service is similar to the yellow pages; it allows objects that can provide a service to register their abilities and it then allows clients to locate those services by describing the functionality they require. From then on, the client deals directly with the service provider object.

  While the Naming Service provides a simple mechanism to locate objects ('services') by a name, this can quickly become unmanageable. For example, consider a system that manages printer queues. We can partition the printers into postscript and non-postscript printers. This is easy to model in a hierarchical manner using the Naming Service. However, if we also want to categorize printers by other capabilities, e.g. color or black and white printing, this becomes more complex. If you then add further categories, such as ink jet or laser printers, the hierarchical model very quickly becomes too complex to manage. Imagine the hierarchy levels that would be needed to categorize printers with varying throughput speed (in pages per minute) this can range from 1 to more than 16 pages per minute! Using the Trading Service, we would define a service type of 'printer' and specify properties that will allow us to categorize the different printers e.g.

  service printer
  {
  interface IDL:PrinterQueue:1.0;
  mandatory property boolean postscript;
  mandatory property short ppm; // Pages per minute
  readonly property Boolean colour;
  readonly property Boolean laser;
  };

  This allows any Trading Service user to query for a printer service based on the printer properties e.g. 'postscript == TRUE and PPM> 6'. You can also specify the order in which the matching service offers are returned. For the above example, you may want the printer service offerings listed by their throughput speed (PPM). You would specify this ordering as 'max PPM in the query return order criteria. Therefore, the Trading Service offers an object location facility that is more sophisticated than that offered by the Naming Service. The ability to search for objects on multiple criteria and to control the order of the returned matches greatly increases the flexibility and usability of the Trading Service.

  3. What is the latest version of the Trading Service?

  Version 4.x of OpenFusion contained the following functionality

  • Full implementation of mandatory and optional parts of the OMG's Trading Service specification, including all interfaces (full-service trader),complete trader constraint language, and service type repository.
  • Configurable caching and purging policies.
  • Automatic garbage collection.
  • Service replication across multiple databases.
  • Deployment in clustered server environments for load balancing and failover. A number of default load balancing policies are included.
  • Highly performant and scalable multithreaded implementation.
  • Persistence of service type and offer data to commercial databases.
  • Dynamic instrumentation of service type and offer counts.

  Version 4.x contains additional configurable parameters to allow users to dynamically tune the dynamic operations of the OpenFusion Trading Service providing more options for reliability and scalability.

  Support for database connection pooling has been added allowing database persistence schemes for the service offers to be reliably and flexibly deployed.

  Support for JDBC 2.0 drivers in latest versions of databases (Oracle, Sybase, Informix, SQL Server) has also been added to take advantage of new features in JDBC 2.0 such as two-phase commit.

  A number of additional features are provided to significantly improve the performance of the OpenFusion Trading Service, these include:

  • Speed improvements with write cache.
  • Improved multi-user access, more robust implementation.
  • Improved offer search algorithm.
  • Optimization of persistence mechanisms
  • Which significantly improves performance when writing and retrieving offers.
  • Support for latest POA ORBs
  • OpenFusion 4.x allows interoperability and federation of the CORBA Trading Service across VisiBroker, Orbix and Orbacus platforms.
  • Ability to output diagnostics information via HTTP.
  • A new GUI tool for configuration and management is provided.

  4. What is the difference between the Naming Service and the Trading Service?

  The Naming and Trading Services are very similar in the services that they provide. These two services are the preferred ways to locate objects and bootstrap a distributed application. However, they do offer different levels of service. The following table illustrates these differences:

   

  

   

  As the table shows, the services provide similar functions (i.e. locating objects), but they do it in very different ways.

  5. What are the different types of Traders?

  The OMG's CORBA Object Trading Service specification defines six different types of traders, depending upon the functionality that they support. The Trading Service specification defines five functional interfaces for a trader:

  • Lookup allows clients to query the trader for offers
  • Register allows services to be 'exported' (advertised) to the trader.
  • Admin allows the trader property to be configured.
  • Link supports the linking (federation) of traders.
  • Proxy supports the delayed evaluation of offers and can be used to encapsulate legacy systems.
  • The types of traders are determined by the interfaces that they support i.e.

  

  The OpenFusion Trading Service implementation supports all five functional interfaces and is, therefore, a full-service trader.

  6. How do I link Traders?

  The operations on the Link interface allow traders to be linked together, so that a trader can make the offer spaces of other Trading Services available to its own clients. A link describes the knowledge that the trader has of the target trader. To link to a target trader, we must have a reference to the Lookup interface of the target and we will need to give the target trader a name. The link operation can also define policies for 'link following' i.e. when, and to what extent, the link should be followed in the resolution of a query e.g.

  link.add_link( "Link to remote trader 2",
  remote_2,
  org.omg.CosTrading.FollowOption.if_no_local,
  org.omg.CosTrading.FollowOption.always
  );

  In this example, we have named the link as "Link to remote trader 2" and remote_2 is a reference to the Lookup interface on the remote trader. We have also set the 'link following' policy as: if_no_local. which means follow the link to the remote trader, if no local matches are found, always which means a client may override the default setting (above) to always follow the link. More details on linking traders can be found in the OpenFusion Developer's Guide.

  7. What is the Service Type Repository?

  The Service Type Repository is a centralized location for storing service type details. Service types can be added, modified, and deleted from the repository. The repository allows service types to be preloaded into a trader, so that the service definitions are ready for service providers (exporters) and clients (importers). The OpenFusion Trading Service implementation supports a Service Type Repository and provides utility tools to load service type descriptions from a text file. The service type descriptions can also be extracted from the repository and written to a text file. A single Service Type Repository can be shared by many traders.

  8. How do I administer a Trading Service?

  The Trading Service specification defines an Admin interface, which provides operations for configuring the service. These operations can be accessed programmatically or, for ease of use, they can be controlled via a GUI-based administration tool. The tool (called the Trader Manager) can be launched from the OpenFusion Administration Manager. It provides a intuitive user interface for configuring and managing a trader, and allows navigation to linked traders so that they can be managed in the same manner.

  9. How well does the Trading Service perform?

  The OpenFusion Trading Service has been proven to by far the most performant implementation available. OpenFusion 4.x has raised the bar further with significantly increased performance in all , and in some cases orders of areas and an order of magnitude improvement in performance over previous versions.