IMS Enterprise Services Best Practice and Implementation Guide 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 Best Practice and Implementation Guide
Revision: 11 June 2004

Date Issued:	11 June 2004
Latest version:	http://www.imsglobal.org/es/esv1p0/imses_bestv1p0.html
Register comments or implementations:	http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=20
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 © IMS Global Learning Consortium 2006. All Rights Reserved. If you wish to distribute this document or use this document to implement a product or service, you must complete a valid license registration with IMS and receive an email from IMS granting the license. 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 Licensee organizations 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 work 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/es/esv1p0/esv1p0speclicense.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

The Enterprise Services specification [EntService, 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:

• Interoperability - Enterprise Services focuses on the exchange of information between Enterprise systems. The specification makes no assumptions on how the data is managed within the Enterprise systems;
• Service-oriented - Enterprise Services defines the exchange of information in terms of the services being supplied by the collaboration of the systems. This takes the form of Person Management Services, Group Management Services and Membership Management Services;
• Component-based - the set of services will be supplied such that they can be combined to form a range of services. The Person Management Services, Group Management Services and Membership Management Services can be combined to provide other services and the Enterprise Service will have other services added to it in later releases;
• Layering - the Enterprise Service and its constituent services (Person, Group and Membership) are part of the Application Services layer;
• Behaviors and Data Models - the Enterprise Services are defined in terms of their behaviors and data models. The behaviors cause changes in the state of the data model and the state of the data model will only be altered as a result of a clearly defined behavior;
• Multiple Bindings - the Enterprise Services information model is to be defined using the Unified Modelling Language (UML). This enables reliable mapping of the information model into a range of different bindings. The bindings of immediate importance are to the Web Services Description Language (WSDL);
• Adoption - the Enterprise Services are based upon the original Enterprise specification data model. While there are significant changes the underlying data model has been maintained and the core Person, Group and Membership structures remain.

1.2 Scope and Context

This document is the IMS Enterprise Services Best Practice and Implementation Guide v1.0 and as such it is used to support the following documents:

1. IMS Enterprise Services Core Use Cases v1.0 [EntService, 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] - this presents the overall structure and capabilities of the Enterprise Services specification;
3. IMS Enterprise Services Conformance Specification v1.0 [EntServices, 04c] - the definition of the conformance criteria that must be followed by systems that wish to claim compliance to the Enterprise Services Information model;
4. IMS Person Management Services Information Model v1.0 [PersonServices, 04a] - the information model of the Person Management Services;
5. IMS Person Management Services WSDL Binding v1.0 [PersonServices, 04b] - the description of the WSDL binding of the Person Management Services information model;
6. IMS Group Management Services Information Model v1.0 [GroupServices, 04a] - the information model of the Group Management Services;
7. IMS Group Management Services WSDL Binding v1.0 [GroupServices, 04b] - the description of the WSDL binding of the Group Management Services information model;
8. IMS Membership Management Services Information Model v1.0 [MemberServices, 04a] - the information model of the Membership Management Services;
9. IMS Membership Management Services WSDL Binding v1.0 [MemberServices, 04b] - the description of the WSDL binding of the Membership Management Services information model.

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 best practice and implementation guide describes some of the issues that need to be addressed during various stages of adoption. This is the first version of these services and so most of the best practice is derived from experience of proprietary implementations of similar functionality.

1.3 Structure of this Document

The structure of this document is:

2. Related Specifications and Activities	The relationship of this specification activity to other IMS and external specification activities;
3. Overall Services Model	A brief summary of the IMS Enterprise Services information model and WSDL binding;
4. Example SOAP/HTTP Messages for Synchronous Services	Examples of the basic Synchronous Enterprise Services messages that are exchanged assuming SOAP/HTTP as the transport;
5. Example SOAP/HTTP Messages for Asynchronous Services	Examples of the basic Asynchronous Enterprise Services messages that are exchanged assuming SOAP/HTTP as the transport;
6. Mapping for Other Specifications	The ways in which the IMS Enterprise Services functionality can be used to support other similar specifications;
7. Best Practice	Implementation guidance on the best practices to be adopted when using the Enterprise Service specification;
8. Supporting the Use Cases	A brief explanation of how the use cases defined in the Enterprise Services Core Uses-cases can be supported using the Enterprise Services specification;
9. Extending the Services	A brief explanation of the ways in which the Enterprise Services can be extended without causing problems with backwards compatibility. This material will also give an indication of the ways in which the Enterprise Services are to be extended in later versions;
Appendix A - Glossary of Terms	A glossary of the key terms and elements used within the specification.
Appendix B - OKI Enterprise Open Service Interface Definitions	A brief description of the OKI Enterprise Services OSIDs that are used to support the explanation of the usage of the Enterprise Services as an implementation binding based upon the OKI.

1.4 Nomenclature

ADL	Advanced Distributed Learning
AICC	Aviation Industry CBT Committee
ANSI	American National Standards Institute
API	Application Programming Interface
CBT	Computer Based Training
CEN	Central European Normalization
DTD	Document Type Definition
EDI	Electronic Data Interchange
GWS	General Web Services
HR	Human Resources
HTTP	HyperText Transfer Language
IAF	IMS Abstract Framework
IETF	Internet Engineering Task Force
I-GMS	IMS Group Management Service
I-MMS	IMS Membership Management Service
I-PMS	IMS Person Management Service
ISO	International Standards Organization
LDAP	Lightweight Directory Access Protocol
LIP	Learner Information Package
OSID	Open Service Interface Definition
PDI	Personal Data Interchange
SCORM	Sharable Content Object Reference Model
SIF	Schools Interoperability Framework
SOAP	Simple Object Access Protocol
SOAPwA	Simple Object Access Protocol with Attachments
TEISS	Telematics European Industry Standardisation Support
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, Ed. C.Smythe, IMS Global Learning Consortium, Inc., July 2003.
[AbsGloss, 03]	IMS Abstract Framework: Glossary v1.0, Ed. C.Smythe, IMS Global Learning Consortium, Inc., July 2003.
[AbsWhite, 03]	IMS Abstract Framework: White Paper v1.0, Ed. C.Smythe, IMS Global Learning Consortium, Inc., July 2003.
[Enterprise, 02a]	IMS Enterprise Information Model Final Specification v1.1, G.Collier, C.Etesse, W.Veres and C.Smythe, IMS Global Learning Consortium, Inc., July 2002.
[Enterprise, 02b]	IMS Enterprise XML Binding Final Specification 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 Final Specification 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.
[EntServices, 04c]	IMS Enterprise Services Conformance Specification v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., Version 1.0, June 2004.
ESCommon, 04	IMS Enterprise Services Common Data Specification v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., Version 1.0, 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.
[GWS, 04a]	IMS General Web Services Base Profiles Public Draft v1.0, C.Schroeder, S.Raju, and C.Smythe, IMS Global Learning Consortium, Inc., Version 1.0, May 2004.
[GWS, 04b]	IMS General Web Services Binding Methodology & Recipes Public Draft v1.0, C.Schroeder, S.Raju, and C.Smythe, IMS Global Learning Consortium, Inc., Version 1.0, May 2004.
[LIP, 01a]	IMS Learner Information Package Information Model v1.0, R.Robson, C.Smythe, and F.Tansey, Version 1.0, IMS Global Learning Consortium Inc., March 2001.
[LIP, 01b]	IMS Learner Information Package XML Binding v1.0, R.Robson, C.Smythe, and F.Tansey, Version 1.0, IMS Global Learning Consortium Inc., March 2001.
[LIP, 01c]	IMS Learner Information Packaging Best Practices & Implementation Guide v1.0, R.Robson, C.Smythe, and F.Tansey, IMS Global Learning Consortium, Inc., March 2001.
[MemberServices, 04a]	IMS Membership Management Services Information Model v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[MemberServices, 04b]	IMS Membership Management Services WSDL Binding v1.0, C.Smythe and C.Vento, IMS Global Learning Consortium, Inc., June 2004.
[OKI, 03]	OKI Course management Open Service Interface Definition, OKI, Doc Release v0.2, June 2003.
[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, June 2004.
[SpecDev, 03]	IMS Specification Development Methods & Best Practices Draft 5.0, C.Smythe, IMS Global Learning Consortium, Inc., August 2003.
[VDEX, 04]	IMS Vocabulary Definition Exchange Information Model v1.0, A.Cooper and M.Mckell, IMS Global Learning Consortium, Inc., April 2004.

2. Related Specifications and Activities

2.1 IMS Enterprise v1.1 Specification

The IMS Enterprise Services specification supersedes the IMS Enterprise v1.1 specification. The services specification adds behaviors to the data model defined in the Enterprise v1.1 specification. The Enterprise Service uses a similar data model to that of the Enterprise v1.1 specification. All of the data-oriented information model features of the Enterprise v1.1 Specification are supported by the new Enterprise Services. The only core feature of the Enterprise v1.1 specification that is not supported is the <property> element. This element was used to provide some behavior capabilities and as such it is not required and is replaced by the usage of the service definitions.

2.2 Other IMS Specifications

2.2.1 IMS Learner Information Package v1.0 Specification

There is some overlap of functionality between the IMS Enterprise Services and the IMS Learner Information Package (LIP) specification [LIP, 01a], [LIP, 01b], [LIP, 01c]. The overlap is between the IMS Person Management Service (I-PMS) and the IMS LIP <identification> element. The I-PMS should be used for interactions that involve the IMS Group Management and IMS Membership Management services. The IMS LIP functionality should be used when working with individual profiles e.g., ePortfolios, life-long learning logs, etc.

2.2.2 IMS General Web Services Recommendations

The web service binding of the Enterprise Services specification is based upon the IMS General Web Services recommendations [GWS, 04a], [GWS, 04b]. The IMS General Web Services Base Profiles [GWS, 04a] provide a basic structure for the definition of Web Services. They consist of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications that promote interoperability. The General Web Services Base Profiles address the most common problems experienced when implementing web service specifications. The IMS Enterprise Service is based upon the General Web Services Base Profile.

The IMS General Web Services UML to WSDL Binding Transformation Rules [GWS, 04b] outlines a process for creating web service bindings using the Base Profiles, Abstract Framework and business domain knowledge intrinsic to the Information Model of a particular Specification. This includes guidelines that instruct project teams in how to use the Work Aids in gathering information, processing information, and specifying a Web Services protocols and binding as appropriate. The methodology includes information and graphics describing the role and relationship of the General Web Services methodology to the IMS Specifications. The IMS Enterprise Services bindings have been created using these transformation rules.

2.3 The Abstract Framework

The IMS Abstract Framework is an approach to enable the IMS to describe the context within which it develops its e-learning technology specifications. This framework is not an attempt to define the IMS architecture, rather it is a mechanism to define the set of interfaces for which IMS may or may not produce a set of interoperability specifications. It is the intention of IMS that the Abstract Framework and the associated IMS specifications produced to realize the exchange of information between the identified services will be adopted in a manner suitable for a particular system requirement. The core features of the framework are:

• Application layer - the set of systems, tools and applications that are constructed from the suite of application and common services to provide a particular set of e-learning functionality;
• Application services layer - the set of entities that provide the e-learning specific services e.g., course management. It is these services that constitute the primary focus for IMS specification development;
• Common services layer - the set of entities that provide the generic services to be used by the application services e.g., authentication;
• Infrastructure layer - the underlying services that enable the exchange of the data structures in terms of physical communications, messaging and corresponding transaction needs;
• Service access points - the access points, or interface, to the corresponding service. Each access point provides access to one service capability;
• Entities - the processes that are used to represent a particular service. The realization of an entity with its service access points is termed a component and its abstract representation is called a Class.

The Enterprise Service and its component services (the Person Management Service, the Group Management Service and the Membership Management Service) are all entities within the Applications Services layer of the IAF. The binding of these services is based upon the usage of a web services infrastructure of SOAPv1.1/HTTPv1.1 defined using WSDLv1.1.

2.4 Related Activities

2.4.1 World Wide Web Consortium (W3C)

The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential. The IMS makes extensive usage of some of the W3C specifications, in particular:

• XML and related technologies - this is used by IMS as the basis for the data model bindings;
• SOAP - this is used by IMS as one of communication protocols for the service model bindings;
• Web services and WSDL - this is used by IMS as the basis for the service model bindings.

Further information is available at: http://www.w3c.org.

2.4.2 Web Services Interoperability Organization (WS-I)

WS-I is an open, industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages. The organization works across the industry and standards organizations to respond to customer needs by providing guidance, best practices, and resources for developing Web services solutions. WS-I was formed specifically for the creation, promotion, or support of Generic Protocols for Interoperable exchange of messages between services. Generic Protocols are protocols that are independent of any specific action indicated by the message beyond actions necessary for the secure, reliable, or efficient delivery of messages; "Interoperable" means suitable for and capable of being implemented in a neutral manner on multiple operating systems and in multiple programming languages.

More details are available at: http://www.ws-i.org.

2.4.3 Open Knowledge Initiative (OKI)

The core deliverable of the Open Knowledge Initiative (OKI) is an architectural specification in support of learning management and educational application development, the primary feature of which is a set of application programming interface (API) definitions. OKI are specifying the architecture by identifying a set of services, a framework, upon which learning tool developers can base their work. See Appendix B for more details.

2.5 Related Specifications

2.5.1 WSDL Specification

The IMS service model bindings are expressed using WSDL v1.1. Version 1.1 is used in preference to version 2.0 due to the maturity of the earlier version and the availability of tools to support the development and adoption of the accompanying WSDL. A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types that are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address with a reusable binding and a collection of ports defines a service.

The IMS Enterprise Services bindings are expressed as WSDL files. The structure of these files is summarized in Section 3.3.

2.5.2 WS-I Profile

The WS-I Basic Profile is shown in Table 2.1.

Core Specification	Description
XML Schema V1.0	All data models will be defined in terms of XML Schema and will require the definition of the corresponding control documents (XSD).
HTTP V1.1 (RFC2616)	HTTP is the mandated protocol binding for the SOAP messages.
SOAP V1.1	SOAP is the mandated messaging protocol.
WSDL V1.1	An instance of the service is defined using WSDL v1.1. WSDL is used to enable the description of services as sets of endpoints operating on messages.
UDDI V2.0	An instance of the service may be defined using a UDDI v2.0 binding template.

It is recognized that SOAP v1.2 and WSDL v1.2 are later versions of the SOAP and WSDL specifications respectively, however, there are no sufficiently robust tools that support these versions. The IMS GWS Basic Profile uses the WS-I basic profile with the exception of the UDDI. See [GWS, 04a] and [GWS, 04b] for further details.

2.5.3 Internet vCard Specification

The vCard specification allows the open exchange of Personal Data Interchange (PDI) information typically found on traditional paper business cards. The specification defines a format for an electronic business card, or vCard. The vCard specification is suitable as an interchange format between applications or systems. The format is defined independent of the particular method used to transport it. The transport for this exchange might be a file system, point-to-point public switched telephone networks, wired-network transport, or some form of unwired transport. The vCard has direct application to the way users utilize the Internet network. The vCard can be used to forward personal data in an electronic mail message. The numerous forms a user of the WWW fills out on a homepage can also be automated using the vCard. The Internet Mail Consortium is working with the Internet Engineering Task Force (IETF) to complete work on an extension to the Internet MIME-based electronic mail standard to allow for this capability. An XML binding of the vCard specification has produced a DTD [vCard, 98] and this has been used to inform the development of the IMS Enterprise Person structure.

The mapping between the IMS Enterprise Service and vCard is shown in Section 6.3.

2.5.4 Internet2 eduPerson

In February 2001, the joint Internet2(R) and EDUCAUSE working group announced the release of the 'eduPerson' specification for services that provide seamless access to network-accessible information regardless of where or how the original information is stored. The eduPerson specification provides a set of standard higher-education attributes for an enterprise directory, which facilitate inter-institutional access to applications and resources across the higher education community. The EDUCAUSE/Internet2 eduPerson task force has the mission of defining a Lightweight Directory Access Protocol (LDAP) object class that includes widely-used person attributes in higher education.

The mapping between the IMS Enterprise Service and eduPerson is shown in Section 6.4.

2.5.5 LDAP Specification

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. The terms "LDAP" and "LDAPv3" are commonly used to informally refer to the protocol specified by this technical specification. The LDAP suite, as defined here, should be formally identified in other documents by a normative reference to this document. LDAP is an extensible protocol. More detail is available from: http://www.ietf.org.

The mapping between the IMS Enterprise Service and LDAP is shown in Section 6.5.

2.5.6 OKI Open Services Interface Definition (OSID)

Further detail on the OKI OSIDs is given in Appendix B. The mapping between the IMS Enterprise Service and vCard is shown in Section 6.6.

3. Overall Services Model

3.1 Overall Domain Model

A schematic representation of the core objects exchanged using the IMS Enterprise Services specification is given in Figure 3.1; this diagram is based upon the IMS Abstract Framework.

The core enterprise services are:

• Person management service - the management of information about individuals who are undertaking some form of study and/or group related activity e.g., they are members of a particular course. The person record is designed to be a data model for all of the personal information to be exchanged about an individual;
• Group management service - the management of information about a collection of objects related to learning activities or individuals. There is no restriction on how the Group and sub-group structures can be used with respect to containing other groups, persons, etc.;
• Membership management service - the management of information about the membership structure is used to define the members of a Group. A member can be a Person or another Group. A Group or Person can be a member of any number of groups. The Group and the member are identified using their sourcedIds.

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

3.2 Class Summaries

It is important to note that the UML representation of the interfaces is used to help develop and document the corresponding service information models. 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.1 Person Management Service

The PersonManagementService class is used to model the service responsible for manipulating information about people. 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 [PMS, 04a]. 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 3.1.

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 two or more populated 'person' records on the target system and the target is responsible for the allocation of each 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.

3.2.2 Group Management Service

The GroupManagementService class is used to model the service responsible for manipulating information about groups. 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 [GMS, 04a]. 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 3.2.

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 two or more populated 'group' records on the target system and the target is responsible for the allocation of each 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.

3.2.3 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 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 [MMS, 04a]. 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 3.3.

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 two or more populated 'membership' records on the target system and the source is responsible for the allocation of each 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.

3.3 WSDL Bindings

The WSDL bindings have been generated using the methodology documented in [GWS 04a] and [GWS, 04b].

3.3.1 Person Management Services

The composition of the synchronous Person Management Services WSDL binding files is listed below [PMS, 04b]:

• 'imsPersonManServiceSyncv1p0.wsdl' - the synchronous service specific WSDL binding file. For the Person Management Service this is based upon SOAP/http. This file imports the abstract definitions using the <wsdl:import> construct;
• 'imsPersonManAbstractSyncv1p0.wsdl' - the synchronous abstract message definitions that represent the behavior of the Person Management Service operations. This file imports the message XSD using the <xsd:import> construct;
• 'imsPersonManSyncv1p0.wsdl' - the synchronous WSDL binding file. This is the single file equivalent of the combination of the 'imsPersonManServiceSyncv1p0.wsdl' and 'imsPersonManAbstractSyncv1p0.wsdl' files;
• 'imsPersonManMessSchemav1p0.xsd' - the XSD definitions for the synchronous and asynchronous messages. This file imports the Person data model XSD using the <xsd:import> construct;
• 'imsPersonManDataSchemav1p0.xsd' - the definition of the Person data model. This is the file that was produced by the equivalent data model binding in Enterprise v1.1;
• 'imsMessBindSchemav1p0.xsd' - the XSD binding of the message header parts. This includes the message headers for synchronous, polled and asynchronous message models;
• 'imsEnterpriseCommonSchemav1p0.xsd' - the XSD binding of the IMS Enterprise Services common data objects. This file is used by the Person message and data model XSDs as well as the IMS message binding XSD;
• 'wsiwsdlv1p1.xsd' - this is the reference XSD for the WSDL definition. This file is the WS-I amended version of the original file from W3C;
• 'wsisoapv1p1.xsd' - this is the reference XSD for the SOAP extensions to WSDL. This file is from WS-I.

3.3.2 Group Management Services

The composition of the synchronous and asynchronous Group Management Services WSDL binding files is listed below [GMS, 04b]:

• 'imsGroupManServiceSyncv1p0.wsdl' - the synchronous service specific WSDL binding file. For the Group Management Service this is based upon SOAP/http. This file imports the abstract definitions using the <wsdl:import> construct;
• 'imsGroupManAbstractSyncv1p0.wsdl' - the synchronous abstract message definitions that represent the behavior of the Group Management Service operations. This file imports the message XSD using the <xsd:import> construct;
• 'imsGroupManSyncv1p0.wsdl' - the synchronous WSDL binding file. This is the single file equivalent of the combination of the 'imsGroupManServiceSyncv1p0.wsdl' and 'imsGroupManAbstractSyncv1p0.wsdl' files;
• 'imsGroupManMessSchemav1p0.xsd' - the XSD definitions for the synchronous and asynchronous messages. This file imports the Group data model XSD using the <xsd:import> construct;
• 'imsGroupManDataSchemav1p0.xsd' - the definition of the Group data model. This is the file that was produced by the equivalent data model binding in Enterprise v1.1;
• 'imsMessBindSchemav1p0.xsd' - the XSD binding of the message header parts. This includes the message headers for synchronous, polled and asynchronous message models;
• 'imsCommonSchemav1p0.xsd' - the XSD binding of the IMS common data objects. This file is used by the Group message and data model XSDs as well as the IMS message binding XSD;
• 'wsiwsdlv1p1.xsd' - this is the reference XSD for the WSDL definition. This file is the WS-I amended version of the original file from W3C;
• 'wsisoapv1p1.xsd' - this is the reference XSD for the SOAP extensions to WSDL. This file is from WS-I.

3.3.3 Membership Management Services

The composition of the synchronous and asynchronous Person Management Services WSDL binding files is listed below [MMS, 04b]:

• 'imsMemberManServiceSyncv1p0.wsdl' - the synchronous service specific WSDL binding file. For the Membership Management Service this is based upon SOAP/http. This file imports the abstract definitions using the <wsdl:import> construct;
• 'imsMemberManAbstractSyncv1p0.wsdl' - the synchronous abstract message definitions that represent the behavior of the Membership Management Service operations. This file imports the message XSD using the <xsd:import> construct;
• 'imsMemberManSyncv1p0.wsdl' - the synchronous WSDL binding file. This is the single file equivalent of the combination of the 'imsMemberManServiceSyncv1p0.wsdl' and 'imsMemberManAbstractSyncv1p0.wsdl' files;
• 'imsMemberManMessSchemav1p0.xsd' - the XSD definitions for the synchronous and asynchronous messages. This file imports the Membership data model XSD using the <xsd:import> construct;
• 'imsMemberManDataSchemav1p0.xsd' - the definition of the Membership data model. This is the file that was produced by the equivalent data model binding in Enterprise v1.1;
• 'imsMessBindSchemav1p0.xsd' - the XSD binding of the message header parts. This includes the message headers for synchronous, polled and asynchronous message models;
• 'imsCommonSchemav1p0.xsd' - the XSD binding of the IMS common data objects. This file is used by the Membership message and data model XSDs as well as the IMS message binding XSD;
• 'wsiwsdlv1p1.xsd' - this is the reference XSD for the WSDL definition. This file is the WS-I amended version of the original file from W3C;
• 'wsisoapv1p1.xsd' - this is the reference XSD for the SOAP extensions to WSDL. This file is from WS-I.

3.3.4 Namespacing

The name spaces used within the bindings are listed in Table 3.4.

Namespace	Prefix	Usage
-	"tns:"	The target namespace identifier.
http://www.w3.org/2001/XMLSchema	"xsd:"	The XML schema definition namespace.
/enterprise/xsd/imsCommonSchemav1p0	"iaf:"	The IMS Enterprise Service common data model definitions namespace.
/common/xsd/imsMessBindSchemav1p0	"isb:"	The IMS message header binding definitions namespace.
/pms/xsd/imsPersonManDataSchemav1p0	"per:"	The data model namespace for the Person class.
/gms/xsd/imsGroupManDataSchemav1p0	"grp:"	The data model namespace for the Group class.
/mms/xsd/imsMemberManDataSchemav1p0	"mem:"	The data model namespace for the Membership class.
/pms/xsd/imsPersonManMessSchemav1p0	"imspms:"	The IMS Person Management Services message binding definitions namespace.
/gms/xsd/imsGroupManMessSchemav1p0	"imsgms:"	The IMS Group Management Services message binding definitions namespace.
/mms/xsd/imsMemberManMessSchemav1p0	"imsmms:"	The IMS Membership Management Services message binding definitions namespace.
/pms/wsdl/imsPersonManAbstractAsyncReqv1p0	"absp:"	The Person Management Service asynchronous abstract definitions file references.
/pms/wsdl/imsPersonManAbstractAsyncResv1p0	"absp:"	The Person Management Service asynchronous abstract definitions file references.
/gms/wsdl/imsGroupManAbstractAsyncReqv1p0	"absg:"	The Group Management Service asynchronous abstract definitions file references.
/gms/wsdl/imsGroupManAbstractAsyncResv1p0	"absg:"	The Group Management Service asynchronous abstract definitions file references.
/mms/wsdl/imsMemberManAbstractAsyncReqv1p0	"absp:"	The Membership Management Service asynchronous abstract definitions file references.
/mms/wsdl/imsMemberManAbstractAsyncResv1p0	"absp:"	The Membership Management Service asynchronous abstract definitions file references.
wsisoapv1p1	"soap:"	The SOAP references used within the WSDL files.
wsiwsdlv1p1	"wsdl:"	The default WSDL files namespace for WSDL v1.1.

4. SOAP/HTTP Messages for Synchronous Services

4.1 The SOAP/HTTP Message Structures

All of the messages described in the following examples have the same basic structure. The structure of these Request/Response messages is now described.

4.1.1 Request Messages

The basic SOAP/HTTP request message is shown below. The HTTP components are shown in lines (1-5). The invoking service name is shown in line (1) with the host server identified in line (2). The associated SOAP Action is given in line (5). The associated SOAP message structure is supplied in lines (7-9) i.e., enclosed in the element <SOAP-ENV:Envelope>. The usage of the namespace 'SOAP-ENV:' is defined in line (7).

0001 0002 0003 0004 0005 0006 0007 0008 0009

POST /PersonManagementService HTTP/1.1 Host: www.personmanagementserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://www.imsglobal.org/soap/pms/deletePerson"   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> ... </SOAP-ENV:Envelope>

The detailed structure of the SOAP envelope is shown below. The contents of the SOAP envelope are listed in lines (7-15). The envelope consists of the SOAP header, lines (8-12) and the SOAP body, lines (13-15). The SOAP header is used to contain the message control information that is required for the synchronous end-to-end messaging to support the service behaviors. The header namespace is defined in line (9).

Every request message has a unique message identifier, i.e., line (10). The transmitting system is responsible for creating this unique identifier. The structure for this header is shown in the file 'imsMessBindSchemav1p0.xsd'.

0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016

POST /PersonManagementService HTTP/1.1 Host: www.personmanagementserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://www.imsglobal.org/soap/pms/deletePerson"   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <h:syncRequestHeaderInfo xmlns:h="../imsMessBindSchemav1p0.xsd"> <h:messageIdentifier>AB12345e4t6789</h:messageIdentifier> </h:syncRequestHeaderInfo> </SOAP-ENV:Header> <SOAP-ENV:Body> ... </SOAP-ENV:Body> </SOAP-ENV:Envelope>

The SOAP body is shown below in lines (13-19). The namespace to be used in the body is defined in line (14). Line (14) also contains the associated XSD control document file.

0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020

POST /PersonManagementService HTTP/1.1 Host: www.personmanagementserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://www.imsglobal.org/soap/pms/deletePerson"   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <h:syncRequestHeaderInfo xmlns:h="../imsMessBindSchemav1p0.xsd"> <h:messageIdentifier>AB12345e4t6789</h:messageIdentifier> </h:syncRequestHeaderInfo> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:deletePersonRequest xmlns:m="../imsPersonManMessSchemav1p0.xsd"> <m:sourcedId> <esx:identifier>oldsource:oldidentifier</esx:identifier> </m:sourcedId> </m:deletePersonRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

4.1.2 Response Messages

The basic SOAP/HTTP response message is shown below. The associated SOAP message structure is supplied in lines (5-7) i.e., enclosed in the element <SOAP-ENV:Envelope>. The usage of the namespace 'SOAP-ENV:' is defined in line (5).

0001 0002 0003 0004 0005 0006 0007

HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> ... </SOAP-ENV:Envelope>

The detailed structure of the SOAP envelope is shown below. The contents of the SOAP envelope are listed in lines (5-19). The envelope consists of the SOAP header, lines (6-15) and the SOAP body, lines (16-18). The SOAP header is used to contain the message control information that is required for the synchronous end-to-end messaging to support the service behaviors. The header namespace is defined in line (7).

Every response message has a unique message identifier, i.e., line (8). The transmitting system is responsible for creating this unique identifier. The structure for this header is shown in the file 'imsMessBindSchemav1p0.xsd'.

Every response message has a status field. The status field for a single transaction it is supplied as <h:statusInfo> whereas for multiple transactions it is supplied as <h:statusInfoSet>. The content of the status information is defined in the IMS Common Data Model [ESCommon, 04].

0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019

HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <h:syncResponseHeaderInfo xmlns:h="../imsMessBindSchemav1p0.xsd"> <h:messageIdentifier>AB12345e4t6889</h:messageIdentifier> <h:statusInfo> <h:codeMajor>success</h:codeMajor> <h:severity>status</h:severity> <h:messageIdRef>AB12345e4t6789</h:messageIdRef> </h:statusInfo> </h:syncResponseHeaderInfo> </SOAP-ENV:Header> <SOAP-ENV:Body> ... </SOAP-ENV:Body> </SOAP-ENV:Envelope>

The SOAP body is shown below in lines (16-18). The namespace to be used in the body is defined in line (17). Line (17) also contains the associated XSD control document file.

0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 0016 0017 0018 0019

HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn   <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> <h:syncResponseHeaderInfo xmlns:h="../imsMessBindSchemav1p0.xsd"> <h:messageIdentifier>AB12345e4t6889</h:messageIdentifier> <h:statusInfo> <h:codeMajor>success</h:codeMajor> <h:severity>status</h:severity> <h:messageIdRef>AB12345e4t6789</h:messageIdRef> </h:statusInfo> </h:syncResponseHeaderInfo> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:deletePersonResponse xmlns:m="../imsPersonManMessSchemav1p0.xsd"/> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

4.2 Person Management Service Messages

The set of example Person Management Service SOAP/HTTP messages are described in Table 4.1. These files are stored in the directory '/examples/pms/sync/<operationname>/'. To access the example click on the corresponding filename listed in Table 4.1.

Activity	Request Message Example File	Response Message Example File
Creation of a Single Person Record	createPersonRequest.txt	createPersonResponse.txt
Proxy Creation of a Single Person Record	createByProxyPersonRequest.txt	createByProxyPersonResponse.txt
Deletion of a Single Person Record	deletePersonRequest.txt	deletePersonResponse.txt
Reading of a Single Person Record	readPersonRequest.txt	readPersonResponse.txt
Updating of a Single Person Record	updatePersonRequest.txt	updatePersonResponse.txt
Replacing of a Single Person Record	replacePersonRequest.txt	replacePersonResponse.txt
Changing the Identifier of a Single Person Record	changePersonIdentifierRequest.txt	changePersonIdentifierResponse.txt
Creation of Multiple Person Records	createPersonsRequest.txt	createPersonsResponse.txt
Proxy Creation of Multiple Person Records	createByProxyPersonsRequest.txt	createByProxyPersonsResponse.txt
Deletion of Multiple Person Records	deletePersonsRequest.txt	deletePersonsResponse.txt
Reading of Multiple Person Records	readPersonsRequest.txt	readPersonsResponse.txt
Reading of Persons that are a Member of a Group	readPersonsForGroupRequest.txt	readPersonsForGroupResponse.txt
Updating of Multiple Person Records	updatePersonsRequest.txt	updatePersonsResponse.txt
Replacing of Multiple Person Records	replacePersonsRequest.txt	replacePersonsResponse.txt
Changing the Identifier of Multiple Person Records	changePersonsIdentifierRequest.txt	changePersonsIdentifierResponse.txt

4.3 Group Management Service Messages

The set of example Group Management Service SOAP/HTTP messages are described in Table 4.2. These files are stored in the directory '/examples/gms/sync/<operationname>/'. To access the example click on the corresponding filename listed in Table 4.2.

Activity	Request Message Example File	Response Message Example File
Creation of a Single Group Record	createGroupRequest.txt	createGroupResponse.txt
Proxy Creation of a Single Group Record	createByProxyGroupRequest.txt	createByProxyGroupResponse.txt
Deletion of a Single Group Record	deleteGroupRequest.txt	deleteGroupResponse.txt
Deletion of Single Group Relationship	deleteGroupRelationshipRequest.txt	deleteGroupRelationshipResponse.txt
Reading of a Single Group Record	readGroupRequest.txt	readGroupResponse.txt
Updating of a Single Group Record	updateGroupRequest.txt	updateGroupResponse.txt
Replacing of a Single Group Record	replaceGroupRequest.txt	replaceGroupResponse.txt
Changing the Identifier of a Single Group Record	changeGroupIdentifierRequest.txt	changeGroupIdentifierResponse.txt
Creation of Multiple Group Records	createGroupsRequest.txt	createGroupsResponse.txt
Proxy Creation of Multiple Group Records	createByProxyGroupsRequest.txt	createByProxyGroupsResponse.txt
Deletion of Multiple Group Records	deleteGroupsRequest.txt	deleteGroupsResponse.txt
Deletion of Multiple Group Relationship	deleteGroupsRelationshipRequest.txt	deleteGroupsRelationshipResponse.txt
Reading of Multiple Group Records	readGroupsRequest.txt	readGroupsResponse.txt
Reading of Groups that have a particular Person as a Member.	readGroupsForPersonRequest.txt	readGroupsForPersonResponse.txt
Updating of Multiple Group Records	updateGroupsRequest.txt	updateGroupsResponse.txt
Replacing of Multiple Group Records	replaceGroupsRequest.txt	replaceGroupsResponse.txt
Changing the Identifier of Multiple Group Records	changeGroupsIdentifierRequest.txt	changeGroupsIdentifierResponse.txt

4.4 Membership Management Service Messages

The set of example Membership Management Service SOAP/HTTP messages are described in Table 4.3. These files are stored in the directory '/examples/mms/sync/<operationname>/'. To access the example click on the corresponding filename listed in Table 4.3.

Activity	Request Message Example File	Response Message Example File
Creation of a Single Membership Record	createMembershipRequest.txt	createMembershipResponse.txt
Proxy Creation of a Single Membership Record	createByProxyMembershipRequest.txt	createByProxyMembershipResponse.txt
Deletion of a Single Membership Record	deleteMembershipRequest.txt	deleteMembershipResponse.txt
Reading of a Single Membership Record	readMembershipRequest.txt	readMembershipResponse.txt
Updating of a Single Membership Record	updateMembershipRequest.txt	updateMembershipResponse.txt
Replacing of a Single Membership Record	replaceMembershipRequest.txt	replaceMembershipResponse.txt
Changing the Identifier of a Single Membership Record	changeMembershipIdentifierRequest.txt	changeMembershipIdentifierResponse.txt
Creation of Multiple Membership Records	createMembershipsRequest.txt	createMembershipsResponse.txt
Proxy Creation of Multiple Membership Records	createByProxyMembershipsRequest.txt	createByProxyMembershipsResponse.txt
Deletion of Multiple Membership Records	deleteMembershipsRequest.txt	deleteMembershipsResponse.txt
Reading of Multiple Membership Records	readMembershipsRequest.txt	readMembershipsResponse.txt
Reading of the Memberships for a Particular Person.	readMembershipsForPersonRequest.txt	readMembershipsForPersonResponse.txt
Reading of the Memberships for a Particular Group.	readMembershipsForGroupRequest.txt	readMembershipsForGroupResponse.txt