Hervé GERARD's JEE, MDA, SOA blog

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 30 juin 2011

Connecteur Bonita Groovy

Puissance de Bonita

Bonita est un outil communiquant. Il permet de se connecter à de nombreuses sources de données ou de services. De prime abord, cette fonctionnalité est très appréciable. Malheureusement, elle souffre souvent de lacune d'intégration. Sécurité, industrialisation de développement, tests unitaires sont autant de fonction qui sont difficilement reproductibles dans un tel outil. Finalement, le connecteur que je préfère, c'est le connecteur groovy ! Non pas que je sois fan de ce langage (dont je ne suis vraiment pas spécialiste...), mais il me permet d'utiliser n'importe quelle classe java qu'un développeur aura réalisée. Je trouve alors que la puissance de Bonita n'est pas tant ces nombreux connecteurs, mais plutôt sa capacité à intégrer des jar dans ses classpath de build et de run.

Classes Java

Imaginons que nous avons une classe java à interfacer en web service avec Bonita. Nous pourrions utiliser naturellement le connecteur Web Service. Je trouve que celui-ci est difficile à utiliser. Tout d'abord, il faut y placer le WSDL, ensuite faire l'appel par un script groovy et récupérer le DOM de retour pour parser le flux XML pour le mapper dans une variable. Tout ceci peut très bien se faire par notre IDE préféré (!!). En effet, dans Eclipse, il existe de nombreuses façons d'invoquer un web service. Avec en prime la possibilité d'effectuer des call back client/serveur pour la sécurité, de contextualiser les utilisateurs d'appel et de récupérer directement le bean de retour. Nous pouvons utiliser SpringWS, CXF mais j'ai un petit faible pour SCA (j'utilise habituellement l'implémentation Tuscany d'Apache mais d'autres existes) Notre classe est très simple, Il s'agit d'une sorte d'individu avec son adresse. Cela pourrait-être n'importe quelle grappe d'objets.

Retour Bean

Avec la classe adresse : Code Adresse

Nous pouvons maintenant créer une méthode qui rend cette grappe d'objets simples : Classe d'appel

Bien sûr cette méthode rend ici un bouchon. Elle pourrait très bien faire une connexion à une base, un appel web service ou un look up JNDI. Peu importe ici. Ce qui est assez souple, c'est ce qui suit avec Bonita.

Intégration dans Bonita.

Nous pouvons exporter notre jar depuis Eclipse et l'importer dans Bonita. La méthode d'import est très simple. Il s'agit simplement de déclarer notre jar dans les dépendances du processus. Ici, il s'agit du jar JavaBonita.jar Dépendances Bonita

Vous pouvez mettre ce jar au niveau du pool ou du processus directement. Ceci n'impacte que la portée de votre import. Tout dépend où se trouve l'activité qui doit faire appel au jar. Nous allons également déclarer une variable au niveau du processus. Donnees-Processus.png

Maintenant, nous pouvons sélectionner l'activité de notre processus qui doit faire appel à cette méthode puis choisir l'onglet Connecteur : Ajout de Connecteur Au début, il n'y aura aucun connecteur mais en cliquant sur Ajouter, nous voyons apparaitre la liste des connecteurs disponibles.Nous allons prendre ici Script puis Groovy.Nous pouvons sélectionner le moment durant l'activité où ce script s'exécutera. Pour ce tuto, ça n'a aucune importance. Nous pouvons maintenant éditer notre script et simplement appeler notre classe java et affecter très simplement le résultat à notre variable de processus. Script d'appel Java

Nous pouvons cliquer sur "Evaluer" ou "tester la configuration" pour tester notre appel. Normalement, nous voyons que le retour est "11111".

Et voilà, nous pouvons maintenant appeler très facilement une classe java qui elle-même utilise les standards d'appel de services que vous aurez établis.

mardi 7 juin 2011

ESB et EAI...

J’ai lu l’autre jour que les EAI offraient plus de valeurs métier que les ESB. Outre que ce n’est certainement pas faux puisque je ne pense pas qu’un ESB isolé apporte la moindre fonctionnalité métier (excepté peut-être de la traçabilité ou le passage d’une logique batch à une logique temps réel), je suis tout de même surpris de vouloir comparer deux briques techniques dans des domaines où elles ne sont pas maîtresses.

ESB et SOA

