The purpose of JMSLite is to make the workflow engine behave in an Integrated Development Environment in the the closest possible way to how it behaves when deployed on an application server. This increases the likelihood of catching problems early (while testing in the Integrated Development Environment) rather than late (when testing on an application server), thereby reducing both risk and cost.
For example, consider the following situation: Suppose the WMS (running in an Integrated Development Environment) were to enact workflows
synchronously.
Reminder: In production, workflows are enacted asynchronously because they are assumed to be long-lived (on the order of hours, days or weeks) relative to normal user operations (order of seconds or milliseconds).
Suppose also that a developer were to write a method that enacted an automated
case-approval workflow and then (immediately after the call to the enactment service)
tried to do something with the result (e.g. check if
the case was automatically approved). Since the test environment operates in
a different manner (synchronously) from the production environment - the
code would work fine in test, but would fail in production (this is an
example of a 'temporal coupling' bug).
However, since JMSLite executes asynchronously - this problem would show up in the Integrated Development Environment in the same way as it would on an application server, thereby allowing the developer to catch it early.