Cloud4All Matchmaker Framework
In previous versions of the GPII architecture, the choice of matchmaking strategy was essentially static. The system provided a simple means by which matchmaking requests could be routed to different remote matchmaking strategies (such as the Rule-Based or Statistical Matchmakers) using configurable URLs. In general, however, this approach was limited to a startup setting that could be configured by an implementer or administrator of a Cloud4All system, rather than on-the-fly or by user decision.
In order to provide greater flexibility in terms of how matchmaking strategies are configured and dispatched, a new GPII Matchmaker Framework component has been introduced. This component serves as a central point for invoking Matchmakers and configuring new dispatch strategies. Moving forward, this will make it possible to implement two new scenarios for dynamic matchmaking:
- user selection of the preferred Matchmaker via a preference in the user’s NP Set
- a hybrid Matchmaker, which can contextually dispatch to either the Rule-Based or Statistical Matchmakers based on the contents of a user’s preference set
The Matchmaker Framework provides a central configuration file that serves as a registry for all Matchmaking strategies (e.g. Rule-based, Statistical, flat, and canopy) available to the system. All Matchmakers must conform to a simple API consisting of a single service call, match. A Matchmaker is provided with a comprehensive payload of information about the user’s preferences, contexts, device information, environmental data, and more. In response, it will return a JSON response containing all the settings that the Matchmaker inferred for each application, categorized by context.
Figure 1: Sequence diagram showing the default dispatching workflow of the Matchmaker Framework.
Using the Matchmaker Framework as the central abstraction point for the matchmaking process helps to shield the other components from the complexities of the matchmaking process, and allows new dispatching mechanism and strategies to be plugged into the system simply by registering new implementations with the framework’s configuration file. For example, a new dispatching strategy could be introduced into the system that automatically analyses the contents of a user’s preference set and—if it contains many “common terms”—automatically dispatch the matchmaking request to the Rule-Based Matchmaker, which is optimized for this type of data. Alternately, if the preference set contained predominantly application settings from a source such as the GPII Snapshotting tool, the Statistical Matchmaker could be invoked instead.
More information about the Matchmaker Framework, including example input and output payloads, is available in the GPII realtime framework’s universal repository documentation.
Colin Clark, December 2014