Architectures & Interfaces - Overview

Terms of use
X Terms of use
Free to distribute for non-commercial purposes.
Print
E-learning systems and platforms are becoming more and more popular in all educational environments (K-12 schools, universities,etc). But the fast proliferation and popularization of these kind of systems has also brought several disadvantages:
  • Most academic products on the market today were initially conceived as solutions for departments, or even single courses
  • Their underlying architectures did not anticipate the need to scale to many thousands of students and to smoothly integrate with student information, financial, human resources, and other academic computing systems
  • The price of the systems themselves is rising as vendors strive for profitability, and anecdotal evidence indicates that some campuses have written more lines of code to integrate their campus systems with a vendor’s course management system than there are lines of code in the vendor’s system itself
  • Massive customized in-house development brings with it not only cost but also an increased risk of a system failure that cannot be diagnosed or that cannot be fixed at a reasonable cost

To overcome those problems several steps must be carried out:
  1. First of all, there is a need for the technology being used to deliver online higher education courses to conform to international learning technology standards. The standards in question are designed to promote interoperability among learning content and online learning systems and are gaining acceptance worldwide
  2. Education leaders must find a way to reduce the cost and complexity of system integration work while ensuring that their learning systems are built on a reliable and scalable architecture that allows them the flexibility to meet the needs of diverse teaching and learning styles
  3. The educational technology systems of the future must be built from the perspective of enterprise infrastructure. They must be based on an open and modular framework that can be used by software vendors and that meets the needs of entire campuses, individual departments, and even single courses. And they must be based on international standards that are being used by formal educational systems around the world

The purpose of developing system architectures is to discover high-level frameworks for understanding certain kinds of systems, their subsystems, and their interactions with related systems, i.e., more than one architecture is possible.

An specific kind of interfaces is related with the access to digital repositories. These systems provide the infrastructure for the storage, preservation, management, discovery and delivery of all types of electronic content. Usually, they are accessed from other e-learning systems to get or storage their contents. More info about these systems can be found under the category Digital Repositories.

An architecture isn't a blue print for designing a single system, but a framework for designing a range of systems over time, and for the analysis and comparison of these systems, i.e., an architecture is used for analysis and communication.

By revealing the shared components of different systems at the right level of generality, an architecture promotes the design and implementation of components and subsystems that are reusable, cost-effective and adaptable, i.e., critical interoperability interfaces and services are identified.
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the AICC Web site and edited for presentation. Please refer to the AICC Web site for additional information on terms of use.
Print
Image for 'Overview'
Aviation Industry CBT Committee
The specification/guidelines Package Exchange Notification Services (PENS), developed by the AICC (CMI010), describes a protocol to support a notification service to announce the location of content package(s) that are available for transport. The intent is to automate the notification, transfer and delivery confirmation of content packages between tools or systems that generate content and systems that manage, publish or deliver content.
Purpose and Scope
The purpose of this specification is to fill a gap that currently exists between the creation of content packages by “content authors” and the deployment of those content packages on LMSs by “LMS administrators” where learners may ultimately have access to them. Without a specification that addresses this gap, the concept of shared content is incomplete: LMSs do not have a means to obtain newly developed, revised or updated content.

The scope of the specification is specifically constrained to the notification request, package transfer and related responses. Specifically outside the scope of this specification are mechanisms for physical deployment of content packages, content management, version control, publication or revoca-tion of content.
AICC Package Exchange Notification Services overview
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
Free to distribute for non-commercial purposes.
Print
Image for 'Description'
European Commitee for Standardization
The Simple Publishing Interface (SPI) specification (CWA 16097:2010), partly sponsored by the CEN Workshop on Learning Technologies, defines a protocol for publishing learning objects and/or their metadata to digital repositories. This protocol facilitates transferring metadata and learning objects from tools that produce materials to applications that persistently manage learning objects and metadata, but is also applicable to the publication of a wider range of digital objects. A CEN Workshop Agreement containing the specification and a binding to the ATOM Publishing Protocol (APP), compatible with the SWORD profile which is widely used by institutional repositories, is due for publication in 2010.

The objective is to develop a practical approach towards interoperability between repositories for learning and applications that consume or produce educational materials. Examples of repositories for learning are educational brokers, knowledge pools, institutional repositories, streaming video servers, etc. Applications that consume these educational materials are for instance query and indexation tools, authoring tools, presentation programs, content packagers, etc. The work will concentrate on the development of the simple publishing interface (SPI), an interface for storing educational materials in a repository.

