Home - GeneralizedLearningUtilities/SuperGLU GitHub Wiki

Welcome to the SuperGLU wiki! Documentation is being transitioned to this page from some other sources. Notes on the messaging format are here. The overall design and original purpose of the architecture is explained in papers published in JADLET (as part of the University of Memphis SKO Architecture), in the context of recommendations for generalized intelligent tutoring systems (e.g., the 2013 GIFT Workshop), and some initial exploratory work for integrating with the GIFT architecture. These represent an evolution on the thinking on this architecture, which is still continuing.

The overall goal of this architecture is to make it blindingly easy to mash up educational technology, including intelligent and adaptive systems that previously struggled to interoperate easily. Three main components underlie this system:

  • Messages: Messages follow a specific format and are used to transmit all meaningful information between services. Messages are objects (e.g., have both data and functions associated with them), that are consistent across different systems and languages. Messages can be serialized, but the specific serialization formats are irrelevant to how services process them (e.g., a service should never need to process a raw, serialized message).
  • Services: Services are modules that receive and send messages, which may be processed by other services. They are intended to understand certain messages, which carry semantic information that determines how they behave. Services cannot depend on the existence of specific other services, and should soft-fail rather than hard-fail if the messages they expect are not received.
  • Gateways: Gateways determine how messages are routed, both in terms of application-level protocols (e.g., Websockets, HTML5 postMessage, SOAP, etc.) and also in terms of network and service topography. In short, gateways exist to represent the service topography so that services should never need to. Gateways can form either a tree or an acyclic graph, by connecting to other gateways. Services are always leaf nodes attached to some gateway. By default, Gateways transmit all messages by a fanout policy that ensures that a message sent by any service reaches all other services. To optimize this process, each Service can transmit specifications for the types of messages that it will accept, which can be used to filter messages from reaching certain services or gateways (e.g., can be used to semantically partition the Gateway graph).

In short, Gateways exist to abstract away many of the painful details of implementing and moving services. In general, services should follow these principles:

  1. Anonymity: Services should not store the names or locations/paths to other services. Other than services intended to manage network topography, very few services for education ever need to care where a server lives.
  2. Semantic Messaging: Messages should be passing along events or information that other services find useful (semantically-rich information). Messages should typically not be sending orders to other services (e.g., imperatives), since such procedural messaging tends to be fragile and become entangled with other services' implementation details.
  3. Resilience: In a distributed system, things will go wrong. Services should be designed to soft-fail and recover from errors, where possible.