1. eSciDoc – Service infrastructure and solutions development
Natasa Bulatovic, MPDL

2. Content eSciDoc service infrastructure eSciDoc solutions
Service development
eSciDoc solutions
Solution development
Development and build environment at MPDL
Preparing for community processes

3. eSciDoc Development teams
FIZ Team: Fachinformationszentrum Karlsruhe
MPDL Team: Max Planck Digital Library, Munich
Service Management (SvM)
User interface engineering (GUI)
Software Developement (DEV)

4. Service development: Subject domains
Biology and Medicine Section
Developmental and Evolutionary Biology/Genetics Immunobiology and Infection Biology/Medicine Cognition Research Microbiology/Ecology Neurosciences Plant Research Structural and Cell Biology
Chemistry, Physics and Technology Section
Astronomy/Astrophysics Chemistry Solid State Research/Material Sciences Earth Sciences and Climate Research High Energy and Plasma Physics/Quantum Optics Computer Science/Mathematics/Complex Systems
Humanities Section
Cultural Studies Jurisprudence Social and Behavioral Sciences
20000 potential users (Scientists, Librarians, Research groups, Project groups) in the 80 research institutes of the Max Planck Society

5. Service development: Setting the focus
Main usage scenarios
Publication Data (Institutional repository, metadata management, quality assurance workflows)
Research Data (Digital collections of images, multimedia content, cooperative authoring and annotating)
Common functions that have to be supported
Generalized and unified data model for all content resources
Content modeling of resources as a specialization instrument
Versioning
PID
User management, authentication and authorization
Service orientation means:
Reusability — regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse.
Formalized contracts— For services to interact, they need not share anything but a formal contract that describes each service and defines the terms of information exchange.
Loose coupling - services are loosely coupled— Services must be designed to interact without the need for tight, cross-service dependencies.
Abstraction - of logic-the only part of a service that is visible to the outside world is what is exposed via the service contract. Underlying logic, beyond what is expressed in the descriptions that comprise the contract, is invisible and irrelevant to service requestors.
Composability- services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers.
Autonomous - the logic governed by a service resides within an explicit boundary. The service has control within this boundary and is not dependent on other services for it to execute its governance.
Statelessness - services should not be required to manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere.
Discoverability - services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic

6. Service development: basic premises
Service orientation and service infrastructure instead of silos applications
Fedora as a repository management system for the content
Open-source (for used and delivered eSciDoc software components)
Open-content (for complete documentation and research deliveries)
Based on standards
Development of a service-oriented architecture (SOA)

7. Service development: SOA composition
Core data entities (resources) identified and defined
Items, Containers, Organizational Units, Contexts, Relations, etc.
Service layers defined
core, intermediate, application service layers
Services identified and designed
functional descriptions, service operations, data in use, service operation input/output messages

8. Service development: SOA roadmap

9. Service development: core services
“We need high level of abstraction and some common functions …”
Context handler
Item handler
Container handler
Organizational units handler
Role handler
Content model handler
Semantic store handler ..
Data-centric (CRUD), logic-centric (versioning, release, withdraw, etc.).

10. Service development: intermediate services
“.. but we also need some more added functionality …”
Duplicate detection
Image handling
Metadata handler
Validation of data
Retrieval/download statistics
Workflow management
Functionality adding services, Technology gateways, adapters, façades

11. Service development: application services
“… we still need to create additional services…”
Depositing
Publishing
Quality assurance
Citation manager
Export manager
SearchAndOutput
Controlled vocabularies
Process-centric or simply public services shared with partner instutitions

12. Towards specialization
“.. and in addition end user interfaces to manage different content …”
Publication items (at least one author must exist)
Face images (metadata describe object on the image)
Digitized Book (law books from Holly Roman Empire)
Language resources (description of languages, features, other resources)
“… different metadata schema and controlled vocabularies…”
Flexible metadata handling
Metadata schema/ context / content model specific validation rules
“… with different workflows …”
Publication management workflow (“depositing” service enriches core workflow)

13. We have (eSciDoc) solutions 
Publication management
Image collections
Scanned books

14. eSciDoc project landscape

15. Solution development: towards specialization
Services provide more common functions that can be reused
Solutions reuse services and may add value (e.g. data mashups)
Services work with Items, Containers, Metadata
Solutions work with Publication Items, Albums, DC metadata, Publication metadata etc.
Solutions are built for end users (persons)
Services are built for developers, end users and non-human service requestors

16. eScidoc@MPDL: Key aspects
Business processes engineering (SvM)
Usage scenarios
Use cases
Process workflows
User interface engineering (GUI)
Interface conception, design and development
Usability analysis & evaluation
Communications support
Software development (DEV)
Service architecture design and implementation
Solutions design and implementation
Integration of services
Integration of services and solutions

17. Software development@MPDL: Technology in use in short
Java EE (
Presentation&Logic: Sun RI JSF1.2 , JSP 2.1, Java Servlet 2.5, EJB 3.0)
Tag libraries in use (Trinidad, RichFaces)
XML
JibXtransform XML to Java
Python
Turbogears
IDE
Eclipse
Design
Technical design: Enterprise Architect
GUI prototyping: Axure RP Pro

18. Software development@MPDL: Build and development environment
SUBVERSION
The build infrastructure consists of several servers and tools to support all developers and testers of the escidoc project in the development process.
The build process is supported by several servers:
Archiva, which holds all the binary artifacts (including external and internal binary dependencies)
Continuum, a testing server for nightly builds, unit- and integration testing, releases
Maven, a software project management and comprehension tool, used for building, testing and release management
Subversion, a source control management tool, with the following repositories:
common used by project common_services
pubman used by project PubMan
virr used by project ViRR
faces used by project Faces

19. Software development@MPDL: Code repositories

20. eSciDoc services and solutions: What next?
Extending existing solutions and services
Setting up productive environment (performance, service authorization, data ingestion)
More data diversity
Building more services and solutions (component reusability, tools, enhance SOA)
Improve data interoperability, data dissemination, data repurposing
Community-based open source development

21. Related MPDL projects WALS Online http://wals.info/
Open Access Journal Publishing

22. eSciDoc project resources
eSciDoc project web pages, Infrastructure download
MPDL collaboratory network
MPDL software download
The project webpage is a useful information resource for developers or any other interested people.
The project webpage contains useful information on the build environment, source code access, javadocs, code analysis etc.

23. Thank you!