IMS Logo

IMS Enterprise Services Conformance 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 Conformance 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 Structure of this Document
     1.4 Nomenclature
     1.5 References

2. The Context for Enterprise Services Conformance
     2.1 Nature of System
           2.1.1 Service Requester
           2.1.2 Service Provider
     2.2 System Assumptions

3. Level of Compliance
     3.1 Level 1 Compliance
           3.1.1 Service Requester Compliance
           3.1.2 Service Provider Compliance
     3.2 Level 2 Compliance
           3.2.1 Service Requester Compliance
           3.2.2 Service Provider Compliance
     3.3 Level 3 Compliance
           3.3.1 Service Requester Compliance
           3.3.2 Service Provider Compliance
     3.4 Level 4 Compliance
           3.4.1 Service Requester Compliance
           3.4.2 Service Provider Compliance
     3.5 Preferred Levels of Compliance

4. Interoperability and Conformance

Appendix A - ES Conformance Statement

About This Document
     List of Contributors

Revision History

Index

1. Introduction

1.1 Enterprise Services Overview

The Enterprise Services specification [EntServices, 04b] is the definition of how systems manage the exchange of information that describes people, group, 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:

1.2 Scope and Context

This document is the IMS Enterprise Services Conformance Specification v1.0 and it is based on the following documents:

  1. IMS Enterprise Services Core Use Cases v1.0 [EntServices, 04a] - the set of use-cases that are the basis for the definition of the information model;
  2. IMS Enterprise Services Specification v1.0 [EntServices, 04b] - the description of the overall Enterprise Services as created by the combination of the Person Management Services, Group Management Services, and Membership Management Services specifications;
  3. IMS Person Management Services Information Model v1.0 [PersonService, 04];
  4. IMS Group Management Services Information Model v1.0 [GroupService, 04];
  5. IMS Member Management Services Information Model v1.0 [MemberService, 04].

As such 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 Conformance Specification defines the formal test specification for the IMS Enterprise Service Information Model. This test specification is used to define the criteria by which an implementation can be evaluated to determine whether or not it complies with the Enterprise Services Information Model.

1.3 Structure of this Document

The structure of this document is:

 
2. The Context for Enterprise Services Conformance
The definition of the 'Service Provider' and 'Service Requester' perspective for conformance;
3. Levels of Compliance
The definition of the four levels of compliance that a system can claim;
4. Interoperability & Conformance
A discussion of how the reconciliation of conformance statements is produced to make a desk-top determination of interoperability;
Appendix A - ES Conformance Statement
A Conformance Statement that should be use to describe the compliance of a 'Service Consumer' and/or 'Service Provider' to the Enterprise Services Conformance Specification.

1.4 Nomenclature

 
API
Application Programming Interface
IAF
IMS Abstract Framework
UML
Unified Modelling Language
W3C
World Wide Web Consortium
WSDL
Web Services Description Language
XML
Extensible Mark-up Language

