La dernière soirée du Paris JUG a provoqué quelques débats sur MDA, avec notamment le post d’Eric sur le positionnement de Valtech. Pour continuer sur la lancée d’Eric, Yann Letanou, Leader Technique chez Valtech Technology, nous propose un article riche sur les bénéfices du MD dans le cadre d’une SOA.

SOA et Approche Model-Driven

L’intérêt grandissant pour les architectures orientées-services amène à se poser la question de l’intérêt d’une approche MDA (Model-Driven Architecture) pour modéliser et au final générer le code permettant l’implémentation des différents composants logiciels.

Nous n’allons pas ici rentrer dans le détail du pour ou contre MDA pour SOA. A Valtech nous pensons que les approches de développement Agile permettent l’émergence d’un design et d’une architecture de bien meilleure qualité qu’une approche MDA. Cette dernière reporte toute la complexité d’écriture du code sur des modèles qui sont loin de permettre les mêmes nuances que du code. La complexité est également reportée sur les générateurs de code qui deviennent alors le point dur car très difficiles à maintenir et à faire évoluer. Au final, Cette élaboration de modèles très détaillés rend improductive l’équipe de développement, qui n’a pas les moyens d’agir au cœur des problèmes.

Toutefois, certaines approches dites « Model-Driven » peuvent être intéressantes lorsqu’elles permettent d’améliorer la productivité et la communication, à condition de ne pas être axées sur de la génération de code à tout va (qui nous ramène au point précédent). C’est par exemple le cas du « Model-Driven Testing » axé sur la génération des tests. C’est aussi le cas des approches centrées sur la génération de fichiers de paramétrage (typiquement à partir de schémas XML standardisés) permettant de configurer des composants logiciels « sur étagère » et à forte valeur ajoutée.

Les technologies utilisées pour implémenter des architectures de services (SOA) sont très axées sur ce type de composant logiciel avec notamment :

• Les moteurs d’orchestration de service, principalement utilisés pour l’automatisation des processus métier,
• Les bus d’intégration de services ESB, épines dorsales de la SOA,
• Les conteneurs de services avec notamment le standard SCA.

L’idée est donc de pouvoir obtenir des applications par paramétrage d’un certain nombre de ces composants logiciels, grâce à l’élaboration de modèles dédiés permettant de s’intégrer dans une démarche agile prenant pour le reste en charge le développement du code applicatif ainsi que le cœur des services. La démarche est ainsi toujours la même :

• On modélise et on paramètre graphiquement, avec un langage et un éditeur dédié,
• On génère le ou les fichiers XML,
• On déploie les fichiers générés dans le composant technique pour le configurer, parallèlement au déploiement du code écrit à côté,
• On supervise ensuite l’exécution.

Moteur d’orchestration : Génération BPEL à partir de BPMN
BPMN est une notation définie et standardisée par l’OMG; elle permet de modéliser des processus métier à partir d’un ensemble d’éléments de modélisation permettant de couvrir une large palette de besoin. BPEL est un standard de l’OASIS définissant une grammaire XML permettant de décrire des processus directement exécutable par un moteur d’orchestration BPEL. L’une des force de BPEL est de se baser sur de l’orchestration de webservices et de supporter via BPEL4People la gestion de tâches humaines à travers un workflow.

Toutefois la syntaxe BPEL est très complexe et des outils ont rapidement vu le jour pour offrir une notation graphique au-dessus de BPEL (ActiveBPEL par exemple). Cette notation graphique est cependant très proche du BPEL et il reste nécessaire de maitriser ce langage pour définir correctement un processus. De plus, cette proximité de la notation graphique par rapport au BPEL fait que les processus définis ainsi restent difficilement lisibles par des personnes non-aguerries aux subtilités du langage. L’OMG a donc défini un mapping BPMN à BPEL permettant de conserver les avantages descriptifs et documentaire du BPMN tout en ayant la possibilité d’en faire un exécutable à travers BPEL. Ainsi des outils comme Intalio BPMS autorisent ce niveau de modélisation et permettent à une personne non-initiée au BPEL de modéliser et de déployer des processus exécutables. Attention toutefois, cela reste un outil d’informaticiens qu’on ne mettra pas dans les mains d’un pur analyste. Néanmoins, il permet de s’abstraire en grande partie des subtilités du BPEL tout en offrant une puissance de modélisation permettant de développer et déployer rapidement des processus exécutables basés à la fois sur de l’orchestration de services et de la gestion de tâches humaine.

