Quelle est la différence entre JBPM et Intalio ?

Une question m’a été posée ce soir : Quelle est la différence entre JBPM et Intalio?

La réponse n’est pas aussi évidente :

Je résume les principales différences entre jbpm et Intalio:

- Jbpm est davantage orientée vers les développeurs / Intalio est axée sur les utilisateurs ayant peu d'expérience technique

- jbpm Exige du code dans la majorité des cas / Intalio est (presque) zéro-code

- Jbpm nécessite une bonne connaissance de Java et du web / Intalio nécessite une savoir faire sur l’outil de design, de mapping de données, BPEL et BPMN

- Jbpm est compatible BPEL / Intalio est basé sur les concepts de BPEL

- Les deux proposent des outils à base de plugins Eclipse

- Jbpm 3.x ne prend pas en charge BPMN, mais un langage propre le JPDL (même pas le XPDL)/ Intalio est basé sur BPMN 2.0

- JBPM est 100% open source, Intallio pas exactement …

- JBPM, nativement, n’offre pas de solution BAM, Intallio inclus du BAM dans le package Entreprise (et pas l’édition communautaire)

La version 4 de JBPM est orientée BPMN, mais elle est en début de vie…

Je n'ai pas couvert toutes les différences entre les deux.

Pour un développeur Java, JBPM est plus simple à aborder …

Pour un concepteur, maitrisant BPMN, la solution Intallio est la plus séduisante

Pour une comparaison plus détaillé et plus scientifique

Open Source Power on BPM - A Comparison of JBoss jBPM and Intalio BPMS

autres sujets :

1. Un peu de monitoring Métier (BAM) avec JBPM et SeeWhy (event-driven business intelligence )

2. Comment modéliser un processus métier avec JBPM : exemple “gestion des entretiens”

3. Quelle est la différence entre JBPM et Intalio ?

4. Graph Oriented Programming (GOP) avec JBPM

5. La version 4 de JBPM prend le virage de BPMN

6. BPM & Moteur de workflow : l’offre open source

Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution

Une longue discussion ce matin: “comment faire pour avoir une application web performante, en terme de temps de réponse”.

Constat : une confusion entre les deux concepts : performance au sens de Montée en charge et performance au sens rapidité/vitesse d’exécution.

Montée en charge Vs performance

La montée en charge est la capacité d'un système à traiter une augmentation de la charge sans une dégradation perceptible de la performance.

Ainsi, la notion d'évolutivité est liée à celle de la performance, mais elle est différente de.

Prenons le cas d'une application web ayant N utilisateurs, et présentant un temps de réponses moyen acceptable de "t" secondes.

Cette application web est elle capable de maintenir ce niveau acceptable de performance, (réponse moyenne "t" secondes), si le nombre d'utilisateurs devient 2N, 3N, 10N …

La montée en charge reflète également la capacité d'une application Web de maintenir un niveau acceptable de performance lorsque de nouvelles ressources matérielles ou logiciels sont ajoutés à celui-ci.

Beaucoup d'applications Web ne parviennent pas à monter en charge, même si elles sont "performantes" à faible sollicitation, parce qu'elles n'ont jamais été conçues pour fonctionner sur plusieurs serveurs, ou ne parviennent pas à tirer parti de toutes les ressources matérielles à leur disposition.

Comment « démontrer » une capacité de monté en charge

L'objectif des tests de charge est de déterminer les performances et la capacité de montée en charge (Scalability ou évolutivité) d'une application Web.

Qu'est ce qu'on doit analyser

Penser en terme de « transactions utilisateur » ou « use cases » pour votre application

Les exemples typiques d'une transaction simple pourraient être …

• Logging in
• Demander la position d'un compte
• Comparer un prix

Observer l'usage des ressources par cas d'utilisation (spécialement les pointes)

St Rester concentré sur ce que vos clients font avec votre application… pourquoi perfectionner quelques choses d'autres ?

Qu'est ce qu'on doit observer

Les facteurs qui influent sur les performances sont parfois en dehors de l'application elle-même.

Ces facteurs comprennent

- la configuration du réseau et la plate-forme matérielle caractéristiques,

- le système d'exploitation paramètres,

- paramètres de réglage de la machine virtuelle Java

- paramètres de réglage des paramètres de base de données,

- et surtout l'architecture de l'application Web elle-même.

Ainsi, il est primordiale d'observer le comportement des ces facteurs lors d'une étude de performance, afin de s'assurer de la validité des résultats :

Les ressources

• Conteneur Web

• Sessions HTTP

