From NSDLWiki

Contents [hide] 1 DDS and CCS Use Cases for Collections API 1.1 Use Case One: Read-Only DDS 1.1.1 Walk through 1.2 Use Case Two: Read-Write DDS 1.2.1 Walk through 1.3 Use Case Three: Read-Write CCS 1.3.1 Walk through

DDS and CCS Use Cases for Collections API

The DDS has two primary use cases for the Collections API. One is a read-only mode in which the DDS reads in collections, items and annotations from the NDR to build it's search index. The second is a read-write mode in which the DDS maintains collections, items and annotations in an NDR synchronously with the items in it's own index. The CCS use case is an example of and extension to the read-write DDS use case.

Use Case One: Read-Only DDS

An example of this use case is the MSP2 DL collections. The collections are managed in the NDR outside of DDS by another application, in this case the NCS. The DDS builds and periodically synchronizes it's search index by polling the related MSP2 collections, items and annotations from the NDR.

Walk through

Boot up - DDS starts up and initializes, bootstrapping from the NDR as necessary.

1. DDS reads from a configuration file to determine the NDR collection groups it is interested in (in this case 'msp2')
2. DDS then performs an initial synchronization (see below)

Synchronization - At regular periods (say once a day), DDS synchronizes it's index with the desired collections, items and annotations in the NDR.

1. Perform a ListCollections call and inspect the response.
2. For each collection that has the desired group specified in the NDRCollectionInfo XML (group='mps2'), DDS creates a corresponding collection in it's index if it does not already exist using the name, description and collctionID found in the header and NDRCollectionInfo record in the ListCollections response
   • DDS removes any collections in it's index that are no longer found under the given group in ListCollections response
3. For each collection DDS then performs a ListRecords request for the native XML format. For each record in ListRecords, DDS adds the item or annotation to the corresponding collection in it's index.
   • Collections may contain items or annotations in any order. If the record is an item, the indexer checks if any items in the index annotates it and if so, it builds the annotation data into the index record for that item. If the record is an annotation, the indexer checks for items that it annotations and if found, builds the annotation data into the index record for that item.
   • DDS then removes any item or annotation that it had previously indexed but no longer exists in the ListRecords response for that collection

Use Case Two: Read-Write DDS

An example of this use case is the DDS operating in read-write mode. DDS provides a public API that is used by applications to create, update and delete collections, items and annotations in a DDS repository. DDS would leverage the NDR to provide persistence and optionally share certain collections, items and annotations with other NDR consumers. DDS may combine this functionality with read-only functionality described in Use Case One to optionally bring in collections managed by other agents/metadataSources.

Walk through

Start up - DDS starts up and initializes, setting up the necessary agent for write operations and ensuring necessary collections are present.

1. DDS checks for the existence of the DDS agent in the NDR and creates one if necessary using the PutAgent call.
2. DDS iterates through each of the collections in it's repository. For each collection in DDS, use GetCollection to ensure corresponding collections exist in the NDR.
3. If a collection does not exist, use PutCollection to crate one
   • Supply the title, description, ID and DDS internal collection record in the PutCollection call.
   • Apply a group identifier in PutCollection to identify it for this instance of DDS, for example 'dds-ccs', and apply restrictAccessTo to DDS agent only.
   • Apply additional group identifiers in PutCollection to identify a collection for use by other consumers, for example 'ccs-shared-user-resources', and apply access rights using restrictAccessTo for other agents/metadataSources.
   • If the collection is an annotation format, ensure that the annotation relation path is registered in the NDR using ListAnnotationRelationPaths and PutAnnotationRelationPath

Real-time synchronization - Each time a collection, item or annotation is created, updated or deleted in DDS, perform the corresponding operation in the NDR synchronously.

• Collection is created, updated or deleted in DDS
  1. If the collection is new, follow the steps described above for PutCollection operation.
  2. If the collection is updated, update the data using PutCollection.
  3. If the collection is deleted, perform a DeleteCollection call.
  4. If error, back out while maintaining state in DDS.
• Item or annotation is created, updated or deleted in DDS
  1. Perform PutRecord or DeletRecord in the NDR for the corresponding collection.
  2. If error, back out while maintaining state in DDS.

Synchronization with external collection - For collections managed by another agent/metadataSource, synchronize them periodically with DDS using the steps outlined in Use Case One.

Bootstrapping/periodic synchronization from NDR - For collections managed by the DDS, it may be necessary to occasionally bootstrap and/or synchronize collections, items and annotations from the NDR to restore state in the DDS. For this, essentially follow the same procedure outlined in Use Case One to restore/synchronize DDS-managed collections.

Use Case Three: Read-Write CCS

Another example of a read-write use case is the Curriculum Customization Service (CCS). CCS is a rich learning application that relies heavily on DDS search functionality to provide DL resources to users, implement personalization services such as notes, comments, tagging, star ratings, uploading and sharing, and implement authorization/authentication and user identity management services. CCS would leverage the NDR to provide persistence, store binary content, potentially share certain items and annotations with other NDR consumers and potentially discover relevant items and annotations from other NDR agents/metadataSources.

For this use case, CCS would rely heavily on the functionality described in Use Case Two. That is, the DDS would largely do the work of maintaining the collections, items and annotations in the NDR for the CCS. The CCS would interact directly with the NDR store and retrieve binary content and to potentially fetch items that do not require search functionality to discover.

Walk through

Start up - CCS starts up and initializes, creating collections in the DDS as it does now to store items (user-contributed resources, user/profile data) and annotations (notes, comments, tags, start ratings). The DDS would maintain/synchronize these in the NDR as described above. CCS would set up a collection to store binary content (uploaded user-contributed resources) directly in the NDR.

1. CCS checks for the existence of the CCS agent in the NDR and creates one if necessary using the PutAgent call.
2. CCS checks for the existence of the binary content collection and creates one if necessary using GetCollection, PutCollection.
   • Apply apply restrictAccessTo to CCS agent only, optionally allow access to other agents/metadataSources if desired.

Store/retrieve binary content - Binary content created by CCS users would be stored and retrieved from the NDR.

1. When user saves a file, PutContent is called to store the item in the NDR. A corresponding metadata record for the item would also be stored via the DDS PutRecord operation.
2. Discovery of user-contributed resources is implemented using DDS.
3. When user requests content from the CCS, authorization/authentication is performed by CCS (shared resources are made available to any authenticated user; private resource only the creator). If authorized, CCS performs a GetContent call from NDR to fetch the content and stream it to the user.

Access items from others collections - Collections managed by other agents/metadataSources may be of interest to CCS users. For example, educational resources or standards data. There are two options here: direct access from the NDR or access via a DDS search index synchronized with the NDR.