Functional Description of Name Service. More...
Functional Description of Name Service.
The OpenClovis Name service provides a mechanism that allows an object or a service to be referred by its name instead of the Object Reference (Object Reference). This friendly name is agnostic to the topology and location. The Object Reference can be the logical address, resource ID, and so on. Object Reference is opaque to Name Service. Name service returns the logical address when the friendly name is provided to it. Hence, Name Service provides location transparency. Name Service maintains a mapping table between objects and the Object Reference (logical address) associated with the object.
An object consists of an object name, an object type, and object attributes. The object names are strings and are meaningful when considered along with the object type. Examples of object names are print service, file service, functions, and so on. Examples of object types include services, nodes, or any other user-defined type. An object can have a number of attributes (limited by a configurable maximum number.) An object attribute consists of a
pair of strings. For example, <version, 2.5>, <status, active>, and so on.
The Name Service provides functions to register/de-register object names, types, attributes, and associated addresses. A process can register multiple services with a single address or multiple processes can register with a single service name and attributes. Some object names, attributes, and addresses can also be statically defined. Each registration is associated with the priority of the process providing the service. It is the responsibility of the process that registers an object, to remove the mapping when the object becomes invalid. However, a process can terminate abnormally. Name Service subscribes to notifications that can be received when a process dies from the Component Manager (CPM) and deletes the entries of the process in the database associated with the component.
The Name Service provides the ability to query the name database in various ways. Clients can provide the object name and object type to the Name Service and query it to retrieve the address and attributes of that object. Alternatively, clients can also provide attributes and query for object names that satisfy those attributes. Wild cards can also be used in the query. If two components provide the same service and have the same priority, the entry that is read first from the database is returned. Different components can provide different variants of a single service name with different attributes. For example, comp1 provides car wash (manual) and comp2 provides car wash (automatic). Manual and automatic are attributes of comp1 and comp2, respectively. If the query is specified as name = carwash and attribute = manual, comp1 is returned. If the attribute, manual, is not specified, the Object Reference of the component with the highest priority is returned.
Name Service supports different sets of name to Object Reference mappings (also called as Context of the mapping table). They are:
The Name Service to be registered can have two scopes:
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 global scope or 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. To support global and local scope, Name Service provides two types of Contexts:
The service provider decides the Context in which service entry needs to be registered. The service users must know the Context in which the service entry needs to be queried.
Name Service is used when the address of the service provider is dynamic. For example, if the service A is running on only one Node at a known port, the service users can use the physical address to contact service A, and Name Service is not required.
Name Service is used with Transparency Layer(TL) service provided by Intelligence Object Communication (IOC). Name Service contains Name to Object Reference Mapping and TL contains Object Reference to physical address mapping.
Name Service not only stores the name to logical address mapping but also stores any mapping between name and other Object References. For example, semname to semid, name to message queue ID, and so on.
The purpose of the Name Service is to provide location transparency. The service providers can register the mapping between services (exported by them) and Object Reference. To use the services of Name Service, the user application has to initialize the Name Service by invoking the clNameLibInitialize() function. When this service is not required, the association with Name Client can be closed by invoking the clNameLibFinalize() function. Service users can create their own Context or use the default Context. Service users can create their own Context using the clNameContextCreate() function. clNameContextCreate() returns a {{ContextId}} that can be used in clNameRegister() function to identify the Context. Users can register their services with their unique name using the clNameRegister() function. A service can be registered by multiple components. As part of {{clNameRegister()}}, the service provider can request Name Service to generate an Object Reference or they can set the Object Reference to a particular name. When the service provider fails, it can de-register the service using the clNameComponentDeregister() function.
Multiple components can register with a single name. The last component can de-register its service, using the clNameServiceDeregister() function. A service provider can delete a Context using the clNameContextDelete() function. The default Context cannot be deleted. Name Service deletes the default Context when the service shuts down gracefully.
Every Object Name is characterized by its name, attribute count, and a set of attributes. These attributes are specified when the service is registered through the {{ClNameSvcAttrEntryT}} structure.
The service users can query the Name Service for Object Reference using the clNameToObjectReferenceGet() function. The service users have to provide the following:
The service users can also query the entire mapping of service Name to Object Reference using the clNameToObjectMappingGet()function. This function returns all the matching records. clNameToObjectMappingGet() returns the following:
The mapping returned can be freed using the clNameObjectMappingCleanup() function.