1EdTech Final Release

1EdTech logo

1EdTech Learning Information Services Specification

Version 2.0.1

Final Release

 

Date Issued: 30 September 2013

Latest version: http://www.imsglobal.org/lis/

 

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTechs procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2013 1EdTech Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.


Executive Summary

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. The LIS v2.0 specification supersedes the 1EdTech Enterprise Services v1.0 specification. The LIS specification is based upon the aggregation of the Person Management, Group Management, Membership Management, Course Management, Outcomes Management and the Bulk Data Exchange Management Services specifications. The LIS v2.0 can be implemented using a Web Services infrastructure (based upon a SOAP/http transport mechanism).

An implementation is not required to support each and every service. Neither is an implementation required to support each and every operation. The specific requirements are defined in the corresponding profile. Interoperability is supported between systems that implement the same profile. Cross-profile interoperability may occur but this is a by-product and should NOT be used as the basis for any system realization. One of the outputs of the LIS specification is the set of Web Services Description Language/XML Schema Definition (WSDL/XSD) binding files. Each service has its own set of WSDL/XSD files. It is these files that are used by code-generation tools to create the source code that handles the SOAP messages and XML data structures. Some small changes are required to the WSDL files to map the SOAP messages to the actual server-based implementation of the Web Service.

The LIS documentation set consists of:

· Information Models – these documents contain the normative description of the various service definitions, data structures and their relationships. These descriptions use the Unified Modeling Language (UML). Each of the six services has its own Information Model;

· WSDL Bindings – these documents contain the Platform Specific Model (PSM) for the service. This PSM has been transformed into the corresponding WSDL/XSD files using the 1EdTech Binding Auto-generation Tool-kit (I-BAT). The Binding document describes the underlying structure of the WSDL/XSD, the associated vocabulary files and the formats of the corresponding SOAP messages;

· Best Practice & Implementation Guide – this document is intended to provide vendors with an overall understanding of the 1EdTech LIS Specification, the relationship of the specification with other 1EdTech specifications, and a best practices guide derived from experiences of those using the specification. The guide also includes several examples that describe how vendors can make the best use of the 1EdTech LIS Specification;

· Core Profile & Conformance Specification – the Core Profile defines the minimal subset of the functionality that must be supported by systems developed for deployment between a Student Information System and a Learning Management System. This Profile (there is a Core plus several Additions) defines the set of operations and data models that must be supported by the systems implementing the set of services within the LIS. A system can support greater functionality but there is no guarantee of interoperability for those extra features. Interoperability is only guaranteed for the functionality described in the Core Profile.


1 Introduction

1.1 Learning Information Service Systems

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. The Learning Information Services specification is constructed following the recommendations documented in the 1EdTech Abstract Framework (IAF) [IAF, 03a], [IAF, 03b], [IAF, 03c]. This means that this specification is based upon the concepts of:

· Interoperability – Learning Information Services focuses on the exchange of information between Learning Information Services systems. There are no assumptions in the specification on how the data is managed within the Learning Information Services systems;

· Service-oriented – Learning Information Services defines the exchange of information in terms of the services being supplied by the collaboration of the systems;

· Component-based – the Learning Information Services 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 Learning Information 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 Learning Information Services information model is to be defined using the Unified Modeling 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) and the Lightweight Directory Access Protocol (LDAP);

· Adoption – whenever appropriate, the Learning Information Services specification makes use of other 1EdTech and non-1EdTech standards and specifications.

1.2 The Scope and Context

This document is the 1EdTech Learning Information Services Specification v2.0.1; an overview is available in [LIS, 13a]. The Learning Information Services specification supersedes the 1EdTech Enterprise Services specification [ES, 04a]. This specification is based upon the aggregation of the Person Management, Group Management, Membership Management, Course Management, Outcomes Management and the Bulk Data Exchange Management Services specifications, namely:

a) 1EdTech Person Management Service Information Model v2.0.1 [PMS, 13a];

b) 1EdTech Group Management Service Information Model v2.0.1 [GMS, 13a];

c) 1EdTech Membership Management Service Information Model v2.0.1 [MMS, 13a];

d) 1EdTech Course Management Service Information Model v1.0.1 [CMS, 13a];

e) 1EdTech Outcomes Management Service Information Model v1.0.1 [OMS, 13a];

f) 1EdTech Bulk Data Exchange Management Services Information Model v1.0.1 [BDEMS, 13a].

The Learning Information Services Specification v2.0 can be implemented using both a Web Services infrastructure (based upon a SOAP/http transport mechanism) and the LDAP. The Web Service bindings are detailed in the corresponding service binding documents [PMS, 13b], [GMS, 13b], [MMS, 13b], [OMS, 13b], [CMS, 13b], [BDEMS, 13b].

1.3 Structure of this Document

The structure of this document is:

2. The Learning Information Services Specification

Provides an overview of the specification as a whole and explains how the six component services are orchestrated to provide the full range of services;

3. The Historic Perspective

Provides the historic context for this specification as it has evolved from a pure data model to this current service description. This includes a summary of the changes from the 1EdTech Enterprise Services v1.0 specification;

4. Using the New Version

Provides an overview of the various ways in which this specification can be used to support different learning administration requirements;

5. The Document Set

Lists and explains the set of documents produced as part of the specification. This includes an explanation of the relevant set of 1EdTech GLC Specification Development Notes;

Appendix A: Person Management Service 2.0 Overview

An overview of the operations provided in the Person Management Service;

Appendix B: Group Management Service 2.0 Overview

An overview of the operations provided in the Group Management Service;

Appendix C: Membership Management Service 2.0 Overview

An overview of the operations provided in the Membership Management Service;

Appendix D: Course Management Service 1.0 Overview

An overview of the operations provided in the Course Management Service;

Appendix E: Outcomes Management Service 1.0 Overview

An overview of the operations provided in the Outcomes Management Service;

Appendix F: Bulk Data Exchange Management Service 1.0 Overview

An overview of the operations provided in the Bulk Data Exchange Management Service.

1.4 Nomenclature

BDEMS Bulk Data Exchange Management Service

CMS Course Management Service

GMS Group Management Service

IAF 1EdTech Abstract Framework

I-BAT 1EdTech Binding Auto-generation Tool-kit

1EdTech 1EdTech Consortium Inc.

LDAP Lightweight Directory Access Protocol

LIP Learner Information Packaging

LIS Learning Information Services

LMS Learning Management System

MMS Membership Management Service

OMS Outcomes Management Service

PIM Platform Independent Model

PMS Person Management Service

PSM Platform Specific Model

SIS Student Information System

UML Unified Modeling Language

URL Uniform Resource Locator

VDEX Vocabulary Definition Exchange

WSDL Web Services Description Language

XSD XML Schema Description

1.5 References

[BDEMS, 13a] 1EdTech Bulk Data Exchange Management Service Information Model v1.0.1 Final Release , L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[BDEMS, 13b] 1EdTech Bulk Data Exchange Management Service WSDL Binding v1.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[CMS, 13a] 1EdTech Course Management Service Information Model v1.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[CMS, 13b] 1EdTech Course Management Service WSDL Binding v1.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[ES, 04a] 1EdTech GLC Enterprise Services Specification Final Release v1.0, C.Smythe and C.Vento, 1EdTech Consortium, June 2004.

[ES, 04b] 1EdTech GLC Enterprise Services Use-cases Final Release v1.0, C.Smythe and C.Vento, 1EdTech Consortium, June 2004.

[GMS, 04] 1EdTech GLC Group Management Service Information Model v1.0 Final Release, C.Smythe and C.Vento, 1EdTech Consortium, June 2004.

[GMS, 13a] 1EdTech Group Management Service Information Model v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[GMS, 13b] 1EdTech Group Management Service WSDL Binding v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[GWS, 06a] 1EdTech GLC General Web Services Base Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0, 1EdTech Consortium, January 2006.

