Previous section.

Systems Management: Software License Use Management (XSLM)
Copyright © 1999 The Open Group

Processing Flow and Linkages

This chapter describes the processing flow and linkages between an application and a licensing system, and between a management application and the licensing servers that together constitute the licensing system.

Application Broker

The Application Broker is, in effect, a routing function. It serves only to render the presence of multiple licensing system implementations (from one or more licensing system vendors) transparent to application clients; that is, to create a single logical license management system in those situations where the actual licensing system is comprised of two or more XSLM-compliant licensing system implementations.

Note that where an implementation provides for the concurrent existence of multiple physical license servers, the responsibility for providing server transparency (that is, server topology) lies with that specific implementation1. In other words, the Broker provides implementation rather than server transparency with respect to those application clients served by the Broker.

As illustrated in Application API Architecture, the Application Broker is positioned between the application client and one or more XSLM-compliant license use management system implementations. The numbered steps in the figure indicate processing order. The primary functions of the Application Broker are to:

A licensing system implementation is exposed to the Broker in the form of an implementation dependent Application Agent. This is discussed further in Application Agent.

The Application Broker DLM must be named "XSLM_Broker" and must export the names of all XSLM application API (XAAPI) functions. This provides application clients with a means of accessing all supported services without requiring knowledge of the number or identity of the specific licensing system implementation(s) that are providing those services.

It is expected that licensing system publishers will assume responsibility for developing and delivering at least one Application Broker. However, this does not preclude other software publishers from delivering alternative Broker implementations providing additional features.

Figure: Application API Architecture

Application Agent

The Application Agent itself provides the Application Broker and (when dynamic client-to-Agent binding is employed) application clients with a means of accessing all supported XSLM-defined application services without requiring knowledge of the methods used to implement those services; that is, without knowing which implementation is being used, how function is distributed between the agent and its corresponding server(s), or which protocol is being used to effect physical communication between the agent and its server(s).

As illustrated in Application API Architecture, each Application Agent implementation must physically consist of at least one dynamically loadable module (DLM).

The Application Agent must export the names of all XSLM application (XAAPI) functions. This provides the means by which the Application Broker can bind to the implementation Agent.

An Application Client can:


Application-to-Licensing System Communications

XSLM does not define the protocol over which an application client communicates with an XSLM-compliant licensing system.

The physical (wire level) communication protocol between XSLM-enabled application clients and license servers is implementation specific, yet transparent to the clients. This is accomplished by requiring clients to dynamically bind to, and direct all XSLM-defined application service requests (API calls) to, an implementation independent Application Broker (DLM) or, when appropriate, to an implementation dependent Application Agent.

Referring to the numbers in Application API Architecture, the process flow between the application client and the licensing system server is as follows:

  1. The Application Client calls a desired XSLM-defined function entry point within the Broker DLM. This is always possible since each licensing system implementation is required to provide a Broker DLM named "XSLM_Broker.DLM" that exports entry points for all XSLM- defined functions. The Application Client may be either statically bound (link edited with) or dynamically bound (at run time) to the Broker.

  2. The Broker, via an implementation dependent method, locates profile (initialization) information that provides the Broker with the UUIDs of the licensing system publishers with which the Broker is to establish a dynamic binding. These UUIDs are used by the Broker to locate each licensing system's Application Agent (implementation) DLM. This is possible because each implementation is required to supply an Agent DLM named "uuid_XAAPI.DLM," where "uuid" is the implementation publisher's UUID.

  3. The Broker, having located all required Application Agent DLMs, either invokes each implementation Agent (in an implementation determined order) until the first time an "OK" response is received, or the entire list of Agents as defined in the Broker profile information.

  4. The implementation Agent (DLM) is invoked at the corresponding entry point to that at which the Broker was originally entered. The Agent prepares an implementation dependent representation of the function request and forwards it to a compatible license server belonging to the same publisher as the one that provided the Agent. XSLM does not specify the form of the function request representation, or the means by which that representation is communicated to, nor how the response to the represented request is received from, the licensing system server.

  5. The license server receives the implementation specific representation of the XSLM function request over a licensing system (implementation) defined communications medium. The server processes the request, prepares an appropriate response, and sends the response back to the requesting Application Agent.

  6. The Implementation Agent converts, as necessary, the server response information to a form compliant with that mandated by the requested XSLM function. The XSLM-compliant response data is then returned to the Broker function.

  7. The Broker receives control back from the implementation Agent and either:

    1. Checks for an "OK" return, indicating that the requested function completed without error, and when received effects an immediate return to the requesting Application Client. In the event a "Not OK" return is received the Broker continues by invoking the same function in the Agent DLM for the next implementation (UUID) defined to the Broker.

      or (for some functions):

    2. Saves the information returned from the implementation, invokes the same function in the Agent DLM for the next implementation (UUID) defined to the Broker, saves the information returned by that Agent, and so on, until the requested function has been invoked for each defined implementation. At the conclusion of this process the Broker analyzes the responses, producing one consolidated response which is provided upon return to the requesting Application Client.

At this point the Application Client will have received control back from the Broker, along with an appropriate XSLM-defined return code and all output data defined for the requested XSLM function.

Management Agent

