docspell/modules/microsite/docs/dev/adr/0002_component_interaction.md

---
layout: docs
title: Component Interaction
permalink: dev/adr/0002_component_interaction
---

# Component Interaction

## Context and Problem Statement

There are multiple web applications with their rest servers and there
are multiple document processors. These processes must communicate:

- once a new job is added to the queue the rest server must somehow
  notify processors to wake up
- once a processor takes a job, it must propagate the progress and
  outcome to all rest servers only that the rest server can notify the
  user that is currently logged in. Since it's not known which
  rest-server the user is using right now, all must be notified.

## Considered Options

1. JMS (ActiveMQ or similiar): Message Broker as another active
   component
2. Akka: using a cluster
3. DB: Register with "call back urls"

## Decision Outcome

Choosing option 3: DB as central synchronisation point.

The reason is that this is the simplest solution and doesn't require
external libraries or more processes. The other options seem too big
of a weapon for the task at hand. They are both large components
itself and require more knowledge to use them efficiently.

It works roughly like this:

- rest servers and processors register at the database on startup each
  with a unique call-back url
- and deregister on shutdown
- each component has db access
- rest servers can list all processors and vice versa

### Positive Consequences

- complexity of the whole application is not touched
- since a lot of data must be transferred to the document processors,
  this is solved by simply accessing the db. So the protocol for data
  exchange is set. There is no need for other protocols that handle
  large data (http chunking etc)
- uses the already exsting db as synchronisation point
- no additional knowledge required
- simple to understand and so not hard to debug

### Negative Consequences

- all components must have db access. this also is a security con,
  because if one of those processes is hacked, db access is
  possible. and it simply is another dependency that is not really
  required for the joex component
- the joex component cannot be in an untrusted environment (untrusted
  from the db's point of view). For example, it is not possible to
  create "personal joex" that only receive your own jobs…
- in order to know if a component is really active, one must run a
  ping against the call-back url