IMS Logo

IMS Enterprise Services Specification

Version 1.0 Final Specification

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Enterprise Services Specification
Revision: 11 June 2004

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.

IMS 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 IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2004 IMS Global Learning Consortium. All Rights Reserved.

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

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

The limited permissions granted above are perpetual and will not be revoked by IMS 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.


Table of Contents


1. Introduction
     1.1 Enterprise Services Overview
     1.2 Scope and Context
     1.3 Nomenclature
     1.4 References

2. Core Use Case Descriptions

3. Enterprise Service Description
     3.1 An Abstract Representation
     3.2 Enterprise Service Architecture Model
     3.3 Enterprise Services Domain Model

4. Person Management Service

5. Group Management Service

6. Membership Management Service

7. Extending the Enterprise Service
     7.1 Proprietary Extensions
     7.2 Further Work

About This Document
     List of Contributors

Revision History

Index

1. Introduction

1.1 Enterprise Services Overview

The 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) [AbsGloss, 03], [AbsASC, 03], [AbsWhite, 03]. This means that this specification is based upon the concepts of:

1.2 Scope and Context

This document is the IMS Enterprise Services Specification v1.0 and as such it is used as the basis for the development of the following documents:

  1. IMS Enterprise Services Conformance Specification v1.0 [EntServices, 04b] - the definition of the conformance criteria that must be followed by systems that wish to claim compliance to the Enterprise Services Information model;
  2. IMS Enterprise Services with WSDL Binding Best Practices & Implementation Guide v1.0 [EntServices, 03c] - the recommended best practices to be adopted when implementing the Enterprise Services using a webs services binding;

The core uses cases for the Enterprise Services are described in [EntServices, 04a]. The Enterprise Services specification supersedes the original Enterprise specifications:

  1. IMS Enterprise Information Model Final Specification v1.1 [Enterprise, 02a].
  2. IMS Enterprise XML Binding Final Specification v1.1 [Enterprise, 02b];
  3. IMS Enterprise Services Best Practice and Implementation Guide Final Specification v1.0 [Enterprise, 02c].

This specification is based upon the aggregation of the Person Management, Group Management and Membership Management Services specifications, namely:

  1. IMS Person Management Services Information Model v1.0 [PersonServices, 04a];
  2. IMS Person Management Services WSDL Binding v1.0 [PersonServices, 04b];
  3. IMS Group Management Services Information Model v1.0 [GroupServices, 04a];
  4. IMS Group Management Services WSDL Binding v1.0 [GroupServices, 04b];
  5. IMS Membership Management Services Information Model v1.0 [MemberServices, 04a];
  6. IMS Membership Management Services WSDL Binding v1.0 [MemberServices, 04b].

This information model defines the Enterprise Service Abstract Application Programming Interface (a-API). 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 UML and the syntax adopted for the description of the UML is given in the IMS Specifications, Methods and Best Practices document [SpecDev, 03].

The Enterprise Services Specification v1.0 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 [PersonServices, 04b], [GroupServices, 04b], [MemberServices, 04b].

1.3 Nomenclature

 
API
Application Programming Interface
a-API
Abstract Application Programming Interface
CRUD
Create, Read, Update and Delete
HR
Human Resources
HRMS
Human Resources Management System
http
HyperText Transfer Protocol
IAF
IMS Abstract Framework
LMS
Learning Management System
LibMS
Library Management System
MIS
Management Information System
SOAP
Simple Object Access Protocol
SIF
Schools Interoperability Framework
SIS
Student Information System
TMS
Training Management System
UML
Unified Modelling Language
URL
Universal Resource Locator
VLE
Virtual Learning Environment
W3C
World Wide Web Consortium
WSDL
Web Services Description Language
XML
Extensible Mark-up Language

