JMSLite zielt darauf ab, dass sich die Workflow-Engine in einer integrierten Entwicklungsumgebung möglichst so verhält wie bei einer Bereitstellung auf einem Anwendungsserver. Dadurch können etwaige Probleme (beim Testen in der integrierten Entwicklungsumgebung) so früh wie möglich erkannt werden, wodurch mögliche Risiken und Kosten gesenkt werden.
Es wird beispielsweise die folgende Situation angenommen: Das (in einer integrierten Entwicklungsumgebung ausgeführte) WMS soll Workflows
synchron umsetzen.
Zur Erinnerung: In der Produktion werden Workflows asynchron umgesetzt, da vorausgesetzt wird, dass sie in Bezug auf normale Benutzeroperationen (die Sekunden oder Millisekunden dauern) eine lange Lebensdauer (Stunden, Tage oder Wochen) haben.
Angenommen, ein Entwickler soll zudem eine Methode schreiben, die einen automatisierten Workflow zur Fallgenehmigung umsetzt, und dann (sofort nach dem Aufruf an den Umsetzungsservice) versuchen, etwas mit dem Ergebnis zu machen (z. B. prüfen, ob der Fall automatisch genehmigt wurde). Da die Testumgebung sich anders (synchron) als die Produktionsumgebung verhält, würde der Code zwar beim Test funktionieren, jedoch in der Produktion fehlschlagen (dies ist ein Beispiel für einen 'zeitlichen Kopplungsfehler').
Da jedoch JMSLite die Ausführung asynchron vollzieht, würde sich dieses Problem in der integrierten Entwicklungsumgebung in gleicher Weise wie auf einem Anwendungsserver zeigen und kann somit vom Entwickler frühzeitig erkannt werden.