• Pools de Thread

• Utilisation CPU

• Utilisation des I/O

• Utilisation réseau

L'usage de la Mémoire

• Garbage collection

• fuite de mémoires

Les Pools de connections

• JDBC Statement Types

• Prepared Statement Cache

• Exceptions

Messaging

• JMS

• File d'attente

Qu'est ce qu'on doit utiliser pour simuler une montée en charge

Les outils ne manquent pas :

Radview WebLoad (open source)

OpenSTA (open source)

JMeter (open source)

Mercury LoadRunner (HP)

Compuware QALoad

Rational Robot (Performance Studio, IBM)

Microsoft Web Applicatio Stress Tool

Et d’autres sur http://opensourcetesting.org/performance.php

Mais, n’oubliez jamais que l’outil n’est rien sans processus

Mais, ceci est une autre histoire

SpringSource acquiert Hyperic

Le fondateur de Spring Framework, continue sa marche en tant que éditeur.

Après le lancement de son propre serveur d’application, de son “presque” ESB, l’acquisition de Grooy & Grails, le voici se mettre à la supervision des applications. Espérons rapprocher le monde du développement et des opérations.

... ça expliquait le mariage dont Rod Johnson parlait, sur son twitter, la semaine dernière

hyperic : http://www.hyperic.com/springsource/

Graph Oriented Programming (GOP) avec JBPM

Introduction

La notion de Graph Oriented Programming (GOP), offre l’avantage de structurer l’application autour d’un graphe présentant une modélisation du processus à automatiser. GOP définit une notion de GVM (Graph Virtual Machine) a) définit le graphe b) définit the modèle d’exécution du graph c) ajoute le support aux états d’attente Le graphe est déclaré & séparé du code java: a) Des noeuds b) Des transitions

Le langage de définition de processus jBPM : jPDL

Dans sa version 3.x, Jbpm est basé sur le langage jPDL (JBPM 4 prend le virage de BPMN, mais il est encore en version béta)

jPDL est composé d’un ensemble d’éléments décrivant comment se déroule notre processus. Ces éléments sont :

Les nœuds C’est un petit rectangle qui représente une seule activité du processus.
Les tâches C’est un nœud qui doit être assigné pour une personne particulière et exécuté par le processus.
Les états C’est un nœud dont le rôle est de mettre le processus en attente.
Les forks et joins Lorsqu’on veut avoir deux chemins en parallèle, on utilise un fork pour la séparation et un join pour la jointure.
Les décisions Lorsque nous sommes appelés à prendre une décision sur un état ou une tâche du processus, on peut utiliser un nœud de décision.
Les transitions Elles relient entre deux nœuds. Elles peuvent être nommées au cas où on veut différencier entre deux ou plusieurs transitions.
Les variables du processus Elles renseignent sur les détails techniques du processus.

IDE : Vue générale sur l’interface du plugin éclipse

L’interface utilisateur contient deux grands niveaux :

a) Package explorer

b) Editor area

Package explorer

C’est l’espace de navigation qui contient les fichiers sources nécessaires pour notre projet ainsi que des fichiers JAVA.

Editor area

C’est l’espace réel du travail. Elle contient 5 onglets : le diagramme de l’application, les Swimlanes, le déploiement du processus, le design et la source.

Le diagramme de l’application Ce diagramme nous renseigne sur les différentes tâches réalisées par notre processus métier. Pour rajouter quelques nœuds on utilise le menu situé à gauche dans le schéma ci-après :
Les swimlanes Les swimlanes sont utilisés dans la définition des différents groupes ou profiles (notion d’acteur dans UML).
Le déploiement du processus Chaque fois qu’on modifie un paramètre dans l’environnement nous sommes appelés à déployer le processus pour que ces changements soient appliqués dans notre serveur jBPM. Vous pouvez déployer votre processus en appuyant sur le bouton « Deploy Process Archive » :
Le vue design Le design nous renseigne sur les détails des différents éléments du processus métier. La vue source Elle contient les codes XML qui gèrent le navigateur web de notre processus métier.

Article précédent sur les moteurs de BPM :

1. Un peu de monitoring Métier (BAM) avec JBPM et SeeWhy (event-driven business intelligence )

2. Comment modéliser un processus métier avec JBPM : exemple “gestion des entretiens”

3. Quelle est la différence entre JBPM et Intalio ?

4. Graph Oriented Programming (GOP) avec JBPM

5. La version 4 de JBPM prend le virage de BPMN

6. BPM & Moteur de workflow : l’offre open source