The core technology used to implement the services is based on Java and XMLExtensible Markup Language. Instead of building the infrastructure “from scratch”, the eSciDocEnhanced Scientific Documentation team chose to integrate existing open-source components as much as possible.
eSciDocEnhanced Scientific Documentation 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 eSciDocEnhanced Scientific Documentation service infrastructure groups its services into three service layers:
- core services
- intermediate services
- application services
- process layer services (not implemented at present)
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.
eSciDocEnhanced Scientific Documentation SOAService-Oriented Architecture motivation
- 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 eSciDocEnhanced Scientific Documentation 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 eSciDocEnhanced Scientific Documentation 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.