Service Interoperability

(1)

Service Interoperability

–

Multi-Modal Interoperability Concept (M 1.3.4.1)

Version 12/05/2013

Work Package 1.3

Responsible Partner MPDL

DARIAH-DE

Aufbau von Forschungsinfrastrukturen

für die e-Humanities

This research and development project is / was funded by the German Federal Ministry of Education and Research (BMBF), fund number 01UG1110A to M, and managed by the Project Management Agency of the German Aerospace Center (Deutsches Zentrum für Luft- und Raumfahrt, PT-DLR).

(2)

Project: DARIAH-DE: Aufbau von Forschungsinfrastrukturen für die e-Humanities

BMBF Fund number: 01UG1110A to M

Duration: March 2011 till February 2014

Document status: First version

Dissemination level: DARIAH-DE-internal

Authors:

Ye Cao, MPDL

Revisions:

Date Author Comment

02/18/2013 Ye Cao Outline

03/27/2013 Ye Cao Draft

01/05/2013 Ye Cao Reversion

06/05/2013 Stefan Schmunk Comments

07/05/2013 Peter Gietz / Stefan E. Funk

Reversion and Comments

(3)

Summary

This document introduces the interoperability concept for DARIAH technical services. It starts with setting scope of the topic. The main part lies on the multi-modal Interop-erability model concept and best practices. The closing chapter give interopInterop-erability guide with DARIAH core infrastructure services.

Purpose and Audience

The proposed interoperability model can be applied to facilitate interoperability be-tween the technical services created by independent stakeholders. This document has been written for DARIAH partners and DARIAH community to give recommenda-tion so that how services could be interoperable with DARIAH infrastructure.

1. Problem Definition

Interoperability is a very broad topic and it includes many aspects, e.g., the use of protocols and machine interfaces for accessing data, interoperability of data and metadata formats, adoption of open data licenses, and the use of machine-readable license formats [1].

Technical interoperability is complements of data interoperability [2]. It is said “in-teroperability touches different levels of exchange. The most basic of these is the technical or system level”[3].

The term “service” refers to a set of related software functionalities that can be ac-cessed via application programming interface (API). A “tool” covers one specific scholarly activity, e.g. XML editor and it requires user interaction. The service in-teroperability discussed here includes both tools and services.

2. DARIAH Technological Architecture

The technological architecture of DARIAH is service oriented architecture (SOA) [4]. The big advantage of SOA architecture is that users can implement their own ser-vices as modules that can be used to expand the available serser-vices. This approach will ensure that new developers will be able to “plug” their own tools into the DARIAH architecture or one can combine these services by building higher level services on top of existing ones.

2.1. Multi-Modal Concept

The DARIAH technical report [5] defines 3 levels of service Interoperability: Docu-mented, Interoperable and Certified. Services in DARIAH need to be at least docu-mented, should be interoperable and can finally be fully DARIAH-certified. Each compliance level is a step further into the DARIAH ecosystem, with more responsibili-ties but also more opportuniresponsibili-ties to benefit from [5].

(5)

Level1 Documented

Exhaustive documentation is available to employ and adapt the component; ideally its source code is openly available. However, standards-based interfaces may be missing and any interaction with other components may need to be hard-coded into the software.

Moreover, documentation and transparency of research services may be required for good scholarly practice, and they may hence be the key to trust.

Level2 Interoperable

The service is well-documented, and it offers standards-based technical interfaces to interact with other components in the DARIAH ecosystem. Interoperable services are capable of interacting with DARIAH core services including DARIAH Authentication and Authorization Infrastructure (AAI) and persistent identifiers (PID) services. Core services are essential for enabling interoperability across the heterogeneous data sources and decentralised services in the DARIAH ecosystem.

Best Practices

 Applying standard web services interfaces, i.e., SOAP and REST-based ser-vices.

 Applying open standards, .e.g., OAI-PMH, RSS to expose reusable services.  Promotion of applications based on DARIAH services for several use cases.

Dedicated education and outreach activities from AP2 are expected.

 Specific technical paradigm, e.g., an Eclipse Rich Client with graphical user in-terfaces or a Virtual research environment (VRE), should be at least interoper-able with DARIAH core services and involved service environment.

Level3 Certified

At the highest integration level, DARIAH aims to certify services based on existing best practices and relevant international standards. The organisational context of the component ensures the maintenance of the software and potentially migration paths to successors. For hosted services, the host institution ensures its availability, re-sponsible management of any user-specific data, and other aspects usually dis-cussed in service level agreements.

Best Practices

DARIAH service lifecycle [7] practise DARIAH service quality Assurance procedure. A certified service means it will pass the usability and value check by a team of scien-tific and technological mentors, so it can be hosted by DARIAH permanently.

(6)

Figure 1 DARIAH Service Life Cycle [7] state diagram shows how a new service could be integrated into the DARIAH infrastructure.

Exception

Individual components have three integration levels. However there are different channels for technical interoperability, not all services in the DARIAH ecosystem must be capable of interacting with each other.

2.2. Core Infrastructure services

Interoperability

The Core Infrastructure services are those that are essential to the running of the infrastructure and upon which other service are built and rely. So Interoperability with these services needs to be considered.

DARIAH Authorization and Authentication (AA) Service

Currently DARIAH deploys its AA service based on two standards: SAML and LDAP. It supports both Web Browser Single Sign-on (SSO) and Enhanced Client or Proxy (ECP) user cases.