The Management Agent provides management clients with a means of accessing all supported XSLM-defined management services without requiring knowledge of the methods used to implement those services; that is, without knowing which implementation is being used, how function is distributed between the Agent and its corresponding server(s), or which protocol is being used to effect physical communication between the agent and its server(s).

As illustrated in Management API Architecture, each conforming implementation must provide a Management Agent physically consisting of at least one dynamically loadable module). This DLM must be named "uuidXMAPI.DLM" where "uuid" is the publisher identification (UUID) for the licensing system that provides the DLM.

Each Management Agent must export the names of all XSLM management (XMAPI) functions. This provides the means by which a management client can dynamically bind to one or more Management Agents.

Communication Protocol

XSLM does not define the protocol over which a Management Client and a license server communicate. The physical (wire level) communication protocol between a given licensing system's Management Agent and corresponding license server(s) is implementation specific, and transparent to clients.

As illustrated in Application API Architecture, each implementation's Management Agent must physically consist of at least one dynamically loadable module (DLM) that exports the names of all XSLM-defined management functions. This provides Management Clients with access to all XSLM-defined management functions without requiring client knowledge of the methods used to implement those functions; that is, without knowing how functionality is distributed between the Agent and its corresponding server(s), or what protocol is being used to effect physical communication between the Management Agent and the server(s).

There is no specified limit as to the number of Management Agents a Management Client may concurrently load. A client must, at a minimum, load an agent at least once for each licensing system implementation with which it intends to communicate.

Server-level addressability (XMAPI requests directed to a specific licensing system server) facilitates the creation of management tools that can provide a single point of control for a given logical licensing system comprised of multiple physical servers while maintaining an accurate topological view of the physical components of that licensing system.

The XMAPI provides for directed communication with any compliant license server through a unique communications handle provided by the Management Agent (DLM) associated with the server implementation. The "XSLM_Query_Servers" function, directed to the implementation Management Agent, is used to obtain the communication handle for each active server for that implementation. A management application may subsequently direct XMAPI requests to a specific server running on the behalf of an implementation by invoking the desired XMAPI function (contained in the corresponding implementation Management Agent) and providing as an input parameter the communication handle for the desired target server.

Figure: Management API Architecture

Management Client-to-Licensing System Communication

This specification does not define the protocol over which a Management Client communicates with an XSLM-compliant licensing system, or with the license servers that comprise it.

The physical (wire level) communication protocol between XSLM-enabled management clients and license servers is implementation specific, yet transparent to those clients. This is accomplished by requiring clients to dynamically bind to a unique implementation specific Management Agent for each licensing system implementation. This direct binding to multiple Agents is, unlike for Application Clients, required for Management Clients because management clients require complete knowledge of the physical topology of the logical licensing system.

Referring to the numbered steps in Figure 3-1, the process through which Management Client-to-licensing system server is effected is as follows:

  1. The Management Client, via an implementation dependent method, locates its initialization information. This information includes a list of publisher UUIDs for the licensing system implementations with which the Client may establish a dynamic binding. These UUIDs are used by the Management Client to locate each licensing system's Management Agent (implementation) DLM. This is possible because each compliant implementation is required to supply an Agent DLM named "uuid_XMAPI.DLM", where "uuid" is the implementation publisher's UUID.

    The Client, having located all required Management Agent DLMs, invokes the "XSLM_Query_Servers" function for each Management Agent to obtain a list of the identities and attributes of the active license servers for each implementation. The output of this function provides the Management Client with the information required to direct XSLM requests to each active server for a specific implementation. By consolidating the information obtained from the Management Agents for all specified implementations the Management Client is able to determine the identities and logical communication identifiers of all servers comprising the XSLM-compliant licensing system.

  2. The Management Client receives an implementation specific management request from either a terminal user or management application program (tool).

  3. The Management Client, based on the input received from the terminal user or program, calls the required XSLM-defined management function entry points contained within one or more Client selected Management Agent DLMs.

  4. The Management Agent, upon receiving control at the Management Client-selected XSLM- defined function entry point, prepares a licensing system implementation-dependent representation of the function request and forwards it to a compatible license server belonging to the same publisher as the one that provided the Agent. XSLM does not specify the form of the function request representation, or the means by which that representation is communicated to, nor how the response to the represented request is received from, the licensing system server.

  5. The license server receives the implementation specific representation of the XSLM management function request over a licensing system (implementation) defined communications medium. The server processes the request, prepares an appropriate response, and sends the response back to the requesting Management Agent.

  6. The Management Agent converts, as necessary, the server response information to a form compliant with that mandated by the requested XSLM function. The XSLM-compliant response data is then returned to the Management Client.

  7. The Management Client receives control back from, and processes the output data returned by the Management Agent. Depending on the terminal user or program request, the Management Client may choose to make subsequent calls to the same or to other Management Agent functions.

At this point the Management Client completes the terminal user or program request by preparing an appropriate (implementation dependent) response that is either delivered to (displayed upon) the user's terminal, or returned to the requesting (management) program (tool).


Footnotes

1.
This Technical Standard does not detail the requirements for the server-to-server interactions required to provide transparency between servers from different licensing system publishers. See Futures for more information.

2.
It is possible in some environments that a broker must be "refreshed" in order to recognize a newly-added Application Agent.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index