Les lightweight ESB, par opposition aux ESB traditionnels, sont un type émergent de solutions d’intégration simplifiées, qui se concentrent sur les besoins récurrents. Celles-ci n’apportent pas de nouvelles fonctionnalités, mais adressent les problématiques d’intégration d’application de manière rafraîchissante et innovante. On peut compter les solutions reconnues comme lightweight ESB sur les doigts d’une main: ApacheCamel, MuleESB et SpringIntegration. Le but n’est pas ici de comparer ces trois outils, mais d’apprécier ce qu’ils ont pour sur en commun: leur nature efficiente et productive.

Cet article est constitué d’une série de points à adresser lorsqu’il s’agit d’intégration d’applications. La plupart de ces questions servent indifféremment à choisir une architecture d’échange, à comparer des solutions ou encore à concevoir des flux. Pour couvrir ce vaste sujet, la checklist se décompose comme suit, en se limitant aux aspects différenciant pour les lightweight ESB :

• les exigences fonctionnelles, c’est-à-dire le strict besoin en fonctionnalités d’intégration,
• les exigences non-fonctionnelles comme la supervision technique et le déploiement,
• les contraintes organisationnelles

Lire la suite de l’article en anglais

Suggestion d'articles :

1. Choisir son ampli (et son usine de développement)…
2. Choisir un Core Banking System?
3. Choisir Grails pour faire du web: Au menu ou à la carte ?

Les services de réseau de diffusion de contenu, ou Content Delivery Network (CDN), adressent des problématiques liées à l’optimisation des performances du web, que ce soit en terme de scalabilité ou de haute disponibilité.

Une présentation des solutions de CDN vient d’avoir lieu chez Octo dans le cadre du WebPerf User Group France. En parallèle, voici un petit retour suite à une étude menée sur le sujet, abordée dans l’optique d’avoir une solution à moindre coût notamment pour ressources d’une application iPhone.

Avec la démocratisation des moyens de diffusion d’information instantanés, allant de Facebook à Twitter, on assiste régulièrement au phénomène de buzz. Le phénomène existe depuis des années déjà et rejoint les problématiques rencontrées par tout site web qui connait un gain soudain de popularité. Celui-ci est encore plus vrai avec les applications pour smartphones : en moyenne, un mois après l’installation, seulement 15% des applications iPhone téléchargées sont encore utilisées : il est difficile de prévoir à l’avance le nombre de téléchargements et d’utilisateurs simultanés.

D’un point de vue technique, ce phénomène soulève plusieurs questions:

• Comment répondre à cette montée en charge imprévisible?
• Et si l’application proposée a un succès franc et durable, comment garantir des performances correctes pour tous les utilisateurs, quelle que soit leur localisation?
• Les entreprises ne sont pas forcément prêtes à investir dans des serveurs et/ou des hébergements dédiés supportant ces pics de fréquentation : comment pallier à ces problématiques rapidement et à moindre coût?

Depuis plusieurs années, les CDN offrent des réponses intéressantes en termes de performances pour la distribution de ressources statiques. Ces solutions sont largement utilisées par des acteurs tels que Youtube, Allociné, ou encore par des sites de presse tels que Le Parisien.

La nouveauté est que certaines de ces solutions deviennent aujourd’hui accessibles même pour des petites structures grâce à une facturation entièrement basée sur la consommation.

Why CDN?

Initialement, ces services répondent à une problématique simple :
une requête a un certain chemin à parcourir du navigateur au serveur d’un site, et la dernière partie de ce parcours est invariablement un chemin unique d’accès au serveur, ce qui peut engendrer un goulet d’étranglement.

De nombreuses solutions existent pour améliorer la disponibilité des sites web, que ce soit par exemple en augmentant les capacités des infrastructures, ou encore en optimisant son serveur HTTP avec des options de cache pour les fichiers statiques comme mod_cache sur un serveur Apache.

Les services CDN proposent de résoudre ces problèmes d’une autre manière, en rapprochant les ressources de l’utilisateur sur le réseau : plutôt que de disposer d’un point de service unique, on place un certain nombre de noeuds “à proximité” des utilisateurs finaux. Lors d’une requête pour accéder à une ressource, le service est alors à même de router la requête vers le noeud le plus proche contenant l’information. Ceci apporte deux avantages non négligeables :

• une amélioration des temps de réponse: par exemple le blog Octo met aujourd’hui beaucoup plus de temps à s’afficher depuis les USA que depuis Paris. Avec un CDN, on peut espérer avoir un temps de réponse plus uniforme quelle que soit l’origine de la requête.
• une garantie de haute disponibilité : la ressource est diffusée sur plusieurs noeuds supportant une forte montée en charge

Côté technique, le principe est similaire à l’utilisation d’un cache statique dans un ReverseProxy, et la recherche du meilleur noeud pour l’obtention d’un contenu s’appuie en général sur une résolution DNS.
Les principaux atouts d’un CDN sont ces possibilités de performances et de disponibilité, mais les raisons d’utiliser un CDN peuvent être diverses.
Un intérêt notable pour les sociétés souhaitant diffuser un contenu est la délégation technique du service, notamment pour des entreprises dont la diffusion de contenu n’est pas le coeur de métier. Ces services peuvent par exemple permettre de ne pas impacter un système existant, ou d’adresser des problèmes de fiabilité.

Le CDN accessible à tous

Historiquement, les services de CDN sont essentiellement utilisés par de gros acteurs du Web, notamment pour améliorer des services de streaming de médias. Ces services étaient en fait réservés à des diffuseurs de contenu de taille importante ou pour des utilisations massives, principalement en raison d’un coût élevé.
Mais on voit aujourd’hui apparaître des solutions comportant une offre avec un paiement entièrement à la consommation, qui ouvrent des perspectives intéressantes concernant notre problématique du buzz.

En effet, les CDN sont dédiés à la diffusion de ressources statiques, mais en adaptant une architecture applicative afin de générer des ressources statiques, la perspective d’un applicatif scalable et reactif s’offre a nous.

On peut alors très bien imaginer utiliser une solution CDN dans le cadre de la publication d’une application mobile, qui ne connaîtra peut être pas une fréquentation constante, mais potentiellement un ou plusieurs pics de fréquentation, par exemple lors de retombées dans la presse.

Panorama de quelques solutions de CDN

On peut globalement distinguer deux types de solutions :

• Des solutions clés en main
• Des solutions intégrées à des services de cloud computing, pour lesquelles il est en général nécessaire de réaliser quelques paramétrages et/ou développements

Voici quelques solutions de CDN du marché. Cette liste est loin d’être exhaustive et vise à donner un bref aperçu des conditions de ces services et de leurs tarifs pour une utilisation à petite échelle.

Solutions « clés en main »

Le service est fourni clés en main, il suffit globalement de paramétrer la configuration DNS du serveur à mettre en cache.
En moyenne, les prix de ces CDN ne sont pas publics, mais ils se caractérisent généralement par un prix forfaitaire à l’entrée, assorti d’un prix à la consommation. Plus les besoins sont importants, plus le prix d’entrée sera élevé, mais le prix à la consommation baissera en conséquence.
De manière générale, le marché des CDN connaît des variations importantes de prix, qui ont globalement tendance à être revus à la baisse au fil des années.

Akamai

