The eSciDoc system is designed as a service-oriented architecture (SOA) implementing a scalable, reusable, and extensible service infrastructure. Application- and discipline-specific applications 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.

The 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. At the same time, the SOA approach of eSciDoc comes with other advantages.

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.

The core technology used to implement the services is based on Java and XML. Instead of building the infrastructure “from a 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 constraining 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: basic services, intermediate services and application services.

Components of the Basic Services Layer

The eSciDoc service infrastructure currently does not implement the process layer services. We consider the implementation of process layer services at a later stage. This will enable the orchestration of services.