The design of the SPI API is based on the design principles of the Simple Query Interface (SQI) specification. It has been defined a simple set of commands that is extensible and flexible. By analogy with SQI, this protocol makes a distinction between semantic and syntactic interoperability:
  • Syntactic interoperability is the ability of applications to deal with the structure and format of data. For instance, a language such as XML Schema Description (XSD) ensures the syntactic interoperability of XML documents as it allows for the parsing and validation of these documents.
  • Semantic interoperability refers to the ability of two parties to agree on the meaning of data or methods. When exchanging data, semantic interoperability is achieved when data is understood the same way by all the applications involved.
Objectives
This publishing protocol meets the following objectives:
  • SPI enables integrating publishing into authoring environments. This is beneficial for the authors’ workflow, as they do not need to manually upload their learning objects using external publishing applications.
  • SPI provides interoperability between applications that publish and applications that manage learning objects and metadata. Doing so, the effort of integrating publishing access into an authoring application can be reused on other learning object repositories, provided that they support SPI.
Simple Publishing Interface specification
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the European Committee for Standardization (CEN) official Web site and edited for presentation. Please refer to the CEN official Web site for additional information on terms of use.
Print
Image for 'Description'
European Commitee for Standardization
The Simple Query Interface (SQI) specification, supported by CEN WS-LT (CWA 15454:2005), presents an Application Programming Interface (API) for querying learning object repositories. Since one major design objective is to keep the specification simple and easy to implement, the interface is labelled Simple Query Interface (SQI).

In the context of SQI, learning object repositories are defined as collections of educational material, courses, and learning objects with associated descriptions (referred to as “metadata”). Examples of repositories for learning are educational brokers, knowledge pools, streaming video servers, etc.

The collaborative effort of combining highly heterogeneous repositories has led to the following requirements:
  • SQI is neutral in terms of results format and query languages. The repositories connecting via SQI can be of highly heterogeneous nature, therefore, SQI makes no assumptions about the query language or results format.
  • SQI supports Synchronous and Asynchronous Queries in order to allow application of the SQI specification in heterogeneous use cases.
  • SQI supports, both, a stateful and a stateless implementation.
  • SQI is based on a session management concept in order to separate authentication issues from query management.
The design of the API itself is based on following design principles:
  • Command-Query Separation Principle,
  • Simple Command Set and Extensibility.
SQI forms a key part of the infrastructure used by the ASPECT project. ASPECT will also develop mappings from SQI to other search specifications including SRU.Simple Query Interface specification
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IEEE Learning Technology Standards Committee (LTSC) official Web site and edited for presentation. Please refer to the IEEE Learning Technology Standards Committee (LTSC) official Web site for additional information on terms of use.
Print
In general, the purpose of developing system architectures is to discover high-level frameworks for understanding certain kinds of systems, their subsystems, and their interactions with related systems, i.e., more than one architecture is possible.

An architecture isn't a blue print for designing a single system, but a framework for designing a range of systems over time, and for the analysis and comparison of these systems, i.e., an architecture is used for analysis and communication.

By revealing the shared components of different systems at the right level of generality, an architecture promotes the design and implementation of components and subsystems that are reusable, cost-effective and adaptable, i.e., critical interoperability interfaces and services are identified.

The architectural framework developed in this standard should not address the specific details of implementation technologies (e.g., programming languages, authoring tools, or operating systems) necessary to create the system components, or the management systems (e.g., learning material lifecycle, quality assurance, access control, or user administration) necessary to manage a learning technology system, i.e., the standard should facilitate the development of configuration guidelines for general learning technology systems.

The standard shall identify the objectives of human activities and computer processes and their involved categories of knowledge, i.e., it is possible to identify protocols and methods of cooperation and collaboration.



Note
Note that the "Architecture & Reference Model Working Group 1 LTSA" status is Inactive


Architecture & Reference Model - Working Group 1 Web Site
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
Free to distribute for non-commercial purposes.
Print
Image for 'Introduction'
IMS Abstract Framework
The IMS Abstract Framework (IAF) is a device to enable the IMS to describe the context within which it will continue to develop its eLearning technology specifications. This framework is not an attempt to define the IMS architecture, rather it is a mechanism to define the set of services for which IMS may or may not produce a set of interoperability specifications. In the cases where IMS does not produce a specification then every effort will be made to adopt or recommend a suitable specification from another organization.