(7)

Figure 2 Web Browser VS ECP client user cases [11]

For Service providers (SP): SP are free to implement its service in SSO or ECP way. DARIAH Plans to adopt OAuth2 standard to facility SP, so developers only need to support one API only.

For specific research project who wants to use DARIAH services, one coordinating facility will be assigned and at least two project administrators, i.e., a contact person and a representative are required according to DARIAH AAI role model. For the complete DARIAH AAI concept, please read [11]

(8)

Figure 3 DARIAH AAI Role Model [11]

DARIAH Persistent Identifiers (PID) service

The PID resolution and PID management is not built up by DARIAH, but DARIAH relies on the PID-Service of the European Persistent Identifier Consortium (EPIC). The PID development within DARIAH is coordinated with EPIC.

EPIC is Handle based identifier system. Its focus is the registration of data in an early state of the scientific process, where lots of data is generated and has to become referable to collaborate with other scientific groups or communities [10]. The Digital Object Identifier (DOI) is widely used by the publishing industry for the persistent identification of journal articles. If a later registration with a DOI is wanted for some reason, the PIDs can be transferred because the identifier systems use the same underlying handle software.

(9)

Figure 3 Different PID is needed in each stage of the Data Creation Cycle (http://www.pidconsortium.eu)

The PID-Service is implemented as a RESTful web service and the software is con-tinuously being developed by EPIC. For the complete APIs documentation, please read http://www.pidconsortium.eu/more.

DARIAH Storage API

The Storage API supports the creation and enhancement of data infrastructures for the management of research data [12]. The API is RESTful and it supports access from a web browser or an ECP client.

(10)

Figure 4 DARIAH Storage Service [12]

For the complete APIs documentation, please read [12].

3. Related Issues

Some issues need be addressed regarding interoperability are not in the discussion of this document, but are also under the scope of DARIAH research:

 How to carry out machine-comprehensible user identification between distinct services and enable personalisation?

Please refer to the DARIAH AAI service.

 What is needed to record a component version, etc. for provenance? Please refer to the DARIAH provenance concept Report [6].

 Where are the operations of services monitored, and how does this help both the service provider as well as overall control of the DARIAH ecosystem? Please refer to DARIAH monitoring service [7].

 VRE is a user’s research environment. It narrows down the potential paths to interoperability. How DARIAH deal with this?

DARIAH is going to deliver a service package called Archive-in-a-box (AiB). The AiB service will provide an institution with the facility to install software on its servers in order to create a digital asset management system for its

(11)

re-that need to be interoperable in additional to DARIAH core infrastructure ser-vices: DARIAH Hosting and Generic search service [8]. There are three candi-dates will be put through full integration tests: TextGridRep, Pubman and dSpace [8].

4. Roadmap

Phase Activities Mo/ Yr to be completed

1  Add collection registry, schema registry and general search ser-vices documentations and APIs as web services interoperability user case

 Revise DARIAH AAI interopera-bility requirement based on its latest implementation

Oct,2013

2  Integrate the final ready-to-use software solution from AiB (M1.4.1.2) as VRE interoperabil-ity user case.

Feb,2014

3  Collate Interoperability user cas-es from community contributed services

(12)

5. Bibliography

[1] DARIAH-DE Brochure. (2012). Von http://dx.doi.org/10.3249/webdoc-3590

[2] Stefan E. Funk, Daniel Kurzawe, Bastien Saquet, Stefan Schmunk. (kein Datum). R 1.3.3, Analyse von technischen ProvenanceModellen

und Evaluation der Auswirkungen auf die Interoperabilität von Werkzeugen.

[3] Stavros Angelis, Andreas Aschenbrenner, Agiatis Benardou, Tobias Blanke , Natasha Bulatovic and etc. (2010). DARAIAH Technical Report.

[4] Lossau, D. N. (2010). DARIAH-DE: Construction of Research Infrastructures for the e-Humanities.

[5] Tobias Blanke, Michael Bryant, Mark Hedges. (2011). Preparing DARIAH. 7th IEEE e– Science conference. King's College London.

[6] Stefan E. Funk, Daniel Kurzawe, Bastien Saquet, Stefan Schmunk. (kein Datum). R 1.3.3, Analyse von technischen ProvenanceModellen

und Evaluation der Auswirkungen auf die Interoperabilität von Werkzeugen. [7] DARIAH Service Life Cycle

https://dev2.dariah.eu/wiki/display/DARIAHDE/DARIAH+Service+Life+Cycle

[8] Rainer Becker, Richard Eckart de Castilho. (2012). Archive-in-a-box, Service-Concept, M1.4.1.1. Technische Universität Darmstadt.

[9] DARIAH Montoring Infrastructure

https://dev2.dariah.eu/wiki/display/DARIAHDE/Monitoring+Infrastructure

[10] EPIC website

http://www.pidconsortium.eu/index.php?page=goal

[11]Peter Gietz, Martin Haase. (2011). DARIAH Authorization and Authentication Infrastructure.

[12]Stefan Funk, Peter Gietz, Martin Haase and etc. (2012). DARIAH Storage API- A Basic Storage Service API on Bit Preservation Level. http://hdl.handle.net/11858/00-1734-0000-0009-FEA1-D?noredirect

Service Interoperability