Architecture Requirements

From Olympus
Jump to: navigation, search

Requirements for a messaging architecture for Olympus.


Galaxy Issues

Here are some issues that we currently have with Galaxy.

  1. Galaxy doesn’t handle dynamic processes, which we require in the multi-robot domain.
  2. Galaxy doesn’t seem to be well maintained currently.
  3. Galaxy is not compatible with any other well-known systems.
  4. Galaxy has brokering functionality that we don’t need/Too complex for the jobs at hand.
  5. Galaxy is not from CMU.


  1. handles messages with arbitrarily nested custom types, support for many low-level property types
  2. messages are basically human readable, but also in a format that’s compatible with a large number of existing tools (lisp s-expressions and xml formats are both solutions to (1) and (2))
  3. at least supports applications written in C, C++, Java, and Perl, and on Windows and Linux
  4. applications can subscribe and unsubscribe to messages of a certain type.
  5. well documented
  6. well maintained/has a large user base
  7. not proprietary
  8. responsive/lightweight
  9. api is at a very high level (no need to concern oneself with parsing messages or network code)


Some things that might not be requirements but might count as desiderata.

  1. messages can be persistent. i.e. applications may request the latest value of X rather than or in addition to message subscriptions.
  2. integration with a process manager
  3. mature support tools like loggers and log parsers
  4. step-through message debugging
  5. profiling


Personal tools