Many software applications are physically or logically split into separate components, or services, which communicate with each other via an inter-process communication (IPC) mechanism. For example, some components/services of a software application may act as server components that provide defined services to other software components. Software components that utilize the services of other software components may be referred to as client components.
In an IPC service, it is useful for one component to be able to send a message to another component without knowing its physical location. That is, the sending component should be able to reach a destination component using an address that is not tied to a specific physical location. In this manner, the sending component does not have to keep track of an address that may change when the destination component is moved. This feature becomes increasingly important in the currently evolving cloud based infrastructures.
It is also useful if a sending component can rely on a constant semantic meaning of an access key that can be used to reach a particular type of service. For example, it is useful for a sending component to be aware that “a destination that is reachable with key X always provides service Y”. This way, the key can safely be hard-coded into the sending component without risking that it will ever become obsolete. This type of key is referred to herein as a destination name, or simply a name.
When a constant semantic access key is used, a lookup step must be performed in the IPC system to obtain a physical address corresponding to the destination name. In the lookup process, a destination name is translated to a location-specific address that may be used during the subsequent message transmission. The lookup process can be done in a number of ways.
For example, a lookup can be performed in the data transmission phase each time a message is sent. In this approach, a lookup is done for each message by the transport service itself. The sending component uses a destination name as if it were an address. The actual address of the destination component is resolved by the transport mechanism at transfer time.
Another approach is for the sending component to perform a lookup for each destination component. For example, the lookup can be done explicitly by using a supporting library in each component at startup, or just before sending the first message to a particular destination. The library may keep a table (e.g., a cache) of destination names and their corresponding destination addresses. The table can be updated as destination addresses change. Alternately, the application code of the sending component may itself ask for the lookup done by a service, and store the resulting address for later use.
The transport address format that is to be used for a particular transmission depends on the selected transport protocol. For example, for UDP and TCP transmissions, the address will be IP addresses. For Unix Sockets, the address will be a Unix path. Other transport protocols and address formats are possible.
To do the address lookup or translation, a lookup key, such as a URL, an integer or set of integers, etc., may be provided by the client to a lookup or address resolution service.
The binding, or relationship, between the lookup keys and the server addresses must be maintained somewhere in the system, for example, in one or more tables in a database. The lookup table may be consulted by the client component during lookup, and the client component may cache the returned address values. There may be one single instance of this table, but also several replicated versions of it.
The management of a system for global name-to-address translation may present a number of problems. For example, such systems may suffer from a lack of flexibility, decreased efficiency, and/or large memory and/or bandwidth requirements.