1.4 References

 
[AbsASCs, 03]
IMS Abstract Framework: Applications, Services & Components v1.0, C.Smythe, IMS Global Learning Consortium, Inc., July 2003.
[AbsGloss, 03]
IMS Abstract Framework: Glossary v1.0, C.Smythe, IMS Global Learning Consortium, Inc., July 2003.
[AbsWhite, 03]
IMS Abstract Framework: White Paper v1.0, C.Smythe, IMS Global Learning Consortium, Inc., July 2003.
[Cockburn, 01]
Writing Effective Use-case, A.Cockburn, Addison-Wesley, 2001, ISBN 0-201-70225-8.
[Enterprise, 02a]
IMS Enterprise Information Model v1.1, G.Collier, C.Etesse, W.Veres and C.Smythe, IMS Global Learning Consortium, Inc., July 2002.
[Enterprise, 02b]
IMS Enterprise XML Binding v1.1, G.Collier, C.Etesse, W.Veres and C.Smythe, IMS Global Learning Consortium, Inc., July 2002.
[Enterprise, 02c]
IMS Enterprise Best Practice & Implementation Guide v1.1, G.Collier, C.Etesse, W.Veres and C.Smythe, IMS Global Learning Consortium, Inc., July 2002.
[EntServices, 04a]
IMS Enterprise Services Core Use Cases Description v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[EntServices, 04b]
IMS Enterprise Services Conformance Specification v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[EntServices, 04c]
IMS Enterprise Services with WSDL Binding Best Practices and Implementation Guide v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[GroupServices, 04a]
IMS Group Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[GroupServices, 04b]
IMS Group Management Services WSDL Binding v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[MemberServices, 04a]
IMS Member Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[MemberServices, 04b]
IMS Member Management Services WSDL Binding v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[PersonServices, 04a]
IMS Person Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[PersonServices, 04b]
IMS Person Management Services WSDL Binding v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[SpecDev, 03]
IMS Specification Development Methods and Best Practices Draft 5.0, C.Smythe, IMS Global Learning Consortium, Inc., August 2003.

2. Core Use Case Descriptions

The following use cases1 are the core subset adopted to represent key requirements for this version of the Enterprise Services (the full description for each of these use cases is given in [EntServices, 04a]):

The Enterprise Services core use case description document [EntServices, 04a] contains many use cases that are not supported by the v1.0. Support for those use cases will be addressed in later versions.

3. Enterprise Service Description

3.1 An Abstract Representation

It is important to remember that this document is describing the underlying information model in terms of the abstract API. The manner in which this abstract representation is visualized is not intended to dictate the implementation form of an Enterprise System. The breakdown of the service into its component services and the further breakdown of each service into the interface classes used is a convenient way to document the set of behaviors. The internal organization of an implementation of the full abstract API is beyond the scope of this specification. The only constraint is that the external behavior of the abstract API complies with this specification. This means that a .NET, Java, etc. physical implementation of this abstract API does not have to represent the functionality using the same breakdown of operations/methods. This physical implementation is not subject to the conformance specification.

It is important to note that the UML representation of the interfaces is used to help develop and document the Enterprise Services information Model. It is not a requirement for an implementation to implement this interface as defined, i.e., to use the same parameters, etc. Conformance against this specification will be confirmed by inspecting the appropriate binding of the information model and ensuring that the relevant information is present and that different sequences of activity result in the predicted and mandated behavior. It is essential that the behaviors described by each of the operations are fully supported and it is also essential that the behaviors described by different sequences are also maintained.

3.2 Enterprise Service Architecture Model

The basic abstract architectural model for the Enterprise Services specification is shown in Figure 3.1.

Enterprise Services architecture model

Figure 3.1 Enterprise Services architecture model.