[GWS, 06b] 1EdTech GLC General Web Services WSDL Binding Guidelines Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0, 1EdTech Consortium, January 2006.

[IAF, 03a] 1EdTech Abstract Framework: Applications, Services & Components v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[IAF, 03b] 1EdTech GLC Abstract Framework: Glossary v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[IAF, 03c] 1EdTech GLC Abstract Framework: White Paper v1.0, Ed. C.Smythe, 1EdTech Consortium, July 2003.

[LIS, 13a] 1EdTech Learning Information Services Specification Overview v2.0.1 Final Release , L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[LIS, 13b] 1EdTech Learning Information Services Best Practices & Implementation Guide v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[LIS, 13c] 1EdTech Learning Information Services Core Profile v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[MMS, 04] 1EdTech GLC Membership Management Service Information Model v1.0 Final Release, C.Smythe and C.Vento, 1EdTech Consortium, June 2004.

[MMS, 13a] 1EdTech Membership Management Service Information Model v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[MMS, 13b] 1EdTech Membership Management Service WSDL Binding v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[OMS, 13a] 1EdTech Outcomes Management Service Information Model v1.0 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[OMS, 13b] 1EdTech Outcomes Management Service WSDL Binding v1.0 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[PMS, 13a] 1EdTech Person Management Service Information Model v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[PMS, 13b] 1EdTech Person Management Service WSDL Binding v2.0.1 Final Release, L.Feng, W.Lee and C.Smythe, 1EdTech Consortium, September 2013.

[SAN11, 06] 1EdTech Profile Definition, Registration and Maintenance Procedures, SAN-11, C.Smythe, 1EdTech Consortium, November 2006.

[SDN07, 06] 1EdTech GLCUML Profile for Platform Independent Model Descriptions of Specifications, SDN-07, C.Smythe, 1EdTech Consortium, October 2006.

[SDN08, 06] 1EdTech GLCUML Profile for Platform Specific Model Descriptions of Specification Bindings, SDN-08, C.Smythe, 1EdTech Consortium, October 2006.

[SDN11, 06] 1EdTech Vocabulary Definitions, Registration and Maintenance Procedures, SDN-11, C.Smythe, 1EdTech Consortium, July 2006.

[VDEX, 04] 1EdTech Vocabulary Definition Exchange Information Model v1.0, A.Cooper, 1EdTech Consortium, February 2004. http://www.imsglobal.org/vdex/

2 The Learning Information Services Specification

2.1 Core Use-cases

The core set of use-cases addressed by this specification is:

· Manage and manipulate information about People ­– to provide data exchange about people who are participating in learning;

· Manage and manipulate enrolment of People in Courses – to control the exchange of information for people attending courses;

· Manage and manipulate organizational structures – to control the exchange of information for people attending courses;

· Manage and manipulate Course structure information – to provide data exchange for information about taught courses;

· Manage and manipulate of Grade-book information – to provide data exchange for outcomes information;

· Batch processing – to provide initialization and synchronization transfer of very large amounts of data.

2.1.1 Management and Manipulate Information about People

People undertake learning and as such attend, or are members of, courses, undertake assessment and obtain grades, and undertake other groups of activities. The specific set of operational needs is:

· Initialize Person, Organization Structure, Enrolment Data;

· Synchronize Person, Organization Structure, Enrolment Data;

· Create Person;

· Change Person Information;

· Update Authentication Credentials for a Person;

· Update Authentication Credentials for all Persons;

· Get All New Persons;

· Get Updated Person Information;

· Get Deleted Persons.

2.1.2 Management and Manipulate Enrolment of People on Courses

The specific set of operational needs is:

· Enroll a Person in a Course Template, Course Offering and Course Section;

· Un-enroll a Person in a Course Template, Course Offering and Course Section;

· Change the Role of a Person in a Course Template, Course Offering and Course Section;

· Get All Enrollment Information for a Person;

· Get All Enrollment Information for All Persons.

2.1.3 Management and Manipulate Organizational Structures

The specific set of operational needs is:

· Create a Parent/Child Relationship in an Organizational Structure;

· Delete a Parent/Child Relationship in an Organizational Structure;

· Get All Persons Enrolled in an Organizational Structure Entity;

· Get All Enrollment Information for an Organizational Structure Entity;

· Use a Learning Context for Several Administrative Contexts;

· Use Differing Kinds of Learning Context for Differing Administrative Contexts.


2.1.4 Management and Manipulate Course Structure Information

The specific set of operational needs is:

· Create a Course Template, Course Offering and Course Section;

· Update Course Template, Course Offering and Course Section information;

· Update Status of Course Template, Course Offering and Course Section;

· Roll-over a Course Template, Course Offering and Course Section;

· Delete a Course Template, Course Offering and Course Section;

· Get Information for a Course Offering;

· Get All Course Offerings for a Semester;

· Get All Active Course Offerings under a Given Organization Structure Entity;

· Get Course Offerings for an Instructor;

· Get Equivalent Course Templates and Course Offerings;

· Get All Enrollment information for a Semester;

· Search for a Course Template or Offering.

2.1.5 Management and Manipulate of Grade Book Information

The specific set of operational needs is:

· Get Grade Book Information for All Persons Enrolled in a Course Offering;

· Get Grade Book Information for a Person;

· Get Grade Book Information for All Persons Enrolled in a Course Section;

· Get Grade Book Information for a Person;

· Get All Final Grade for All Persons Enrolled in a Course Offering;

· Get the Final Grade for All Active Course Offerings for a Given Person.

2.1.6 Batch Processing

There are operational points when the service consumer (the Synchronization Agent) needs to be bulk synchronized or initialized with, or by, the service provider (the Reference Agent). The synchronization/initialization point is typically declared as changes from a particular reference point. Specific synchronization/initialization needs are:

· Batch Initialization and Synchronization of all Person objects;

· Batch Initialization and Synchronization of all Group objects;

· Batch Initialization and Synchronization of all Membership objects;

· Batch Initialization and Synchronization of all Course Template objects;

· Batch Initialization and Synchronization of all Course Offering objects;

· Batch Initialization and Synchronization of all Course Section objects;

· Batch Initialization and Synchronization of all Grade-book objects;

· Batch Initialization of everything.


 

2.2 An Abstract Representation

The basic architectural model for the LIS specification is shown in Figure 2.1. In this architecture the scope of the data exchange provided by the services is shown as the dotted line. The scope of the interoperability is the data and behavioral models of the objects being exchanged.

Figure 2.1 Schematic architecture of the learner information services.

Six services are defined. Instances of the data models are stored in the service consumer/provider object repositories. It is the persistence of the data in these repositories that reflects the dynamic changes in the system. The set of services are realized as SOAP messages to exchange the XML-based data object.

2.3 Building Real Systems

An implementation is not required to support each and every service. Neither is an implementation required to support each and every operation. The specific requirements are defined in the corresponding profile[1]. Interoperability is supported between systems that implement the same profile. Cross-profile interoperability may occur but this is a by-product and should NOT be used as the basis for any system realization.

One of the outputs of the LIS specification is the set of WSDL/XSD binding files. Each service has its own set of WSDL/XSD files. It is these files that are used by code-generation tools to create the source code that handles the SOAP messages and XML data structures. Some small changes are required to the WSDL files to map the SOAP messages to the actual server-based implementation of the Web Service. These changes can either be manually applied to the WSDL files or to the UML files. The UML files must then be processed using the 1EdTech GLC Binding Auto-generation Tool-kit (I-BAT) to create the new, tailored WSDL/XSD files.

3 The Historic Perspective

3.1 Past Versions

The release history for the LIS is listed in Table 3.1. The original Enterprise v1.0 data model was the second specification released by 1EdTech. It has undergone several revisions in response to feedback from the experience gained in the various implementations.

