There are two options for using Motech with the OpenLmis system.
Using the Motech Platform Server
The first one is to set up the Motech server and have it integrate with OpenLmis, acting as a service bus between OpenLmis and different services (mentioned below). Communication between Motech and OpenLmis would be done either through REST or through the ActiveMQ queue/topic. Using Motech in this manner would provide us with its full feature set, but the obvious drawback is the overhead of running the entire Motech server. Motech provides Docker images of itself and its dependencies, but this obviously would make the deployment grow - a Motech server running on Tomcat, an ActiveMQ broker and two databases are a minimum for deploying Motech.
Using select Motech modules
The second approach is to use only the picked Motech modules from OpenLmis code. The upside of this solution is that we wouldn't have to host the entire Motech server to integrate with. The downside is that this would require some additional effort on part, to make these modules easily usable. Motech modules currently heavily rely on being launched within an OSGi container - using them without OSGi might require additional work - trimming them down (i.e. removing logging from the IVR module, since it is done through Motech Data Service, which cannot run without OSGi). We can get assistance on this from the Motech team. Ripping out the event system that integrates with the ActiveMQ broker can also be done, however at that point using the entire platform server is worth considering.
The second approach is the more lightweight one and obviously does not tie us to the Motech Platform like the first one does. With some assistance from the Motech team, modules can be trimmed to usable state with little effort depending on their complexity.
Before we start doing this, it is worth to gather concrete use cases that will show us how we want to use these modules and to what ends. If some functionality that we require is missing in the modules (for example in the ODK module), we can try bringing that upstream to the Motech team.
The event system in Motech provides a nice of pub/sub communications. Regular Spring beans can have methods annotated with the '@MotechListener' annotation. These are automatically picked up at startup and registered with the event system as listeners for a particular subjects. All events going through the event queue/topic are then forwarded to the appropriate listeners for handling. Launching an event is as easy as creating an object with a String subject and optionally a key-value map of parameters. An event relayed through the Motech event system is then passed to all its listeners (depending on whether a queue or topic is used, the event can go to all or a single Motech instance in a cluster, which provides a nice way of scaling). The event system also deals with retries and error handling.
Underneath Motech events use Spring Integration for connecting with a JMS channel - in Motech this was always ActiveMQ, but because of the Spring Integration abstraction this can be any JMS broker and potentially non JMS ones, such as 0mq (which was once spiked in Motech).
Currently the event system in Motech might be hard to use outside of OSGi, however we can still leverage the concept. In our architecture, this could be a way of communication between microservices - we must decide however if we want to go this way, instead of just using REST API calls, since communication could be done in two different ways if this gets adapted - either through synchronous REST API calls or asynchronous pub/sub events going through JMS (JMS can be potentially also used for synchronous). Preferably this would be handled by a library shared between different microservices - they would use Spring integration for registering to the JMS queue/topic.
A topic would have to be used in order for microservices to share JMS message across each.
The scheduler module provides a nice bridge between ActiveMQ and the Quartz scheduler. Within a Motech deployment, it easily allows to schedule jobs handled by Motech listeners. Using the scheduler outside of the Motech Platform might provide challenging - we would have to at least be using the ActiveMQ broker for this to have any sense.
These modules present value if we would ever want to integrate with these systems (no plans currently).
ODK
Interoperates with the following services: Open Data Kit , Ona, and Kobo Toolbox. We can leverage the module for ODK integration. Its probable that some effort might be required in order to use the module in a lightweight manner without using the entire Motech Platform Server.
The email module is fairly basic, using it in OpenLmis is of little value.
IVR, SMS
These modules allow a generic way of integration with IVR and SMS systems. Reusing them might be nice, but again we will have to drop their OSGi part if we only wish to use these parts (they use MDS for logging call/sms status in the database).