1.5 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.
[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 v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[EntServices, 04b]
IMS Enterprise Services Specification v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[GroupServices, 04]
IMS Group Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[MemberServices, 04]
IMS Member Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, June 2004.
[PersonServices, 04]
IMS Person Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, June 2004.

2. The Context for Enterprise Services Conformance

Conformance is based upon the following considerations:

2.1 Nature of System

It is assumed that the behaviors defined by an abstract API are invoked by the exchange of messages between the 'Service Requester' and 'Service Provider'. The physical construction and manner in which these messages are physically exchanged is outside the scope of the relevant information models and thus this Conformance Specification.

2.1.1 Service Requester

A 'Service Requester' is defined as the system that issues the 'Request' message of a behavior and receives in return the corresponding 'Response' message. The normative responsibilities of a 'Service Requester' are:

  1. It must construct the appropriate 'Request' messages as defined by the binding definition being used to support the information model;
  2. It must be capable of reliably generating unique 'sourcedIds' that are to be assigned to the data objects;
  3. It must be capable of processing the corresponding 'Response' messages as defined by the binding definition to be used to support the information model. It is the binding document that is responsible for detailing how a 'Service Consumer' must maintain the atomic relationship of the Request/Response message sequence. From the perspective of this Conformance Specification it is assumed that the service implementation guarantees that duplicate 'Response' messages do not occur;
  4. It must report the returned status codes and comments to the process invoking the behavior.

2.1.2 Service Provider

A 'Service Provider' is defined as the system that receives the 'Request' message for a behavior and issues in return the corresponding 'Response' message. The 'Service Provider' is responsible for maintaining the persistence of the data throughout its lifetime. The normative responsibilities of a 'Service Provider' are:

  1. It must be capable of processing the set of 'Request' messages that can be received as defined by the binding definition being used to support the information model. Invalid data received within a 'Request message should not cause a failure of the 'Service Provider' and should not result in incorrect information being stored;
  2. It must accurately implement the processing behavior invoked by the request. The completion of this processing must result in the reporting of the appropriate status information;
  3. It must construct the appropriate 'Response' messages as defined by the binding definition being used to support the information model. It is the binding document that is responsible for detailing how a 'Service Requester' must maintain the atomic relationship of the Request/Response message sequence;
  4. It must be capable of reliably generating unique 'sourcedIds' that are to be assigned to the data objects;
  5. It must maintain the persistence of the data objects once they have been created until they are deleted. This persistence must ensure that the data object can be accessed using the unique 'sourcedId' allocated to it.

2.2 System Assumptions

From a system perspective the following points must be noted:

  1. The underlying communications system is reliable. This mans that there is no loss, duplication or corruption of messages;
  2. The underlying detailed message choreography for the binding is such that a logical 'Request/Response' model is supported. The conformance statements are define with respect to this logical 'Request/Response' model. For example, the detailed message choreography for the asynchronous/polled bindings is not address in the conformance statement. Instead only the invoking 'Request' and data containing 'Response' messages are considered because it is only these that are responsible for maintaining the corresponding system behavior;
  3. Mechanisms such as security, service discovery, etc. are outside the scope of the conformance specification. Interoperability of real systems will also have to address these issues.

3. Level of Compliance

3.1 Level 1 Compliance

3.1.1 Service Requester Compliance

This level of compliance means that the service cannot be invoked by the 'Service Requester', i.e., the corresponding API call is not available.

3.1.2 Service Provider Compliance

This level denotes that the service is not supported by the 'Service Provider'. However, the 'Service Provider' must be capable of responding to a service request that the service is unavailable. Upon receipt of the 'Request' message the 'Service Provider' must:

3.2 Level 2 Compliance

3.2.1 Service Requester Compliance

This level denotes that the 'Service Requester' can invoke the defined behavior, using the 'Request' message and can process the corresponding 'Response' message from the 'Service Provider'. Upon receipt of the appropriate trigger the consumer must issue the 'Request' message such that:

Upon receipt of the corresponding 'Response' message the 'Service Requester' must:

3.2.2 Service Provider Compliance

Upon receipt of the 'Request' message the 'Service Provider' must:

3.3 Level 3 Compliance

3.3.1 Service Requester Compliance

As per level 2 compliance plus:

3.3.2 Service Provider Compliance

As per level 2 compliance plus:

3.4 Level 4 Compliance

3.4.1 Service Requester Compliance

As per level 2 compliance plus:

3.4.2 Service Provider Compliance

As per level 2 compliance plus:

3.5 Preferred Levels of Compliance

The preferred level of compliance is (in decreasing order of preference):

Interoperability is determined by the system that supports the compliance highest in the order of preference. If a system supports only Level 2 compliance, then it will reject any data contained within an optional element. The rejection of the data will result in a behavior failure status code.

4. Interoperability and Conformance

An implementation of an Enterprise Service is expected to accurately complete a Conformance Statement - see Appendix A for the format of the Conformance Statement. The Conformance Statement lists the level of compliance claimed for each of the behaviors defined within the Enterprise Service specification. Interoperability between two systems is then identified by comparing their Conformance Statements, i.e., a comparison of the 'Service Requester' and 'Service Provider' statements.

Table 4.1 Comparison matrix for the service requester/service provider compliance.

 
Service Requester Service Provider


Level 1 Level 2 Level 3 Level 4
Level 1 No interoperability. The Requester cannot issue the operation and the Provider does not support the operation.
No interoperability. The Requester cannot issue the operation.
No interoperability. The Requester cannot issue the operation.
No interoperability. The Requester cannot issue the operation.
Level 2 No interoperability. The Provider does not support the requested operation.
Constrained Interoperability. The Requester and Provider will exchange only the mandatory data structures.
Requester Constrained Interoperability. The Provider will supply some optional data structure but the Provider can only process the mandatory ones.
Requester Constrained Interoperability. The Provider can supply all of the optional data structure whereas the Requester can only process the mandatory ones.
Level 3 No interoperability. The Provider does not support the requested operation.
Provider Constrained Interoperability. The Provider will only store the mandatory data structures and will reject any optional ones supplied by the Provider.
Limited Interoperability. Only the mandatory data structures are exchanged under guarantee. Some commonly supported optional data structures may also be exchanged.
Requester Constrained Interoperability. The Provider can support any of the data structures sent by the Requester but it can supply optional data that the Requester may reject.
Level 4 No interoperability. The Provider does not support the requested operation.
Provider Constrained Interoperability. The Service Provider will only store the mandatory data structures and will reject any optional ones supplied by the Service Provider.
Provider Constrained Interoperability. The Requester can handle any of the data supplied by the Provider but the Provider may reject some of the optional data supplied by the Requester.
Full Interoperability. The Requester and Service Provider can exchange all of the data structures.

Table 4.1 lists the interoperability implications for each possible combination of the service requester and service provider compliance claims. The key points from Table 4.1 with regard to interoperability are (all matrix points are denoted as {i,j} with 'i' referring to the level of conformance of the Service Provider - this gives rise to sixteen possible interoperability states):

It must be stressed that the matrix in Table 4.1 reflects the level of interoperability for a single behavior. The same matrix comparison needs to be supplied for each of the behaviors. An example of this comparison based upon the Conformance Statement given in Appendix A is shown in Table 4.2.

Table 4.2 Example Person Management Services conformance statement.

 
Behavior Service Requester Conformance Service Provider Conformance Interoperability Capability
createPerson
3
4
Requester Constrained
createByProxyPerson
3
1
No
deletePerson
4
4
Full
readPerson
3
4
Requester Constrained
updatePerson
3
4
Requester Constrained
replacePerson
3
4
Requester Constrained
changePersonIdentifier
1
1
No
createPersons
3
4
Requester Constrained
createByProxyPersons
3
1
No
deletePersons
4
4
Full
readPersons
3
4
Requester Constrained
readPersonsForGroup
1
4
No
updatePersons
3
4
Requester Constrained
replacePersons
3
4
Requester Constrained
changePersonsIdentifier
1
1
No

In the example in Table 4.2 the Service Provider is defined as a full service (Level 4 conformance) for many behaviors, i.e., it can support all of the mandatory and optional data structures. The Service Requester provides Level 3 conformance for many behaviors. This results in many behaviors being 'Requester Constrained'. The notable differences are the 'deletePerson' and 'deletePersons' behaviors for which no Person data information is required.

Appendix A - ES Conformance Statement

A typical Conformance Statement for the Enterprise Services is shown in Tables A.1, A.2, and A.3. A full Enterprise Services Conformance Statement would entail all three tables being combined.

For each of these tables the 'Service Requester Conformance' and 'Service Provider Conformance' columns need to be completed. The 'Service Requester Conformance' column is used to denote the level of conformance supported by a system that issues Request messages and receives response messages, whereas, the 'Service Provider Conformance' column is used to denote the level of conformance supported by a system that receives Request messages and issues response messages. The possible values in the 'Service Requester Conformance' column are:

The possible values in the 'Service Provider Conformance' column are:

Every Service Provider must provide at least level 1 conformance for each behavior. If a system cannot act as a Service Provider then every row must have the entry 'N/A'. Similarly, if a system cannot act as a Service Requester then every row must have the entry 'N/A'.

Table A.1 Person Management Services conformance statement.

 
Person Management Service
Behavior
Service Requester Conformance
Service Provider Conformance
createPerson




createByProxyPerson




deletePerson




readPerson




updatePerson




replacePerson




changePersonIdentifier




createPersons




createByProxyPersons




deletePersons




readPersons




readPersonsForGroup




updatePersons




replacePersons




changePersonsIdentifier




Table A.2 Group Management Services conformance statement.

 
Group Management Service
Behavior
Service Requester Conformance
Service Provider Conformance
createGroup




createByProxyGroup




deleteGroup




deleteGroupRelationship




readGroup




updateGroup




replaceGroup




changeGroupIdentifier




createGroups




createByProxyGroups




deleteGroups




deleteGroupsRelationship




readGroups




readGroupsForPerson




updateGroups




replaceGroups




changeGroupsIdentifier




Table A.3 Membership Management Services conformance statement.

 
Membership Management Service
Behavior
Service Requester Conformance
Service Provider Conformance
createMembership




createByProxyMembership




deleteMembership




readMembership




updateMembership




replaceMembership




changeMembershipIdentifier




createMemberships




createByProxyMemberships




deleteMemberships




readMemberships




readMembershipsForPerson




readMembershipsForGroup




updateMemberships




replaceMemberships




changeMembershipsIdentifier




About This Document

 
Title
IMS Enterprise Services Conformance 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 Conformance 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. The material in this document describes the Conformance Specification as applied to the Enterprise Services Information Model. 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_confv1p0.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
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)
Cathy Schroeder
Microsoft Inc.
Nathaniel Zinn
Blackboard Inc.

