SOA-RA Introduction

Purpose of this document

This reference architecture has the purpose to make it easier for serious games designers and developers to build games that follow the Service Oriented Architecture principles, which in turn can bring a series of benefits such as reduced costs and time to market, and the production of more readily integrated systems . It can also aid vendors to provide software products that are more likely to support the needs of serious games developers.

Target audiences:

• Serious games developers
• Serious games designers
• Vendors of game and serious game-related software

What this document is:

• A high-level blue print for architectures of educational serious games, which can be used to facilitate consistency based on best practices;
• An orientation on which are the aspects, building blocks, and layers of an SOA-based serious games that should be considered by developers when designing solutions or assessing a game architecture;

What this document is NOT:

• This document is NOT intended to be used as provided; it should be customized to create an appropriate solution for each case;
• This document is NOT a standard, but rather a non-normative and exemplary document to be used as input to the development process;
• This document does NOT include an explanation of the fundamentals and value of SOA, nor its benefits in the serious games domain. Readers are requested to consult the references and related documentation for more information on these topics.

Background

Educational serious games (SGs) are typically designed to meet specific learning requirement and are shipped as one-of-a-kind products fully customized according to its requirements. This situation leads to products that have high production costs, challenging and time-consuming production process, and low reusability of the final product and its components. Service-Oriented Architecture (SOA) can offer a solution to this problem by allowing for increased reusability and customization of components in educational games within different genres and domains.

Nevertheless, adopting SOA can be a daunting task. This document is an attempt to contribute in reducing costs and other barriers to adopting SOA in the development of educational serious games.

By proposing a common reference architecture to serve educational games of different genres and domains, we expect to:

• Provide a common understanding of serious games elements, needs and typical solutions;
• Improve communication within teams and within the industry/research groups through common vocabulary and concepts;
• Provide an architecture baseline to jumpstart serious game development efforts;
• Contribute in reducing costs associated with the development, acquisition, integration, and deployment of services in serious game development.

Methodology

The methodology used to create this architecture was the Architecture Development Methodology (ADM), as defined in the TOGAF 9.1.

In short, ADM is an iterative and cyclic method to develop an enterprise architecture which will meet the business and information technology needs previously defined. The Figure below illustrates the method.

For the purpose of the development of the SOA-RA for SGs, we have applied a simplified version of ADM, consistent with the relatively small and very specific scope of this effort. This architecture is composed of the following components:

• Architecture Principles (Preliminary Step)
• Architecture Vision (Step A)
• Architecture Requirements (Underlies all steps)
• Business Architecture (Step B)
• Application Architecture (Step C)
• Conceptual Data Architecture (Step C - partially)
• Technological Suggestions (Step D)

The requirements phase underlies the whole ADM process, as illustrated by the circle at the center of the ADM figure above. The requirements are recorded and managed in this wiki, particularly the Architecture Principles, Vision and Requirements page.

Steps E to H in the original ADM were not implemented, since they refer mostly to implementation of a proposed architecture in an enterprise, possibly replacing an existing architecture.

Step D (Technology Architecture) is not described in full. Rather, in the section Technology Suggestions we offer an overview of existing services and solutions that could potentially be used to deploy our suggested SOA architecture, with or without modifications. That page will also serve to map current technological gaps in the serious game domain that could be prioritized by the community.

Notes and references

This document is based on the HTNG Reference Architecture, which in turn used the TOGAF (The Open Group Architectural Framework) as framework for its creation. This document also uses concepts from The Open Group Reference Architecture Technical Standard.

See also:

• The Open Group SOA Reference Architecture Technical Standard
• HTNG Reference Architecture
• HTNG Reference Architecture - SOA realization
• J.D. Meier (2011). Reference Models, Reference Architectures, and Reference Implementations
• The Open Group. Navigating the SOA Open Standards Landscape Around Architecture White Paper : How the Technical Products Fit Together

---

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

Continue to the Architecture Principles, Vision and Requirements