Quel moteur de workflow choisir?
Nous sommes actuellement en train d'évaluer un moteur BPM et j'apprécierais vraiment la contribution de la communauté. Je fais ma propre diligence raisonnable, mais j'aimerais également entendre la suggestion basée sur des histoires de mise en œuvre.
Mes principaux critères d'évaluation sont ci-dessous
- open source et licence conviviale OEM
- installations de production (les réussites sont d'une grande aide)
- support commercial disponible
- support des standards ouverts - BPMN
- création/assemblage dynamique du workflow en fonction de la saisie
- intégrable
Actuellement, j'évalue Activiti et JBPM. Bonita open BPM semble également être un bon candidat mais ne l'a jamais utilisé. Avez-vous des déploiements réussis sur Bonita?
Je viens de faire une évaluation d'Activiti vs jBPM.
En fait, il semble y avoir très peu entre les deux solutions.
- Activiti est Apache V2, jBPM 5.0 est également Apache V2.
- Nous utilisons actuellement Activiti, mais le projet est toujours en développement, je ne peux donc pas commenter sa robustesse en production.
- jBPM commence le processus de production, donc la prise en charge de 5.x sera disponible au premier trimestre 2012, voir diapo 32: démo jBPM . jBPM 4 n'était pas pris en charge par Redhat.
- jBPM 4.x ne prend pas en charge BPMN 2.0, mais 5.x le fait, Activiti le fait également. jBPM 5.0 vient de sortir, ce qui inclut la prise en charge de BPMN 2.0. Alors maintenant, les deux solutions prennent en charge BPMN 2.0.
- Je ne sais pas trop ce que vous entendez par là, mais vous pouvez faire beaucoup à travers les deux API
- Encore une fois, vous ne savez pas ce que vous entendez par là, voulez-vous dire intégré dans le cadre d'un serveur d'applications, auquel cas, oui pour les deux solutions.
L'un de nos critères pour jBPM était l'interaction avec Guvnor, et quand j'ai téléchargé et exécuté l'installation de démonstration pour jBPM (28/03/2011) et il semblait toujours y avoir quelques bugs majeurs ( GUVNOR-1274 ), j'ai donc personnellement testé beaucoup plus avant de choisir cette solution.
En fait, nous recommanderons l'une des deux solutions ci-dessus, mais nous ne savons pas encore laquelle, nous l'examinerons de plus près cette année.
Bien que je possède peu d'expérience pratique, j'ai entrepris un pic de recherche sur Java options BPM récemment. Je l'ai réduit à 3:
La communauté Drools semble plus active, les outils sont meilleurs, le moteur de règles était très sophistiqué (car c'était la base des bave) mais les processus métier environnants étaient bien intégrés. Cependant, jBPM était davantage axé sur les processus métier et lisse également. Ils sont tous deux gérés par JBoss
D'autres comparaisons entre Drools et JBPM peuvent être trouvées ici:
Si vous avez une équipe de développement confiante et que les exigences ne sont pas trop complexes, il vaut toujours la peine d'envisager de faire la vôtre. Les BPM peuvent conduire à des modèles de domaine anémiques (comme décrit dans cet article règles et avantages du moteur de règles sur les moteurs de règles) lorsque vous essayez d'adopter vos modèles de domaine pour s'adapter à de tels systèmes, ainsi que des systèmes bien construits personnalisés pour votre entreprise vont toujours être plus efficaces.
En ce qui concerne vos critères:
Licence Open-Source et OEM friendly - Drools utilise une "licence ASL/BSD/MIT-esque" libérale, la communauté est active. jBPM utilise les licences Apache, Eclipse et MIT
Installations de production . Je comprends que la bave est utilisée par de nombreuses compagnies d'assurance et vérificateurs de crédit, je ne suis pas sûr qu'un jBPM
Support commercial disponible pour les deux
Prise en charge des normes ouvertes - BPMN - Les deux implémentent BPMN et, en raison de la nature des projets open source, sont très orientés sur les normes.
Création/assemblage dynamique du workflow en fonction de l'entrée. Les deux, bien qu'il soit généralement facilement implémenté manuellement.
Intégrable - les deux offrent des systèmes entiers mais sont modulés, ce qui devrait intégrer l'intégration dans les systèmes existants.
Je n'utilise pas de pile MS? WWF 4.0 pour le moteur, concepteur réhébergeable. WCF pour la communication. Serveur MS SQL pour BI. De nombreux développeurs .NET sont disponibles pour vous aider à créer et à personnaliser. Autre qu'une cible Windows, aucune dépendance à l'égard d'un fournisseur externe.