Platform startup

5 views
Skip to first unread message

Bruce MacLeod

unread,
Jan 9, 2012, 9:03:26 AM1/9/12
to MOTECH Architecture
Greetings !

A very basic demonstration of the platform is now available on
the motech-campaigndemo branch. It allows someone to sign up for
messages (with no content for now) every two minutes. There is also
functionality to stop the messages.

Unfortunately, our implementation required us to make changes to
the core platform that we not anticipated and may not represent the
"best practices" approach for platform applications. The file

http://code.google.com/p/motech/source/browse/campaigndemonstration/platformchangesandimplementation.txt?name=motech-campaigndemo

summarizes these changes, but one of the key platform modifications
that we did was to add jsp pages and change the dispatcher for motech-
platform-server. It works and it was relatively easy, but it seems a
rather unattractive way to build an implementation.

Any suggestions on how this could be done in a better way.

I do recall that the OSGi based implementation that 2Paths
worked on had a way to add to the dispatcher-servlet and thereby link
new pages into the core platform. Is this the direction we should
head ?

There is also some basic documentation for the demo in the code
and on the following pages :

http://motechdocumentation.wikispaces.com/Demo-Dependencies

http://motechdocumentation.wikispaces.com/CouchDB-Persistence

To complete the documentation, we will expand the Demo-Dependencies
diagram to show some of the dependencies between demo packages and the
platform packages. In addition, we are building a diagram to explain
the event processing.

We welcome suggestions on how to improve this. We are hoping to build
an example that first time implementers can start from.

Bruce

Rob LaRubbio

unread,
Jan 9, 2012, 3:11:27 PM1/9/12
to motech-ar...@googlegroups.com
I think these changes should make their way back into the master platform branch

platform-ivr changes
Added Json annotations to CallRequest class for proper Json serialization when storing in CouchDB

message-campaign changes
MessageCampaignScheduler schedules job IDs by message key, but attempts to unschedule by message name. The
stop() method was changed to unschedule messages by their key.

voxeo changes
added IVRservice bean
Various code changes for Json serialization, CouchDB lookup and callerID with Voxeo

I know you are documenting things as they currently are implemented.  The couchDB document was another reminder to me that we should remove the MotechAuditible* classes and just depend on the MotechBase* classes.

In the dependency graph, the red arrows are things that must be eliminated once we have a module loading system in place.  Additionally I'd like to understand why the campaigndemo had to depend on the voxeo module.  That is a dependency that ultimatly shouldn't exist.

Also Bruce, your memory is correct.  With the original OSGi implementation when your module was activated it registered handlers with the main dispatch-servlet allowing modules to respond to URLs under the main server context.  We need to get that functionality back in the platform.

-Rob
Reply all
Reply to author
Forward
0 new messages