JMMC/ObsPortal: Software architecture
Questions
Several points must be discussed in order to define an architecture.
Vollt library (CDS) provides a TAP reference implementation:
Usages
- What do we want to do?
- Using Aspro2
- To find past observations about selected targets (with the same interferometer, instrument, configuration, ...) directly from the GUI or using SAMP + web portal
- To display these observations by plotting points under "Observability" and "UV coverage" tabs
- Using a Web portal
- May provide an advanced web interface to search / filter observation logs
- Could provide SAMP interoperability (like CDS simbad / vizier) to ASPRO2 (custom messages + votable output)
Data
- On which metadata to search and filter the observations?
- target name
- target coordinates
- Requires cone-search (like TAP)
- ...
- Which metadata to display for one observation?
- To plot the observation under "Observability" tab
- LST ranges or MJD ranges (converted by ASPRO2 at the given interferometer)
- To plot the observation under "UV coverage" tab
- UV point per baseline (radius, angle in ESO archive) + instrument wavelength range to draw the UV segments per baseline
- To show inside a tooltip
- Observation setup (interferometer, instrument, mode, identifiers ...)
- Where to find the source metadata?
- Extracted from headers provided by the ESO Archive but stored in a 'standard' DM to also handle CHARA observation logs in the future
- See the page JmmcObsPortalDataAnalysis for the keywords mapping
-
Protocols and links between software parts
- Aspro2 <--> "ObsPortal System"
- How to query the "ObsPortal System" from Aspro2?
- How?
- Which protocol?
- API REST on HTTP/HTTPS (maybe)
- SAMP (maybe with web portal)
- TAP (?)
- Which parameters?
- See the question "On which metadata to search and filter the observations?" (target coordinates first ie 1 object per query)
- How to send the query results to Aspro2?
- How?
- Directly
- Via A2P2 (NO)
- By a generated intermediary file (OBXml / Asprox)
- Which protocol?
- API REST on HTTP/HTTPS
- SAMP
- TAP
- Which data structure?
- JSON (NO)
- VOTable (1)
- OBXml (2)
- Asprox (NO)
- ...
- Which properties to return?
- See the questions "Which metadata to display for one observation?"
- OiDB <--> "ObsPortal System"
Modeling method
The architecture will be designed using the method described on
https://c4model.com
and the online modeling tool
draw.io
with the extension
https://github.com/tobiashochguertel/c4-draw.io
Current context around OiDB
Source:
JMMC-ObsPortal-C1-current.drawio
Level 1: System context
A
System Context diagram provides a starting point, showing how the software system in scope fits into the world around it.
Source:
JMMC-ObsPortal-C1.drawio
Comments
At this step, a first question is related to the integration and the future role of
OiDB and
A2P2...
Level 2: Container
A
Container diagram zooms into the software system in scope, showing the high-level technical building blocks.
Proposition 1
Source:
JMMC-ObsPortal-C2.1.drawio
The frontend ("Web Application") may be part of "Core Application"...
Proposition 2
Source:
JMMC-ObsPortal-C2.2.drawio
The frontend ("Web Application") may be part of "Backend Application"...
Level 3: Component
A
Component diagram zooms into an individual container, showing the components inside it.
Level 4: Code
A
code (e.g. UML class) diagram can be used to zoom into an individual component, showing how that component is implemented.
--
Philippe Bollard - 2019-11-26