Génération XML pour le paramétrage d’un ESB
Nous pouvons résumer simplement un ESB comme un bus logiciel de médiation, basé sur les standards du Web, orienté-service (et non orienté-flux à la différence d’un EAI classique) permettant de mettre en relation les composants d’une SOA, indépendamment des types de protocoles et de messages utilisés.

L’ESB permet d’exécuter des médiations, qui peuvent être vues comme un assemblage de modules logiciels permettant de mettre en relation des composants logiciels. Par exemple, l’ESB peut permettre de gérer différentes versions d’un webservice déployé sur différents serveurs. La médiation consiste alors à définir les conditions permettant de savoir à quelle version du service chaque appel doit être routé. Le service peut être activé via différents protocoles de communication. La médiation définit alors ces protocoles et les transformations nécessaires permettant au final d’activer le bon webservice.

La médiation peut être décrite graphiquement, à l’aide d’un outil, comme par exemple Spagic, IDE Eclipse permettant de paramétrer l’ESB d’apache ServiceMix. On assemble alors un certain nombre de composants élémentaires, issus généralement des EIP (Enterprise Integration Patterns). Puis on génère à partir de cela les différents fichiers XML de description de la médiation que l’on peut alors déployer dans l’ESB. Le format de ces fichiers XML varie en fonction de l’éditeur. A ce titre, le standard JBI (Java Business Integration, JSR208) tente de standardiser les spécifications d’un ESB et donc le format de ces fichiers de configuration XML. Contrairement aux grands éditeurs du marché, plusieurs ESB open-source suivent aujourd’hui ce standard : c’est notamment le cas de Apache ServiceMix, de Sun OpenESB ou encore de Petals.

Génération XML pour le paramétrage d’un conteneur SCA
SCA (Service Component Architecture) est une spécification de l’Open-SOA définissant un modèle pour la création et l’assemblage de composants de service, indépendamment des langages de programmation utilisés pour leur implémentation. Cette initiative est fortement supportée par IBM, dont la suite SOA est basée sur ce modèle.

L’idée est que le développeur puisse définir des assemblages de composants de service, graphiquement, puis pour chaque composant spécifier son implémentation (par exemple, BPEL, Moteur de règle, code java, etc.). Cet assemblage forme un composite SCA, dont la description est réalisée à travers une syntaxe XML dédiée.

Une fois le composite créé, l’outil génère les fichiers XML puis effectue le déploiement dans un ou plusieurs conteneurs de services SCA, selon que les composants de l’assemblage sont tous locaux ou distants.

Vers un environnement de développement SOA unifié
L’idéal est ensuite de disposer d’un environnement unifié pour définir ces différents modèles puis générer les fichiers de paramétrage associés pour automatiquement les déployer dans la brique logicielle correspondante. Les éditeurs tendent également vers cette ambition, comme IBM avec sa suite basée sur Websphere Process Server, et BEA avec sa suite Aqualogic.

Côté Open-Source, le projet Eclipse STP (pour SOA Tool Platform) est aujourd’hui le candidat le plus crédible. Bien que STP ne soit pas parfait pour l’ensemble des briques que nous avons citées (mais c’est aussi le cas des autres), il reste une initiative particulièrement suivi par la communauté SOA.

Auteur: Yann Letanou.

Qui n’a jamais perdu des fichiers lors d’un crash de disque dur ? ou de la machine tout entière ?
Dans cet article je vous expliquer quels sont les moyens que j’ai mis en œuvre pour sauvegarder les données qui se situent sur mon serveur de fichiers (qui contient mes documents personnels, ma musique, mes photos, etc..) dans mon appartement.
Rsync est un logiciel qui construit des sauvegardes incrémentales, c’est à dire qu’il transfert entre chaque sauvegarde que le delta observé entre les 2.
Les machines concernées sont sous Ubuntu Server 7.10 mais l’article reste valide pour toute Ubuntu ou Debian.

Sauvegarde locale

La sauvegarde locale consiste à sauvegarder certains répertoires d’un disque vers un autre disque, dans la même machine (mon serveur de fichiers en l’occurrence) de manière périodique (toutes les semaines).
En l’occurrence sur la partition /dev/hda1 j’ai les répertoires /home /var /etc à sauvegarder; pour cela j’ai la partition /dev/sda2 (sur un disque différent donc) qui est montée sur le pointe de montage /backup
Ainsi mon script cron (sauvegarde.sh, executable bien sûr) à lancer toutes les semaines est le suivant :