Akamai est un fournisseur historique de CDN et un des plus gros acteur du secteur : la société possède 73 000 serveurs répartis dans 70 pays, et ferait transiter 15 à 20% du trafic internet quotidien par son service.

Ikoula

Ikoula est une société française d’hébergement qui propose notamment un CDN clé en main dans la même veine qu’Akamai.

Par contre, cette offre s’adresse plus particulièrement à la France et à l’Europe, étant donné que les datacenters utilisés sont exclusivement en France et qu’Ikoula possède son propre datacenter à Reims. Cet aspect est plutôt intéressant pour les clients français, que ce soit pour les avantages d’un support de proximité ou des questions d’ordre juridique sur la localisation de l’hébergement.

Solutions cloud

Ce type de service apporte tous les avantages du cloud computing :

• Élasticité : l’infrastructure s’adapte à la montée en charge
• Self-service : le client est totalement autonome, peut souscrire au service en ligne et y accéder quelques minutes plus tard
• Pay as you go : Facturation en fonction de la consommation réelle (processeur, stockage, trafic réseau)

L’avantage principal de ce type de service est qu’il ne comporte aucun prix forfaitaire. En contrepartie, quelques développements peuvent être nécessaires pour interfacer le CDN avec son serveur.
Le choix d’une telle solution soulève toutefois plusieurs problématiques inhérentes aux solutions de cloud computing :

• Quels changements pour la gouvernance du SI?
• Quels sont les risques juridiques?

Amazon CloudFront

Le panel de l’offre Cloud d’Amazon Web Services intègre un service de CDN appelé CloudFront, et permet de configurer directement un espace de stockage statique (buckets Amazon S3) pour le mettre en cache CDN. On peut facilement automatiser la mise en cache moyennant quelques développements.

Les données en cache CDN peuvent être réparties sur les différents datacenters Amazon, et peuvent être restreintes à l’Europe par un hébergement en Irlande.

Microsoft Azure CDN

La solution CDN de Microsoft est techniquement assez équivalente à CloudFront, mais propose la mise en place du CDN via un simple paramétrage.

L’hébergement peut être fait dans le monde entier, et plus spécifiquement en France dans un datacenter à Paris.

Tableau comparatif

Lorsqu’un CDN ne suffit pas

Dans un contexte où la distribution de contenu est vitale pour l’entreprise, l’utilisation de meta-CDN, tels que Cedexis, proposent d’améliorer la qualité de service en utilisant plusieurs CDN à la fois. Ceci apporte deux avantages non négligeables:

• en multipliant les réseaux de diffusion, on sécurise ce maillon de la chaîne
• les ressources sont diffusés en choisissant à chaque instant le CDN le plus disponible, ce qui permet de lisser les performances  globales.

Perspectives

Les services de CDN restent globalement adressés à des acteurs importants du Web, pour qui la diffusion de contenus volumineux et/ou en grand nombre est vitale.

Cependant les solutions de CDN facturées en Pay as you go ouvrent de nouvelles perspectives en permettant de déployer rapidement et à moindre coût des ressources statiques dans un cadre optimisé.

On peut donc facilement envisager d’héberger les ressources statiques ou des ressources dynamiques rendues statiques pour une petite application de smartphone sans pour autant exploser les coûts.

Suggestion d'articles :

1. Quelques perspectives pour 2011…

Pour tester des web services (REST/SOAP), je me suis demandé si je devais développer mon framework : des tests de contrats (tests des requêtes XML via un framework de test unitaire) et des  tests d’intégration (via Fitnesse/GreenPepper).
Pas forcément compliqué à mettre en place, mais rébarbatif et pouvant être sujet à erreurs (donc, d’éventuelles contraintes supplémentaires de maintenance).

Mes besoins : trouver un outil rapide à prendre en main et gratuit pour automatiser mes tests de web service. On m’avait parlé de soapUI, je voulais m’en faire une idée.

Dans cet article je vais, au travers d’un exemple, utiliser soapUI pour effectuer toutes les étapes nécessaires à l’élaboration de tests automatisés : tests unitaires de requêtes, tests fonctionnels, tests en intégration continue.
Nous allons donc mettre à l’épreuve soapUI dans le but de créer une suite de tests automatisés.

Note : il existe bien sûr d’autres outils permettant le test de web services (Rational Tester, SOATest, Visual Studio…) mais cet article ne se focalise que sur soapUI qui semblait se rapprocher de mes besoins (cités plus haut).

Notre exemple sera le développement d’un portail de banque en ligne. Nous allons nous intéresser aux fonctionnalités suivantes :

• Identification
• Récupération de la liste des comptes
• Diverses opérations sur un compte : dernières opérations, caractéristiques du compte…

On a un serveur web communiquant avec une interface web distante. L’identification à l’interface par l’utilisateur se fait en deux phases :

• L’utilisateur entre son identifiant et son adresse e-mail.
• L’utilisateur entre ensuite un code via un pavé numérique généré.

L’utilisateur doit entrer un code dans les espaces restant correspondant à son mot de passe. Les positions définies sont générées aléatoirement.

Voici la cinématique entre le client et le serveur :

Commençons notre projet soapUI :

Pour démarrer c’est très simple : il suffit de créer un projet soapUI et d’indiquer l’URL du WSDL (contrat) de notre première requête. SoapUI se charge de créer un squelette de requête selon la définition du contrat. Un pré-requis tout de même, le serveur exposant les WSDL doit être démarré.

La logique d’organisation de soapUI est similaire à celle d’un projet de développement : un projet contient plusieurs end-points (point d’accès à un service exposé) qui contiennent chacun une liste de requêtes.

Un test, puis un autre

Pour notre exemple, il y a 2 end-points et 2 requêtes : login et (validate) pin.
Démarrons avec la première requête : elle contient un identifiant et un e-mail. SoapUI charge la définition de la requête à partir du WSDL publié. On peut entrer nos valeurs pour voir la réponse du serveur.

On veut maintenant s’assurer que pour de faux identifiants, le noeud “Result” doit être à faux. SoapUI propose plusieurs types d’assertions sur les réponses : tester la valeur d’un noeud selon XPath, valider le schéma selon le WSDL…

Maintenant que nous avons nos tests sur la requête de login, nous pouvons faire la même chose sur la requête de validation du code pin.

On teste de manière unitaire les 2 requêtes. C’est intéressant pour détecter des régressions sur les contrats mais pas suffisant pour une couverture de test fonctionnel significative.

Tester un enchaînement d’actions utilisateur

L’enchaînement de requêtes va permettre de simuler un utilisateur.
Un Test Case soapUI (cas de test) exécute chaque requête qu’il contient. Plus généralement, un Test Case soapUI exécute chaque élément, appelés “étapes” (Step), séquentiellement. Une requête est une étape, une injection de propriété également :

Dans certains cas, une requête dépend de la réponse à la requête précédente. Pour illustrer, prenons l’exemple de l’achat d’un produit. La première requête est une recherche d’un produit. La deuxième requête est l’achat d’un produit. Pour enchaîner ces requêtes, nous devons récupérer l’identifiant du produit de la recherche pour l’utiliser dans la deuxième requête.

Certaines steps de soapUI permettent l’injection de paramètres entre les requêtes. Il est possible de sauvegarder des paramètres utilisables par des requêtes différentes (properties) et de passer des paramètres d’une requête à l’autre (property transfer).

