L'objectif de JMSLite est de rendre le comportement du moteur de flux de travaux dans un environnement de développement intégré de la façon la plus proche possible de la manière dont il se comporte lorsqu'il est déployé sur un serveur d'applications. Cela accroît la probabilité de détecter rapidement les problèmes (lors du test dans l'environnement de développement intégré) plutôt que tardivement (lors d'un test sur un serveur d'applications), réduisant ainsi les risques et les coûts.
Par exemple, envisagez la situation suivante : à supposer que WMS (en cours d'exécution dans un environnement de développement intégré) devait adopter des flux de travaux de façon
synchrone.
Rappel : Dans la production, les flux de travaux sont adoptés de façon asynchrone, car ils sont censés être de longue durée (qui se compte en heures, en jours ou en semaines) par rapport aux opérations normales de l'utilisateur (qui se comptent en secondes ou en millisecondes).
A supposer également qu'un développeur devait écrire une méthode qui a adopté un flux de travaux d'approbation de dossier automatisé et a ensuite (immédiatement après l'appel au service d'adoption) essayé d'exploiter le résultat (par exemple, vérifier si le dossier a été automatiquement approuvé). Etant donné que l'environnement de test fonctionne d'une manière différente (de manière synchrone) à partir de l'environnement de production, le code fonctionnerait correctement dans le test, mais échouerait dans la production (il s'agit d'un exemple de bogue de "couplage temporelle").
Toutefois, étant donné que JMSLite s'exécute de façon asynchrone, ce problème devrait apparaître dans l'environnement de développement intégré de la même façon que sur un serveur d'applications, permettant ainsi au développeur de le détecter rapidement.