L’option “-avz” signifie que la sauvegarde (le transfert) des fichiers sera récursif; les fichiers seront tranférés en mode “archive” qui garantit que les les liens symboliques, les attributs,les permissions, les droits, etc… seront préservés lors du transfert; de plus une compression sera utilisée lors du tranfert (qui n’affectera pas vos fichiers)
l’option “–delete” signifie elle que lorsque l’on supprimera un fichier sur /etc par exemple, il devra être supprimé aussi de /backup/etc/ lors de la sauvegarde. (si vous ne mettez pas cette option, votre /backup risque de se remplir très rapidement !!!)

Mise en place du “job” cron

Pour appeler le script de sauvegarde sauvegarde.sh, il faut l’indiquer dans une table cron; pour cela je vous renvoie au tutoriel cron d’ubuntu-fr.org
En particulier, le script de sauvegarde doit être lancé par un utilisateur ayant accès à l’ensemble du système de fichiers.
Plutôt que d’utiliser root, nous allons créer un nouvel utilisateur , “sauvegarde” qui fera partie du groupe root, et autres groupes utilisateurs nécessaires pour qu’il puisse sauvegarder l’ensemble des répertoires spécifiés.
Son “home directory” sera /backup
% sudo useradd -d /backup -g root -G anthony sauvegarde
donnez lui l’appartenance de ce répertoire:
% sudo chown -R sauvegarde:root /backup
Ainsi, le script sauvegarde.sh doit être accessible et lancé par notre nouvel utilisateur sauvegarde; pour cela, créez une nouvelle crontab pour l’utilisateur sauvegarde :

Votre éditeur (vi ou emacs) se lance, insérez la ligne suivante :
@weekly /chemin_ou_situe/sauvegarde.sh #sauvegarde

çà y est !
votre sauvegarde locale est créée, vous être à l’abri du crash du disque contenant /home /etc et /var !!
Mais si votre machine est victime d’une surtension,et que tous les disques sont endommagés, vous perdrez tout !!!

Sauvegarde distante

Pour se prémunir d’un dégât, d’un vol, d’un incendie, il faut sauvegarder vos données vers une machine distante.
Si vous possédez un serveur dédié (ou si un ami ou autre personne de confiance vous donne accès à son serveur) vous pouvez alors mettre en place une solution de sauvegarde distante.
Pour cela, compléter le fichier sauvegarde.sh en y rajoutant ces lignes :

Comme vous pouvez le constater, avec rsync, une sauvegarde locale ou distante est traitée de la même manière, la syntaxe est identique, au $serveur: près.
Bien entendu pour que tout ceci fonctionne, vous devez, sur la machine distante, créer un utilisateur sauvegarde , avec pour “home directory” /backup (répertoire à créer sur la machine distante).
% sudo useradd -d /backup sauvegarde
donnez lui l’appartenance de ce répertoire:
% sudo chown -R sauvegarde:sauvegarde /backup
donnez à votre utilisateur sauvegarde un mot de passe (fort de préférence) :
% sudo passwd sauvegarde
Aussi, pour permettre à votre machine locale de se connecter à la machine distante, sans intervention de votre part (sans demander de mot de passe donc) vous devez créer un couple de clés DSA.
Sur la machine locale, logguez vous en utilisateur sauvegarde :
% sudo su sauvegarde
et créez votre couple de clés DSA :

Acceptez l’emplacement par défaut pour la création des clefs, et appuyez sur entrée lorsque l’on vous demande une “passphrase” (comme çà, nul besoin de saisir de mot de passe pour utiliser la clef).
Il n’y a plus qu’à partager la clef publique générée avec la machine distante :
toujours loggué en utilisateur sauvegarde sur la machine locale :
ssh-copy-id -i ~/.ssh/id_dsa.pub sauvegarde@machine_distante
C’est fini, votre utilisateur sauvegarde, sur la machine locale, pouvant se logguer sur la machine distante, votre script cron, sauvegarde.sh, sera lancé toutes les semaines sans problème afin de sauvegarder localement et à distance vos données importantes.
Vos commentaires sont les bienvenus !

Références :
le site officiel de Rsync
Formation Debian : accès par ssh