Table 3.1 Version history for Enterprise/LIS specifications.

Version

Release Date

Description

Enterprise 1.0

November, 1999

Original data model for Enterprise systems interoperability.

Enterprise 1.0.1

January, 2000

Correction of a small number of bugs identified in version 1.

Enterprise 1.1

July, 2002

Revised data model to introduce new functionality based on commonly used extensions.

Enterprise Services v1.0

August, 2004

Introduction of services, based upon the 1EdTech General Web Services, to support the exchange of the information based upon the Enterprise v1.1 data model.

LIS v2.0 is a radical reworking of both the original services and data models.

3.2 A Summary of Changes from Version 1

3.2.1 Person Management Service

The functional changes in version 2 compared to version 1 are:

a) A single service interface is used. With the exception of the ‘ReadPersons’ operation all of the operations in the original ‘Persons Manager’ interface have been removed;

b) The ‘ReadPersons’ operation has been changed such that it returns a single StatusInfo object;

c) New service operations have been added, namely:

  • ReadCorePerson – to read information that is defined as the ‘core’ Person
  • ReadAllPersonIds – to read all of the SourcedIds allocated in the target system
  • ReadPersonIdsFromSavePoint – to read all of the SourcedIds for Person objects that have been altered since the defined reference point
  • ReadPersonsFromSavePoint – to read all of the Person objects, that have been altered since the defined reference point
  • DiscoverPersonIds – to provide the SourcedIds of the Person objects that are identified by the completion of the requested query operation;

d) The core data model has been extended to support both the PMSv1.0 and the 1EdTech Learner Information Packaging (LIP) v1.0 ‘identification’ data models. The data model has also been modified to use external vocabularies.

3.2.2 Group Management Service

The changes in version 2 compared to version 1 are:

a) A single service interface is used. With the exception of the ‘ReadGroups’ operation all of the operations in the original ‘GroupsManager’ interface have been removed;

b) The ‘ReadGroups’ operation has been changed such that it returns a single StatusInfo object;

c) New service operations have been added, namely:

  • ReadAllGroupIds – to read all of the SourcedIds allocated in the target system
  • AddGroupRelationship – to add a relationship between two Group objects
  • RemoveGroupRelationship – to remove a relationship between two Group objects
  • ReadGroupIdsForPerson – to read all of the SourcedIds for Group objects for a specific Person object
  • ReadGroupIdsFromSavePoint – to read all of the SourcedIds for Group objects that have been altered since the defined reference point
  • ReadGroupsFromSavePoint – to read all of the Group objects, that have been altered since the defined reference point
  • DiscoverGroupIds – to provide the SourcedIds of the Group objects that are identified by the completion of the requested query operation;

d) Version 1.0 implementations of the Group Management Service were used to exchange information about courses. For Version 2 this is only permitted for additional features that are added to the Course Management Service capabilities (see [CMS, 12a] for more details).

3.2.3 Membership Management Service

The changes in version 2 compared to version 1 are:

a) A single service interface is used. With the exception of the ‘ReadMemberships’ operation all of the operations in the original ‘MembershipsManager’ interface have been removed;

b) The ‘ReadMemberships’ operation has been changed such that it returns a single StatusInfo object;

c) New service operations have been added, namely:

  • ReadAllMembershipIds – to read all of the SourcedIds allocated in the target system to a Membership object
  • ReadMembershipIdsForPerson – to read all of the SourcedIds for Membership objects for a specific Person object
  • ReadMembershipIdsForPersonWithRole – to read all of the SourcedIds for Membership objects for a specific Person object with a specific role
  • ReadMembershipIdsForCollection – to read all of the SourcedIds for Membership objects for a specific type of object i.e., Group, CourseTemplate, CourseOffering, CourseSection and SectionAssociation
  • ReadMembershipIdsFromSavePoint – to read all of the SourcedIds for Membership objects that have been altered since the defined reference point
  • ReadMembershipsFromSavePoint – to read all of the Membership objects, that have been altered since the defined reference point
  • DiscoverMembershipIds – to provide the SourcedIds of the Membership objects that are selected by the application of the requested query operation;

d) The data model has been modified such that:

  • The final and interim results structures have been removed (these are now supported using the Outcome Management Service [OMS, 12a ])
  • The ‘recordInfo’ attribute has been redefined as a type of meta-data
  • A Group cannot have a membership of a Group. Therefore, the ‘memberIdType’ attribute has been removed because it is now unnecessary i.e., only a Person object can be a member of a Group, etc.

3.2.4 Course Management Service

The Course Management Service was not part of the 1EdTech Enterprise Services v1.0 specification [ES, 04a]. Instead, this functionality was supported using the 1EdTech Group Management Service v1.0 [GMS, 04] specification in a variety of different ways. This created interoperability problems hence the creation of the CMS specification. The Course Management Service v1.0 is closely linked to the Group Management Service v2.0 and Membership Management Service (MMS) v2.0. The MMS is used to define the participants in a Course defined by the CMS and Courses are extended using the GMS. Therefore the GMS and MMS must be implemented to obtain the full functionality of the CMS.

3.2.5 Outcomes Management Service

The Outcomes Management Service was not developed in the 1EdTech GLC Enterprise Services v1.0 specification [ES, 04a]. Instead, a simplified form of functionality was supported using the 1EdTech Membership Management Services (MMS) v1.0 [MMS, 04]. In general, there is NO backwards compatibility between the usage of the OMSv1.0 and the ways in which MMSv1.0 has been implemented to support outcomes management. Vendors may define compatibility bridges for their own implementations but these are outside the scope of this specification.

3.2.6 Bulk Data Exchange Management Service

The Bulk Data Exchange Management Service was not developed in the 1EdTech Enterprise Services v1.0 specification [ES, 04a]. Instead a series of best practices were defined to achieve data synchronization and initialization. These are now replaced by the use of the BDEMS.

3.3 Version 2 and Version 1 Compatibility

The release of the Learning Information Services 2.0 creates the issue of compatibility between version 1 and version 2 implementations. Compatibility issues occur when:

a) A version 1 service implementation initiates data exchange with a version 2 implementation;

b) A version 2 service implementation initiates data exchange with a version 1 implementation.

The binding of the Information Model recommends that the Uniform Resource Locator (URL) for the messaging actions is dependent on the type and version number of the source specification: in such a case it is not possible for cross-interaction between implementations of version 1 and 2. However, if a common URL is used then cross-interaction becomes possible. The definition of the behavior for interactions between different versions is beyond the scope of this specification.

4 Using the New Version

4.1 Building an Interoperable Solution

The LIS Best Practices & implementation Guide [LIS, 12b] provides a detailed set of guidance notes on issues to consider when implementing the LIS specification. The LIS specification describes interoperability and so it is silent on many aspects of deploying operational systems. However the most essential interoperability features to address in an implementation of LIS are:

· LIS consists of six services and an implementation may support one, many or all of them. Correct operation of some of the services depends on other services (or the equivalent functionality being supplied). For example, the MMS requires the PMS and either the GMS or the CMS: membership is the act of a Person becoming a member of a Group or Course and so the creation of a Membership can only be achieved if the corresponding Person and Group/Course objects have already been created. The specification does not address this inter-service choreography, in terms of messaging sequencing, but it must be addressed as part of the creation of an operational end system;

· The Web Services implementation for each of the services is based upon the 1EdTech General Web Services (GWS) specification (this is a profile of the WS-I Basic Profile v1.1). This describes how the SOAP messages must be constructed and includes a simple request/response message correlation mechanism. It also includes the mechanism by which the end-system transaction status information is reported. It is essential that APIs that implement the GWS and the LIS pass this information, in suitable form, to the corresponding end-system applications. Furthermore, conformance requires that the defined status information is returned for requests that are made on services or operations that are not supported by an implementation i.e., a transaction request must always receive a transaction response;