This Abstract Framework document describes the general architectural assumptions that underlie IMS specifications and other technical documents. This is a living document which is likely to evolve and be extended to include areas not covered in the current version.
IMS Abstract Framework Web Site
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS Global Learning COnsortium official Web site and edited for presentation. Please refer to the IMS official Web site for additional information on terms of use.
Print
Image for 'intro'
IMS Global Learning Consortium
IMS Basic Learning Tool Interoperability (IMS BLTI) is a subset or profile of the full IMS Learning Tool Interoperability (LTI) v1.0 specification. IMS BLTI gives developers experience using the core concepts and provides a preview of the more advanced feature set of IMS LTI v1.0.

IMS is developing Learning Tools Interoperability (IMS LTI) to allow remote tools and content to be integrated into a Learning Management System (LMS). This document brings a subset of that specification forward for standardization. This document precedes the full IMS LTI v1.0 specification set.

The key differences between IMS BLTI and IMS LTI v1.0 are the following ones:
  • IMS BLTI exposes a single destination in the Tool Provider system. The procedure for establishing a link to this single destination is very simple, but limited. There is no provision for accessing run-time services in the Tool Consumer and only one security policy is supported.
  • IMS LTI v1.0 defines a formal, negotiated deployment process whereby the Tool Consumer and the Tool Provider reach an agreement about (1) the run-time services that will be used to support tight integrations between the systems, (2) the security policies that will apply, and (3) the set of destinations within the Tool that can be launched from the Tool Consumer system.
More info
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS Global Learning Consortium official Web site and edited for presentation. Please refer to the IMS Global Learning Consortium official Web site for additional information on terms of use.
Print
Image for 'Overview'
IMS Global Learning Consortium
The purpose of the Digital Repositories Interoperability (DRI) specification, developed by the IMS Global Learning Consortium, is to provide recommendations for the interoperation of the most common repository functions. These recommendations should be implementable across services to enable them to present a common interface.

On the broadest level, this specification defines digital repositories as being any collection of resources that are accessible via a network without prior knowledge of the structure of the collection. Repositories may hold actual assets or the meta-data that describe assets. The assets and their meta-data do not need to be held in the same repository.
IMS Digital Repositories Web Page
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS web site and edited for presentation. Please refer to the IMS web site for additional information on terms of use.
Print
Scope
The IMS Enterprise Services specification is the definition of how systems manage the exchange of information that describes people, groups and memberships within the context of learning. The Enterprise Services specification is constructed following the recommendations documented in the IMS Abstract Framework (IAF). This means that this specification is based upon the concepts of:
  • Interoperability - Enterprise Services focuses on the exchange of information between Enterprise systems. There are no assumptions in the specification on how the data is managed within the Enterprise systems.
  • Service-oriented - Enterprise Services defines the exchange of information in terms of the services being supplied by the collaboration of the systems. This takes the form of Person Management Services, Group Management Services and Membership Management Services.
  • Component-based - the set of services will be supplied such that they can be combined to form a range of services. The Person Management Services, Group Management Services and Membership Management Services can be combined to provide other services and the Enterprise Service will have other services added to it in later releases.
  • Layering - the Enterprise Service and its constituent services (Person, Groups and Membership) are part of the Application Services layer.
  • Behaviors and Data Models - the Enterprise Services are defined in terms of their behaviors and data models. The behaviors cause changes in the state of the data model and the state of the data model will only be altered as a result of a clearly defined behavior.
  • Multiple Bindings - the Enterprise Services information model is to be defined using the Unified Modelling Language (UML). This enables reliable mapping of the information model into a range of different bindings. The bindings of immediate importance are to the Web Services Description Language (WSDL).
  • Adoption - the Enterprise Services are based upon the original Enterprise specification data model. While there are significant changes the underlying data model has been maintained and the core Person, Group and Membership structures remain.
Purpose
The IMS Enterprise Services specification is based on and supersedes the IMS Enterprise v1.1 specification. The original Enterprise specification was based upon the description of the data model for the information to be exchanged between communicating enterprise systems. The Enterprise Services specification extends this work by adding a series of behavioral models that define how the data models are to be manipulated. These behavioral models are described using the Unified Modelling Language (UML).

The Enterprise Services Specification is to be implemented using a Web Services infrastructure based upon a SOAP/http transport mechanism. These web service bindings are detailed in the corresponding service binding documents.

IMPORTANT: The LIS v2.0 specification supersedes the IMS GLC Enterprise Services v1.0 specification.
IMS Enterprise Services Web Page
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS Global Learning COnsortium official Web site and edited for presentation. Please refer to the IMS official Web site for additional information on terms of use.
Print
The General Web Services Base Profile promotes interoperability for web service based specification implementations on different software and vendor platforms.

The Base Profile focuses on a core set of web service specifications and the most common problems experienced implementing the identified web service specifications.

