|
|
| Line 17: |
Line 17: |
| *REST interfaces are realized through sending a basic HTTP requests (GET, PUT, POST, DELETE) to a resource/subresource URI (each resource has a URI represented via XLink). | | *REST interfaces are realized through sending a basic HTTP requests (GET, PUT, POST, DELETE) to a resource/subresource URI (each resource has a URI represented via XLink). |
|
| |
|
| Input and output messages for same operations offered by both types of interfaces are specified with the same XML representation. | | Input and output messages for same operations offered by both types of interfaces are specified with the corresponding XML representation. Note: until build 0.94 both SOAP/REST interfaces were based on same schemas. As of build 0.94 this is changed, and the SOAP interfaces use slightly modified schemas(no xlink attributes) then the REST interfaces. |
|
| |
|
|
| |
|
| Example 1: create an item | | Example 1: create an item |
| *SOAP: ItemHandler.createItem ("item.xml") (where item.xml is compliant with the item.xsd schema). | | *SOAP: ItemHandler.createItem ("item.xml") (where item.xml is compliant with the SOAP item.xsd schema). |
| *REST: PUT /ir/item/ (with "item.xml" in the body of the request) (where item.xml is compliant with the item.xsd schema) | | *REST: PUT /ir/item/ (with "item.xml" in the body of the request) (where item.xml is compliant with the REST item.xsd schema) |
|
| |
|
| item.xml (enriched with system generated data is returned if the request is successfully executed) | | item.xml (enriched with system generated data is returned if the request is successfully executed) |
| Line 35: |
Line 35: |
| The REST API differentiates between resource- and task-oriented methods. All resource-oriented methods use GET, PUT and DELETE verbs. Task-oriented methods use the POST verb. | | The REST API differentiates between resource- and task-oriented methods. All resource-oriented methods use GET, PUT and DELETE verbs. Task-oriented methods use the POST verb. |
|
| |
|
| At present, intermediate and application services implemented in Java invoke the Basic Services via the SOAP API. They use the [[http://jibx.sourceforge.net/ JiBX data-binding framework]] to transform the XML representation of resources returned by Basic services, since it allows for the definition of custom mappings to Java classes. | | At present, intermediate and application services implemented in Java invoke the core services via the SOAP API. They use the [[http://jibx.sourceforge.net/ JiBX data-binding framework]] to transform the XML representation of resources returned by Basic services, since it allows for the definition of custom mappings to Java classes. |
|
| |
|
| Services on intermediate and application layers offer two types of interfaces: SOAP and standard Java interfaces. | | Services on intermediate and application layers offer two types of interfaces: SOAP and standard Java interfaces. |
| Line 41: |
Line 41: |
| SOAP interfaces will be offered for services that are strong reuse candidates for clients outside the core eSciDoc system implementation. | | SOAP interfaces will be offered for services that are strong reuse candidates for clients outside the core eSciDoc system implementation. |
|
| |
|
| | | [[ESciDoc_Services/core_services | Core services]] |
| == Core services ==
| |
| The Core services layer implements a set of resource handlers. Each resource handler is responsible for handling of a specific type of a resource.
| |
| | |
| ===Context Service===
| |
| Context is a resource that represents an administrative unit for a set of Items and Containers associated with the Context. The configuration rules such as: content types allowed, publication workflows, metadata schema in use, default metadata etc. are defined within the AdminDescriptor of a Context resource. Each context is associated with at least one institutional body that is responsible for the content administered in the context. The Context Service provides operations to create, retrieve and update the context information and the rules for management of content resources.
| |
| | |
| ===Item Service===
| |
| Items are basic objects that represent content entities within the repository, e.g. articles, images, videos etc. Item service provides basic operations to create, retrieve, update and delete resources of type Item. In addition it provides several task-centric operations that change the status of the Item in the content repository (submit, release, withdraw), filtering items based on specific criteria and set-up/release explicit user-defined lock on the Item.
| |
| | |
| An Item resource consists of (subresources): metadata record (one or many), component (zero or many). Metadata record contains metadata that describe the Item resource in accordance with a particular description schema (metadata schema). A Component represents the actual contents of an Item in a specific format. A Component may have associated licenses and additional “technical metadata” that are specific to that component such as: size, format, etc.
| |
| Item service in addition provides basic operations to create, retrieve, update and delete metadata records and content components.
| |
| | |
| The general layout of a resource of type Item can be further specialized by content types. Content types impose constraints on objects (e.g. allowed metadata schemas, required metadata, allowed file types and mime types for the binary content and specify a set of content type specific properties).
| |
| | |
| ===Container Service===
| |
| A Container is an aggregation objects that allows for arbitrary grouping of items and other containers. Container service provides basic operations to create, retrieve, update and delete resources of type Container. In addition it provides several task-centric operations that change the status of the Container in the content repository (submit, release, withdraw), filtering items associated with the container based on specific criteria and set-up/release explicit user-defined lock on the Container.
| |
| | |
| A Container resource consists of (subresource) metadata record (one or many). Metadata record contains metadata that describe the Container Resource in accordance with a particular description schema (metadata schema). Container service in addition provides basic data-centric operations to create, retrieve, update and delete metadata records of the Container.
| |
| | |
| The information of the aggregated Items and Containers is saved within the StructuralMap of the Container. The information of representation of the aggregated Items and Containers is saved within the TableOfContents of the Container. The StructuralMap and the Table of Contents of the Container are not necessarily same e.g. not all aggregated items/containers are always referenced in the TableOf Contents of the Container. Container service provides basic data-centric operations that retrieve and update the StructuralMap (i.e. membership of resources) of the Container and the TableOfContents of the Container.
| |
| | |
| ===Organizational Unit Service===
| |
| Organizational Unit Service provides basic operations to create, retrieve, update and delete resources of type Organizational Unit. In addition it provides several task-centric operations that change the status of the Organizational Unit in the system (open, close).
| |
| | |
| ===Search Service===
| |
| The Search service is based on the SRW/SRU interface (see also [[http://www.oclc.org/research/software/srw/default.htm OCLC SRW Interface]] and [[http://www.loc.gov/standards/sru/ SRU standard]]). It offers the following operations:
| |
| *explain operation (used by clients to self-configure),
| |
| *searchRetrieve operation (searches for a specific term within a list of indexed terms),
| |
| *scan operation (request a range of the available terms at a given point within that list).
| |
| | |
| ===User Account Service===
| |
| The User Account service provides basic operations to create, retrieve and update a User account and the Grants (granted privileges on resources) for the User Account. The User Account service in addition provides several task-centric operations that enable activation and deactivation of a User Account.
| |
| | |
| ===Authentication Service===
| |
| The Authentication service provides operations for user login to the system. It encapsulates the communication with an external user management system to authenticate the user and retrieve the user’s attributes and creates or updates the local user proxy object within the eSciDoc. In case of successful user authentication it provides an eSciDocUserHandle that is used to identify the User when authorizing the service operation execution.
| |
| | |
| ===Content type service===
| |
| <CandidateService>
| |
| Item and container resources can be further specialized in accordance with the requirements for content modeling of a specific eSciDoc solution. Content type service provides basic operations to create, retrieve, update and delete content type definitions for content types in the repository. An example of a content type is publicationItem, translationItem, transcriptionItem, imageItem, lexiconContainer, faceItem, walsLanguageItem etc.
| |
| | |
| At present service is not implemented. The content reference is however associated with each Item or Container resource.
| |
| | |
| | |
| ==Intermediate services==
| |
| | |
| ===Validating service===
| |
| | |
| The validating service provides interfaces for validation of the item and container resources in accordance with defined set of rules.
| |
| Validation rules are defined for a combination of a content type, context, metadata schema version and a validation point.
| |
| Validation point represents the aspect of validation e.g. save, submit, release, etc.
| |
| The validating service takes as an input the xml representation of an item or container and the validation point. In return it provides and XML-structured validation report that contains an errors or warnings (i.e. restrictive or informative validation messages).
| |
| | |
| ===Baskets Service===
| |
| <CandidateService>A service that provides operations for creation, retrieval, update, deletion and sharing/unsharing of user baskets. User baskets are objects that represent a set of selected Items and Containers of interest for a specific user. User baskets can be private or shared with a single user or a group of users.
| |
| | |
| ===Notification service===
| |
| <CandidateService>A service that provides operations for notification and alerting purposes on saved searches and upon application service specific events.
| |
| | |
| ===ImageHandling===
| |
| <CandidateService>A service that provides operations for manipulation of images (zoom-in, zoom-out, image area selection etc.).
| |
| At present [http://digilib.berlios.de/ Digilib] is considered as a tool for implementation of the image handling service.
| |
| | |
| More information about the ongoing discussion about this candidate service can be found [[Digilib|here]].
| |
| | |
| ==Application services==
| |
| | |
| ===Depositing Service===
| |
| Depositing service provides operations to deposit content of specific type as a resource in the content repository. It offers content type specific interfaces such as: PublicationItem Depositing, SWB Object Depositing, SWB Collection Depositing, SWB Bundle Depositing. This service is using the respective Item and Container service interfaces offered from the BasicService Layer and implements additional business logic related to concrete business workflows and content type of the resource.
| |
| | |
| ===Solutions Searching Service===
| |
| Solutions searching service provides operations to search for resources of specific content type within the content repository. It offers interfaces such as PublicationItem Searching (only resources content type Publication Item), SWB Searching (only resources of content type SWB Object, SWB Bundle and SWB Collection) and eSciDoc Searching (searches for resources of any content type within repository).
| |
| This search service provides some predefined query criteria for specific interfaces and is using the Search service interface offered with the Basic Layer.
| |
| | |
| ===CitationStyleFormatting Service===
| |
| This service provides operations for representing a set of items/containers in a specific citation style and specific output format. The internal administrative interface will provide operations for definition of a citation style.
| |
| | |
| ===RightsChecking Service===
| |
| <CandidateService>A service that provides operations for management of content licenses and checking the licenses and rights on the content components (e.g. preprints, abstracts, postprints, etc).
| |
|
| |
|
| [[Category:ESciDoc]] | | [[Category:ESciDoc]] |
| [[Category:ServiceOrientedArchitecture]] | | [[Category:ServiceOrientedArchitecture]] |
