Processing Flow and Linkages

Application Broker

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 implementation¹. 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:

• Locate the Application Agents (DLMs) for each XSLM-compliant licensing system implementation defined to the Broker².

• Route application client service requests to one or more implementation Agents.

• Logically propagate implementation-Agent provided responses to "routed" service requests to the application client from which those requests were received. Note that for certain XAAPI functions (for example, xslm_query_api_level()), the Broker is required to consolidate responses received from multiple implementation Agents to yield a single response, which is then delivered to the application client.

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.

Application Agent

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:

• Dynamically or statically bind to the Application Broker.

• Directly (but dynamically) bind to the implementation Agent as an alternative to using an Application Broker. This capability is useful in operating environments where only a single compliant licensing system implementation is present and/or required, and thus where binding the Agent to an Application Broker would necessarily result in a performance penalty without offering any functional benefit.

• Be statically bound to a specific implementation Agent. This capability could be used, for example, to provide a software publisher with additional, but implementation specific, authentication features, albeit at the expense of a loss of interoperability with respect to alternative compliant licensing system implementations.

Application-to-Licensing System Communications

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

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

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.

Management Client-to-Licensing System Communication

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.