Dans notre cas, l’utilisateur doit passer par les deux étapes d’identification. Le souci est que la deuxième étape dépend du résultat de la première.
Pour rappel, les positions pré-remplies du code pin -venant de la réponse de la première requête- sont générées aléatoirement.

Les “property step” ne permettent malheureusement pas de transformer des positions en code pin ! Pour résoudre ce problème, il faut retrousser ses manches et écrire des scripts Groovy permettant de manipuler les requêtes.

Ainsi, on peut initialiser une série de test par un script Groovy lisant du fichier plat (à tout hasard, au format CSV) puis injectant les données récupérées dans les requêtes.
On peut également variabiliser un end-point, des inputs… Tout pour éviter les paramètres en dur, freins à une automatisation efficace.

Avec un script Groovy permettant de traduire un ensemble de positions en portion de code pin, l’enchaînement des étapes se fait naturellement :

def tc = testRunner.testCase;
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )

// Récupérer le noeud de la réponse du login
def holder = groovyUtils.getXmlHolder( "Login - Login request OK#Response" )

// Récupérer la position du pin depuis la réponse
holder.namespaces["def"] = 'http://octo.com/exemple/definitions'
def pinPosition = holder.getNodeValue( "//def:Pinposition" ).split(',')

// Définition du code pin en dur
def pinNumberTable = [1, 0, 2, 0, 5, 4 ]

// Construction du pin à envoyer
def pin = ''
for ( position in pinPosition ) {
	pin += pinNumberTable.get(position.toInteger() - 1)
}

// Injecter le pin dans la requête au service PinPosition
holder = groovyUtils.getXmlHolder( "Pin - Pin OK#Request" )
holder.namespaces["def"] = 'http://octo.com/exemple/definitions'
holder.setNodeValue( "//def:Pin", pin )
holder.updateProperty()

Notre test case est maintenant un enchaînement de requêtes que l’on peut exécuter manuellement.

Tu me passes ton cas de test ?

Une étape de plus vers le gain de productivité : la réutilisation de cas de test.

Cette fois, on entre dans la logique de design de nos cas de tests. Tout comme du code, les cas de tests soapUI doivent suivre une architecture modulaire pour éviter les duplications.

Reprenons notre exemple. Nous avons donc nos services d’identification (login + validation du pin). Nous voulons maintenant tester la récupération de la liste des comptes ainsi que la récupération du détail d’un des comptes (type de compte, plafond de retrait, autorisation de découvert, etc…).
Suivant le même modèle, on crée un cas de test ayant les requêtes suivantes :

• Login
• Pin
• GetListeDeComptes
• GetCompteDetail

On garde entre les deux premières requête notre script Groovy. On utilise aussi une Property Step pour récupérer, via XPath, un numéro de compte parmi ceux de la liste (GetListeDeComptes) qu’on injecte à la requête GetCompteDetail.

Maintenant, on veut consulter les dernières opérations d’un compte :

• Login
• Pin
• GetListeDeComptes
• GetDernieresOperations

Idem pour la liste des cartes associées a un compte… Bref, on voit que la duplication des 3 premières requêtes se fait sentir !

Plutôt que de réécrire les trois premières requêtes (login, pin, liste des comptes + la Property Step injectant le numéro d’un compte) pour les deux nouveaux cas de tests, créons un cas de test « récupérer un numéro compte depuis une liste ».

Ce cas de test sera ensuite réutilisé dans les cas « DetailCompte » et « DernieresOperations ». SoapUI permet de faire cela de deux manières :

• Graphiquement : en utilisant l’étape « Run TestCase ». Cette étape permet de démarrer un autre cas de test présent dans le projet, de lui affecter des valeurs par défaut et de récupérer des valeurs de sorties. Personnellement, je n’ai pas réussi à faire cela dans la version gratuite…
• Avec un script Groovy : en invoquant un cas de test du projet et en lui donnant des propriétés (Property Step)

On a rendu notre suite de tests modulaire !

Et maintenant, sans les mains !

L’étape supérieure dans l’automatisation est la suppression de l’exécution manuelle des scénarios de test.
soapUI est livré avec un script, testrunner, pour exécuter les tests d’un projet soapUI en ligne de commande.
En environnement .NET, on peut donc faire sa tâche MSBuild de test de web-services dans son intégration continue qui lance le projet soapUI avec testrunner et parse l’output.

Côté JAVA, il existe un plugin Maven pour soapUI. Démonstration par ce morceau de pom :

    eviware
    maven-soapui-plugin
    3.5.1
    
../../../Blog/BlogOcto-soapui-project.xml
true
    
    
        
            soapui-test
integration-test
            
                test
            
        
        

Ceci est à compléter par des tâches pre/post phase servant à démarrer votre serveur d’application préféré pour tester les services.

Pour aller plus loin

En plus des tests de recette, il est possible de faire du test de charge. On peut choisir un use-case à dérouler selon un nombre défini d’utilisateurs simultanés (possibilité d’inclure de la latence).

Si l’on travaille en contract-first (on fixe les contrats WSDL puis on implémente), plutôt que de partager uniquement les WSDL, il est possible de mocker les réponses. Cela permet également de partager un projet soapUI (très utile en approche contract-first).

On peut même imaginer une interface web type Fitnesse pour définir des jeux de données d’entrée aux cas de tests en modifiant le projet soapUI (les projets sont sauvegardés en format XML) ou en générant des fichiers parsés par des scripts Groovy dans le projet soapUI.

Version pro ou version gratuite ?

En projet, j’ai pu constater que la version gratuite me suffisait largement.

Les différences entre la version pro et la version basique se font principalement sur l’aide à l’utilisateur. En effet, la version pro apporte en plus des outils d’aide aux tests : aide XPath, templates de code Groovy, gestion des données externes via IHM (au lieu d’utiliser des scripts Groovy)…

Tout ce qu’apporte la version pro est faisable en version gratuite mais en plus « geek » !

Verdict ?

Pour conclure, soapUI m’a été d’une grande aide pour :

• Enchaîner des requêtes.
• Tester la validité des requêtes selon les WSDL.
• Tester la non-régression en intégration continue.

L’utilisation des scripts Groovy est un plus pour appliquer des règles de gestion entre des requêtes.

Tout cet article est applicable sorti de l’exemple « Hello World ! ». En effet, l’exemple cité était la version simple de ce que j’ai croisé en réalité : les positions et le code pin devaient être encryptés, les deux étapes d’identifications permettaient de générer un hash servant de token d’authentification pour les autres requêtes.

La grande question : est-ce que j’aurai pu faire sans ? Dans mon écosystème geek, la réponse est oui. J’ai effectivement gagné beaucoup de temps mais j’ai perdu en intégration avec mon environnement de développement local (en JAVA notamment, même si soapUI s’intègre avec quelques IDE). J’ai utilisé soapUI en complément de tests unitaires

Dans un contexte plus réaliste, avec des MOA et/ou partenaires impliqués sur le projet (c’était évidemment mon cas), il est très difficile de s’en passer pour les raisons suivantes :