Pourtant, je vais tout de même me risquer à commenter cette phrase. Pour moi, les ESB, s’il n’apporte effectivement pas de réelles fonctions métier, se mettent en place avec une démarche de type SOA. C’est ici je pense la principale différence entre les EAI et les ESB. Ces derniers se focalisent sur les différents niveaux de services dans un système d’information et sur leur réutilisation. Pour ce faire, les ESB viennent avec une démarche d’identification de services et une architecture fonctionnelle urbanisée globale, où chaque silo applicatif est défini principalement pour un métier de l’entreprise. C’est ici que résident leur réalité économique avec finalement la capacité d’offrir par exemple des applications composites. Pour ma part, je ne pense pas que les EAI viennent avec ce type de démarche ou de préoccupations. La finalité étant de pouvoir connecter deux applications entre-elles afin de pouvoir récupérer des données et non de réutiliser des services.

Au final, si on compare non pas les ESB et les EAI mais la démarche globale d’introduction d’un ESB et les EAI, je pense que c’est cette démarche SOA qui apporte le plus de valeur métier.

dimanche 29 mai 2011

ESB vs BPM

ESB ou BPM, laquelle de ces briques devrait-on installer en priorité dans un SI ? Si l’une nous apporte des fonctionnalités techniques de supervision et de référencement, l’autre au contraire porte des plus-values métier indéniables. Supervision de processus, exécution de processus par événements dans le SI, passage d’une logique batch à une logique fil de l’eau, etc…

Les exigences d’un moteur de processus.

Le moteur de processus de l’entreprise doit réagir comme un centre de délégation (de type numéro d’urgence 112…) Il connait la réaction à avoir lors d’un événement dans le SI mais il ne sait pas comment le réaliser lui-même. Comme le central téléphonique d’urgence, il va déléguer en appelant le bon service. Le moteur de processus doit alors avoir accès à l’ensemble des services du SI qui pourraient servir ses activités. Mais il doit également être accessible par les applications au travers des événements postés par celles-ci. C’est ici que les ESB rejoignent les intérêts des moteurs de processus. Si l’IT souhaite exposer tous ces (ses ?) services, elle doit le faire à travers un bus qui lui permettra de correctement les superviser et les gouverner pour garantir une qualité de services, voire une qualité d’usage indispensable à leur consommation.

Et alors ?

Comme une fondation qui n’apporte aucune fonction à une maison mais qui sans-elle interdirait le montage des murs et de la toiture, les ESB forment le socle nécessaire aux moteurs de processus. Le bus doit alors être opérationnel avant de mettre en place un moteur de processus. Au risque de créer des points à points entre le moteur et les applications. Participant ainsi au fameux plat de spaghettis…

Le débat n’est donc pas de savoir ce qu’apporterait en fonctionnalités métier le bus de services. Pour moi, il n’en apporte aucune. Son absence est par contre préjudiciable à l’exposition des services en toute sécurité par les autres applications porteuses, elles, de plus-values métier et en particulier le moteur de processus, élément central dans le système d’information.

mardi 28 septembre 2010

Haute Disponibilité pour Petals avec Pacemaker

Si le BPM est l’élément central de délégation (oui, une explication est certainement nécessaire…) et le BRMS l’élément central fonctionnel, les bus représentent les éléments centraux techniques. S’ils n’apportent aucune plus-value métier (oui une explication…) ils sont en revanche nécessaires pour organiser et superviser les services offerts par l’ensemble des silos métier. (BPM et BRMS inclus). Pour cela, nous devons assurer la disponibilité maximale de cet élément technique. Si Petals offre la capacité à constituer des clusters par ses topologies, la ferme constituée contient un SPOF qui est le nœud maître. Sous Linux, nous pouvons rapidement paramétrer un cluster Actif/Passif sur le nœud maître à l’aide des logiciels Pacemaker et Corosync de la communauté LinuxHA. Je vous propose une petite installation de ces soft avec Petals sous Fedor 12. Elle n’est bien sûr pas parfaite (ah bon, l’utilisation de root n’est pas une bonne idée !?) mais offre déjà une bonne base pour la suite… et est particulièrement performante. Toute idée d’amélioration est donc la bienvenue !!

  1. Télécharger Petals 3.0.5
  2. En root : yum install -y openais pacemaker

