Core platform Questions

[Bruce MacLeod]

Russell Gillen (Graduate student) and I have been examining the core
MoTeCH architecture and had some questions :

1. MotechSchedulerGateway vs MotechSchedulerService

Currently there are two different ways to schedule a job, although
both ultimately go through the MotechSchedulerService bean defined in
the scheduler module. The MotechSchedulerGateway is injected into the
application-wide Context. It provides four methods, while the service
provides those and more. A few modules are utilizing the gateway and
some are using the service. Besides its inclusion in platform-common's
Context, the gateway can be found in the motech-appointments, motech-
outbox and motech-demo modules. The service can be found in the
scheduletracking, message-campaign and pillreminder modules. A
schedule queue is used when using the MotechSchedulerGateway. If you
directly invoke the service, you actually move to a single queue
architecture, where only an event queue is shuttles messages. A
separate queue for scheduling could distribute the workload.

Which is the preferred method going forward?

2. Core platform dependency on the rules engine

There is some question to whether or not the KnowledgeBaseManager,
rule repository, and rule file/bundle loading are always needed in the
core platform. We can envision uses of the platform where Drools or
other rule management are not necessary. For example, message
campaigns and schedule tracking allow any user to be enrolled, and
this may be the intention of a particular deployment. The behavior and
rules of these message campaigns are inherent in their specification
and configuration.

Do we want to have include the rules engine/drools as part of core
platform ?

If you build the WAR file from the project, the server, server-
api, common and ivr platform modules are all pulled in as
dependencies. However, the scheduler module is excluded from this. It
should be known that the MotechSchedulerGateway in the common platform
will not work properly (or at all) without the scheduler module. It
attempts to push scheduled jobs to the schedule queue, but they will
never be shuttled to the payload router unless the scheduler's context
has been started, providing an in adapter for the schedule queue.

Should the scheduler module be part of the core platform build ?

3. Testing of some code

We were able to test both the MotechSchedulerGateway and
MotechSchedulerService, by using the MotechScheduler class in the
scheduler module. The MotechSchedulerGateway has an unschedule method
that is routed to the MotechSchedulerService. If you attempt to test
this code without making any changes, an exception will be thrown
claiming that the service implementation does not have all of the
proper methods to handle messages. This is because the unschedulejob
in the service that only takes a String for job ID is private. Making
this method public fixes the issue. Another problem is that both the
inbound adapters for the event and schedule queue are named jmsin.
This creates a conflict if you are running both in the same Spring
context. What happens is that a job is sent to the schedule queue,
which is dequeued then received and routed by the application, which
schedules the job with the service implementation. When the Quartz
trigger is activated and the job is executed, an event is raised,
which is never dequeued because of the overlapping names in the same
context. This is fixed by renaming one of the two adapters.

What is the status of this code ? Should we be using this code going
forward ?

Thanks, Russell and Bruce

[Rob LaRubbio]

Bruce, thanks for raising these issues.  It's always useful to discuss things and I think this mail will bring up some of the project history that will be useful for further discussions.  I'm going to try and respond without getting too wordy but I think the core questions in this mail boil down to:

1) Motech Scheduler Gateway v. Motech Scheduler Service.

2) What is 'core' to MOTECH

Also my response if from memory, I'll need to look at the code for specifics but hopefully the gist is correct.

1) Motech Scheduler Gateway v. Motech Scheduler Service

Your first point brings up this topic directly, while points 2.5 and 3 touch on it more indirectly.  If you look at the list of modules you call out you'll notice that all the ones using Motech Scheduler Gateway are the original modules from 2Paths while the Motech Scheduler Service modules are more recent.  Personally I believe all modules should be using Motech Scheduler Gateway (or some abstract interface to the scheduler service).  Originally the Motech Scheduler Service was a separate process that the platform spoke to over a message queue, hence the split between the gateway and the service.  Going forward all modules should speak to an interface to the scheduler and individual deployments should be able to configure the platform to run with either an embedded scheduler (useful for small deployments) or a remote clustered scheduler for larger deployments.

Assuming we still have that split (i.e. the scheduler is in a separate process) then it makes sense that the war file from the project doesn't pull in the scheduler.  In fact the gateway shouldn't depend on the scheduler, it just needs to place messages on a queue.

Additionally given that split the fact that both queues have the same name shouldn't be an issue since each jmsin queue is an input queue in a separate process space.

Ideally I'd like it if whatever framework we used for speaking to our queue allowed us to transparently switch between using an external message queue and an in vm queue.  If that was the case then queues would need to be renamed.  As things stand now it sounds like we need to update the newer modules to use the gateway, and update the gateway so it can operate against both an in process scheduler and a remote scheduler.

2. What is 'core' to MOTECH

To answer your question directly about the rules engine, no it shouldn't be core to MOTECH.  However the broader answer involves a larger discussion about what should be core to MOTECH.  In my mind the only core pieces should be the OSGi framework and the event system.  Everything else should be a module.  Today we have deployments that are using SMS, but not IVR or mforms, yet they are forced to include those pieces.  I know this was the topic of some heated discussions early on, I just want to point out that just because it isn't 'core' to the platform doesn't mean it's not a valued module that will be used in many deployment.