· The specification uses the terms Ref Agent, Sync Agent, Service Provider and Service Consumer. A Service Consumer is an end-system that calls a service i.e., issues the request message. A Service Provider is an end-system that provides the service and returns a response message. A Ref Agent is a business function description for the end-system that is to be used as the definitive source of information i.e., the reference. The Sync Agent is the corresponding end-system that is to be synchronized with the Ref Agent. With the exception of the BDEMS the Ref Agent pushes information out (create and write data) and the Sync Agent pulls the data in (read data). When the Ref Agent pushes data out the Sync Agent is the Service Provider, whereas, when the Sync Agent pulls the data in the Ref Agent is the Service Provider. In the case of system exchanges, such as the SIS and LMS, then depending on the nature of the service they may be either the Ref Agent or the Sync Agent (hence in an extensive implementation of LIS an end system may be both a Ref and Sync Agent depending on the service). For example, in the case of course enrollment the SIS is the Ref Agent and the LMS the Sync Agent whereas for grade reporting the LMS is the Ref Agent and the SIS the Sync Agent;

· Apart from the BDEMS, the services operate in real-time i.e., a request message is sent and the calling end system (the service consumer) waits (formally termed blocked) until the corresponding response message is received (an implementation should consider timeout issues as part of error handling). This is also termed a synchronous service. The BDEMS operates as a batch service (this is also termed asynchronous). In this case a request for data file transfer is made, this request is acknowledged, at some time later the data file is made available and downloaded, and finally a report of the data file downloading is reported. During this operation, the real-time/synchronous service calls are blocked i.e., not permitted to the service provider. However real-time exchanges with other service providers are permitted. Real-time processing recommences once the batch exchanges have been completed or cancelled;

· The data models have two uses. The first is to define the permitted contents in the SOAP messages and the second is to inform the end-system data storage implications. In general, all of the contents in a SOAP message are optional. This is because there can never be a guarantee that a required piece of data is available e.g., for a failed read attempt there will be no data and so any ‘mandatory’ data will be missing. In the case of end-system provisioning, an end-system must support one instance of any object that is either required or optional and has a multiplicity of one. In the case of multiplicities of greater than one then the maximum number of supported instantiations is implementation dependent. In the case of a profile, whenever a smallest permitted maximum is defined then an end system implementation must support at least that number of instantiations. If a request attempts to exceed either a service consumer or service provider implementation constraint then the corresponding status code must be returned;

· SourcedIds are used to uniquely identify object instances. In an ideal implementation the SourcedIds would be globally unique identifiers. However, practical constraints normally make it impossible to make this assumption. A SourcedId must be unique between the communicating end-systems. It is possible that SourcedIds could be reused in different services because the use of a SourcedId is always presented in the context of a specific service and its associated data model. It is recommended that an implementation assume that a SourcedId is only unique to a service i.e., all SourcedId processing should be accompanied by the service context also being used. This provides the most robust implementation;

· It is important to note that the use of the LIS specification does not provide ‘out-of-the-box’ interoperability. This is not a failure of the specification but a reflection of the pragmatic nature of agreeing such a specification and enabling commercial competitiveness. Many system architecture aspects are not addressed by the specification e.g., service link initialization by which two end systems become aware of the capabilities supported by the other, service integrity and security, etc. This type of information is exchanged using either an out-of-band set of services or as part of service deployment and configuration.

4.2 The Core Profiles

The Core Profiles identify the minimal subset of the functionality that must be supported by systems developed for Student Information System/Learning Management System (SIS/LMS) deployment. These Profiles (there is a Core plus several Additions) define the set of operations and data models that must be supported by the systems supporting the set of services within the LIS. A system can support greater functionality but there is no guarantee of interoperability for those extra features. Interoperability is only guaranteed for the functionality described in the Core Profiles.

The Core Profile consists of:

· The deletePerson, readPerson (required for conformance testing only) and replacePerson operations for the Person Management Service;

· The deleteMembership, readMembership (required for conformance testing only) and replaceMembership operations for the Membership Management Service;

· The deleteCourseSection, readCourseSection (required for conformance testing only) and replaceCourseSection operations for the Course Management Service;

· The announceBulkDataExchange, reportBulkDataExchange, ignoreBulkDataExchange and SOAP-based file download operations for the Bulk Data Exchange Management Service.

The three Addition Profiles are:

· Final Grade – provides support for the management of grades and grade books using the Outcomes Management Service;

· Combined Sections – provides support for the management of SectionAssociations using the Course Management Service

· Full Course Hierarchy – provides support for the management of the full course structure (templates, offerings, sections and section associations) using the Course Management Service.

4.3 Creating a Profile

If the Core Profile, either alone or in combination with one or more of the Addition Profiles, is inadequate then a new profile can be created and registered with 1EdTech [SAN11, 06]. The recommended steps for creating a profile of the LIS are:

· Identify which of the six services are to be included in the Profile;

· For each service identify the set of operations that are to be included in the Profile of the service;

· For each operation identify the set of status codes that are to be supported in the Profile of the operation;

· For each data model in each service identify which parts of any vocabulary are to be supported in the Profile of the vocabulary. If appropriate, or necessary, new vocabularies should be defined to replace the corresponding default vocabularies;

· For each data model identify any increased constraints on the multiplicity of any attributes i.e., optional can become mandatory, optional can be prohibited and many can be reduced to one.

It is recommended that the profile be documented using the original Unified Modeling Language (UML) Platform Independent Model (PIM)/Platform Specific Model (PSM) descriptions. Each change should have a documented comment. Once the Profile has been completed, the I-BAT should be used to generate the new WSDL/XSD from the profiled UML PSM.

4.4 Conformance to a Profile

Conformance to LIS is non-trivial even when this is against a Profile. An inclusive approach to conformance has been adopted. The conformance statement for a profile is described as the set of business capabilities that are supported by the Profile e.g., student enrolment in a course, reporting of a student result, etc. An implementation claiming conformance must identify which of the capabilities are supported; this takes the form of a checklist. Therefore, interoperability between two systems is determined by the extent of the overlap in the corresponding checklists.

As an aid to implementers, once the business capability checklist has been produced a corresponding functional map is produced. This functional map identifies the set of services, operations and data model features that must be supported to realize the business capability. Any list of business capabilities will require a common set of LIS functional capabilities (the extent defines how much of the LIS is required to support a Profile). This list of functionality defines how a business capability MUST be realized using the LIS specification.

This approach has been used to allow incremental adoption of the LIS specification. Therefore, there are degrees of interoperability and it becomes the responsibility of developers to clearly identify which features of the LIS specification are implemented. Over time, the degree of interoperability across the community should increase.

5 The Document Set

5.1 The Set of Documents

5.1.1 The LIS Specification

This document. It describes how the LIS is composed using its six component services. There is an overview version of this document [LIS, 12a]. A schematic representation of the document set is shown in Figure 5.1.

5.1.2 Information Models

The Information Model documents contain the normative description of the various service definitions, data structures and their relationships. These descriptions use the UML, and in particular, the 1EdTech GLC UML Profile Platform Independent Model (PIM) Description for Specifications [SDN07, 06]. Each of the six services has its own Information Model [PMS, 12a], [GMS, 12a], [MMS, 12a], [CMS, 12a], [OMS, 12a] and [BDEMS, 12a].

5.1.3 WSDL Bindings

The WSDL Binding documents contain the PSM for the service. This PSM has been transformed into the corresponding Web Services Description Language (WSDL) and XML Schema Definition (XSD) files using the I-BAT. The Binding document describes the underlying structure of the WSDL/XSD, the associated Vocabulary Definition Exchange (VDEX) vocabulary files and the formats of the corresponding SOAP messages.