• Partager les suites de test entre les développeurs/projets/MOA/[insérez votre interlocuteur].
• Mocker les réponses pour tester les contrats pour le cas de développement avec un partenaire.
• Tester indépendamment d’un Eclipse ou d’un Visual Studio (casser la dépendance MSUnit/jUnit/[insérez votre framework de test]

Deux liens pour continuer vous-même :

• Le site de soapUI avec des tutos et de la doc : http://www.soapui.org/
• La doc de Groovy pour être le roi du script : http://groovy.codehaus.org/Documentation

Suggestion d'articles :

1. « Behavior Driven Development » grâce au pattern MVVM et GreenPepper
2. Versioning des services: principes et éléments d’architecture…
3. Tests unitaires et tests d’interface sur iPhone : État des lieux

Nos DSI pensaient avoir passé un cap en mettant en place des infrastructures de site web client, boutique en ligne, support… Ca a été difficile, notamment pour rendre disponible sur des applications Internet des services de coeur de SI, qui n’avaient pas du tout été conçus dans cette logique, mais au moins on espérait en avoir fini avec les remises en cause.

Et bien non: les tablettes tactiles arrivent, iPad, tablettes Android, etc., y compris en B2B, et elles vont changer certains des métiers, dont la vente et la distribution. Et comme les applications Internet, elles vont poser de nouvelles difficultés en nécessitant un accès selon de nouvelles modalités à des services parfois (souvent) profondément enfouis dans nos systèmes d’information.

Pourquoi?

Partons d’une autre question: Pourquoi les applications iPhone sont-elle majoritairement agréables à utiliser et ont-elles contribué notablement au succès de ces smartphones?

Si je peux avancer une réponse, ce serait parce qu’elles partagent une charte ergonomique stricte et qu’elles sont construite autour de certains modes d’interaction. Ces modes d’interaction sont intuitifs, mais limités, et les applications sont conçues autour de cette limite. Elles sont également conçues autour des cas d’utilisation spécifiques les plus courants: les use cases d’un smartphone sont différents de ceux d’un PC. On va par exemple utiliser un PC pour réserver un billet d’avion, alors que le smartphone va permettre de s’enquérir des horaires, des retards et de s’enregistrer.

La même dichotomie se retrouve sur les tablettes tactiles vs les applications pour PC, même sur des applications d’entreprise. Imaginons un système de vente, permettant de réaliser une souscription de téléphonie mobile, un upgrade de forfait, un changement de mobile… Le cas d’usage de l’application sur PC est celui d’un opérateur en centre d’appel ou en agence, qui a déjà réalisé le dialogue avec son client et passe à la phase administrative, assis à son poste, alors que le client attend. La phase intense d’échange avec le client est plus ou moins terminée, les choix sont faits.

La même application sur tablette aura une autre orientation: elle va pouvoir être utilisée dès le début de la vente, alors que les choix ne sont pas réalisés. Le vendeur est en proximité physique avec le client, il dialogue avec lui et la tablette est une aide pour ce dialogue, y compris pour le client lui-même qui la voit et interagit avec. Le vendeur peut comparer des terminaux, tester la couverture, montrer des options, choisir des offres… Il n’est pas concentré sur son interaction avec son ordinateur, mais sur celle avec son client.

Du coup, il apparaît que l’application qui justifie d’introduire une tablette tactile en distribution ne peut pas être un simple portage technique, mais demande une réécriture avec une logique d’interaction différente. Reformater les écrans d’une application Web ou d’un portail donnant accès à plusieurs applications conçues pour un PC ne suffit pas. Il faut tout repenser en partant des cas d’utilisation les plus importants, en utilisant la grammaire d’interactions de la tablette et en veillant à ne pas détourner l’utilisateur du dialogue avec son client. Ceci implique alors d’accéder aux données et aux services du système d’information d’une manière différente des application traditionnelles, parce que la logique différente de l’application tablette et les contraintes techniques de la tablette impliquent des services et modalités d’accès nouveaux.

Alors, que faire?

Nous pouvons nous inspirer des démarches mises en oeuvre pour créer des applications Internet. On considère les applications Internet comme mouvantes, multiples, parfois jetables, parfois même non issues de l’entreprise mais réalisées par des tiers. Elles doivent pouvoir être réalisées rapidement avec une expertise spécifique, mais sans devoir à chaque fois affronter la complexité du système d’information et sa dette technique.

Pour ce faire, on mettait en place des couches de services spécifiques, isolant cette galaxie d’applications légères et agiles de la complexité du coeur de système d’information. Je propose de suivre une même démarche pour les applications tablettes, en mettant en place une couche de services adaptés à leurs besoins spécifiques, intégrant des services métiers, et peut-être des services techniques partagés.

En plus des cas d’utilisation spécifiques, quelles contraintes techniques nouvelles? Nous pouvons citer:

• des protocoles légers (REST / JSON par exemple), parce que la bande passante et la capacité de traitement du terminal « tablette » sont plus limitées que sur un PC;
• un écran = un service, parce que la fluidité de l’interaction est primordiale, et que la capacité du terminal est limitée;
• des données simples, parce que l’utilisateur doit rapidement s’y retrouver et que le terminal tablette ne doit pas avoir à réaliser de conversion de données complexes (pas de modèle pivot trop riche!).

Comment créer cette couche de service?

Ne pas la créer: la faire émerger. S’inspirer de l’excellente session de l’USI 2009 de mes camarades Benoît Guillou et Dominique Jocal. L’essence est d’utiliser deux patterns de définition de service:

• au départ, un service est créé pour une application, sans préoccupation de réutilisation. Il est défini par un contrat entre un client et un fournisseur, qui repose sur sa signature et le cas d’utilisation de ce client. On a un pattern « consumer contract », ou « contrat client », où on ne se préoccupe pas de réutilisation, seulement d’adéquation avec un besoin. On respecte néanmoins les bonnes pratiques d’implémentation des services (nommage, granularité, gestion d’états…) et de développement;
• lorsque des services similaires sont nécessaires pour plusieurs clients (au moins trois!), on peut envisager une mutualisation et mettre en place un pattern « consumer-driven contract ». Le contrat de service lie un fournisseur et plusieurs clients. Il repose sur la signature de service et la somme des cas d’utilisation par les clients.

Pourquoi ces patterns? Ils rendent les services facilement testables, et transparents d’utilisation. Le service respecte le contrat s’il passe une somme de tests d’utilisation. On favorise ainsi une approche de développement et de design reposant sur les tests, cruciale pour sécuriser un service qui doit être d’autant plus fiable qu’il est utilisé en plusieurs endroits, et donc susceptible de générer plus de perturbations s’il dysfonctionne.

En synthèse?

Les tablettes arrivent, préparons-nous à en tirer partie, pour la satisfaction de nos clients et de nos salariés. Elles nous offrent l’occasion de tirer partie des enseignements collectés sur les applications Internet pour accélérer le développement d’applications utiles, performantes et agréables. Elles vont enfin nous permettre de construire des infrastructures SOA pragmatiques, dans un modèle adaptable (possibilité de réagir rapidement par rapport aux besoins nouveaux) plutôt qu’adapté (couvrant parfaitement un besoin – réel ou théorique – tel que compris à un instant donné). Ne nous en privons pas!

Suggestion d'articles :

1. SCA, quel apport pour la SOA?

… la suite du billet précédent Un guide pratique en 10 questions (2/3)

6 ) Comment faciliter la réutilisation d’un service?

5 principales actions peuvent être envisagées pour faciliter et favoriser la réutilisation des services :
1) Prévoir un référentiel pour regrouper et décrire tous les contrats d’interface existants: Il n’y pas d’outil idéal. Selon le nombre de services et le budget dont on dispose, les solutions suivantes peuvent être envisagées :

