DevelopmentSUMRepositoryMigration – e-Framework Community Wiki

Context Navigation

e-Framework Service Usage Model Name

*Bulk-migration service for objects within repository systems

*SOURCE (Sharing Object Under Repository Control with Everyone) Project - JISC funded 2007-2008 (Capital Programme)

Version

0.1.

Version History

Version	Date	Author	Description	Organization / Project
0.1.	2007-11-06	David F. Flanders	Initial Draft	SOURCE

Rationale

The SOURCE project puts forward a bulk-migration service by which to programmatically move objects from one repository system to another. A healthy marketplace is an open marketplace, where objects are able to be transferred between stakeholders without being controlled by a single monopoly. Information in the form of digital objects require an open marketplace if they are to be successful in the larger open web marketplace. This means allowing the owner (or caretaker) of the objects to migrate them between systems (regardless of platform) to any other container system. The SOURCE project demonstrates -by means of an open API- to enable any repository system to perform generic tasks that will allow digital objects to be seamlessly transferred from one container repository to another.

Classification

To be provided by the submitter:

SUM Type	[X] Domain	[ ] CORE (a commonly recurring SUM; designation requires e-Framework Integrity Group approval)
Domain(s)	[ ] Learning & Teaching	[ ] Research [ ] Libraries	[ ] Administration [ ] IT Services	[X] Common
Maturity	[X] Immature	[ ] Mature
Purpose(s)	[ ] Exemplar	[X] Application	[ ] Modelling	[ ] Toolkit
XOR (exclusive “or”)	[ ] Service Genres	[X] Service Expressions
Development Status	[ ] Proposed	[ ] Developmental	[X] Prototype	[ ] Production
Deployment Scale	[X] Isolated	[ ] Ubiquitous			<-Phil it would help to have something in between: "adopted"
State Behaviour	[X] Stateful	[ ] Stateless
Transactional Behaviour	[X] Transactional and ACID	[ ] Transactional but Non ACID	[ ] Non-Transactional
Batch Behaviour(s)	[ ] Individual	[ ] Batch
Time-Constraint Behaviour	[ ] Hard Real Time	[ ] Soft Real Time	[ ] None
Service End Point	[ ] Provider	[ ] Requestor	[ ] Transcoder (both requests and provides)
Authentication/Authorization Dependency	[ ] Auth-Dependent	[ ] Auth-Independent
Protocol Binding(s) (only applies to service expression-based SUMs)	[ ] Web Service [ ] SOAP	[ ] REST [ ] HTTP	[ ]Other

To be determined by the e-Framework:

Status	[ ] Approved	[ ] Placeholder [ ] Unapproved	[ ] Superseded [ ] Withdrawn
Confidence Level	[ ] High	[ ] Medium	[ ] Low

Notation [optional]

List and explain the conventions and terminology used that are essential for understanding the rest of the Service Usage Model description. A complete list of terms should be included in the Glossary (below).

Description

Write an informal, non-technical narrative describing what the Service Usage Model does and how it does it: the problem it addresses and its intended function, business-level capabilities and basic workflow.

Business Process Modelling

Summarise the business analysis motivating the Service Usage Model and provide a link to the full analysis. Then outline the business function(s) and process(es) that the Service Usage Model supports to provide context for its Functionality, but do not go into detail about system functions, services or workflows.

SUM Diagram

Provide a diagram that is similar to the Generic SUM diagram used on the e-Framework website. Include only the SUM diagram here; the narrative explaining the diagram belongs in “Structure & Organisation”. When submitting this completed document, also upload the diagram graphics as a separate file, or combine the file with this document to upload as a ZIP file.

Usage Scenarios [optional]

Briefly describe one or more applications that use the Service Usage Model or give examples of business scenarios that use the SUM’s workflows.

Applicability [optional]

Provide a detailed explanation about how and when the Service Usage Model is to be used or not used; include specific constraints and assumptions.

Functionality

Outline the individual system functions that the Service Usage Model provides in terms of workflows, messages, and data (documents); include constraints and conditions but do not include implementation-specific information. If appropriate, include an illustration of the workflows, related data and processes.

Structure & Organisation

Outline the services, data sources and choreography that underlie all the individual functionalities in the Service Usage Model. Describe how the functions are integrated at the service level as a whole system.

Applicable Standards [recommended]

List the standards that pertain to the functionality of the Service Usage Model as a whole; provide the name, version and citation link (to the JISC Standards Catalogue if possible). Note any conformance requirements and extensions.

Design Decisions & Tradeoffs [optional]

Describe the decisions involved in designing the Service Usage Model. Limit the discussion to the design of the overall Service Usage Model; do not discuss internal details of the services or specific applications.

Implementation Guidance & Dependencies [optional]

Describe all anticipated issues that may affect the implementation of applications that use the Service Usage Model, such as the organisation, performance, behaviours, representations and policies.

Known Uses [optional]

List the known implementations or uses of the Service Usage Model by any applications or systems. List other Service Usage Models that incorporate, use or are dependent on this Service Usage Model.

Data Sources Used

Provide the names and descriptions of all data sources used in the Service Usage Model.

Related SUMs [optional]

List the names and versions of other Service Usage Models that are used within this Service Usage Model to build the functionality.

Services Used

List the names and versions of the Service Genres XOR Service Expressions that this Service Usage Model is based on.

CORE SUMs Used [recommended]

List the names and versions of all Commonly Recurring (CORE) SUMs that this Service Usage Model is based on.

References

List references and bibliographic citations to works needed to understand the Service Usage Model.

Glossary [optional]

List and define the domain-specific terms used in documenting the Service Usage Model.

This SUM is licensed under:

Creative Commons Attribution-NonCommercial-ShareAlike 2.5 licence

Submitting the Service Usage Model Description

For additional guidance in preparing the Service Usage Model description, refer to Guidelines for Submitting a Service Usage Model to the e-Framework and the technical definitions of the Service Usage Model Description Elements. For further assistance, contact the e-Framework editor at: editor@…

Prior to submitting the description, please read the e-Framework Intellectual Property Rights statement Also add your information to the copyright statements in the footer of this template.

By submitting this document, you agree to contribute this document under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 licence.

When you have completed the Service Usage Model description, go to the Submit SUMs page at www.e-framework.org. Click on “Upload your submission” and follow the directions.

Download in other formats:

Plain Text