CHS-WS Design
Access to content is currently done via a Java service interface. This allows server-side applications to access content resources, add new ones, etc. To enable remote access, some form of communication interface is needed. Web service access would allow remote applications to directly access content hosted by Sakai using an interface very similar to the existing Content Hosting service.
Alternatively, this access could be abstracted behind a repository interface using the OKI Repository OSID. A combination of these approaches will be developed. General purpose CHS web services will be created, followed by an implementation of the OKI DR-OSID against these services.
Both the web services and repository approaches will needed to provide the following operations:
- Search (Sakai search service / across sites) - Is this web service accessible?
- basic search by site (not clear if this is recursive to directory tree)
- Browse
- List directory and sub directories
- Download
- Get as a stream or object
- Include metadata
- Upload
- Add a new asset as a stream or object
- Include metata
- Access Metadata
- Identifier
- Name
- Resource Type
- (Content Type - MIME)
- (Description)
- (Creation time) - is this needed?
- (Modification time) - is this needed?
Access via web service to Sakai requires that the user login first using the SakaiLogin service. This returns a session id which is passed in subsequent service requests to indicate the user thread. This also established access permissions of the current user.
The Content Hosting Service is set up to establish separate content roots for each Sakai site containing the Resources Tool. Since thousands of sites are common on Sakai installations, some means must be provided to limit scope. However, each user normally has access to a limited number of sites (typically less than a few dozen). This is an appropriate method to winnow the number of site roots presented to the web service consumer. Site roots are therefore federated under a single "virtual root". Virtual, because it doesn't really exist in the Content Hosting Service, but is instead managed by the ContentHosting web services.
Sakai resources would make available name, description, id, and resource type (based on MIME) to VUE. Additional metadata could also be made available, including creation and modification times, owner, etc. (if desired) Visual materials may include a thumbnail image representation. Finally, a URL to the item in Sakai would also be provided. Resource types are associated with type icons, established by a file type registry in VUE.
CHS Web Services
Based on web service experiements, the following services will provide access to the Content Hosting Service in Sakai.
Name |
Arguments |
Notes |
Status |
---|---|---|---|
getVirtualRoot() |
sessionId |
Allows all accessible sites to be collected. |
|
getResources() |
sessionId, virtualRootId |
Gets the set of accessible site roots. |
|
getResources() |
sessionId, collectionId |
Gets the info of resources in the collections. |
|
getResources() |
sessionId, resourceId |
Gets the resource info. |
|
getInfo() |
sessionId, virtualRootId |
Special case to provide info on virtual root. |
|
getInfo() |
sessionId, collectionId |
Get all information on the collection. |
|
getInfo() |
sessionId, resourceId |
Get all information on the resource. |
|
getContent() |
sessionId, resourceId |
Get a binary data object. |
|
putContent() |
sessionid, object, info, collectionId |
Add the object and info to the collection. |
|
search() |
args are TBD |
Get a list of resource ids and names basedon search criteria. |
These services are designed to balance granularity against request time overhead. The getResources() service should provide all information needed to display hierarchical collection information in a UI. The getInfo() service provides similar information for a single content entity. The getData() and putData() services include the object being transferred and associated metadata. Finally, a search function might be made available to search federated sites for resources specified by some search criteria (TBD). Search capabilities in CHS are very limited at this point and this service may need to be based on the Search Tool develped by Ian Boston at CARET.
Need to consider how to handle attachments, locks, drop boxes.
Content Hosting Web Services - Expanded Capability
These sections describe a more detailed approach to CHS web services that go beyond the scope of VUE integration.
Sakai already provides basic support for revealing existing services as web services. Providing access to the Content Hosting Service largely consists of defining the services and writing the adaptor code needed to make them work. New web services will be tested via Sakai Script using client and server computers. The one challenging aspect of this task is support for SOAP attachments. None of the existing Sakai web services use attachments, which will be required to attach content resources to a SOAP message for uploading into a Sakai CH collection. This is how the maps or map packages get published to Sakai, so support for this must be included.
Three primary objects are likely needed to support access of Sakai content via web services: the service, collections, and resources. Other considerations are examined as well.
Content Hosting Service
addCollection |
Used to create new collection (directory) given a Sakai id (path based) and a collection of properties (metadata). Returns a collection object. |
getCollectionSize |
Given a Sakai id, returns the size in kilobytes. |
getAllEntities |
Returns a list of all entities in a collection given by a Sakai id. Entities may include both resources and collections. |
getAllResources |
Returns a list of all resources in a collection given by a Sakai id. Sub-collections are not included. |
addResource |
Add a resource given a Sakai id (which includes its path). |
addAttachmentResource |
Add an attachment given a Sakai id (which includes its path and resource to be attached to). |
getResource |
Get the resource given a Sakai id (which includes its path). |
rename |
Change the name of a resource given by its id. |
copy |
Not likely needed for VUE implementation. |
copyIntoFolder |
Not likely needed for VUE implementation. |
moveIntoFolder |
Not likely needed for VUE implementation. |
getProperties |
Get the properties (metadata) associated with a resource or collection given its Sakai id. Returned as a map. |
setProperty |
Set a given property for a resource given the resource id, property name, and new value. |
addProperty |
Add a property to the resource given by a Sakai resource id. |
getUrl |
Get the URL associated with a resource or collection given its Sakai id and optional root property. |
getContainingCollectionId |
Get the Sakai id of the collection containing the given resource or collection. |
getDepth |
Get the depth of this resource or collection based on a collection reference. |
getSiteCollection |
Get the root collection associated with the site id given. |
Collection
getMembers |
Get the members of this collection. |
getMemberResources |
Get just the resources included in this collection. |
getBodySizeK |
Get the size of this collection in kilobytes. |
Resource
getContentLength |
Get the length of this resource in bytes. |
getContentType |
Get the MIME types of this resource. |
getContent |
Get the content data for this resource (form to be determined). |
Other Considerations
- Attachments - handled as a regular resource. VUE doesn't support attachments.
- Locks - Locks are not needed by VUE.
- Drop boxes - Drop boxes are also not needed.