– Un simple gestionnaire de contenu (de type wiki): généralement utilisé pour regrouper la description de tous les contrats de services et utilisé en phase de développement.

– Un UDDI (Universal Description Discovery and Integration) : même si la valeur ajoutée de ces solutions reste à prouver, ils peuvent être utilisées comme « repository » de services en phase de développement, ou comme « registry » en phase d’exécution (runtime).

2) Prévoir un dictionnaire de synonymes pour l’entreprise pour faciliter la réutilisation des services entre les différentes entités : Parfois, la description des champs des contrats d’interface n’est pas forcément compréhensible à toutes les entités de l’entreprise, ce qui peut avoir un impact sur la compréhension du contrat et par conséquent sur sa réutilisation.

3) Faciliter la testabilité du service : Fournir une plateforme de tests des services permet de rendre les services plus accessibles pour le client en lui permettant de bien valider son adéquation avec ses besoins en toute autonomie.

4) Prévoir plusieurs niveaux de traçabilité (Ex : DEBUG, INFO, etc.) activables et désactivables selon le besoin (en développement ou en exploitation) : Cela permet d’effectuer des analyses approfondies en cas de problèmes et d’augmenter le degré de confiance du ré-utilisateur du service.

5) Communiquer, communiquer et communiquer autour des services existants, et partager les expériences.

7 ) Comment gérer le cycle de vie d’un service
L’article suivant traite cette problématique avec les principes d’architecture qui lui sont associés: Versioning des services : principes et éléments d’architecture…

8 ) Quel style architectural choisir ? (SOAP-RPC ou REST ?)
Le tableau suivant synthétise, selon les cas d’utilisation, le style architectural adéquat:

(Pour plus de lisibilité, merci de cliquer sur le tableau)

9 ) Comment sécuriser les Web services ?
Deux modes de sécurisation des web services existent:
- Sécurisation applicative : en implémentant des mécanismes d’authentification des clients par le fournisseur de service ou en s’appuyant sur des standards, comme la stack WS-Security, WS-Trust, etc.
- Sécurisation Hardware : par le déploiement de boîtiers réseaux (exemple WebSphere DataPower) qui permettent notamment de:

– Virtualiser les services : masquer les ressources d’arrière-plan afin de cacher les structures internes
- Jouer le rôle d’un firewall en filtrant le contenu XML selon des règles pré-configurées
- Implémenter XML encryption et digital signature
- Contrôler l’accès aux services web
- Valider les données par rapport à des schémas XML et protège les application des attaques DoS (Denial of Service)

10) …et pour conclure?
Au delà de ce guide pratique, il est important de prendre en considération les aspects organisationnels et de gouvernance des services, sujets sur lesquels on s’étalera dans d’autres articles. La conjugaison de tous ces facteurs fait qu’on réussisse ou pas la mise en œuvre d’une plateforme de services.

Suggestion d'articles :

1. Réussir votre SOA : Un guide pratique en 10 questions (2/3)
2. Réussir votre SOA : Un guide pratique en 10 questions (1/3)
3. Le tour des ESB en 10 questions

Les entreprises qui ont fait le pari de l’externalisation ont de plus en plus d’applications sur Internet. S’ajoutant à cela la nécessité stratégique de pouvoir s’interfacer toujours plus vite avec d’autres partenaires, de nouveaux besoins d’intégration sont apparus:

• la continuité de l’information entre SI interne et Cloud (scénarios SI2Cloud et Cloud2SI)
• la continuité de l’information entre applications sur le Cloud (scénarios Cloud2Cloud)

Le besoin de continuité entre SI interne et Cloud ravive d’anciennes problématiques. Les principaux freins ont été jusque là:

• la réticence au changement (manque de confiance dans le Cloud, crainte de perdre le contrôle des données)
• le risque encouru en exposant davantage le réseau de l’entreprise (ouvertures de ports supplémentaires sur le firewall)
• le manque de visibilité des adresses IP internes depuis le Cloud (contrainte du NAT, mécanisme IPV4 de passage du réseau public au réseau privé)

Face à ces défis nouveaux et anciens, l’intégration d’applications sur le Cloud est en pleine émergence. Tâchons dans cet article d’appréhender les différentes technologies d’intégration disponibles et leurs écueils, et d’identifier les tendances pour les années à venir.

SI2Cloud & Cloud2Cloud

Les éditeurs de SaaS proposent un interfaçage plus ou moins riche avec leurs solutions. Cela va de la simple exposition de services web pour les petits éditeurs, à la couche d’intégration complète de SAP (SAP Information Interchange), en passant par le moteur de workflow de Salesforce.com. Dans de nombreux cas, ces modules d’intégration se suffisent à eux-mêmes, mais sont indissociables de la solution SaaS en question. Ils sont particulièrement appropriés pour des échanges SI2Cloud (à l’initiative du SI interne) où les contraintes de sécurité sont négligeables, puisqu’il n’est pas nécessaire d’exposer davantage l’entreprise sur le réseau public.

Des spécialistes comme RunMyProcess et Cast Iron poussent leur offre d’intégration Cloud2Cloud. L’achat d’une solution standalone et propriétaire pour couvrir ce seul scénario ne semble pas pertinente, dans la mesure où les solutions SaaS exposent et consomment déjà des services web, voire embarquent un moteur de workflow. C’est la simplicité d’utilisation de ces solutions que l’on appréciera ici, ainsi que l’outillage pour le design et le monitoring des échanges. Leur côté très démocratique et l’implémentation complète des flux par paramétrage en font plutôt des solutions SaaS.

Aucune de ces solutions SaaS ne permet de passer outre les contraintes de sécurité du SI, ni d’accéder directement aux ressources internes de l’entreprise. La problématique des échanges Cloud2SI (à l’initiative du Cloud) reste entière.

Internet Service Bus

Le concept embryonnaire d’Internet Service Bus (ISB) ne ressemble pas à un serveur d’échange classique tel qu’un EAI, un ESB ou tout autre middleware. L’ISB se situe au niveau PaaS et à pour vocation de relayer des messages sur Internet au travers de protocoles rudimentaires comme TCP et HTTP; que les échanges soient à l’initiative du Cloud ou du SI interne. C’est tout du moins la définition que je vous en propose.

La motivation première qui a conduit aux solutions Linxter ISB, Microsoft Azure AppFabric, ou encore Amazon Simple Queue Service, est la difficulté et la réticence des entreprises à ouvrir leur réseau interne, empêchant les échanges Cloud2SI. En initiant lui-même la connexion, le service lève ici les problématiques de NAT et de firewall:

Les ISB de Linxter et Microsoft sont très proches, puisque tous deux reposent sur Windows Communication Foundation. Ils permettent la négociation automatique du protocole approprié (HTTP ou TCP) et, sur le modèle des réseaux Peer2Peer, d’établir une connexion directe entre client et service. La plupart des ISB proposent également le queuing de messages.

Pour assurer la continuité entre SI et Cloud, l’ISB peut aussi être employé comme une extension du serveur d’échange interne. C’est typiquement la stratégie Software + Services de Microsoft.

Dans ce cas, c’est l’intégration native entre l’ESB et l’ISB qui permet de passer au travers du firewall et du NAT. Une seule liaison permanente et bidirectionnelle relie les deux serveurs d’échanges, permettant ainsi aux applications internes et aux applications sur le Cloud de communiquer librement.