In this architecture the scope of the IMS enterprise services specification is shown as the dotted line. The scope of the interoperability is the data and behavioural models of the objects being exchanged. Figure 3.1 is an abstract model showing the interfaces that are under specification (see the IMS Abstract Framework [AbsWhite, 03]; it is not a representation of how an Enterprise System should be constructed. IMS Service Package is the definition of the IMS Enterprise Services resulting in a WSDL binding. The WSDL binding is then mapped onto a SOAP/http Infrastructure Layer.

The IMS Enterprise Services specification contains a very simple abstract messaging model that is assumed to underlie the exchange of the data between the communicating Enterprise systems. The basic data exchange mechanism is shown in Figure 3.2 in which the 'source' and 'target' Enterprise systems exchange an IMS Enterprise Services 'message' using a 'Request/Response' transaction. This abstract messaging representation is adopted because the Enterprise System architecture is based upon loosely coupled system and the primary IMS binding of this information model is based upon the exchange of XML documents/messages.

It is important to remember that the structure of the exchanged information has NO bearing on how the same information is contained within the 'source' and 'target' Enterprise systems. It is simply an exchange interoperability representation of the data (the information that crosses the dotted line in Figure 3.2).

Enterprise service abstract information exchange model.

Figure 3.2 Enterprise Services abstract information exchange model.

The behavioral descriptions will describe:

3.3 Enterprise Services Domain Model

A schematic representation of the core objects exchanged using the IMS Enterprise Services specification is given in Figure 3.3. Only those services that are shown in grey are defined in this information model. The core enterprise services are:

Two other Enterprise Services have been identified: Gradebook management service and Course catalog management service. This will not be defined as part of the V1.0 information model but may be included in later releases.

The underlying set of services used by the core enterprise services composition application services (as defined in the Abstract Framework):

Enterprise service domain model

Figure 3.3 Enterprise Services domain model.

An underlying assumption in a message-based system is that the sequence of messages will, in general, refer to the same objects at different moments in time e.g., the 'creation' of a Person, the 'updating' of a person and eventually the 'deletion' of the Person record. This means that the objects must have a unique identifier and that this address/label is unique between the communicating systems (an object may have more that one identifier even between the same two systems). The IMS Enterprise specification calls these identifiers the 'sourcedId' of the object and it consists of a 'source' (globally unique across all the Enterprise systems) and an 'id' (unique within the source Enterprise system).

Enterprise services simple object addressing schema

Figure 3.4 Enterprise Services simple object addressing schema.

The usage of the 'sourcedid' for labelling the objects being exchanged gives rise to the scenario shown in Figure 3.4. The consequence of this approach is that any object will have multiple identifiers depending on which part of the system is being considered, i.e.:

Within the Person management, Group Management and Membership management services the 'sourcedid' is defined as a flat string Identifier. For compatibility with the Enterprise v1.1 and earlier specifications the 'sourcedid' will be mapped onto the flat string as: 'source:id,' i.e., the colon (:) is used to delimit the 'source' and the 'id' within the flat string.

4. Person Management Service

The PersonManagementService class is used to model the service responsible for manipulating information about people. The PersonManagementService package is shown in Figure 4.1.

Person management service definition

Figure 4.1 Person management service definition.

The PersonManagementService is split into two interface classes: PersonManager that supports the manipulation of a single Person object; PersonsManager that supports the manipulation of two or more Person objects bound in a single transaction. The manipulation of multiple Person objects can also be supported by the iteration over the PersonManager however this will result in multiple independent transactions. The data-types used to support the PersonsManager class are derived as sets of the equivalent data-types used for the PersonManager class. The service operations are summarized in Table 4.1.

Table 4.1 Summary of PersonManagerService operations.

 

Operation

Description

createPerson
To request the creation of a populated 'person' record on the target system and the source is responsible for the allocation of the unique identifier.
createByProxyPerson
To request the creation of a populated 'person' record on the target system and the target is responsible for the allocation of the unique identifier.
deletePerson
To request the deletion of a 'person' record. The 'person' record is deleted and all of its associated relationships.
readPerson
To read the full contents of the identified 'person' record. The target must return all of the data it has for the identified 'person' record.
updatePerson
To write new content into the identified 'person' record. The target must write the new data into the 'person' record. This is an additive operation.
replacePerson
To replace the content of the identified 'person' record. The target must write the new data into the 'person' record. This is a destructive write-over of all of the original information.
changePersonIdentifier
To change the sourcedId of the 'person' record. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.
createPersons
To request the creation of a set of populated 'person' records on the target system. The source is responsible for the allocation of the unique identifiers.
createByProxyPersons
To request the creation of a set of populated 'person' records on the target system. The target is responsible for the allocation of the unique identifiers.
deletePersons
To request the deletion of a set of 'person' record. The 'person' records and all their associated relationships are deleted.
readPersons
To read the full contents of the set of identified 'person' records. The target must return all of the data it has for each of the identified 'person' records.
readPersonsForGroup
To retrieve the 'person' records for a particular Group. This returns the person record for every person that is a member of the Group i.e., for whom a membership record in the Group exists.
updatePersons
To write new content into the set of identified 'person' records. The target must write the new data into each of the 'person' records. These are additive operations.
replacePersons
To replace the content of a set of identified 'person' records. The target must write the new data into the 'person' records. These are destructive write-overs of all of the original information.
changePersonsIdentifier
To change the sourcedId of the set of 'person' records. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.

5. Group Management Service

The GroupManagementService class is used to model the service responsible for manipulating information about groups. The GroupManagementService class diagram is shown in Figure 5.1.

Group management service definition

Figure 5.1 Group management service definition.

The Group Management Service is split into two interface classes: GroupManager that supports the manipulation of a single Group object; GroupsManager that supports the manipulation of two or more Group objects bound in a single transaction. The manipulation of multiple Group objects can also be supported by the iteration over the GroupManager however this will result in multiple independent transactions. The data-types used to support the GroupsManager class are derived as sets of the equivalent data-types used for the GroupManager class. The operations are summarized in Table 5.1.

Table 5.1 Summary of GroupManagerService operations.

 

Operation

Description

createGroup
To request the creation of a populated 'group' record on the target system and the source is responsible for the allocation of the unique identifier.
createByProxyGroup
To request the creation of a populated 'group' record on the target system and the target is responsible for the allocation of the unique identifier.
deleteGroup
To request the deletion of a 'group' record. The 'group' record is deleted and all of its associated relationships.
deleteGroupRelationship
To request the deletion of a relationship within a 'group' record. This does not delete the associated 'group' records.
readGroup
To read the full contents of the identified 'group' record. The target must return all of the data it has for the identified 'group' record.
updateGroup
To write new content into the identified 'group' record. The target must write the new data into the 'group' record. This is an additive operation.
replaceGroup
To replace the content of the identified 'group' record. The target must write the new data into the 'group' record. This is a destructive write-over of all of the original information.
changeGroupIdentifier
To change the sourcedId of the 'group' record. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.
createGroups
To request the creation of a set of populated 'group' records on the target system and the source is responsible for the allocation of each of the unique identifiers.
createByProxyGroups
To request the creation of a set of populated 'group' records on the target system. The target is responsible for the allocation of the unique identifiers.
deleteGroups
To request the deletion of a set of 'group' record. The 'group' records and all their associated relationships are deleted.
deleteGroupsRelationship
To request the deletion of a set of relationships within the 'group' records. This does not delete the associated 'group' records.
readGroups
To read the full contents of the set of identified 'group' records. The target must return all of the data it has for each of the identified 'group' records.
readGroupsForPerson
To retrieve the 'group' records for a particular Person. This returns the set of group records of which the person i.e., for whom a membership record in the Group exists.
updateGroups
To write new content into the set of identified 'group' records. The target must write the new data into each of the 'group' records. These are additive operations.
replaceGroups
To replace the content of a set of identified 'group' records. The target must write the new data into the 'group' records. These are destructive write-overs of all of the original information.
changeGroupsIdentifier
To change the sourcedId of the 'group' record. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.

6. Membership Management Service

The MembershipManagementService class is used to model the service responsible for manipulating information about the membership of people or groups in groups. The MembershipManagementService class diagram is shown in Figure 6.1.

Membership management service definition

Figure 6.1 Membership management service definition.

The Membership Management Service is split into two interface classes: MembershipManager that supports the manipulation of a single Membership object; MembershipsManager that supports the manipulation of two or more Membership objects bound in a single transaction. The manipulation of multiple Membership objects can also be supported by the iteration over the Membership Manager however this will result in multiple independent transactions. The data-types used to support the MembershipsManager class are derived as sets of the equivalent data-types used for the Membership Manager class. The operations are summarized in Table 6.1.

Table 6.1 Summary of MembershipManagerService operations.

 

Operation

Description

createMembership
To request the creation of a populated 'membership' record on the target system and the source is responsible for the allocation of the unique identifier.
createByProxyMembership
To request the creation of a populated 'membership' record on the target system and the target is responsible for the allocation of the unique identifier.
deleteMembership
To request the deletion of a 'membership' record. The 'membership' record is deleted and all of its associated relationships.
readMembership
To read the full contents of the identified 'membership' record. The target must return all of the data it has for the identified 'membership' record.
updateMembership
To write new content into the identified 'membership' record. The target must write the new data into the 'person' record. This is an additive operation.
replaceMembership
To replace the content of the identified 'membership' record. The target must write the new data into the 'person' record. This is a destructive write-over of all of the original information.
changeMembershipIdentifier
To change the sourcedId of the 'membership' record. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.
createMemberships
To request the creation of a set of populated 'membership' records on the target system. The source is responsible for the allocation of the unique identifiers.
createByProxyMemberships
To request the creation of a set of populated 'membership' records on the target system and the target is responsible for the allocation of each of the unique identifiers.
deleteMemberships
To request the deletion of a set of 'membership' record. The 'membership' records and all their associated relationships are deleted.
readMemberships
To read the full contents of the set of identified 'membership' records. The target must return all of the data it has for each of the identified 'membership' records.
readMembershipsForPerson
To retrieve all the 'membership' records for a particular Person. This returns every 'membership' record for the identified 'person' record.
readMembershipsForGroup
To retrieve all the 'membership' records for a particular Group. This returns every 'membership' record for the identified 'group' record.
updateMemberships
To write new content into the set of identified 'membership' records. The target must write the new data into each of the 'membership' records. These are additive operations.
replaceMemberships
To replace the content of a set of identified 'membership' records. The target must write the new data into the 'membership' records. These are destructive write-overs of all of the original information.
changeMembershipsIdentifier
To change the sourcedId of the set of 'membership' records. The completion of this operation will result in later actions using the original sourcedId reporting an unknown identifier status.

7. Extending the Enterprise Service

7.1 Proprietary Extensions

The proprietary extensions of the specification are based upon two approaches:

  1. The extension of the data models being manipulated by the current set of operations;
  2. The inclusion of new operations to support new proprietary functionality.

It is NOT permitted to change the behavior of the current set of operations. Such changes MUST be supported by the creation of new operations.

Proprietary extensions must make use of the extensions facilities in the respectively components services. Refer to the appropriate specification documentation for the full details.

7.2 Further Work

The Enterprise Services Specification and is based on the composition of other clearly defined and functionally discrete services. This means that the addition of new services and the extension of the established services can be supported without compatibility problems. The areas of work that will be addressed in new versions of the Enterprise Services are:

About This Document

 
Title
IMS Enterprise Services Specification
Editor
Colin Smythe (IMS)
Team Co-Lead
Chris Vento (WebCT Inc.)
Version
1.0
Version Date
11 June 2004
Status
Final Specification
Summary
This document presents the IMS Enterprise Services 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 behaviors are defined in a set of independent and aggregate services: Person Management Service, Group Management Services and Membership Management Services. This information is the definition of the abstract application-programming interface for the Enterprise Service. This version supersedes the IMS Enterprise v1.1 specifications.
Revision Information
11 June 2004
Purpose
This document has been approved by the IMS Technical Board and is made available for adoption.
Document Location
http://www.imsglobal.org/es/esv1p0/imses_specv1p0.html

 
To register any comments or questions about this specification, please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=20

List of Contributors

The following individuals contributed to the development of this document:

 
Name Organization Name Organization
Scott Baker
Oracle Inc.
Les Smith
SCT Inc.
Fred Beshears
UC Berkeley, USA
Colin Smythe
Dunelm Services Ltd.
Kerry Blinco
IMS Australia
Chris Vento
WebCT Inc.
Chris Etesse
Blackboard Inc.
Kimberley Voltero
WebCT Inc.
John Hallet
WebCT Inc.
Scott Wilson
JISC (CETIS), UK
Cathy Schroeder
Microsoft Inc.
Nathaniel Zinn
Blackboard Inc.

Revision History

 
Version No. Release Date Comments
Base Document 1.0
21 July 2003
The final approved Base Document for the IMS Enterprise Services Information Model.
Public Draft 1.0
12 January 2004
The final approved Public Draft Document for the IMS Enterprise Services Specification.
Final Specification 1.0
11 June 2004
This is the formal Final release of the IMS Enterprise Services specification.

Index

A
Abstract Framework 1, 2, 3, 4, 5
API 1, 2
Attributes
     Common

extension 1

sourcedId 1, 2, 3, 4      Membership

membership 1, 2, 3, 4, 5, 6      Org

id 1      Relationship

label 1      Result

result 1, 2, 3, 4, 5, 6, 7, 8      Role

status 1, 2, 3      StatusInfo

description 1, 2, 3      UserId

authentication 1

B
Binding technologies
     SOAP 1, 2
     WSDL 1, 2, 3, 4

C
Classes
     Common

Identifier 1, 2

StatusInfo 1      Group 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11

Description 1, 2, 3, 4, 5, 6      Member 1, 2
     Membership 1, 2, 3, 4, 5, 6, 7
     Person 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Conformance 1, 2, 3

E
Enterprise Service 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

G
Group Management Service 1, 2, 3, 4, 5

I
Interface Class
     GroupManager 1
     GroupsManager 1
     MembershipManager 1
     MembershipsManager 1
     PersonManager 1
     PersonsManager 1

M
Membership Management Service 1, 2, 3, 4

O
Operations
     Group

changeGroupIdentifier 1

changeGroupsIdentifier 1

createByProxyGroup 1

createByProxyGroups 1

createGroup 1

createGroups 1

deleteGroup 1

deleteGroupRelationship 1

deleteGroups 1

deleteGroupsRelationship 1

readGroup 1

readGroups 1

readGroupsForPerson 1

replaceGroup 1

replaceGroups 1

updateGroup 1

updateGroups 1      Membership

changeMembershipIdentifier 1

changeMembershipsIdentifier 1

createByProxyMembership 1

createByProxyMemberships 1

createMembership 1

createMemberships 1

deleteMembership 1

deleteMemberships 1

readMembership 1

readMemberships 1

readMembershipsForGroup 1

readMembershipsForPerson 1

replaceMembership 1

replaceMemberships 1

updateMembership 1

updateMemberships 1      Person

changePersonIdentifier 1

changePersonsIdentifier 1

createByProxyPerson 1

createByProxyPersons 1

createPerson 1

createPersons 1

deletePerson 1

deletePersons 1

readPerson 1

readPersons 1

readPersonsForGroup 1

replacePerson 1

replacePersons 1

updatePerson 1

updatePersons 1

P
Person Management Service 1, 2, 3, 4

S
Schools Interoperability Framework 1, 2
Services
     Group Management 1, 2, 3, 4, 5
     Membership Management 1, 2, 3, 4
     Person Management 1, 2, 3, 4
SOAP 1, 2
Specifications
     Other

Schools Interoperability Framework 1, 2

W
WDSL 1, 2, 3, 4

1 Note that each use-case will be supported by one or more behaviors in the corresponding specification. For example, the 'Read Person' use case in the Person Management Service is supported by the 'readPerson()', 'readPersons()' and readPersonsForGroup()' behaviors.

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Enterprise Services Specification ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS 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.

IMS would appreciate receiving your comments and suggestions.

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

Please refer to Document Name:
IMS Enterprise Services Specification Revision: 11 June 2004