A DEEP DIVE INTO OPENCLOVIS NAME SERVICE

Introduction

The Name Service is a vital component of the OpenClovis Communication Infrastructure. It allows an object to be referred to by its “friendly” name rather than its “object(service) reference”. This abstraction provides location transparency, simplifies service discovery, and enhances system scalability and reliability. This article will explore the features, architecture, and operational details of the Name Service.


What is the Name Service?

The Name Service maintains a mapping between objects and the object reference (logical address) associated with the object. Each object consists of an object name, an object type, and other object attributes. The object names are typically strings and are only meaningful when considered along with the object type.


Key Terminology

  • Object: consists of an object name, an object type, and other object attributes.
  • Object Reference: can be the logical address, resource ID, and so on. Object Reference is opaque.
  • Service Name: is a “friendly” name that is topology and location agnostic.
  • Attributes: Additional metadata associated with an object that is limited by a configurable maximum number. An object attribute is itself a <attribute type, attribute value> pair, each of which is a string.


Features of the Name Service

  • The name service maps “service names” to attributes, including addresses
  • Service Providers register their “service name”, “address” and attributes with the Name Service
  • Service Users query the Name Service to get information about a service
  • Service users can communicate with service providers without knowing their logical address or physical location
  • Multiple service providers can register the same name. The name service maintains a reference count for each “name” registered
  • The name service subscribes to component failure notifications from AMF. If a component dies, the reference count for the services it has registered is decremented.
  • Supports context-based naming to allow partitioning of the namespace:
    • Local namespaces are local to the Name Server on a SAFplus Platform node
    • Global Name Spaces are global to the SAFplus Platform cluster
    • Namespaces are dynamically created at run-time
  • Supports three types of queries:
    • Query-based on “Service Name”: Given a service name returns the address and service attributes
    • Query-based on “Service attributes”: Given service attributes, return the Service Name and address
    • Query-based on “namespace context”: Given a namespace context, return all names in that space


Architecture of the Name Service

Based on the responsibilities, the Name Service component can be further subdivided into the following modules:

  • Core Module:Responsible for supporting the creation and deletion of user-defined contexts and processing the requests for registration, and deregistration. Also responsible for supporting the various Name Service-related queries
  • Life cycle Management Module:Responsible for initialization, finalization, restart, and other management functionalities
  • Sync up Manager Module:Responsible for NS DB synchronization and backing up of DB in persistent memory


Context

Name Service supports different sets of name to Object Reference mappings (also called the Context of the mapping table). They are:

  • User-defined set:Applications can choose to be a part of a specific set (or Context). This requires for the Context to be created.
  • Default set:Name Service supports a default Context for services that are not part of a specific Context.


Scope

The Name Service to be registered can have two scopes:

  • Nodelocal scope: The scope is local to the node. The service provider and the user should co-exist on the same blade.
  • Global or cluster-wide scope: The service is available to the user applications running on any of the blades. Any component residing anywhere in the cluster can access it. When a component registers with Name Service, it has to provide the Context and the scope of its service.


Usage Model

Name Service is based on the database model. Service providers can register their service name to Object Reference mapping with Name Service. This registration can be performed for all the services provided by the service provider. The service users query the Name Service for the Object Reference of the service providers. When a service is unavailable, the service provider de-registers the entry with Name Service. When a service provider dies ungracefully, all the services provided by it are de-registered. A service can be registered with the global scope or the local scope. If it is registered with global scope, the service is available to any service user within the cluster. If the scope is local, the access to the services is limited to the Node.


Conclusion

The Name Service in OpenClovis is an essential component that enhances the flexibility and usability of distributed systems. By providing a mechanism for friendly naming and dynamic registration, it simplifies service discovery and communication across components.