Les ISB sont bâtis sur un modèle d’architecture distribuée à base d’API propriétaires, couplant très fortement les systèmes. En outre, là où les serveurs d’échange actuels ont atteint de très bons niveaux de maturité, les ISB sont pauvres en terme de fonctionnalités d’intégration, ce qui ne permet pas de couvrir les scénarios Cloud2Cloud:

• Pas de mécanisme de transformation
• Connectivité réduite au strict minimum
• Pas de couplage lâche producteur/consommateur

Integration as usual

Les fonctionnalités nécessaires à l’intégration d’applications Cloud2Cloud sont peu ou prou les mêmes qu’à l’intérieur de l’entreprise: la connectivité technique, le mapping de données, les différents patterns d’échange, etc. Pourquoi alors ne pas héberger son ESB de prédilection directement sur une plateforme d’IaaS comme Amazon Virtual Private Cloud ?

Par ailleurs l’arrivée progressive de l’IPV6 ne bouleversera pas la manière de gérer la sécurité dans les DSI. Celles-ci seront toujours aussi réticentes à s’exposer sur le réseau public. Quelle que soit la technologie retenue, un pont logiciel prenant la forme d’un flux technique générique s’avère nécessaire entre plateforme d’intégration interne et externe. L’approche ESB prend tout son sens au travers d’une architecture hybride de ce type:

Il faut interfacer un nombre critique d’applications sur le Cloud pour justifier d’une telle architecture. La charge de travail sur un ESB et le traffic réseau étant relativement constants – au moins étalés – l’approche IaaS pourrait être économiquement peu avantageuse. C’est pourtant à mon sens la seule solution qui couvre aujourd’hui tous les scénarios Cloud2SI, SI2Cloud et Cloud2Cloud. Cette approche présente un autre avantage de taille: offrir une bonne évolutivité en cas d’externalisation et de rapatriement de services applicatifs.

Et pour demain

La notion d’ISB reste à préciser. Fort est à parier que les éditeurs ne tarderont pas à se positionner davantage sur ce segment; mais probablement pas sur ce modèle de connecteurs propriétaires qui va à l’encontre de l’esprit même du Cloud Computing. L’ISB a un rôle essentiel dans l’Internet des Objets, où l’un des enjeux est de structurer un très grand nombre d’échanges de données, depuis et vers le Cloud. Au lieu d’API propriétaires les ISB devraient reposer uniquement sur des standards, qui restent à définir. Pour convaincre les entreprises et toucher l’informatique de gestion, les ISB devront s’enrichir de nouvelles fonctionnalités. L’approche IaaS semble pour l’instant plus pérenne. Faut-il alors attendre plusieurs années pour que les éditeurs d’ISB fournissent les mêmes fonctionnalités que les ESB conventionnels ? Il convient de choisir sa solution d’intégration en prenant en compte les scénarios d’intégration SI2Cloud, Cloud2SI ou Cloud2Cloud présents et à venir, la nature des applications à interfacer (SaaS, PaaS ou IaaS), et la maturité de l’entreprise en termes d’architecture d’échange.

Suggestion d'articles :

1. Déployer les applications .NET sur cloud
2. Intégration continue performante (Part #1)
3. Petit-déjeuner : Comment bâtir votre Cloud ? 15 novembre

… la suite du billet précédent Un guide pratique en 10 questions (1/3)

3) Qu’est-ce qui caractérise un service réussi ?

Idéalement un service devrait satisfaire les conditions suivantes:

- Réutilisable : Avoir plusieurs clients pour un même service
- Évolutif : Les besoins évoluent dans le temps. Il est important que le service soit conçu de telle manière à supporter, du moins, les modifications mineures
- Autoportant /explicite, nécessitant peu de documentation pour qu’il soit réutilisable
- Facilement testable par le client : autonomie du client à tester
- Respectant les contraintes requises de performance et de montée en charge

Des services respectant ces caractéristiques permettent à la DSI de disposer de services à forte valeur ajoutée permettant notamment à l’entreprise de :
- Réduire les coûts d’échanges inter-applications
- Accélérer la mise à disposition de nouvelles fonctionnalités aux utilisateurs

4) Quelles sont les meilleures pratiques pour bien architecturer une plateforme de services ?
Afin de garantir une bonne qualité de service, les principes architecturaux suivants sont à prendre en considération:

Réduire le nombre d’étages inclus dans la composition de service
Idéalement, il faut tabler sur 2 niveaux de composition de services (Maximum trois niveaux si on a des processus à gérer). Cela permet d’éviter le problème de dépendance en termes de qualité de service à travers les différents niveaux de composition et de réduire la complexité de gestion des versions des services impliqués dans la composition du service (cf. Versioning des services: principes et éléments d’architecture…).

Bien cibler le porteur de la composition
La composition de service peut être portée soit par le consommateur du service, soit par le fournisseur de service pour proposer un service de plus forte valeur ajoutée:
- Si les consommateurs présentent des besoins différents : c’est à la charge de chaque consommateur de composer le service dont il a besoin.
- Si les consommateurs partagent les mêmes besoins : dans ce cas, la composition est à implémenter par le fournisseur de service

Pouvoir absorber la montée en charge en termes de sollicitation d’un service
Un service/une plateforme de services qui n’implémente pas les bonnes pratiques pour gérer les montées en charge peut avoir un lourd impact sur la bonne exécution et la réutilisation du service à terme. Techniquement, des leviers architecturaux et des bonnes pratiques de conception doivent être prévus. Par exemple, la mise en place d’une couche de « Queuing » entre le fournisseur et le consommateur de service pour persister les requêtes des clients et lisser la charge pour le fournisseur de service. Une bonne pratique serait par exemple de débloquer les « threads » de traitement au niveau fournisseur en gérant des « time-out » quand aucune réponse ne peut être renvoyée à temps, etc.

5) Comment bien concevoir un service?

Qualifier un service

Ci-dessous une liste préalable de questions pour qualifier un service :
- Quels sont les bénéficiaires potentiels du service (interne, partenaire, grand public)?

L’identification des types de bénéficiaires potentiels permet de cibler la bonne politique de gouvernance autour de la gestion du/des service(s):
- Pour des bénéficiaires internes à l’entreprise: la gouvernance du service est totalement interne à l’entreprise.
- Pour les partenaires externes, la gouvernance du service est partagée avec le partenaire. Dans ce cas, en tant que fournisseur de service, il faudra limiter les impacts et garantir au maximum une compatibilité ascendante des versions de service

Par ailleurs, la connaissance des bénéficiaires permet aussi de fixer le niveau de sécurisation des services et le choix de la politique qui convient le mieux

- Combien de clients potentiels seraient intéressés par le service?

Avoir une estimation du nombre de consommateurs à gérer permettra de positionner le curseur vis-à-vis de la généricité des contrats de service. Faut-il s’orienter vers un service le plus générique possible, ou bien proposer une offre de services pour répondre à des besoins bien particuliers ?

- Quelle qualité de service requise ?

La connaissance des contraintes de volumétrie, de performance et de disponibilité permet de prendre en considération, dans la conception du service, des bonnes orientations techniques et architecturales permettant d’atteindre la qualité de service requise.

Spécifier le service

