You can install more than one component for a given service. This allows components to provide only partial implementations of the service, and to rely on other components to provide the remaining functions.
Suppose you create a new name service component called XYZ_name_serv. This component supports looking up a queue name, but does not support inserting a name in, or deleting a name from, the service directory.
The component uses a simple algorithm that returns a fixed queue-manager name for any queue name with which it is invoked. It does not hold a database of queue names, and therefore does not support the insert and delete functions.
The component is installed on the same queue manager as the WebSphere MQ DCE-based name services component. The ServiceComponent stanzas are ordered so that the DCE-based component is invoked first. Any calls to insert or delete a queue in a component directory are handled by the DCE-based component; it is the only one that implements these functions. However, a lookup call that the DCE-based component cannot resolve is passed on to the lookup-only component, XYZ_name_serv. This component supplies a queue-manager name from its simple algorithm.
If you decide to use multiple components to provide a service, you can design a service component that does not implement certain functions. The installable services framework places no restrictions on which you can omit. However, for specific installable services, omission of one or more functions might be logically inconsistent with the purpose of the service.
Table 22 shows an example of the installable name service for which the two components have been installed. Each supports a different set of functions associated with this particular installable service. For insert function, the ABC component entry-point is invoked first. Entry points that have not been defined to the service (using MQZEP) are assumed to be NULL. An entry-point for initialization is provided in the table, but this is not required because initialization is carried out by the main entry-point of the component.
When the queue manager has to use an installable service, it uses the
entry-points defined for that service (the columns in Table 22). Taking each component in turn, the queue manager
determines the address of the routine that implements the required
function. It then calls the routine, if it exists. If the
operation is successful, any results and status information are used by the
queue manager.
Table 22. Example of entry-points for an installable service
| Function number | ABC name service component | XYZ name service component |
|---|---|---|
| MQZID_INIT_NAME (Initialize) | ABC_initialize() | XYZ_initialize() |
| MQZID_TERM_NAME (Terminate) | ABC_terminate() | XYZ_terminate() |
| MQZID_INSERT_NAME (Insert) | ABC_Insert() | NULL |
| MQZID_DELETE_NAME (Delete) | ABC_Delete() | NULL |
| MQZID_LOOKUP_NAME (Lookup) | NULL | XYZ_Lookup() |
If the routine does not exist, the queue manager repeats this process for the next component in the list. In addition, if the routine does exist but returns a code indicating that it could not perform the operation, the attempt continues with the next available component. Routines in service components might return a code that indicates that no further attempts to perform the operation should be made.