Sont installés : pacemaker 1.0.7, openais 1.1.3

  1. En root, unzip petals-platform-3.0.5.zip -d /opt/
  2. chown "user" -R /opt/petals-platform-3.0.5/
  3. Fixer dans le fichier .bashrc la variable JAVA_HOME : export JAVA_HOME=/etc/alternatives/jre
  4. Bien démarrer , Petals en démon : startup.sh -D
    1. Pour l'instant, ne pas démarrer Petals, c'est pacemaker qui le fera.
    2. Bien paramétrer les firewall sur chaque machine (je les ai supprimés….) et le niveau de SELinux (que j'ai mis en permissif)
  5. Renommer le fichier /etc/corosync/corosync.conf.example en corosync.conf et remplacer les éléments suivants (le premier est vraiment contextuel) :
    1. bindnetaddr : 192.168.56.0
    2. mcastaddr : 226.94.1.1
    3. mcastport : 5405
  6. Renseigner le fichier /etc/hosts avec l'ensemble des adresse et des noms des nœuds du cluster
  7. Paramétrer les fichiers /etc/hosts pour prendre en compte les noms réseaux
  8. Demander à corosync de démarrer Pacemaker en créant un fichier pcmck sous /etc/corosync/service.d

@@service {

        # Load the Pacemaker Cluster Resource Manager
        name: pacemaker
        ver:  0
}

@@

  1. Démarrer openais : /etc/init.d/corosync start
  2. Vérifier dans /var/log/messages si les deux nœuds se voient bien

grep CLM /var/log/messages

  1. Vérifier avec crm configuration show
    1. il faut que Pacemaker soit démarré pour cela.
    2. Pacemaker a besoin d'avoir un fichier hosts renseigné avec le nom et l'adresse des nœuds sur chacun des nœuds.
  2. Comme il n'y a pas de synchronisation de données entre les nœuds, Stonith peut être désactivé :
    1. crm configure property stonith-enabled=false
  3. Avec crm_mon, on affiche l'état du cluster
  4. On peut maintenant créer une adresse IP virtuelle pour effectuer notre cluster Actif / Passif :
    1. crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params ip=192.168.56.50 cidr_netmask=32 op monitor interval=30s
    2. Pour un cluster actif/passif avec 2 nœuds, il est nécessaire de demander à Pacemaker de ne pas activer le principe de quorum : crm configure property no-quorum-policy=ignore
    3. On peut ensuite vérifier sur quelle machine l'adresse IP est active : crm resource status ClusterIP
  5. Lors d'un arrêt puis un redémarrage d'un nœud du cluster, il peut être intéressant de demander à Pacemaker de laisser la ressource lancer sur le backup actif et de ne pas arrêter le backup pour activer la ressource initiale lors de son redémarrage. C'est particulièrement utile pour des ressources lentes à démarrer (Oracle) ou qui nécessitent des jeux de sticky session (tomcat).
    1. Pour laisser la ressource active sur le même serveur, il faut spécifier que le coût d'un arrêt n'est pas nul : crm configure rsc_default resource-stickiness=100
  6. Pour attacher la supervision de pacemaker et de Petals, il faut utiliser l'agent "anything"
    1. Petals doit être installé sur les deux nœuds.
    2. Repositionner JAVA_HOME dans setenv.sh (??)
    3. Le script "petals-esb" doit fournir son pid :
      1. Echo $! > /opt/petals-platform-3.0.5/logs/petals.pid
      2. A positionner juste après le démarrage du service
    4. crm configure primitive esbPetals ocf:heartbeat:anything params binfile="/opt/petals-platform-3.0.5/bin/petals-esb" pidfile="/opt/petals-platform-3.0.5/logs/petals.pid" logfile="/var/log/esbPetals.log" cmdline_options="start" op monitor interval="15s"
    5. Bien s'assurer que l'adresse IP tourne sur la même machine que le bus
      1. crm configure colocation esb-with-vip INFINITY: esbPetals ClusterIP
      2. crm configure order petals-after-ip mandatory: ClusterIP esbPetals

Ce qu'il reste comme axes d'amélioration :

  1. Si on fait un kill -9 sur corosync sur le nœud actif, Petals démarre bien sur l'autre nœud mais ne s'arrête pas sur le premier nœud. Ce n'est pas si gênant car l'adresse IP virtuelle pointe bien sur l'autre nœud. De plus, au redémarrage de corosync sur le premier nœud, Petals est bien arrêté puis redémarré proprement. (vive le pid de Petals ?)
  2. Il faudrait spécifier une machine préférée pour les ressources (pour un cluster à 2 nœuds, le chiffre 50 est arbitraire…)
    1. crm configure location prefer-fedoraesb esbPetals 50: fedoraesb.telsendomain
  3. Démarrer avec root n'est pas génial…
  4. Les fichiers de log de petals ne sont pas vidés
  5. Reste un message d'erreur dans la console crm_mon
    1. Failed actions: esbPetals_monitor_0 (node=esbBackup, call=3 rc=1 status=complete): unknown error

- page 1 de 3