Une fois la qualification faite, les points suivants sont à prendre en compte au moment de la spécification du service:
- Étudier la granularité du service pour disposer d’un meilleur compromis entre performance et modularité
- Couvrir un domaine métier donné de telle façon à proposer une cohérence entre les services, et éviter le recouvrement des fonctionnalités qu’ils proposent.

En d’autres termes, il faut éviter les services « couteau suisse », c’est à dire le service dont le contrat est tellement générique, que les objets qu’il traite n’ont aucune signification fonctionnelle.

La solution pourrait être de développer une « offre de services » autour d’un service principal qui traite un objet métier bien identifié. De point de vue pratique, les éléments ci-dessous orientent la bonne conception des services :
- Éviter le service qui manipule plusieurs objets métiers, c’est-à-dire la signification de l’objet dépend des paramètres renseignés dans la requête ou la réponse.

- Éviter les champs paramètres/valeurs. Typer plutôt les champs du service. Cette orientation permet à celui qui va l’utiliser d’être bien guidé sans se sentir obligé de parcourir les centaines de pages de spécifications.

- Si le protocole SOAP est choisi, décomposer le service en « operations » de telle façon que cela constitue un module homogène autour de l’objet métier manipulé.

- Penser à la distribution/diffusion du WSDL et son partage avec d’autres interlocuteurs qui auront à utiliser le service en question. Avoir plus de flexibilité dans la diffusion des services ainsi que leur maintenance.

- Distinguer le volet contractuel des formats de messages du contrat de service du volet transport (HTTP, JMS, SMTP, etc.)

- Prévoir des services stateless. Aucune context-session ne doit être gérée.

On distingue 2 types de services. Des services « applicatifs » constituant un émissaire applicatifs et correspondant plus ou moins à des services CRUD (Create, Read, Update, Delete) et des services de type « Processus ».

1) Services applicatifs
Ce sont des services qui portent sur des objets métier unitaires et qui permettent d’exécuter des actions de création, de suppression, de recherche et de vérification. Autour d’un service principal, l’idée serait de définir une offre de services pour couvrir un périmètre/domaine particulier.

Exemple de règle de nommage:
Une règle de nommage pour le service principal pourrait être : Une [action] + [objet métier]; avec [action] = put, set, update, create, delete, etc.
Exemple d’un service Principal : GetStock

Néanmoins, la granularité d’un objet métier est aussi importante, plusieurs variantes d’un objet peuvent en découler pour définir une offre de services:

Exemple d’offre de services:
Si on considère que le service principal « GetStock » couvre 80% des cas d’utilisation, une offre de services peut se traduire comme suit:

1) En considérant une granularité plus fine de l’objet métier.
Exemple:
- GetStockRetourClient: l’objet métier « StockRetourClient » est un sous-objet métier de stock
- Etc.

2) En appliquant un filtre sur le service principal.
Exemple:
- GetStockByReference
- Etc.

2) Services de type processus
Cette typologie de service englobe les services de plus grosse granularité, issus généralement de la composition de services de l’offre de services applicatifs.
- gererTournee
- gererPurchaseOrder
- Etc.

Suggestion d'articles :

1. Réussir votre SOA : Un guide pratique en 10 questions (3/3)
2. Réussir votre SOA : Un guide pratique en 10 questions (1/3)
3. Le tour des ESB en 10 questions

L’un des facteurs clé pour la réussite de la mise en place d’une architecture orientée services, c’est de parvenir à identifier et mettre en œuvre des services à forte valeur ajoutée. Cet article synthétise, sous forme de questions pratiques, les principaux éléments et concepts à considérer pour réussir cette transformation du SI.

Cet article sera publié en 3 parties :
Partie 1 – Questions 1 et 2
Partie 2 – Questions 3 à 5
Partie 3 – Questions 6 à 10

1) Qu’est-ce qu’un service ?
Dans le domaine informatique, un service est tout programme exposant une ou plusieurs fonctionnalités à des tierces applications en environnement distribué

2) Comment émergent les services ?
Pour qu’on puisse parler de service, il faut un client et un fournisseur de service.

Dans un processus « Bottom up », un service émerge d’une démarche « Push » initiée par un fournisseur ou « Pull » initiée par un consommateur.

Dans un processus « Top-down », il est la résultante d’une étude plus globale et systémique du SI ou d’un bloc du SI.

Processus Bottom-Up

- Processus « push» – par le fournisseur (Le fournisseur fournit un service le plus « générique » possible)

C’est une démarche initiée par un fournisseur qui expose un service et le propose à ses partenaires. Le fournisseur essaie de proposer un service le plus générique possible qui répond au besoin de tous ses partenaires (exemple : les services exposés par ViaMichelin, Amazon, Google, etc.)

- Processus « Pull» – par le client (Le client demande un service)

Cette démarche est initiée par un consommateur qui exprime le besoin pour un ou plusieurs service(s) lui permettant d’échanger avec des tierces applications. Dans ce cas, le fournisseur essaie de répondre au besoin du consommateur sans forcément prendre en compte des perspectives de réutilisation du service. Cela s’explique par le fait que ce genre de demande se conjugue généralement avec des impératifs « Time To market » imposés par le client du service.

Processus Top-Down (Le service est identifé)

Certains services de ce processus émergent d’une démarche d’urbanisation ou de refonte du SI. Le besoin d’échanges est préalablement étudié et une définition des services est proposée.

Il est vrai que cette démarche garantit une cohérence globale de l’ensemble des services, néanmoins, sa mise en place s’avère un challenge inintelligible dont les bénéfices sont loin d’être acquis.

Quelle démarche favoriser?
Dans l’absolu, il n’y a pas de démarche à favoriser en particulier. Les 3 peuvent co-exister selon le contexte et l’offre de services existante. Néanmoins, en phase de conception et de mise en œuvre du service, il est primordial de prendre en considération les points suivants:
1) Favoriser une démarche itérative et collaborative entre clients(s) et fournisseurs de services.

Pourquoi? Parce qu’un service est un processus dont le résultat ne préexiste pas à la demande du client, cela signifie que le client va devoir s’engager vis-à-vis d’un fournisseur avant que la service ne soit réalisée, c’est-à-dire avant qu’il puisse évaluer la qualité de ce résultat, puisque celle-ci ne pourra être évaluée qu’une fois le service réalisé. Ce décalage temporel entre l’engagement de la transaction client/fournisseur et la réalisation du service crée une situation d’incertitude. D’où l’importance des méthodologies de mise en œuvre projet concernant ce type de besoin.
2) Penser un service donné en tant qu’offre de services, plutôt qu’un mono-service qui essaie de répondre à tous les besoins
3) Ne pas considérer l’étude d’urbanisation, s’il y en avait une, comme une cible en elle même, mais plutôt comme un fil conducteur pour la cible.

Suggestion d'articles :

1. Réussir votre SOA : Un guide pratique en 10 questions (2/3)
2. Réussir votre SOA : Un guide pratique en 10 questions (3/3)
3. Le tour des ESB en 10 questions

OCTO sera présent à la table ronde organisée par CIO et Le Monde Informatique sur le thème SOA et Agilité mardi 6 Octobre à l’Automobile Club de France (Paris 8e). Le séminaire démarrera à 8:45 avec de nombreux intervenants, la table ronde aura elle lieu à 14h45.
En espérant vous voir nombreux, promis, nous irons au-delà des poncifs d’usage sur ce sujet …