5.1.4 Best Practice & Implementation Guide

The 1EdTech LIS Best Practice and Implementation Guide [LIS, 12b] is intended to provide vendors with an overall understanding of the 1EdTech GLC LIS Specification, the relationship of the specification with other 1EdTech specifications, and a best practices guide derived from experiences of those using the specification[2]. The guide also includes a several actual examples that describe how vendors can make the best use of the 1EdTech LIS Specification.

5.1.5 Core Profile & Conformance Specification

Core Profiles for the LIS have been created [LIS, 12c]. The Core Profiles identifies the minimal subset of the functionality that must be supported by systems developed for SIS/LMS interaction. This Profile (there is a Core plus several Additions) defines the set of operations and data models that must be supported by the systems implementing the set of services within the LIS. A system can support greater functionality but there is no guarantee of interoperability for those extra features. Interoperability is only guaranteed for the functionality described in the HE Profiles.

For the Core and the set of Additions there is a set of conformance statements. These statements constitute the Conformance Specification for each profile.

5.1.6 Related Documents

The following related documents were used to support the development of this specification:

· 1EdTech General Web Services Base Profile Final Release [GWS, 06a] – provides the definition of how a service is to be implemented using SOAP-based Web Services

· 1EdTech GLC General Web Services WSDL Binding Guidelines Final Release [GWS, 06b] – provides the context by which the WSDL description is derived from the UML-based Information Model;

· 1EdTech GLC SDN 07: UML Profile for PIM Descriptions of Specifications [SDN07, 06] – provides the definition and description of the syntax and semantic of the UML profile used for the PIM description of the data models in the set of information model documents;

· 1EdTech GLC SDN 08: UML Profile for PSM Descriptions of Specification Bindings [SDN08, 06] – provides the definition and description of the syntax and semantics of the UML Profile used for the PSM description of the XML Binding aspects of the service definitions;

· 1EdTech GLC SDN 11: Vocabulary Definition, Registration and Maintenance Procedures [SDN11, 06] – provides the definition and description of how the set of external attribute vocabularies are expressed as instances of the 1EdTech Vocabulary Definition Exchange (VDEX) specification [VDEX, 04].

5.2 The Binding Files

5.2.1 WSDL Files

Each of the services has a WSDL file that describes the nature of the service. Each service has a single combined WSDL/XSD file. Separate WSDL and XSD files are also available.

5.2.2 XSD Files

Apart from the separate XSD file that complements the corresponding separate WSDL file, there are other XSD files. These files are used to validate the content of external data files that are exchanged in the BDEMS using an appropriate file transfer protocol.

5.2.3 Vocabulary Files

Each of the services has a set of VDEX files that contain the set of default vocabularies defined in the Information Model. The VDEX files conform to the 1EdTech VDEX specification [VDEX, 04].

5.3 Using the Documents

The documentation set of the 1EdTech Learning Information Services Specification is daunting. However, a few simple guidelines make it considerably easier for even a newcomer to work through the documents.

Figure 5.1 Schematic representation of the documentation set.

A schematic representation of the document set is shown in Figure 5.1 and the recommended approach to reviewing the set is:

a) Always start with the specification overview (the shorter version of this document);

b) The 1EdTech LIS Best Practices & Implementation Guide is an excellent way to understand the why, what, and how of a specification. The set of examples described in the guide is an excellent way to understand what is being created by the specification. The guide should always be read before attempting to work through either the Information Models or the WSDL Bindings;

c) Once the set of examples has been digested, it is time to work through the Information Models. These models provide the formal definition of all of the service operations, data structures and their behaviors and relationships;

d) Finally, work through the WSDL Binding documents. Often, only the implementation/engineering team needs to understand the details of these documents. Each binding document is the definitive statement of how interoperability is achieved using WSDL. The WSDL Bindings are formally realized as the WSDL/XSD files (these files can be used to generate the corresponding SOAP messages);

The 1EdTech LIS Core Profiles [LIS, 12c] should be used as the basis for providing the core service capability. This profile identifies the minimal set of service operations that are required to create a ‘useful’ learning information service (the profile identified less than 5% of the full set of service operations as necessary).

Appendix A Person Management Service 2.0 Overview

A1 PMS Description

The Person Management Service is used to model the service responsible for manipulating information about people. The PersonManagementService interface is shown in Figure A1.1.

Figure A1.1 PersonManagementService interface definition.

A2 PMS Operations

The PersonManager interface class describes the operations that are permitted on Person objects. These operations are based upon the classic Create/Read/Update/Delete model with variations defined to differentiate subtleties of functionality. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table A2.1.

Table A2.1 Summary of operations for PersonManager.

Operation

Description

createPerson

To request the creation of a populated Person object on the target system where the source is responsible for the allocation of the unique identifier.

createByProxyPerson

To request the creation of a populated Person object on the target system where the target is responsible for the allocation of the unique identifier.

deletePerson

To request the deletion of a Person object. The Person object is deleted and all of its associated Memberships.

readPerson

To read the full contents of the identified Person object. The target must return all of the data it has for the identified Person object.

readPersonCore

To read the minimal mandatory contents of the identified Person object. Only the data structures that form the core of a Person object must be returned.

readAllPersonIds

To obtain the set of identifiers which have been assigned to Person objects.

readPersonIdsFromSavePoint

To obtain the set of identifiers for Person objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readPersons

To obtain the Person objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readPersonsFromSavePoint

To obtain the set of Person objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

updatePerson

To write new content into the identified Person object. The target must write the new data into the Person object. This is an additive operation.

replacePerson

To replace the content of the identified Person object. The target must write the new data into the Person object. This is a destructive write-over of all of the original information. If the Person object does not exist, this operation acts as per a ‘createPerson’ request.

discoverPersonIds

To obtain the set of identifiers for Person objects whose properties agree with those defined in the query.

changePersonIdentifier

To change the SourcedId of the Person object. The completion of this operation will result in later actions using the original SourcedId reporting an unknown identifier status.

Appendix B Group Management Service 2.0 Overview

B1 GMS Description

The Group Management Service is used to model the service responsible for manipulating information about Groups. The GroupManagementService is shown in Figure B1.1.

Figure B1.1 GroupManagementService interface definition.

B2 GMS Operations

The GroupManager interface class describes the operations that are permitted on Group objects. These operations are based upon the classic Create/Read/Update/Delete model with variations defined to differentiate subtleties of functionality. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table B2.1.

Table B2.1 Summary of operations for GroupManager.

Operation

Description

createGroup

To request the creation of a populated Group object on the target system where the source is responsible for the allocation of the unique identifier.

createByProxyGroup

To request the creation of a populated Group object on the target system where the target is responsible for the allocation of the unique identifier.

deleteGroup

To request the deletion of a Group. All of the associated Membership objects are also deleted.

addGroupRelationship

To request the creation of a relationship between two Group objects. This does not create the Group objects themselves.

removeGroupRelationship

To request the deletion of a relationship between two Group objects. This does not delete the Group objects themselves.

readGroup

To read the full contents of the identified Group object. The target must return all of the data it has for the identified Group object.

readAllGroupIds

To obtain the set of identifiers which have been assigned to Group objects.

readGroupIdsForPerson

To read the identifiers for all of the Group objects associated with the identified Person object.

readGroupIdsFromSavePoint

To obtain the set of identifiers for Group objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readGroups

To obtain the Group objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readGroupsFromSavePoint

To obtain the set of Group objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

updateGroup

To write new content into the identified Group object. The target must write the new data into the Group object. This is an additive operation.

replaceGroup

To replace the content of the identified Group object. The target must write the new data into the Group object. This is a destructive write-over of all of the original information. If the Group object does not exist, this operation acts as per a ‘createGroup’ request.

discoverGroupIds

