OME Reactive Architecture.
The basic idea: a framework to build scalable and resilient OMERO micro services.
We use distributed, asynchronous message passing as a foundation for a reactive architecture with scalable, resilient, and composable services. The below components provide the messaging functionality:
- kew: a strongly-typed messaging API that lets you plug in and use different back-end messaging systems such Apache Artemis, RabbitMQ, or even Vert.x.
- kew-artemis: an implementation of the messaging API backed by Apache Artemis which doubles up as a basic container for asynchronous, message-driven, micro services.
The arrangement of these two components is similar to that in a Ports and Adaptors architecture (a.k.a. Hexagonal architecture): kew defines the ports and kew-artemis provides the adaptors.
We're busy adding support for distributed (NoSQL) state. The plan is to have an arrangement similar to the above with an abstract API backed by pluggable state providers so to keep service logic independent of the underlying framework. (The one provider we're definitely going to have is Redis.)
A more ambitious plan is to leverage messaging and distributed state to build a minimalist, light-weight, distributed stream processing component that would let us easily string together OMERO tasks into a distributed computation. (See these notes for the details.) Or we might consider using a full-fledged framework such as Apache Spark instead...
So watch this space!
Want to hack this code to pieces? Or contribute a couple of tweaks or a bug fix? You're welcome to fork the repo and submit a pull request. If you're planning to do open-heart surgery, you may find it useful to read the README files (pun intended!) of the various components as well as the JavaDoc for the specific classes you'll be working on. Also each component comes with lots and lots of unit, integration, and end-to-end tests which may be worth looking at to get the hang of how each unit works. I suppose this was a long way to say: we still don't have a proper documentation site! Oh, did I mention you're welcome to contribute?
Build and test everything:
./gradlew build
Use gradlew <task>
(Unix; gradlew.bat
for Windows) for finer control over
building, testing, etc. This lists all available build tasks:
./gradlew tasks
Ours is a Gradle multi-project build,
./gradlew projects
lists all the build projects. Each of them comes with its own build you can
run independently using gradlew :<project>:<task>
; for example
./gradlew :server:test
runs all the tests in the server
project.
Using Eclipse or IDEA? With recent versions you should be able to import the
entire Gradle multi-project build seamlessly as a Gradle project. If that
doesn't work for you, try adding the Gradle Eclipse or IDEA plugin to each
build project, which you can do in the root build.gradle
file:
allprojects {
apply plugin: 'eclipse'
apply plugin: 'idea'
...
Then run:
./gradlew eclipse
(or ./gradlew idea
for IDEA) and import your Git checkout root directory
into Eclipse (IDEA) as an existing project.
If you're unhappy with the result, you'll have to have a look at our build
files and create the projects manually in your IDE. Give me a shout if you
need help to get you going! (I'm deaf.)