The different Thematic Core Services (TCS) have varying degrees of maturity in their development. Therefore, it is not possible to deal with TCS as if they are all equal and homogeneous. Some TCS have a very specific services architecture based on years of experience in that specific domain. Other TCS don’t have any history of developing services. Some TCS rely on a federated architecture, others on a single sited data centre.
Some TCS have already done the effort of defining metadata standards and web services to disseminate the data. Others are still in the process of undertaking such work.
As a consequence the scenario is very heterogeneous and includes many services with different levels of “technical” maturity.
The architecture is very “general purpose”, simple, and presents the following elements:
- National Layer Research Infrastructures: these can vary in different countries within a specific scientific community. They represent the existing DDSS.
- TCS system: this represents the e-Infrastructure for a specific scientific community. It may include the software used to federate National RIs, or the software to present results on the web (web portal).
- Metadata Catalogue: this is usually a database where each data object (e.g. file, in case of non-streamed data) is referenced and described by the metadata. It can be used to drive the Web Services.
- Web Services / API: this is the entry point where users can access the data. EPOS ICS has no particular recommendation with respect to the software used to build the TCS system. What matters is the way ICS and other stakeholders can access data. API based Web Services ensure data and metadata are accessible and discoverable by humans and machines (e.g. ICS system).