To obtain the set of identifiers for Group objects whose properties agree with those defined in the query/filter.

changeGroupIdentifier

To change the identifier of the Group object. The completion of this operation will result in later actions using the original identifier reporting an unknown identifier status.

Appendix C Membership Management Service 2.0 Overview

C1 MMS Description

The Membership Management Service is used to model the service responsible for manipulating information about people’s memberships of Groups [GMS, 12a] and Courses [CMS, 12a]. The MembershipManagementService is shown in Figure C1.1.

Figure C1.1 MembershipManagementService interface definition.

C2 MMS Operations

The MembershipManager interface class describes the operations that are permitted on Membership objects. These operations are based upon the classic Create/Read/Update/Delete model with variations defined to differentiate subtleties of functionality. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table C2.1.

Table C2.1 Summary of operations for the MMS.

Operation

Description

createMembership

To request the creation of a populated Membership object on the target system where the source is responsible for the allocation of the unique identifier.

createByProxyMembership

To request the creation of a populated Membership object on the target system where the target is responsible for the allocation of the unique identifier.

deleteMembership

To request the deletion of a Membership object. The Membership object is deleted along with all of its associated relationships (the associated Group, Course and Person objects are not deleted).

readMembership

To read the full contents of the identified Membership object. The target must return all of the data it has for the identified Membership object.

readMembershipIdsForPerson

To obtain the set of identifiers for all of the Membership objects for the identified Person object.

readMembershipIdsForPersonWithRole

To obtain the set of identifiers for all of the Membership objects for the identified Person object with a specific Member Role.

readMembershipIdsForCollection

To obtain the set of identifiers for all of the Membership objects for the identified collection object i.e., Group, CourseTemplate, CourseOffering, CourseSection or SectionAssociation.

readAllMembershipIds

To obtain the set of identifiers which have been assigned to Membership objects.

readMembershipIdsFromSavePoint

To obtain the set of identifiers for Membership objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readMemberships

To obtain the Membership objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readMembershipsFromSavePoint

To obtain the set of Membership objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

updateMembership

To write new content into the identified Membership object. The target must write the new data into the Membership object. This is an additive operation.

replaceMembership

To replace the content of the identified Membership object. The target must write the new data into the Membership object. This is a destructive write-over of all of the original information. If the Membership object does not exist, this operation acts as per a ‘createMembership’ request.

discoverMembershipIds

To obtain the set of identifiers for Membership objects whose properties agree with those defined in the query.

changeMembershipIdentifier

To change the SourcedId of the Membership record. The completion of this operation will result in subsequent actions using the original SourcedId reporting an unknown identifier status.

Appendix D Course Management Service 1.0 Overview

D1 CMS Description

The Course Management Service is used to model the service responsible for manipulating information about course structures. The CourseManagementService interfaces are shown in Figures D1.1, D1.2, D1.3 and D1.4.

Figure D1.1 CourseManagementService CourseTemplateManager interface definition.

Figure D1.2 CourseManagementService CourseOfferingManager interface definition.

Figure D1.3 CourseManagementService CourseSectionManager interface definition.

Figure D1.4 CourseManagementService SectionAssociationManager interface definition.

D2 CMS Operations

The Course Management Service is defined by four interfaces: CourseTemplateManager that supports the manipulation of CourseTemplates; CourseOfferingManager that supports the manipulation of CourseOfferings; CourseSectionManager that supports the manipulation of CourseSections; and SectionAssociation Manager that supports the manipulation of SectionAssociations.

D2.1 CourseTemplateManager Interface Description

The CourseTemplateManager interface class describes the operations on a CourseTemplate. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table D2.1.

Table D2.1 Summary of operations for CourseTemplateManager.

Operation

Description

createCourseTemplate

To request the creation of a populated CourseTemplate object on the target system where the source assigns the unique identifier.

createByProxyCourseTemplate

To request the creation of a populated CourseTemplate object on the target system where the target assigns the unique identifier.

deleteCourseTemplate

To request the deletion of a CourseTemplate object. The CourseTemplate object is deleted and all of its associated relationships.

readCourseTemplate

To read the full contents of the identified CourseTemplate object. The target must return all of the data it has for the CourseTemplate object.

readAllCourseTemplateIds

To obtain the set of SourcedIds which have been assigned to CourseTemplate objects.

readCourseOfferingIdsForCourseTemplate

To obtain the set of SourcedIds of the CourseOfferings associated with the CourseTemplate.

readCourseTemplateIdsFromSavePoint

To obtain the set of SourcedIds for CourseTemplates objects which have been altered since the requested reference point. The reference point is set as zero at creation and incremented after every write operation.

readCourseTemplates

To get the CourseTemplate objects for a defined set of SourcedIds. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readCourseTemplatesFromSavePoint

To obtain the set of CourseTemplate objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

updateCourseTemplate

To write new content into the identified CourseTemplate object. The target must write the new data into the CourseTemplate object. This is an additive operation.

replaceCourseTemplate

To replace the content of the identified CourseTemplate object. The target must write the new data into the CourseTemplate object. This is a destructive write-over of all of the original information. If the CourseTemplate object does not exist, this operation acts as per a ‘createCourseTemplate’ request.

discoverCourseTemplateIds

To obtain the set of SourcedIds for CourseTemplate objects whose properties agree with those defined in the query.

changeCourseTemplateIdentifier

To change the SourcedId of the CourseTemplate record. The completion of this operation will result in later actions using the original SourcedId reporting an unknown identifier status.

D2.2 CourseOfferingManager Interface Description

The CourseOfferingManager interface class describes the operations that are permitted on a CourseOffering. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table D2.2.

Table D2.2 Summary of operations for CourseOfferingManager.

Operation

Description

createCourseOffering

To request the creation of a populated CourseOffering object on the target system where the source is responsible for the allocation of the unique identifier.

createByProxyCourseOffering

To request the creation of a populated CourseOffering object on the target system where the target is responsible for the allocation of the unique identifier.

createCourseOfferingFromCourseOffering

To create a new CourseOffering from the supplied CourseOffering for a particular academic session.

deleteCourseOffering

To request the deletion of a CourseOffering object. The CourseOffering object is deleted and all of its associated relationships.

readCourseOffering

To read the full contents of the identified CourseOffering object. The target must return all of the data it has for the identified CourseOffering object.

readAllCourseOfferingIds

To obtain the set of SourcedIds which have been assigned to CourseOffering objects.

readAllActiveCourseOfferingIdsForAcademicSession

To obtain the set of SourcedIds for all of the active CourseOfferings for the identified academic session.

readCourseSectionIdsForCourseOffering

To obtain the set of SourcedIds of the CourseSections associated with the CourseOffering.

readCourseOfferingIdsFromSavePoint

To obtain the set of SourcedIds for CourseOfferings objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readCourseOfferings

To obtain the CourseOffering objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readCourseOfferingsFromSavePoint

To obtain the set of CourseOffering objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

replaceCourseOffering

To replace the content of the identified CourseOffering object. The target must write the new data into the CourseOffering object. This is a destructive write-over of all of the original information. If the CourseOffering object does not exist, this operation acts as per a ‘createCourseOffering’ request.

updateCourseOffering

To write new content into the identified CourseOffering object. The target must write the new data into the CourseOffering object. This is an additive operation.

updateCourseOfferingStatus

To change the status of the identified CourseOffering to the supplied value.

discoverCourseOfferingIds

To obtain the set of SourcedIds for CourseOffering objects whose properties agree with those defined in the query.

changeCourseOfferingIdentifier

To change the SourcedId of the CourseOffering record. The completion of this operation will result in later actions using the original SourcedId reporting an unknown identifier status.


 

D2.3 CourseSectionManager Interface Description

The CourseSectionManager interface class describes the operations that are permitted on a CourseSection. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table D2.3.