It is not a goal of the General Web Services Base Profile to create a plug-and-play architecture for web services or to guarantee complete interoperability.

The General Web Services Base Profile addresses interoperability in the application layer, in particular, the description of behaviors exposed via Web Services.
IMS General Web Services Web Page
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS Global Learning COnsortium official Web site and edited for presentation. Please refer to the IMS official Web site for additional information on terms of use.
Print
Image for 'intro'
IMS Global Learning Consortium
The Learning Information Services (LIS) specification is the definition of how systems manage the exchange of information that describes people, groups, memberships, courses and outcomes within the context of learning. This specification establishes the means by which learning management systems exchange relevant information i.e. it defines system interoperability through a set of identified services.

IMPORTANT: The LIS v2.0 specification supersedes the IMS GLC Enterprise Services v1.0 specification.

The specification is based upon the concepts of:
  • Interoperability – LIS focuses on the exchange of information between learning information systems e.g. student information system, learning management system, etc. There are no assumptions in the specification on how the data is managed internally within a learning information system;
  • Service-oriented – LIS defines the exchange of information in terms of the services being supplied by the collaboration of the systems;
  • Component-based – the LIS are composed of the Person Management Service (PMS), Group Management Service (GMS), Membership Management Services (MMS), Course Management Service (CMS), Outcomes Management Service (OMS) and the Bulk Data Exchange Management Service (BDEMS);
  • Behaviors and data models – the LIS are defined in terms of their behaviors and data models. The behaviors cause changes in the state of the data model and the state of the data model will only be altered as a result of a clearly defined behaviour;
  • Multiple Bindings – the LIS information model is to be defined so that a range of different bindings can be made available. The bindings of immediate importance are to the Web Services Description Language (WSDL) and the Lightweight Directory Access Protocol (LDAP).
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
Free to distribute for non-commercial purposes.
Print
Image for 'IMS Learning Tools Interoperability - Overview'
IMS

IMS Learning Tools Interoperability (LTI) v1.0 provides a single framework or standard way of integrating rich learning applications -- in LTI called Tools -- with platforms like learning management systems, portals, or other systems from which applications can be launched—called Tool Consumers.



The basic use case behind the development of the LTI specification is to allow the seamless connection of web-based, externally hosted applications and content, or Tools (from simple communication applications like chat, to domain-specific learning environments for complex subjects like math or science) to platforms that present them to users. In other words, if you have an interactive assessment application or virtual chemistry lab, it can be securely connected to learning/course management systems, portals, etc. in standard ways without having to develop and maintain custom integrations.



No image

The Benefits of LTI


  • Increases options for students and instructors when selecting learning applications.

  • Reduces development costs for Tool Providers to develop custom integrations with many LMSs.

  • Reduces support costs for institutions, LMS vendors and Tool Providers coming from a more - clearly defined interface between the LMS and the Tool.

  • Protects the LMS from poorly written proprietary tool integrations.

  • Enables software as a service (SaaS), fast becoming prevalent in all segments of the market.

  • Enables mash-ups of applications within the learning system or portal.

  • Allows common tools to be used across multiple LMS systems.

  • Ultimately spurs the kind of innovation that improves education.

Learning Tools Interoperability v1.0 Project Group
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS Global Learning COnsortium official Web site and edited for presentation. Please refer to the IMS official Web site for additional information on terms of use.
Print
The objective of this work is to demonstrate that a selected tool can be connected to various Learning Management Systems (LMS) for actual use by end users.

The scope of this initial project will address measured objectives aimed at achieving simple connection between the LMS and a tool (but including fundamental issues such as authentication).

Some members of the project will develop extensions to their LMS along with some necessary modifications to the tool to demonstrate achievement of this objective.
IMS Tools Interoperability Web Page
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the Learning Systems Architecture Lab. (LSAL) official Web site and edited for presentation. Please refer to the Learning Systems Architecture Lab. (LSAL) official Web site for additional information on terms of use.
Print
Image for 'Overview'
Learning Systems Architecture Lab logo
The Learning Systems Architecture Lab (LSAL) conducts research focused on the design and creation of Internet-based technologies for education and training. We engage in system design and content creation, with emphasis on emerging technologies and standards for e-learning for all users (K-16, training, life-long)

The LSAL is part of Carnegie Mellon University. Our overall research program focuses on the design and creation of Internet-based technologies for education and training.