Suggestion d'articles :

1. ERP et agilité
2. Petit-déjeuner « Agilité et ERP » avec le témoignage de Danone, le 22 mars

Depuis quelques années, on assiste à l’émergence de nouvelles solutions logicielles, dont le concept à la base est loin d’être nouveau, mais dont l’offre est de plus en plus riche et perfectionnée, à savoir, Complex Event Processing.

Alors de quoi s’agit-il ?

Complex Event Processing (CEP)?

Selon la définition fournie par EPTS (Event Process Technical Society) dans son glossaire publié fin 2008, Complexe Event Processing, (en français, traitement des événements complexes), est tout calcul/traitement exécutant des opérations sur des événements complexes tels que la lecture, la création, la transformation, l’abstraction des données portées par ces événements. En d’autres termes, Complex Event Processing traduit plus des concepts d’analyse d’événements porteurs d’informations prévenant de diverses sources de données que de solutions logicielles.

Inspiration et concepts

« Complex Event processing » a été développé vers le début des années 90. C’a été principalement utilisé par les plateformes de simulation en tout genre. Elle doit son inspiration aux concepts développés par Stephan H.Haechel dans son livre: «Adapative Entreprise». Le concept de base est traduit par le schéma suivant:

Deux dérivés conceptuels se distinguent:

- ESP (Event Stream Processing): traite des streams* d’événements ordonnés dans le temps
- CEP (Complex Event Processing): réfère à un processus de traitement d’événements qui assume avoir un Event Cloud* comme input, par conséquent, il n’y a aucune supposition quant à l’ordre d’arrivée des messages.

(*) Ces termes sont définis dans le paragraphe suivant

Un peu de vocabulaire…

EPTS a publié une première ébauche de glossaire regroupant l’ensemble des termes utilisés dans le domaine du CEP.

Le schéma suivant reprend les termes les plus importants extraits de ce glossaire:

Event stream (un flux d’événements): une séquence linéaire d’événements ordonnée par rapport à un axe temps.
Cette séquence peut:
- être bornée
- contenir des événements de différents types.

Event Cloud (un nuage d’événements): une séquence d’événements partiellement ordonnée dans le temps. La séquence est engendrée par des relations (entre les événements) autres que le temps. Typiquement, un event cloud :
- est créé par des événements produits par un ou plusieurs systèmes distribués
- peut inclure plusieurs types d’événements, plusieurs steams d’événements, etc.

Cela dit :
- Dans un cloud, il n’y a pas nécessairement de règles permettant d’ordonner les événements.
- Un Event Stream est un cloud, pas l’inverse.

Event source (une source d’événements): un système qui envoie des événements.

Event Sink (un collecteur d’événements): un système qui reçoit des événements

Event Channel (un canal d’événements): un conduit dans lequel les événements partent du système source au système cible.

Event processing Agent (un agent de traitement d’événements): un module logiciel qui traite les événements.

Complex event (un événement complexe): un événement traduisant une abstraction d’autres événements. Exemple: une transaction en ligne est une abstraction de plusieurs événements (dépôt de l’article dans le panier, saisie d’un code réduction, saisie du n° de la carte bancaire, etc.)

Composite event (un événement composé): un événement construit par combinaison de plusieurs événements utilisant des constructeurs d’événements particuliers, comme une conjonction, disjonction, etc.

Rule (une règle): règle de traitement de l’événement

Window (une fenêtre): une portion de stream d’événements bornée

Event template (gabarit d’événement): Traduit un descriptif de l’événement dont les paramètres sont des variables.

Domaines d’application

Complex Event Processing, en tant que concept, répond à tout besoin exigeant en termes de traçabilité, réactivité, disponibilité et prise de décision. La complexité de mise en œuvre réside dans la définition d’algorithmes de calcul et de corrélation performants ainsi que de processus et règles métiers optimisés.

Les domaines d’application sont divers et variés. Ci-dessous quelques exemples:

• Traçabilité par le biais de puces RFID
– Exemple 1: Fiabilisation de la traçabilité d’objets dans une chaîne logistique
– Exemple 2: Traçabilité des bagages dans un aéroport entre le dépôt à l’enregistrement par le voyageur et le chargement dans l’avion

• Problématiques financières et boursières
– Exemple : Détection des « Microcap stock fraud » (**).

• Optimisation de tournées de flottes de véhicule
– Optimisation en temps réel de tournées de flotte par corrélation de positions GPS et état du trafic

• Supervision technique des plateformes
– Exemple : Traitement des alertes SNMP remontées par les composants logiciels et les serveurs

• Business Activity Monitoring (BAM)

• Sécurité des systèmes d’information par corrélation d’événements.

(**) Combine connue dans le domaine boursier et utilisée par les fraudeurs pour manipuler le cours des actions.

Panorama des solutions logicielles du marché

Depuis quelques années, on assiste à l’intérêt grandissant des acteurs majeurs de l’édition logicielle pour le Complex Event Processing, après avoir été réservé à une niche d’éditeurs dans le domaine « trading».

Les solutions du marché proposent l’outillage nécessaire pour l’implémentation des concepts inhérents à l’ESP et/ou CEP. On désigne Intelligent Event Processing (IEP) les solutions implémentant les 2 concepts.

Le schéma suivant trace l’évolution des solutions du marché (inspiré d’un post de Paul Vincent sur le blog Tibco et mis à jour):

CEP dans la jungle des solutions

Les solutions CEP peuvent être intégrées soit dans un périmètre applicatif (utilisation de frameworks comme Esper ou NEsper) ou positionnées comme un module transverse recueillant l’ensemble des événements provenant d’applications diverses du SI (par exemple, intégrées à une plateforme d’échanges transverse entreprise à base d’ESB).

Par rapport aux solutions existantes, de type BPM, BI ou autres, les solutions CEP se caractérisent par :
- Un traitement continu d’une masse considérable (plusieurs centaines de milliers par seconde) d’événements provenant de sources d’information différentes
- D’un besoin de prise de décision en temps réel par rapport à un ensemble d’événements quelconque surgissant dans une fenêtre temporelle définie. (de quelques secondes, à quelques heures, voire quelques jours)

C’est pour cette raison que ces solutions logicielles ne sont pas positionnées comme des solutions concurrentes, plutôt, complémentaires:
- CEP, BI: solutions d’optimisation du business
- BPM, workflow: solutions de gestion des processus
- ESB/EAI: solution d’infrastructure logicielle
- Serveurs physiques, virtualisation: solutions d’infrastructure physique

Quelles perspectives?

On peut dire aujourd’hui que les solutions existantes sont au stade de la « croissance » et dépassent largement l’écosystème «trading» financier, historiquement connues pour. L’évolution et l’adaptation de ce genre de solution sur les prochaines années sera rapide. Selon IDC, ce marché représente 140M$ aujourd’hui et 800M$ en 2012.

Plusieurs initiatives autour de CEP ont été lancées. On note celle la plus significative qui concerne la définition d’un event metaModel portée par OMG.

Cet article sera suivi par un deuxième présentant un outil du marché ainsi qu’une implémentation d’un cas d’utilisation.

Suggestion d'articles :

1. Complex Event Processing
2. Complex Event Processing avec Esper
3. L’analyse décisionnelle en temps réel Convergence entre Big Data et Complex Event Processing