Table D2.3 Summary of operations for CourseSectionManager.

Operation

Description

createCourseSection

To request the creation of a populated CourseSection object on the target system where the source is responsible for the allocation of the unique identifier.

createByProxyCourseSection

To request the creation of a populated CourseSection object on the target system where the target is responsible for the allocation of the unique identifier.

createCourseSectionFromCourseSection

To create a new CourseSection from the supplied CourseSection for a particular academic session.

deleteCourseSection

To request the deletion of a CourseSection object. The CourseSection object is deleted along with all of its associated Memberships.

readCourseSection

To read the full contents of the identified CourseSection object. The target must return all of the data for the identified CourseSection object.

readAllCourseSectionIds

To obtain the set of sourcedIds which have been assigned to CourseSection objects.

readCourseSectionIdsFromSavePoint

To obtain the set of sourcedIds for CourseSection objects which have been altered since the supplied reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readCourseSections

To obtain the CourseSection objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readCourseSectionsFromSavePoint

To obtain the set of CourseSection objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

replaceCourseSection

To replace the content of the identified CourseSection object. The target must write the new data into the CourseSection object. This is a destructive write-over of all of the original information. If the CourseSection object does not exist, this operation acts as per a ‘createCourseSection’ request.

updateCourseSection

To write new content into the identified CourseSection object. The target must write the new data into the CourseSection object. This is an additive operation.

updateCourseSectionStatus

To change the status of the identified CourseSection.

discoverCourseSectionIds

To obtain the set of SourcedIds for CourseSection objects whose properties agree with those defined in the query.

changeCourseSectionIdentifier

To change the SourcedId of the CourseSection record. The completion of this operation will result in later actions using the original SourcedId reporting an unknown identifier status.

D2.4 SectionAssociationManager Interface Description

The SectionAssociationManager interface class describes the operations that are permitted on a SectionAssociation. The interface stereotype indicates that there are no attributes. The operations are summarized in Table D2.4.

Table D2.4 Summary of operations for SectionAssociationManager.

Operation

Description

createSectionsAssociation

To request the creation of a populated SectionsAssociation object on the target system where the source is responsible for the allocation of the unique identifier.

createByProxySectionsAssociation

To request the creation of a populated SectionsAssociation object on the target system where the target is responsible for the allocation of the unique identifier.

deleteSectionAssociation

To request the deletion of a SectionAssociation object. The SectionAssociation object is deleted and all associated relationships.

readSectionAssociation

To read the full contents of the identified SectionAssociation object. The target must return all of the data it has for the identified SectionAssociation object.

readAllSectionsAssociationIds

To obtain the set of SourcedIds which have been assigned to SectionAssociation objects.

readSectionAssociationIdsFromSavePoint

To obtain the set of SourcedIds for SectionAssociations objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readCourseSectionAssociations

To obtain the SectionAssociation objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readSectionAssociationsFromSavePoint

To obtain the set of SectionAssociation objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

addCourseSection

To add a new Course Section identifier to the SectionAssociation.

removeCourseSection

To remove a Course Section identifier from the SectionAssociation.

replaceSectionAssociation

To replace the content of the identified SectionAssociation object. The target must write the new data into the SectionAssociation object. This is a destructive write-over of the original information. If the SectionAssociation object does not exist, this operation acts as per a ‘create SectionAssociation’ request.

updateSectionAssociation

To write new content into the identified SectionAssociation object. The target must write the new data into the SectionAssociation object. This is an additive operation.

discoverSectionAssociationIds

To obtain the set of sourcedIds for SectionAssociation objects whose properties agree with those defined in the query.

changeSectionAssociationIdentifier

To change the sourcedId of the SectionAssociation record. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.

Appendix E Outcomes Management Service 1.0 Overview

E1 OMS Description

The Outcomes Management Service is used to model the service responsible for manipulating information about outcomes. The Outcomes Management Service interfaces are shown in Figures E.1, E.2 and E.3.

Figure E1.1 OutcomesManagementService LineItemManager interface definitions.


Figure E1.2 OutcomesManagementService ResultManager interface definitions.

Figure E1.3 OutcomesManagementService ResultValueManager interface definitions.

E2 OMS Operations

The Outcomes Management Service is split into three interfaces: LineItemManager that supports the manipulation of LineItem objects; ResultManager that supports the manipulation of Result objects; ResultValueManager that supports the manipulation of ResultValue objects.

E2.1 LineItemManager Interface Description

The LineItemManager interface class describes the operations that are permitted on LineItems object (as shown in Figure E1.1). The set of operations are summarized in Table E2.1.

Table E2.1 Summary of operations for LineItemManager.

Operation

Description

createLineItem

To request the creation of a populated LineItem object on the target system where the source is responsible for the allocation of the unique SourcedId.

createByProxyLineItem

To request the creation of a populated LineItem object on the target system where the target is responsible for the allocation of the unique SourcedId.

deleteLineItem

To request the deletion of a LineItem object. The LineItem object is deleted with all of its associated relationships.

readLineItem

To read the full contents of the identified LineItem object. The target must return all of the data it has for the identified LineItem object.

readAllLineItemIds

To obtain all the SourcedIds assigned to LineItem objects.

readLineItemIdsWithLineItemType

To obtain the set of SourcedIds for the LineItem objects which have a particular state.

readLineItemIdsForPerson

To obtain the set of SourcedIds for the LineItem objects which are associated with a particular Person object.

readLineItemIdsForCourseOffering

To obtain the set of SourcedIds for the LineItem objects which are associated with a particular CourseOffering object.

readLineItemIdsForCourseSection

To obtain the set of SourcedIds for the LineItem objects which are associated with a particular CourseSection object.

readLineItemIdsForCourseSectionWithLineItemType

To obtain the set of SourcedIds for the LineItem objects with the required state, which are associated with a particular CourseSection object.

readLineItemIdsFromSavePoint

To obtain the set of SourcedIds for LineItem objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readLineItems

To obtain the LineItem objects for a defined set of SourcedIds. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readLineItemsFromSavePoint

To obtain the set of LineItem objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may exchange a large volume of data in the response.

updateLineItem

To write new content into the identified LineItem object. The target must write the new data into the LineItem object. This is an additive operation.

replaceLineItem

To replace the content of the identified LineItem object. The target must write the new data into the LineItem object. This is a destructive write-over of all of the original information. In the case of the object not existing, this operation acts as an implied ‘createLineItem’.

discoverLineItemIds

To obtain the set of SourcedIds for LineItem objects whose properties agree with those defined in the query/filter.

changeLineItemIdentifier

To change the SourcedId for a LineItem object.

E2.2 ResultManager Interface Description

The ResultManager interface class describes the operations that are permitted on Result objects (as shown Figure E1.2). The set of operations are summarized in Table E2.2.

Table E2.2 Summary of operations for ResultManager.

Operation

Description

createResult

To request the creation of a populated Result object on the target system where the source allocates the unique SourcedId. The Result object is tied to a LineItem object.

createByProxyResult

To request the creation of a populated Result object on the target system where the target allocates the unique SourcedId. The Result object is tied to a LineItem object.

deleteResult

To request the deletion of a Result object. The Result object is deleted but the associated ResultValue and LineItems remain.

readResult

To read the full contents of the identified Result object. The target must return all of the data it has for the identified Result object.

readAllResultIds

To obtain the set of SourcedIds assigned to Result objects.

readResultIdsForPerson

To obtain the set of SourcedIds for the Result objects which are associated with a particular Person object.

readResultIdsForLineItem

To obtain the set of SourcedIds for the Result objects which are associated with a particular LineItem object.

readResultIdsForCourseOffering

To obtain the set of SourcedIds for the Result objects which are associated with a particular CourseOffering object.

readResultIdsForCourseSection