I just wrote an article for my current client, an investment bank, to explain to project managers what it takes to perform non-regression functional tests in a continuous integration process. When I say non-regression functional tests, I mean real functional tests that stimulates the GUI to perform tests. My main point is to argue that continuous integration is not exactly like continuous testing and that their respective objectives cannot be combined as easily as just integrating functional regression tests into the continuous integration process. This is actually what the managers ask for when we start automating the functional tests: “can we integrate these tests into the continuous integration process ?”. Well, I could merely answer yes, for it is technically possible, but that answer would not be fair because they cannot integrate the functional tests into their specific continuous integration process. Let me explain this.

Usually the projects we are working with have a continuous integration process including the following steps: compile, build, code check (this step is usually referred to as “test” but I don’t like this name), and (sometimes) package. So they are doing continuous integration and they are continuously checking the code, period. Problem is that they want to do continuous testing, I mean not only basic unit tests, they want to continuously perform functional non-regression tests on every build. And this is another story, because it usually requires a fully operational testing environment to test the application at runtime (which is needed for “real” functional tests). Between the time a build is ready for testing and the time it can actually be functionnaly tested, lots of operations are conducted manually, like deployment tasks, database and plateform setup, production data copy, startup of shared services, etc. Some managers don’t know that they must fully automate the deployment in testing environment if they want to integrate fonctional regression tests in the continuous integration process. So first point was to stress on fully automating the deployment process.

But this is not the major issue to be addressed. Another point that I stressed was about not breaking the continuous integration benefits. Continous integration is based on quick feedback to the developers: the quicker the feedback, the better the fix. Anything that increases the delay between the time a developer checks his code in the source repository and the the time he gets notified of a failed build jeopardizes continuous integration success. Thing is that functional regression tests is time consuming, and comes after deployment (as noted above) which can be even more time consuming. So it does not look like a good option to automatically perform functional regression tests in the same workflow as continuous integration. Besides this, it does not make sense to functionally regression test every build

The solution that I advised is to create workflows that are triggered subsequently to provide some sort of increasing verification level while not breaking continuous integration. The target organization is to split the job into at least 2 workflows, but that can be more:

• the classical continuous integration workflow (compile, build) that is triggered as soon as a new piece of code is introduced in the repository. It is usually extended to check code (unit test, code rules, …), but I advise to do so as long as it does not exceed 10-20 mins.
• It is better to add one more workflow to the process between continuous integration and regression workflow so that tasks like package, generate documentation, install, or even code verification could be removed from the continuous integration workflow and be included in this “intermediate” workflow. It should be triggered as soon as a successful continuous integration workflow has been performed (successful build).
• a regression workflow that includes deploying and regression testing (functionnaly) on the test plateform and is triggered at most once a day (say at night), most probably once a week depending on the development cycles and team size.

In short, my answer to the question was:
- fully automate the deployment process
- seperate functional regression tests in another workflow than the classical continuous integration workflow and trigger it at most once a
day

After releasing this article to my client, I started thinking that the name “continuous integration process” as used in the software programming field today is really a bad name. But this is another story.

Cet article a pour objectif de présenter les architectures REST : REpresentational State Transfer. Il s’agit là d’une introduction dont le but est de présenter ses concepts de base, le sujet pouvant aisément faire l’objet d’un livre de 600 pages !

(more…)

Article paru dans la newsletter #20 – Ete 2007

Le 1er juin, a eu lieu à La Défense un séminaire IBM sur la SOA. Big Blue n’a pas lésiné sur les moyens et nous a offert un grand show sur l’état de l’art en matière de SOA.

(more…)

Mardi 13 mars au Pavillon Kleber, BEA a organisé une grande présentation de l’ensemble de sa suite SOA nommée Aqualogic. C’est donc l’occasion de vous présenter cette offre particulièrement intéressante par rapport à ce qu’offre la concurrence sur le sujet.

Ce Roadshow était découpé en présentations d’environ 1 h, permettant chacune d’aborder différentes caractéristiques de la suite, dont je fais ci-dessous un bref résumé. (Vous pouvez également retrouver les supports de ces présentations sur cette page)

(more…)

UPDATE !!!
The author of the Last.fm wordpress plugin has updated it to make it work !!!

Well, it was…until I found out what was actually going wrong !
“last.fm recent tracks” WordPress plugin by Tijs Teulingsdoesn’t work anymore due to Last.fm new XML syntax.
In the file lastfm.php which comes with the plugin, and which may be located at the /wp-content/plugins directory (relatively to your wordpress installation directory), you have to change, line 92 :
$findme = '<track>'; by
$findme = '<track';
to make it work !
Yeah it’s as simple as that, the XML output of Last.fm has changed and the tag <track> has now an attribute, and often becomes <track streamable=”true”> (which doesn’t match <track> but always matches <track).

