ESciDoc SOA

From MPDLMediaWiki
Revision as of 14:56, 9 April 2009 by Robert (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
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

The core technology used to implement the services is based on Java and XML. Instead of building the infrastructure “from scratch”, the eSciDoc team chose to integrate existing open-source components as much as possible.

eSciDoc services in general provide both SOAP and REST style interfaces. This allows for further development of solutions without con-straining the selection of the programming languages, thus accelerating their implementation and enabling the involvement of various developer groups. Even simple scripting and “Web 2.0”-style mash-ups are supported.

The eSciDoc service infrastructure groups its services into three service layers:

Note: We consider the implementation of process layer services at a later stage. This will enable the more complex service interactions such as service orchestration.

eSciDoc SOA motivation[edit]

  • scalability
  • reusability
  • extensibility
  • loose coupling of functionality

To implement a scalable, reusable, and extensible service infrastructure. Application- and discipline-specific solutions can then be built on top of this infrastructure. The heterogeneity of the envisioned solutions in addition imposes an efficient handling of different kinds of content.

A service-oriented architecture fosters the reuse of the existing services. An eSciDoc service may be reused by other projects and institutions, either remotely or locally, thus becoming one building block with a broader e-Science infrastructure.

Instead of a complex and monolithic application, the eSciDoc service infrastructure is rather to be seen as a set of loosely coupled services, which can be specified and implemented independently. This allows for an iterative implementation strategy for services. First services may already be implemented while others are still in their design phase. Based on feedback from early adaptor users (“pilots”), new services can be easily added, thus fulfilling user expectations in a more timely and user-driven manner.


See also eSciDoc – a Scholarly Information and Communication Platform for the Max Planck Society