Revision History

 
Version No. Release Date Comments
Public Draft 1.0
12 January 2004
The final approved Public Draft Document for the IMS Common Data Model Definition. In this document the Common Data Models are described in their own stand-alone information model.
Final Specification 1.0
11 June 2004
This is the formal Final version of the IMS Enterprise Services Conformance specification.

Index

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

sourcedId 1      RecordMetaData

comments 1      Result

result 1, 2, 3, 4, 5      Role

status 1, 2, 3      StatusInfo

description 1, 2      TypeValue

level 1, 2, 3, 4, 5

B
Binding technologies
     WSDL 1

C
Classes
     Group 1, 2, 3

Description 1, 2      Member 1
     Membership 1, 2
     Person 1, 2, 3, 4
Conformance 1, 2, 3, 4, 5, 6, 7, 8

E
Enterprise Service 1, 2, 3, 4, 5
Enterprise Service Information Model 1

G
Group Management Service 1, 2, 3

M
Membership Management Service 1, 2, 3

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, 2

changePersonsIdentifier 1, 2

createByProxyPerson 1, 2

createByProxyPersons 1, 2

createPerson 1, 2

createPersons 1, 2

deletePerson 1, 2

deletePersons 1, 2

readPerson 1, 2

readPersons 1, 2

readPersonsForGroup 1, 2

replacePerson 1, 2

replacePersons 1, 2

updatePerson 1, 2

updatePersons 1, 2

P
Person Management Service 1, 2, 3, 4, 5

S
Services
     Group Management 1, 2, 3
     Membership Management 1, 2, 3
     Person Management 1, 2, 3, 4, 5
Specifications
     IMS

Enterprise Service

Information Model 1 Status Codes
     unsupported 1

W
WDSL 1, 2

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Enterprise Services Conformance 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 Conformance Specification Revision: 11 June 2004