The objective of the projects and activities LSAL engages in is to utilize and extend these system architectures to further enhance the accessibility, interoperability, durability, reusability, and cost-effectiveness of learning systems. The software we develop aims to put the needs of the user/learner first, whether the user is a student in public school (K-12), college, the military or a learner in any other situation.
Learning Systems Architecture Lab Web Site
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the Open Knowledge Initiative (OKI) official Web site and edited for presentation. Please refer to the Open Knowledge Initiative (OKI) official Web site for additional information on terms of use.
Print
Image for 'Overview'
Open Knowledge Initiative
The Open Knowledge Initiative (OKI) is a collaboration among leading universities and specification and standards organizations to support innovative learning technology in higher education. The result of this collaboration is an open and extensible architecture that specifies, in terms of Open Service Interface Definitions (OSIDs), how the components of an educational software environment communicate with each other and with other enterprise systems. OKI provides a modular development platform for building both traditional and innovative applications while leveraging existing and future infrastructure technologies.

The OKI OSIDs seek to standardize interfaces to basic functionality so that one application (an OSID consumer) can access specific data and functionality from another application (an OSID provider) in real time. For example, a digital asset management system can make its collections of assets accessible to a learning management system (LMS) by exposing an implementation of the Repository OSID. The LMS then need only be able to consume that OSID (i.e. be able to call functions in the digital asset management system as defined by the OSID). OKI OSIDs is designed for broad adoption in the higher education domain. It provides a stable, scalable base that supports the flexibility needed by higher education and commercial developers of educational software.
Benefits
By clearly defining points of interoperability, the OKI framework allows the components of a complex learning environment to be developed and updated independently of each other. This leads to a number of important benefits:
  • Learning technologies appropriate for a range of teaching and learning requirements can be integrated together into a common environment. The needs of the Math department are not those of English department, and tools that work well for new users may not be adequate for seasoned users.
  • Learning technology and content can be more easily shared among schools and departments. This provides a catalyst for cooperative and commercial development.
  • There is a lower long term cost of software ownership because single components can be replaced or upgraded without requiring all other components to be modified.
  • Modularity makes learning technology more stable, more reliable, able to grow with increased usage, and allows components to be updated without destabilizing other parts of the environment. OKI is based on technologies that have proven to be scalable and dependable in large scale enterprise computing environments.
  • The architecture offers a standardized basis for learning technology software development. This reduces development effort and encourages the development of specialized components that integrate into larger systems.
Open Knowledge Initiative (OKI) Web Site
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the Open Architecture and Schools in Society (OASIS) official Web site and edited for presentation. Please refer to the Open Architecture and Schools in Society (OASIS) official Web site for additional information on terms of use.
Print
Image for 'Overview'
Open Architecture and Schools in Society
Open Architecture and Schools in Society (OASIS) is a project with a clear ultimate objective: to promote small virtual communities in schools within the public educational system.

In particular, OASIS will pay special attention to the role of socialisation in traditional schooling, as one of the main assets of the public school system, and focus on how this role can be enhanced with the help of the Internet.

This final educational outcome requires the development of a technical network. It consists of setting up both local and regional open telematics and informatics architecture for the school educational network together with zonal servers available to meet the needs of automated maintenance of these school networks.

Its aim is to simultaneously integrate a set of data models together with the organizational structures of this data, thus favouring the interoperability between educational networks.
Open Architecture and Schools in Society (OASIS) Web Site
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the Schools Interoperabily Framework (SIF) official Web site and edited for presentation. Please refer to the Schools Interoperabily Framework (SIF) official Web site for additional information on terms of use.
Print
Image for 'Overview'
Schools Interoperability Framework logo
SIF is a blueprint for education software interoperability and data access. The Schools Interoperability Framework (SIF) is an industry initiative to develop an open specification for ensuring that K-12 instructional and administrative software applications work together more effectively. SIF is not a product, but rather an industry-supported technical blueprint for K-12 software that will enable diverse applications to interact and share data seamlessly; now and in the future.

SIF specification allows to:
  • Enhance product functionality efficiently
  • Facilitate data sharing without incurring expensive customer development costs
  • Leverage co-marketing opportunities with partners and distributors
  • Provide best of breed solutions to customers easily and seamlessly
  • Join industry leaders in creating the next generation framework for education technology
Schools Interoperabiliy Framework (SIF) Web Site
CEN Works
The CEN Workshop on Learning Technologies have produced the following CWAs related with the adaptation of the SIF proposals to the European context:
  • CWA14928. Review on SIF Infrastructure, Architecture, Message Processing and Transport Layer.
  • CWA14929. Internationalisation of SIF and harmonisation with other specs/standards.
  • CWA15155. Adaptation of SIF (Schools Interoperability Framework) Data Model for a European context.
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send