ESciDoc Service Interfaces

eSciDoc SOA SOAP and REST style interfaces Service layers Core services Context Handler · Item Handler Container Handler Organizational Unit Handler User Account Handler Authentication Content Model Handler Semantic Store Handler Intermediate services Validation Service Statistics Manager Technical Metadata extraction PIDManager Basket Handler Duplication detection ImageHandler(Digilib) Application services Depositing Searching Search&Export Control of Named Entities Citation style Manager RightsChecking DataAcquisition Transformation Fledged Data PID Cache OAI-PMH SOA Introduction edit

Disclaimer: Note that the services depicted on this pages are still under development. Some services may be renamed, reassigned to another layer or removed(candidate services). Services marked as <CandidateServices> are still under analysis and will be adressed at a later stage.

eSciDoc services are classified into the following service layers:

• Core services provide create, retrieve, update and delete (CRUD) operations on data resources such as Items, Containers, Contexts, Organizational units etc. Some services in addition provide logic-centric operations that implement part of the core system logic (e.g. changing the status of the resource within the repository). Basic services are stateless and can be used further by other (eSciDoc and non-eSciDoc) service requestors i.e. clients (services, applications).

• Intermediate services represent both a service requestor and a service provider within the eSciDoc SOA. They act as adapters and façades to the basic services or add additional functionality. Intermediate services are stateless and can manipulate their own data in addition. Examples are Validating, Baskets Handling and Duplicate detecting service.

• Application services compose other services from basic, intermediate and application layer and implement business logic from solution-specific domain. They are candidates for future process-centric services to enable the service orchestration. Examples are Depositing service, Publishing service, Citation style manager service, User Management service.

Another class of services are Technical services that enable authentication and authorization. They span vertically all layers of the eSciDoc SOA architecture. Each service operation will invoke the authentication and authorization services.

In addition to services which come with “machine-friendly” interfaces, eSciDoc provides a set of GUI Tools that offer user-friendly interfaces to business processes. Such a tool can be reused within several application solutions and can be further extended to meet domain-specific requirements. GUI Tools thus represent additional building blocks for composite applications development.

On service interfaces

Core services layer offer two types of interfaces for each resource: SOAP and REST interfaces. More precisely, each resource handler service implements the four basic operations create, retrieve, update, and delete (CRUD) and in addition, filter methods and task-oriented methods (e.g., for changing the status of an object within a content repository) are provided.

• SOAP interfaces are realized through resource handlers that offer operations for a specific service functionality that is to be applied to the resource itself or a distinctive part of the resource (subresource). The messaging style for SOAP interfaces is document/literal.
• 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 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

• 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 REST item.xsd schema)

item.xml (enriched with system generated data is returned if the request is successfully executed)

Example 2: retrieve an item

• SOAP: ItemHandler.retrieve(“escidoc:123”)
• REST: GET /ir/item/escidoc:123

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 core services via the SOAP API. They use the [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. Standard Java interfaces will be offered for internal communication between service components of the application and intermediate layer – in this case input and output are standard input/output Java types. SOAP interfaces will be offered for services that are strong reuse candidates for clients outside the core eSciDoc system implementation.

Enhanced Scientific Documentation

Create, Retrieve, Update and Delete

Service-Oriented Architecture

Graphical User Interface

Simple Object Access Protocol

Representational State Transfer

HyperText Transfer Protocol

Uniform Resource Identifier

Extensible Markup Language

Application Programming Interface