Services each contain code to decide which mq exchange to write to or read from.
This is obv inflexible, particularly if it is desirable to add a new service in the message flow between two others.
For example, a message dedup service would read from what is currently known as the physical_timeseries exchange and write to a new exchange that the logical mapper would read from. This is not possible at present without changing the logical mapper source code.
A configuration file that specifies the exchange a service should read from or write to would allow these sorts of changes without modifying source code.
This means services must know their own name so that can look up the configuration information.
It would be best to have base classes for all types of services so coding a new service would not need to copy this code and name handling and configuration lookup/application were always handled consistently.
Services each contain code to decide which mq exchange to write to or read from.
This is obv inflexible, particularly if it is desirable to add a new service in the message flow between two others.
For example, a message dedup service would read from what is currently known as the physical_timeseries exchange and write to a new exchange that the logical mapper would read from. This is not possible at present without changing the logical mapper source code.
A configuration file that specifies the exchange a service should read from or write to would allow these sorts of changes without modifying source code.
This means services must know their own name so that can look up the configuration information.
It would be best to have base classes for all types of services so coding a new service would not need to copy this code and name handling and configuration lookup/application were always handled consistently.