SOA-RA Application Architecture
Application architecture
The relationship between the components of the architecture is represented below.
Game
Games are treated largely as black boxes with connectors to the rest of the architecture exposing events to which external modules can listen, or requesting information that can reside outside the game itself (e.g. factual databases about the learning domain or connect to social network or gaming servers).
The game is also where the main interaction with the player/learner happens.
The tables below list the interaction points (ports) between the game and other components, which make it possible to incorporate certain functionalities. The column "Related components" indicates the modules that are connected via each port.
| Port | Description | Related components |
|---|---|---|
| User profile | In order to benefit from a centralized profile manager and a monitoring dashboard, the game should connect to the user profile service to associate a game session with a user profile. | - User profile |
| Micro-adaptation | The game can receive processed data from the assessment and adaptation service, in order to adjust its characteristics during a gaming session. | - Assessment and adaptation |
| Social networks | In order to use information about the player/learner's social network and implement social leaderboards or other functionalities based on social networks, the game can consume information coming from a connected social network. | - Social network components |
| Auxiliary modules | A game can implement calls to external knowledge bases to reuse existing content or other auxiliary modules (e.g. content formatters, filters) to be used in the game | - Auxiliary components |
| Game events | The events to be exposed can vary according to the game. The recommended events are the universal traces proposed by Serrano-Laguna et al [1]: game traces (start, quit, finish), phase traces (phase start, phase end, completion status), meaningful variables (on performance and games state, such as scores, number of attempts, etc) and input traces (input action, input device and input data associated). In addition to universal traces, other variables related to player performance and interaction with the game may be recorded and exposed. The connection between the game and the other components happens using a unique session ID, so that the other services do not need to receive personal information from the player to interact with the game and with each other. |
- Dashboard, - Learning analytics, - Assessment and adaptation, - User profile |
User profile
The user profile component holds persistent information about the player which can be used across different games. It always asks for authorization before connecting with other components, sending personal information or updating the user profile.
The component also provides a UI to the players to access and manage their profiles and the applications authorized to receive information about the player.
| Port | Description | Related components |
|---|---|---|
| User data management | The user profile collects consolidated data from the game, the assessment/adaptation component and from the learning analytics component to update the user profile. | - Game, - Assessment and adaptation, - Learning analytics |
| User profile | This port serves information about the user profile to the components that need it. To be able to glue components together while preserving player's privacy, a session ID is used to connect a player to a gaming session, and this session ID is used between the components (instead of a player ID). | - Game, - Dashboard |
Assessment and adaptation
The assessment and adaptation component is one of the most important of this reference architecture. It is responsible to provide adaptivity to games.
If the game includes engagement or emotional assessment during gameplay, the internal component will be responsible to implement an interface to collect this data from the environment (directly from the user through a device such as a webcam, physiological sensors, manual input, etc).
| Port | Description | Related components |
|---|---|---|
| Assessment and adaptation | To be able to evaluate the performance of the player/learner in the game, the module needs to receive well-formated data from the game. | - Game |
| Assessment and adaptation | Once the data received from the game has been processed, the module returns the evaluation and the suggested adaptation back to the game. It also provides information that can be displayed to the instructor via the dashboard. | - Game, - Dashboard |
| Consolidated data | Consolidated data about the gameplay session is made available by the component. This information can be consumed by the user profile module, to update the user profile with data from the interaction. | - User profile |
Internal structure of the assessment and adaptation component
Although the interface exposed to the other main components of the reference architecture is one, the assessment and adaptation module is in fact composed by other individual components that can function independently. Figure 2 below details the internal composition of the assessment and adaptation module.
Internally, the assessment and adaptation component is formed by:
- evaluating modules (learning performance evaluation; player's emotional or engagement state evaluation);
- adaptation processing module, which combines data from the evaluating modules to produce adaptation suggestions;
- a mediator module, which communicates with external modules (exchanging data with the game, receiving information on the performance and interaction and sending back the adaptation suggestions) and connects the internal modules among themselves.
Learning analytics
The learning analytics component is responsible for collecting, processing and visualizing data collected during gameplay [1].
| Port | Description | Related components |
|---|---|---|
| Collect data | This component collects the data exposed by the game. The set of traces that can be collected are the recommended universal traces proposed by Serrano-Laguna et al [1]: game traces (start, quit, finish), phase traces (phase start, phase end, completion status), meaningful variables (on performance and games state, such as scores, number of attempts, etc) and input traces (input action, input device and input data associated). | - Game |
| Consolidated data | The learning analytics module returns to the other components a consolidated report of the data collected during gameplay. This data can be used directly by the dashboard to report on the player's performance right after the game session, but also by the user profile module to update the player's profile accordingly. | - User profile, - Dashboard |
Dashboard
The dashboard module is the main interface for the instructor to follow the gaming session. It needs to be connected directly to the user profile so that the instructor is able to identify the player. It is also connected to the other modules that provide real time data and consolidated reports on the player. The consolidated reports remain accessible to the instructor even after the end of the gaming session.
| Port | Description | Related components |
|---|---|---|
| Profile | The dashboard needs to receive information about the user profile (including personal information), so that the instructor can follow the gaming session. It also requires the ID of the gaming session, which connects the user profile to the game and to the other related modules. | - User profile |
| Interaction monitor | The dashboard receives real time data from the game, from the assessment and adaptation module, and from the learning analytics module, which allow the instructor to follow the player's performance during the gaming session. | - Game, - Assessment and adaptation, - Learning analytics |
Social network
Social network services provide interfaces to retrieve information about the social network connected to the user profile, for example friends and their own performances in games. Existing social networks (e.g. Facebook, Google+) already have well documented APIs with these capabilities, which are widely used by social network games.
| Port | Description | Related components |
|---|---|---|
| Social network query | Social network APIs that share information regarding connected users. | - Game |
Auxiliary modules
Whenever relevant, a game can make requests to external auxiliary modules, such as databases holding relevant information to the game which can be reused in different applications (e.g. factual information databases, exercises databases) or modules to help in processing information for the game (e.g. a module to parse natural language queries).
In this architecture, we do not define any specific interface for these modules, since they will vary widely according to the nature of the external components.
SOA Realization
The Open Group SOA Reference Architecture
The Open Group SOA Reference architecture provides guidelines and options for making architectural, design, and implementation decisions in the implementation of solutions. It is intended to be a blueprint for creating or evaluating architecture. It has nine layers representing key clusters of considerations and responsibilities that typically emerge in the process of designing an SOA solution or defining an enterprise architecture standard. This organization does not assume that the provider and the consumer are in one organization. For details, check the SOA Source Book [2].
The horizontal layers are functional layers. The lower layers (Services Layer, Service Component Layer, and Operational Systems Layer) are concerns for the provider and the upper ones (Services Layer, Business Process Layer, and Consumer Layer) are concerns for the consumer. The vertical layers represent cross-cutting concerns of a more supporting (non-functional or supplemental) nature.
Simple SOA implementation
A simple version of an SOA architecture for serious games is represented in Figure 2. This version implements only the consumer interface, business, service component and operational system layers.
This partially layered enables some benefits of service orientation, in which it decouples clearly the roles of consumer and providers and uses a business layers to align the software with business processes. However, it still does not provide proper decoupling between consumer and provider. In other words, without a Service layer, switching providers is made more difficult, since different interface definitions from different components would impact code in the business layer.
Intermediate solution
The architecture represented in Figure 3 implements a Service Layer. The benefits of this change is that it provides well-defined interfaces for capabilities, which can be independent of the actual components that implement those capabilities. It is even possible that more than one service component are combined to provide one service (service composition), or that the same service component is used to implement more than one service.
Full solution
A full implementation of an SOA architecture might include not only the five functional (horizontal) layers, but also the supporting layers. An integration layer, in this case, would mediate the communication between the layers, including transformation, routing, and protocol conversion to transport service requests - a role typically fulfilled by an Enterprise Service Bus (ESB). A Quality of Service layer might include logging, access control and monitoring. An Information layer can include metadata definitions, information repositories, business analytics and so on. And finally, a Governance layer includes components to ensure that the services and SOA solutions within an organization are adhering to the defined policies and guidelines.
The need for a full SOA solution depends on the size of the product or organization and the requirements of the project. It is not recommended to "over-architect" a solution to comply to a model, when the real needs of the project do not specifically call for a complex solution [3].
References
- ↑ 1.0 1.1 Ángel Serrano-Laguna, Javier Torrente, Pablo Moreno-Ger, Baltasar Fernández-Manjón, Application of Learning Analytics in educational videogames, Entertainment Computing, Volume 5, Issue 4, December 2014, Pages 313-322, ISSN 1875-9521, http://dx.doi.org/10.1016/j.entcom.2014.02.003
- ↑ The Open Group. SOA Reference Architecture Technical Standard. http://www.opengroup.org/soa/source-book/soa_refarch/index.htm
- ↑ Ross Mason (2009). To ESB or not to ESB. http://blogs.mulesoft.com/dev/mule-dev/to-esb-or-not-to-esb/
Navigation in the SG SOA-RA document:
- Introduction
- Architecture Principles, Vision and Requirements
- Business Architecture
- Application Architecture
- Conceptual Data Architecture
- Technological Suggestions
- How to apply