To obtain the set of SourcedIds for the Result objects which are associated with a particular CourseSection object.

readResultIdsForCourseSectionWithStatus

To obtain the set of SourcedIds for the Result objects that are associated with a particular CourseSection object and have results of a particular status.

readResultIdsForLineItemWithLineItemType

To obtain the SourcedIds for the Result objects that are associated with a LineItem that has a particular LineItemType state.

readResultIdsFromSavePoint

To obtain the set of identifiers for Result objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readResults

To obtain the Result objects for a defined set of identifiers. This results in a single transaction that may exchange of a large volume of data.

readResultsFromSavePoint

To obtain the set of Result objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may require the exchange of a large volume of data in the response message.

updateResult

To add content to the identified Result object. The target must write the new data into the Result object. This is an additive operation.

replaceResult

To replace the content of the identified Result object. The target must write the new data into the Result object. This is a destructive write-over of all of the original information. In the case of the object not existing, this operation acts as an implied ‘createResult’.

replaceResultsForLineItem

To replace the content of the identified Result objects for a given result status for the specified LineItem. The target must write the new data into the Result object. This is a destructive write-over of all of the original information.

discoverResultIds

To obtain the set of SourcedIds for Result objects whose properties agree with those defined in the query/filter.

changeResultIdentifier

To change the SourcedId of a Result object.

E2.3 ResultValueManager Interface Description

The ResultValueManager interface class describes the operations that are permitted on ResultValue objects (as shown Figure E1.3). The set of operations are summarized in Table E2.3.

Table E2.3 Summary of operations for ResultValueManager.

Operation

Description

createResultValue

To request the creation of a populated ResultValue object on the target system. The source is responsible for the allocation of the unique SourcedId.

createByProxyResultValue

To request the creation of a populated ResultValue object on the target system. The target is responsible for the allocation of the unique SourcedId.

deleteResultValue

To request the deletion of a ResultValue object. The ResultValue object is deleted along with all of its associated relationships.

readResultValue

To read the full contents of the identified ResultValue object. The target must return all of the data it has for the identified ResultValue object.

readAllResultValueIds

To obtain the set of SourcedIds that have been assigned to ResultValue objects.

readResultValueIdForLineItem

To obtain the SourcedId for the ResultValue object which has been associated with a particular LineItem object.

readResultValueIdForResult

To obtain the SourcedId for the ResultValue object which is associated with a particular Result object.

readResultValueIdsFromSavePoint

To obtain the set of identifiers for ResultValue objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation.

readResultValues

To obtain the ResultValue objects for a defined set of identifiers. This results in a single transaction that may require the exchange of a large volume of data in the response message.

readResultValuesFromSavePoint

To obtain the set of ResultValue objects which have been altered since the requested reference point. The reference point is set as ‘zero’ at creation and incremented after every write operation. This results in a single transaction that may exchange of a large volume of data in the response message.

updateResultValue

To write new content into the identified ResultValue object. The target must write the new data into the ResultValue object. This is an additive operation.

replaceResultValue

To replace the content of the identified ResultValue object. The target must write the new data into the ResultValue object. This is a destructive write-over of all of the original information. In the case of the object not existing, this operation acts as an implied ‘createResultValue’.

discoverResultValueIds

To obtain the set of SourcedIds for ResultValue objects whose properties agree with those defined in the query/filter.

changeResultValueIdentifier

To change the SourcedId for a ResultValue object.

Appendix F Bulk Data Exchange Management Service 1.0 Overview

F1 BDEMS Description

The Bulk Data Exchange Management Service is used to model the service responsible for manipulating information used in Learning Information Services systems. The BulkDataExchangeManagementService interface is shown in Figure F1.1.

Figure F1.1 BulkDataExchangeManagementService interface definition.

F2 BDEMS Operations

The BulkDataExchangeManager interface class describes the operations that are permitted on ‘bulk data’ objects. The interface stereotype indicates that there are no attributes for this class. The set of operations are summarized in Table F2.1.

Table F2.1 Summary of operations for BulkDataExchangeManager.

Operation

Description

announceBulkDataExchange

To announce the availability of a bulk data object that is ready to be retrieved by service consumers. This call suspends real-time event notification

announceFailureBulkDataExchange

To inform the service consumer that a previously issued, and acknowledged, requestBulkDataExchange transaction cannot be serviced by the service provider.

reportBulkDataExchange

To report the retrieval of the bulk data object whose availability was announced previously. This signals real-time event processing should be restarted.

requestBulkDataExchange

Issued by the service consumer to request a bulk data exchange from the service provider.

ignoreBulkDataExchange

Issued by the service consumer to inform the service provider that a previously issued announce bulk data exchange request will be ignored. Real-time processing should be resumed by both consumer and server.

cancelBulkDataExchange

Issued by the service consumer to inform the service provider that a previously requested bulk data exchange request has now been cancelled. Real-time processing should be resumed by both consumer and server.

NOTE: The operation used to download the data file(s) is not defined in Table F2.1. Instead, the specific Web Service binding is recommended in [BDEMS, 12].

About This Document

Title: 1EdTech Learning Information Services Specification

Editor: Colin Smythe (1EdTech)

Co-chairs: Linda Feng (Oracle) and Bill Lee (Desire2learn)

Version: 2.0.1

Version Date: 30 September 2013

Status: Final Release

Summary: This document contains the description of the 1EdTech Learning Information Services (LIS) specification. LIS is a collection of six component services that are combined to provide the required functionality. These component services are: Person Management Service; Group Management Service; Membership Management Service; Course Management Service; Outcomes Management Service; and Bulk Data Exchange Management Service. As part of the specification a Core Profile has been created for Learning Management System/Student Information System interaction.

Revision Information: Original Final Release

Purpose: This document is made available for adoption by the public community at large.

Document Location: http://www.imsglobal.org/lis/

List of Contributors

The following individuals contributed to the development of this document:

 

Kerry Blinco DEEWR (Australia)

Kirk Bunte SungardHE (USA)

Angus Chan Desire2Learn (Canada)

Adam Cooper JISC/JISC-CETIS (UK)

Michael De Ridder Desire2Learn (Canada)

Michael Feldstein Cengage (USA)

Linda Feng Oracle (USA)

John Fontaine Blackboard (USA)

Chris Hatton Pearson (USA)

Karen Kuffner University of Michigan (USA)

Zack Leavitt Pearson (USA)

Bill Lee Desire2Learn (Canada)

Richard Moon SungardHE (USA)

Phil Nicholls Psydev Ltd (UK)

Mike Parkhill Desire2Learn (Canada)

Colin Smythe 1EdTech (UK)

Reinhold Staudinger Blackboard (USA)

Nick Terrible University of Wisconsin (USA)

Ed Vannatter Desire2Learn (Canada)

Jason Zhong SungardHE (USA)

 

Revision History

Version No.

Release Date

Comments

LIS Final Release v2.0

30 June 2011

The first formal release of the Final Release version of this document.

Final Release v2.0.1

30 September 2013

Corrections

 

 

 

 

1EdTech Consortium, Inc. (“1EdTech”) is publishing the information contained in this document (“Specification”) for purposes of scientific, experimental, and scholarly collaboration only.

1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an “As Is” and “As Available” basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

1EdTech would appreciate receiving your comments and suggestions.

Please contact 1EdTech through our website at http://www.imsglobal.org.

Please refer to Document Name: 1EdTech LIS Specification Final Release v2.0.1

Date: 30 September 2013

 


[1] 1EdTech has created one such profile called the ‘Core Profiles’ [LIS, 12c].

[2] We recommend that new users of the 1EdTech LIS Specification start with the 1EdTech LIS Best Practices & Implementation Guide. The examples in this document show how we intend the specification to be used, whereas the Information Model and WSDL Binding documents contain the formal description of the services, data structures, their syntax and semantics.