Service Interoperability

Transcription

1 Service Interoperability Multi-Modal Interoperability Concept (M ) 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 12/05/2013 Ye Cao Reversion according to feedback 2

3 Table of Contents Service Interoperability... 1 Multi-Modal Interoperability Concept (M )... 1 DARIAH-DE... 1 Summary... 4 Purpose and Audience Problem Definition DARIAH Technological Architecture Multi-Modal Concept... 4 Level1 Documented... 5 Level2 Interoperable... 5 Level3 Certified... 5 Exception Core Infrastructure services Interoperability... 6 DARIAH Authorization and Authentication (AA) Service... 6 DARIAH Persistent Identifiers (PID) service... 8 DARIAH Storage API Related Issues Roadmap Bibliography

4 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 Interoperability model concept and best practices. The closing chapter give interoperability guide with DARIAH core infrastructure services. Purpose and Audience The proposed interoperability model can be applied to facilitate interoperability between the technical services created by independent stakeholders. This document has been written for DARIAH partners and DARIAH community to give recommendation 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 interoperability 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 accessed via application programming interface (API). A tool covers one specific scholarly activity, e.g. XML editor and it requires user interaction. The service interoperability 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 services as modules that can be used to expand the available services. 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 Multi-Modal Concept The DARIAH technical report [5] defines 3 levels of service Interoperability: Documented, Interoperable and Certified. Services in DARIAH need to be at least documented, should be interoperable and can finally be fully DARIAH-certified. Each compliance level is a step further into the DARIAH ecosystem, with more responsibilities but also more opportunities to benefit from [5]. 4

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 services. 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 interfaces or a Virtual research environment (VRE), should be at least interoperable 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, responsible management of any user-specific data, and other aspects usually discussed 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 scientific and technological mentors, so it can be hosted by DARIAH permanently. 5

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 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. 6

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] 7

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. 8

9 Figure 3 Different PID is needed in each stage of the Data Creation Cycle ( The PID-Service is implemented as a RESTful web service and the software is continuously being developed by EPIC. For the complete APIs documentation, please read 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. 9

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 research community. DARIAH AiB concept report [4] requires two more services 10

11 that need to be interoperable in additional to DARIAH core infrastructure services: DARIAH Hosting and Generic search service [8]. There are three candidates 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 services documentations and APIs as web services interoperability user case Oct,2013 Revise DARIAH AAI interoperability requirement based on its latest implementation 2 Integrate the final ready-to-use software solution from AiB (M ) as VRE interoperability user case. Feb, Collate Interoperability user cases from community contributed services Feb,

12 5. Bibliography [1] DARIAH-DE Brochure. (2012). Von [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 [8] Rainer Becker, Richard Eckart de Castilho. (2012). Archive-in-a-box, Service-Concept, M Technische Universität Darmstadt. [9] DARIAH Montoring Infrastructure [10] EPIC website [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. FEA1-D?noredirect 12