If you’re too lazy (or if you don’t want to open a file editor..) you can download the fixed version of lastfm.php

Working version of the lastfm.php file from “last.fm recent tracks” WordPress plugin compatible with the new Last.fm XML syntax

Ce tutorial vous expliquera comment mettre en oeuvre derrière Apache 2 le script CGI Proxy qui peut vous servir aussi bien à surfer anonyme (désactivation de scripts pendant la navigation), à accéder aux serveurs web de machine situées dans un réseau local, à contrer la censure …

Installer simplement CGI Proxy (sans SSL)

Tout d’abord, vous devez avoir les logiciels suivants installés sur votre machine:
-un serveur sous Linux(çà devrait marcher sur tous les OS…)
-Apache2 (un autre serveur web devrait faire l’affaire mais je n’ai pas testé…)
-Perl
Des commandes comme :
#apt-get install perl apache2
devrait plus ou moins régler les choses sur Debian et les Debian-like…
Pour la suite de l’article, je suppose que vous utilisez une distribution Debian Sarge.

Dirigez vous vers /etc/apache2/sites-available
#cd /etc/apache2/sites-available

Créez un nouveau site web, disons que vous avez le nom de domaine test.fr, créez ainsi le sous domaine cgiproxy.test.fr :
#vim cgiproxy.test.fr

et insérez les lignes suivantes :

Pour que ce nouveau site soit fonctionne, n’oubliez de faire un lien symbolique de cette configuration dans /etc/apache2/sites-enabled :
#cd /etc/apache2/sites-enabled
#ln -s /etc/apache2/sites-available/cgiproxy.test.fr

et de bien sûr créer le répertoire désigné dans votre configuration:
#mkdir /var/www/cgiproxy.test.fr

On redémarre Apache2 pour que la configuration soit prise en compte :
#/etc/init.d/apache2 restart

Petite note pour ceux qui n’ont pas de nom de domaine ou ne sachant pas comment créer un site sous Apache 2 :
Vous avez sans doute dans /etc/apache2/sites-available un site (fichier de configuration) qui s’appelle 000-default, qui pointe vers des fichiers dans /var/www : vous pouvez aussi bien l’utiliser en adaptant cet article (chemins et sites)

Rendez vous dans /var/www/cgiproxy.test.fr et téléchargez le script CGI CGI Proxy :
#wget http://www.jmarshall.com/tools/cgiproxy/releases/cgiproxy.2.1beta15.tar.gz

Pour avoir la dernière version, veuillez consulter le site officiel CGI Proxy

On décompresse l’archive ainsi récupérée :
#tar xvzf cgiproxy.2.1beta15.tar.gz

Et si tout s’est bien passé, en dirigeant son navigateur vers http://cgiproxy.test.fr/nph-proxy.cgi on doit avoir le formulaire de saisie d’URL de CGI Proxy !
Si toutefois cela ne fonctionne pas, n’hésitez pas à laisser un commentaire à cet article, mais commencez par vérifier :
-que vos chemins sont bons
-que vous n’avez pas renommé nph-proxy.cgi en quelquechose.cgi (il faut impérativement que le nom du fichier commence par nph-)
-que le script est exécutable :
#chmod +x nph-proxy.cgi

Installer CGI Proxy en mod ssl :

Un peu plus difficile cette fois-ci, cette partie de l’article s’adresse aux personnes ayant déjà mis en place des sites Apache2 en mod_ssl.(un jour j’écrirai un article pour l’expliquer !).
Pour faire simple, et rapide, inspirez vous de mon fichier de configuration :

Un peu d’explication !
<VirtualHost *:443>
vous permet de déclarer un serveur virtuel écoutant sur le port 443 (https par défaut)
AddHandler cgi-script .cgi
permet à Apache 2 de lancer le moteur d’interpréteur de CGI lorsque les fichiers demandés terminent par .cgi
DirectoryIndex nph-protected.cgi
indique à apache que le fichier index par défaut est : nph-protected.cgi (situé dans /var/www/cgiproxy.test.fr) lorsque qu’aucun nom de fichier est spécifié.
AuthUserFile
permet de mettre en place une sécuristation HTTP Basic (login/mot de passe demandé pour accéder à la ressource)

Liens

Le site de documentation d’Apache2
Le site officiel de CGI Proxy