Sortie de Tibco AMX BPM

J’ai pu récemment assister à une présentation du nouvel outil BPM de Tibco, AMX BPM, qui est la troisième génération de moteur BPM de l’éditeur et vient succéder à IProcess.

Tibco AMX BPM n’est pas une simple évolution de IProcess, mais un produit nouveau dont l’ensemble du runtime a été redéveloppé afin de palier les manques de l’offre IProcess. Continue reading ‘Sortie de Tibco AMX BPM’

Politique de mots de passe des annuaires LDAP

Politique de mots de passe des annuaires LDAP

Un annuaire LDAP, qu’il soit un produit d’éditeur ou une solution open source, est aujourd’hui compatible LDAP V3.

Comme la norme n’est jamais suffisante pour les besoins des entreprises les plus exigeantes, certains éditeurs proposent des fonctionnalités supplémentaires comme des politiques de mots de passe évoluées, implémentées directement dans l’annuaire LDAP. Continue reading ‘Politique de mots de passe des annuaires LDAP’

SQLI Consulting rejoint Alcyonix

SQLI Consulting rejoint la marque Alcyonix, spécialiste de l’amélioration des processus. Ce rapprochement permet de compléter  l’offre actuelle avec une nouvelle practice dédiée à l’Architecture d’Entreprise.

Le nouvel ensemble ainsi formé adresse l’ensemble des besoins des DSI : stratégie et gouvernance IT, amélioration des processus et architecture du système d’information.

Alcyonix devient ainsi le cabinet de conseil du groupe SQLI avec des implantations en France, en Suisse, au Canada et au Maroc.

SQLI Consulting déménage

Nous avons le plaisir d’annoncer le déménagement de l’équipe parisienne de SQLI Consulting dans le 16ème arrondissement, en plein cœur de Paris et à 5 minutes de la place de l’Etoile.

Nos nouvelles coordonnées sont :

111 Av Victor Hugo
75116 Paris

Tél : 01 45 05 31 36

Pour nous rejoindre en transport en commun :

  • RER A : Station Charles-de-Gaulle Etoile
  • Métro Ligne 2 : Station Victor-Hugo

Pour nous rejoindre en voiture :

  • Parking public place Victor-Hugo

Continue reading ‘SQLI Consulting déménage’

Spring Integration – Apache Camel

Cet article fait suite à la présentation des frameworks d’intégration Java et propose un survol des deux solutions les plus en vue aujourd’hui : Spring Integration (Spring SI) et Apache Camel.

Il n’a pas la prétention d’être exhaustif en terme de couverture des fonctionnalités proposées par les produits et n’est pas issu d’un réel retour d’expérience s’appuyant sur les deux frameworks. L’idée est plutôt d’évaluer de manière qualitative et objective ce que propose chacun des candidats sur différents axes permettant de connaître leur positionnement relatif. Continue reading ‘Spring Integration – Apache Camel’

Shibboleth – présentation

Logo Shibboleth

À l’origine, le mot hébreu Shibboleth permettait à un peuple de distinguer ses ennemis, incapables de le prononcer correctement. Grâce à ce mot, une confiance pouvait être établie au sein d’une population bien définie.

Aujourd’hui, Shibboleth désigne un logiciel open source, du consortium Internet 2, qui établit de la même manière une relation de confiance entre entités bien définies et identifiées. Il assure un accès filtré et sécurisé, aux ressources de ces entités, limité uniquement aux membres de ces mêmes entités.

Shibboleth, dans sa version 2, se place ainsi comme le logiciel open source de référence de fédération d’identité qui supporte la norme SAML 2.0. Continue reading ‘Shibboleth – présentation’

Offrez-vous une balade en V6 !

Brian Chan, l’architecte en chef de Liferay, nous l’annonçait au début du mois sur son blog, une avant-première de Liferay 6 est désormais disponible au téléchargement : de quoi patienter un peu avant la sortie de la version officielle prévue courant avril !

Les plus assidus pourront mesurer au jour le jour le chemin parcouru en construisant régulièrement une distribution à partir du trunk du SVN publique de Liferay,  comme l’explique Ed Shin sur son blog. Continue reading ‘Offrez-vous une balade en V6 !’

Livre « Le poste de travail Web »

Le groupe SQLI annonce la sortie de son dernier livre co-écrit par les équipes de SQLI Consulting et SQLI Agency.
Cet ouvrage a pour ambition de traiter à la fois les concepts de poste de travail, de situation de travail ou d’activité interactive et les aspects pratiques de la mise en oeuvre au travers de retours d’expérience et de recommandations. Il aborde également des questions techniques et ergonomiques que soulève inévitablement la mise en oeuvre d’un portail.

L’intégration Java "à la légère"

L’avènement des ESB sur le marché ces dernières années a permis aux entreprises de rationaliser leur SI en s’appuyant sur la notion de services applicatifs ou en structurant/normalisant leurs échanges inter-applications. Cependant, quelque soit la solution choisie, la mise en place d’une couche de médiation de ce type ne se fait pas sans une approche réfléchie globale au système d’information et impactante tant au niveau de l’architecture technique ou applicative que de l’organisation ou de la gouvernance. Elle peut donc être particulièrement lourde et coûteuse, même si à terme le retour sur investissement est indéniable et la maitrise du risque opérationnel améliorée. Continue reading ‘L’intégration Java "à la légère"’

ESB & démarche SOA

Contrairement à une idée reçue encore largement répandue, l’utilisation d’un ESB ne va pas forcément de pair avec une démarche SOA. Cette idée vient sans doute du fait que la notion d’ESB a émergé dans le même temps que celle de SOA, et qu’une majorité de schémas d’architecture SOA contiennent un ESB en point central. Soyons clair : Il est possible d’utiliser un ESB sans suivre de démarche SOA, et à l’inverse, il est possible de construire sa SOA sans utiliser d’ESB.

Cet article s’intéressera au premier point évoqué ci-dessus, à savoir l’utilisation d’un ESB hors d’un contexte SOA ; Afin de mettre en parallèle deux types de démarches – l’une SOA, l’autre non – j’utiliserais deux exemples de projets utilisant un ESB développés chez l’un de nos clients. Continue reading ‘ESB & démarche SOA’

Google utiliserait un chip (peut-être) quantique de 16 Q-bits

Après la mémoire de l’eau et la fusion froide il semble que désormais cela soit au tour des ordinateurs quantiques de faire rêver les amateurs de technologie extrême et exotique.
Un ordinateur quantique est, rappelons-le, un modèle de calcul qui exploite astucieusement certaines caractéristiques de la mécanique quantique (la superposition des états et l’intrication) pour construire des algorithmes qui, dans certains cas précis, battraient à plate couture toute machine classique, basée sur le modèle usuel de Türing. Toute nos machines actuelles sont basées sur ce dernier modèle. Continue reading ‘Google utiliserait un chip (peut-être) quantique de 16 Q-bits’

La fédération d’identité

Ce billet a pour vocation de présenter la fédération d’identité en s’appuyant sur le protocole SAML 2.0. Un futur billet présentera le logiciel Shibboleth, implémentation open source de référence de cette norme.

SAML 2.0

Normalisé, dans sa version 2.0, en mai 2005 par l’OASIS, SAML permet l’échange sécurisé d’informations d’identités (authentification et autorisation). SAML définit le format du message XML, appelé assertion, ainsi qu’un ensemble de profils. Ces profils sont des cas d’utilisation détaillés qui présentent la cinématique d’échange des messages, les paramètres attendus et renvoyés.

Fonctionnement

SAML définit deux briques essentielles pour sécuriser les échanges :

  • Le SP (Service Provider), fournisseur de service, protège l’accès aux applications. Il refuse tout accès sans authentification préalable et redirige l’utilisateur non authentifié vers son fournisseur d’identité
  • L’IdP (Identity Provider), fournisseur d’identité, s’occupe d’authentifier l’utilisateur ainsi que de récupérer des informations additionnelles associées à son identité

Ce mode de fonctionnement est suffisant pour une utilisation cantonnée à l’entreprise avec un annuaire des identités centralisé.
Dans le cadre d’une fédération entre plusieurs domaine d’identification, SAML défini une troisième brique appelée le DS (Discovery Service) qui permet à l’utilisateur de sélectionner manuellement son domaine parmi une liste. Avec un peu de configuration, il est possible de supprimer cet élément, un peu bloquant pour les utilisateurs.

Profils

Le profil le plus courant, appelé « Web Browser SSO », décrit, entre autres, les étapes d’authentification d’un utilisateur et les allers-retours entre le SP et l’IdP. L’utilisateur tente d’accéder à sa ressource protégée par le SP. Le SP vérifie que l’utilisateur est authentifié et s’il ne l’est pas, le redirige vers son IdP. L’IdP demande à l’utilisateur de s’authentifier (identifiant puis mot de passe par exemple) puis renvoie une assertion SAML au SP contenant l’identité de l’utilisateur et la garantie qu’il est authentifié. Le SP autorise alors l’utilisateur à accéder à la ressource initialement demandée.

Ce mécanisme d’authentification repose sur les redirections du navigateur Internet. Ce profil permet aussi de récupérer un ensemble d’attributs supplémentaires liés à l’identité de l’utilisateur et demandés par la ressource.

Un second profil basé sur des artéfacts, permet de décorréler l’authentification de la récupération des informations d’identité de l’utilisateur. Le SP reçoit de l’IdP, par le navigateur Internet de l’utilisateur, une assertion SAML contentant un artefact. Le SP doit alors interroger directement l’IdP pour obtenir les informations liées à l’identité de l’utilisateur.

D’autres profils décrivent comment mettre en œuvre le DS, les notions de logout et la possibilité de se passer du navigateur de l’utilisateur pour transmettre les assertions SAML entre services.

Sécurité

Les assertions SAML sont basées sur les couches SOAP, XML Encryption et XML Signature.

  • SOAP est le protocole d’encapsulation standard des messages XML, utilisé principalement par les Web services.
  • XML Encryption est le protocole standard de chiffrement des messages XML. Il a la particularité de pouvoir chiffrer la globalité du message ou simplement un sous-ensemble précis. Cela permet d’avoir par exemple un document XML en clair avec des valeurs d’attributs chiffrées.
  • XML Signature est le protocole standard de signature des messages XML. Tout comme XML Encryption il permet de cibler l’élément à signer. Cela permet à plusieurs intervenants de signer chacun une partie différente du document XML.

Le SP et L’IdP sont deux entités qui ont connaissance chacun l’une de l’autre en terme d’identifiant et de certificat. Les messages XML qui transitent sur le réseau sont donc chiffrés par la clé publique du destinataire, seul capable de déchiffrer le message avec sa clé privée. L’émetteur signe ses assertions avec sa clé privée permettant au destinataire de vérifier sa provenance.

Conclusion

Ce protocole est donc très sécurisé et remplit parfaitement les fonctions de SSO au sein d’une entreprise et entre différents domaines d’identification. Il devrait, à mon sens, remplacer les logiciels propriétaires de Web SSO, beaucoup moins sécurisés.

Thierry ALBAIN

Evénement Jazoon 2009 : l'avenir du monde Java

J’ai eu la chance de pouvoir assister à la conférence Jazoon cette année. Tiré du site web officiel, Jazoon se définit comme "where Java people meet" en Europe, en bref une série de conférences autour de Java et de tout ce qui s’y rapporte. Ce billet est un résumé très condensé du déroulement de ces quatre jours avec une sélection des meilleures présentations techniques :
Alexis Moussine-Pouchkin de Sun nous présente en quelques slides ce qu’est GlassFish, un projet démarré en 2005, la première implémentation de JEE5. Aujourd’hui la version stable est la 2.1. La v3 arrive en automne et sera compatible JEE 6. Selon Alexis, s’il ne devait rester qu’une seule raison pour utiliser GlassFish, c’est qu’ils (les contributeurs) s’intéressent autant aux personnes de l’exploitation qu’à nous les développeurs, et on le reverra plusieurs fois dans la journée.

Roberto Chinnici de Sun nous a ensuite présenté JEE 6 et toutes ses nouveautés. On peut retenir:

  • Les profiles qui permettent de rassembler un ensemble minimum d’API nécessaires à certains types d’application. Le premier sera le Web Profile. Les autres devront passer à travers le JCP.
  • Le pruning, en résumé le passage en « deprecated » pour les anciens API (Entity Beans 2.0, JAX-RPC), ils seront supprimés de la version suivante.
  • Des mécanismes d’extensibilité pour faciliter la configuration de frameworks tiers.
  • Des nouvelles versions des composants: EJB 3.1 (nouveaux types de beans @Singleton, @Asynchronous, @Schedule), Servlet 3.0 (annotations, @WebServlet, fonctionnement asynchrone,…), JSF 2.0,…
  • Un déploiement facilité avec la possibilité de mettre des EJB directement dans un WAR
  • Des nouveaux API: Beans Validation et peut-être Web Beans (JSR-299)
  • Au final une release qui va encore dans la direction de la simplification et qui est prévue pour septembre de cette année.

Christian Frei, l’organisateur de Jazoon, et James Gosling, un des pères de Java nous expose quelques chiffres l’expansion de Java, 10 milliards d’appareils compatibles avec Java, 6 millions de développeurs professionnels et 15 millions de téléchargement de JRE par semaine. Java est aujourd’hui utilisé partout dans le monde et dans tous les domaines, santé, industrie, mobiles, jeux vidéo,… Ils nous présentent ensuite un petit panel des points forts et des nouveautés, comme GlassFish v3, NetBeans 6.7, Kenai (la forge qui va remplacer java.net), Java Real Time et JavaFX.

Dierk Konig (Canoo) nous propose Groovy, 7 usages pattern . Le langage Groovy est réellement intéressant mais j’ai toujours eu de la peine à identifier les réels cas d’utilisation envisageable dans le cadre du développement d’applications d’entreprise, cette session était l’occasion de trouver quelques réponses avec ces 7 propositions :

  • Super Glue, utiliser Groovy pour créer des applications basées sur l’infrastructure Java et les fonctionnalités Groovy, par exemple les capacités de réseau de Java, Swing et le parseur XML Groovy pour créer un lecteur RSS en quelques lignes de code.
  • Liquid Heart, un peu l’opposé du précédent, dans une application Java complète, utiliser Groovy juste pour coder certaines règles métier qui risquent de, ou qui vont souvent évoluer.
  • Keyhole Surgery, mettre en place une back-door temporairement dans une application pour y exécuter des scripts Groovy, par exemple pour faire un bug fix rapide facilement testable qui sera par la suite corrigé en Java.
  • Smart Configuration, c’est simple, il s’agit de remplacer le XML par du Groovy, l’avantage étant de pouvoir en plus ajouter de la logique dans les fichiers de configuration.
  • Unlimited Openess, consiste à tout faire en Groovy, c’est ce que propose Grails. L’idée est de s’appuyer uniquement sur l’infrastructure Java et de suivre l’exemple PHP ou Python.
  • House elf, déléguer à Groovy toutes les tâches qui font le quotidien du développeur mais qui ne sont pas du développement, par exemple des scripts de build, de l’intégation continue, du déploiement,…
  • Prototype, créer les prototypes en Groovy et les migrer (ou pas dans certains cas…) en Java par la suite. L’utilisation de Grails permet de créer des prototypes et de faire par exemple valider les objets du modèle de domaine au client très rapidement.

Puis Benjamin Bratkus (Crédit Suisse) et Micha Kiener (mimacom) présentent JSF et Ajax au Crédit Suisse. Le Crédit Suisse a standardisé sa technologie de présentation autour de JSF développant plus de 70 composants utilisé par 90 applications. Aujourd’hui pour répondre à de nouveaux besoins utilisateurs, des solutions ont dû être trouvées avec des technologies de type Ajax ou Ajax Push. La solution retenue est d’utiliser le système « direct-to-dom rendering » implémenté par ICEFaces. Ce système permet de limiter au maximum le JavaScript côté client et de conserver le maximum de traitement côté serveur ce qui sied particulièrement bien aux contraintes de sécurité liées au monde bancaire. Au final il a été possible d’intégrer cette technologie sans aucun impact sur les 70 composants existants, la migration s’est faite en une seule journée (!).

Cette seconde journée s’est terminée sur deux très bonnes présentations de Neal Ford et Ivar Jacobson, l’une traitant du futur du développeur, où plutôt d’essayer de le deviner pour ne pas devenir un dinosaure de l’informatique. Il semblerait bien que le développeur doive devenir polyglotte pour survivre, je crois que je vais commencer à pratiquer Groovy plus activement ! L’autre présentation nous expliquait la différence entre un développeur « unsmart » et un développeur « smart », avec entre autres l’exemple d’un architecte au chaud dans sa tour d’ivoire et un architecte pragmatique confronté à la réalité du projet et du code.

La troisième journée, Danny Coward de Sun, chef architecte de toute la partie cliente de Java (SE, ME, FX,…) nous présente les changements dans JavaFX 1.2 et les nouvelles fonctionnalités à venir dans Java SE 7. Voici son top 5 pour le JDK 1.7 :

  • Modularité, il sera possible de créer des modules et de définir des dépendances sur ces modules en spécifiant des versions. Cela devrait, tout le monde l’espère, normalement adresser la problématique des conflits de versions dans les dépendances de librairies. Peut-être la fin du cauchemar du classpath !
  • Langages multiples, le support de langages tiers (JRuby en priorité) sera amélioré et surtout optimisé.
  • Ajouts dans le langage (Project Coin), quelques nouveautés au niveau du langage lui-même comme le switch supportant les chaines de caractères ou une meilleure gestion des types génériques lors des instanciations (diamond).
  • Un nouvel API I/O qui propose par exemple des facilités d’accès au système de fichier, de la notification de changement ou des opérations asynchrones.
  • Un nouveau garbage collector, déjà disponible en RC dans JSE 6 Update 14, qui permet d’assurer des pauses de GC courtes et prédictibles.

Le top 5 pour JavaFX 1.2:

  • S’exécute sur plus de plateformes qu’auparavant, incluant Linux, OpenSolaris, un téléviseur LG et des téléphones portables de développement (HTC Diamond) dont les versions commerciales devraient arriver sous peu.
  • Plus de composants qui permettent maintenant de créer plus facilement des applications de gestion et des formulaires.
  • Des layouts qui permettent de positionner facilement ces nouveaux composants.
  • Des performances en hausse, jusqu’à 40%.
  • Plus de moyens d’accéder à des données, support des formats RSS, lecture asynchrone de données et un API de stockage local de données.

Il nous a fait plusieurs démos lors de sa session et il faut bien dire que JavaFX semble tranquillement, mais sûrement, rattraper son retard sur ses concurrents, espérons que l’outillage suivra !

Dan Bergh Johnsson (Omegapoint) nous expose The Power of Value – Domain Driven Design and Value Objects. Cette présentation, extrêmement bien animée par ailleurs, nous a montré à quel point l’utilisation de Value Objects intelligents (et on ne parle pas ici de DTO) peut diminuer la complexité du code métier, faciliter la gestion de la concurrence et améliorer la lisibilité des API des services et la testabilité. Avec l’exemple tout simple du numéro de téléphone qui doit respecter un certain pattern, il nous a montré comment refactorer une fonctionnalité end-to-end de la couche de présentation à la persistance et quels gains sont obtenus. Il est ensuite allé plus loin avec un refactoring plus poussé sur un exemple de p
aiement par carte de crédit mettant en œuvre des Value Object composite. Une présentation vraiment très intéressante et pleine de bonnes idées à retenir. D’autres informations sur le sujet sur le blog de Dan.

La présentation Metro Web Services Security Usage Scenarios par Harold Carr (Sun) nous décrit plusieurs moyens de sécuriser des Web Services. Metro propose plusieurs profils de sécurité qu’il est possible d’activer et de configurer depuis NetBeans. Sa présentation, bien que très technique, était remplie d’informations et de schémas qui m’ont permis de mieux appréhender les innombrables possibilités de sécurisation disponibles pour les WS. A conserver précieusement dans les ressources sur le sujet.

La dernière session était Jazoon Rookies, un concours organisé pour permettre à des « Java Rookies » de venir présenter, devant la communauté, un projet sur lequel ils ont travaillé. Je retiendrai surtout la présentation de João Arthur Brunet Monteiro, DesignWizard: A Tool that Gives Support to Automatically Check Your Code Against Design Rules. Cet outil permet de définir des règles de design à respecter et de les exécuter en tant que tests JUnit. On peut par exemple définir une règle qui contrôle que seules les classes du package service utilisent les classes du package dao et cela très simplement. Plus d’informations sur le site officiel DesignWizard.

La keynote d’ouverture du dernier jour est présentée par Adrian Colyer, CTO de SpringSource. Après avoir fait une rapide analogie entre l’industrie logiciels et une forêt tropicale (quelques géants qui dominent le paysage, la difficulté de percer pour ceux qui sont dessous et de temps en temps une clairière qui permet à des nouveaux de grandir), Adrian estime que l’on est à l’aube d’une nouvelle ère et que beaucoup de choses vont émerger ces prochaines années. Tout d’abord il parle de l’arrivée des nouveaux langages comme Groovy, Scala, Ruby, qui peuvent être vus comme des alternatives et/ou des compléments à Java. Ces langages montrent des forces selon deux axes, l’augmentation de productivité avec des outils comme Grails ou JRuby et la facilité de gérer la programmation concurrente, ce point sera particulièrement important ces prochaines années avec la multiplication des cœurs intégrés dans les processeurs. Il retient particulièrement Groovy de par sa facilité d’intégration avec Java, ce qui parait logique dans la mesure où SpringSource emploie maintenant les principaux contributeurs de Groovy. Ce qui est certain, c’est qu’aujourd’hui plus que jamais un développeur doit être ouvert à plusieurs langages et utiliser le meilleurs disponible en fonction de la problématique à adresser.

Dans la présentation What’s New and Exciting in JPA 2.0 de Mike Keith (Oracle) porte sur les principales nouveautés de JPA 2.0 qui sort bientôt (en septembre avec l’arrivée de JEE 6). Il insiste sur le fait que la version 1.0 répondait à la majorité des attentes qu’ont généralement les développeurs avec les outils d’ORM. Cette version 2.0 va répondre à certains cas d’utilisations plus spécifiques, elle a été construite sur les nombreux retours de la communauté. Voici les principales fonctionnalités :

  • Plus de propriétés communes pour configurer les entity managers
  • Une plus grande flexibilité pour le mapping de Map et de List
  • De nouvelles capacités pour les objets Embeddable avec la possibilité de créer des compositions
  • La possibilité de mélanger les modes d’accès aux champs d’une classe
  • De nouveaux API, notamment pour la gestion d’un cache partagé
  • Un système de lock pessimiste
  • Et finalement le nouvel API Criteria qui permet de construire des requêtes en Java à la place d’utiliser le query language. Cet API fonctionne soit d’une manière très proche de celui d’Hibernate avec des chaines de caractères pour définir les critères, soit avec un système fortement typé qui permet d’assurer un contrôle de type complet à la compilation. Si ce système offre un contrôle plus élevé, il nécessite d’écrire ou de générer un meta-modèle des entités et le code écrit pour définir une query et beaucoup moins lisible qu’une requête JP QL.

Dalibor Topic (Sun) nous présente le projet OpenJDK, notamment les buts déjà atteints comme la disponibilité de portages OpenJDK 6 sur plusieurs distributions Linux (Fedora, RHEL, Debian,…). Des portages sont également en cours pour BSD. Il faut savoir que le projet OpenJDK est l’endroit où se construit le JDK 7, toutes les nouvelles fonctionnalités de la prochaine version majeure de Java sont développées ici en tant que sous-projets. Plusieurs Milestones du JDK 7 sont déjà disponibles et ils ciblent le premier trimestre 2010 pour la version finale.

Pour clore ces 4 jours, les organisateurs ont invité Linda Cureton, CIO de la NASA, elle nous a présenté Web 2.0 @ NASA, session durant laquelle elle a insisté sur l’importance des réseaux sociaux pour une agence comme la NASA. Il est intéressant de noter qu’ils ont mis en place un Spacebook interne dont le but est de faciliter la communication et le partage de l’information au sein de l’agence. Et ce Spacebook a été développé sur la base de Liferay, portail open-source Java.
Jazoon’09 était une conférence riche en informations que je recommande chaudement à toutes les personnes qui travaillent quotidiennement avec cette technologie. L’édition 2010 est déjà annoncée par Christian Frei. Pour ceux qui aimeraient plus de détails, il faut savoir que toutes les slides des présentations sont disponibles en téléchargement sur le site officiel, de plus certains enregistrements vidéo sont disponibles sur parleys.com.
A l’année prochaine !

Article par Frédéric Chopard

SOA ne s'achète pas, SOA se construit

Voici le contenu d’une interview que j’ai donnée au site Silicon.fr sur SOA.

Dans quels contextes SOA incarne-t-elle une démarche pertinente ?

Globalement, je citerai trois raisons qui présentent un intérêt évident pour une approche SOA. En dehors de ces trois situations, l’entreprise peut se passer de la démarche SOA.

  • Première motivation : apporter de l’agilité aux processus métier. Dans certains secteurs (finance, services…), ces processus évoluent fortement. Or, s’ils sont “codés en dur” dans les programmes, la rigidité freine fortement l’agilité du système d’information qui ne peut s’adapter souplement pour répondre aux besoins évolutifs de l’entreprise. Avec une architecture SOA, les processus sont décomposés en briques élémentaires appelées services. Cela favorise les évolutions sans remettre en cause l’ensemble du schéma applicatif. Par exemple, une banque propose des services bancaires en marque blanche à d’autres acteurs. Or, chacun souhaite disposer de sa propre variante de processus tels que la souscription de crédit (traitement spécifique en cas de refus, limiter les étapes de validation…). En mode SOA, soit le processus présente une souplesse suffisante, soit la banque peut mettre en place des variantes d’un même processus pour un coût très raisonnable.
  • Seconde situation favorable dans laquelle le SOA apporte une solution efficace : l’interopérabilité. Une caractéristique critique pour une entreprise nécessitant de forts échanges entre les briques de son système information, entre ses applications décloisonnées, ou pour communiquer avec les applications de ses partenaires, fournisseuse ou clients. C’est ce que j’appelle la “SOA de surface” : on ne sait pas forcément ce qui se trouve dans l’application, mais on déploie les interfaces nécessaires à la communication (e.g. Services Web). Ainsi, un groupe de transport dont les processus restent identiques doit pourtant se conformer à de nouvelles règlementations. Il ne modifie pas les processus applicatifs, mais uniquement l’interface des échanges.
  • Troisième cas, moins fréquent que les deux autres : la rationalisation du SI. L’objectif consiste à réduire les occurrences multiples d’informations et d’applications ou fonctions. Il s’agit alors de travailler sur la qualité des données et des services applicatifs (MDM et autres outils de ce type). Si ce travail permet de réduire les coûts à moyen terme, on ne vise pas le retour sur investissement rapide, mais plutôt la cohérence du SI.

Quels éléments ou infrastructures favorisent l’élaboration d’une approche SOA ?

L’infrastructure ou les logiciels ne sont pas l’essentiel de la démarche, et les questions à leur sujet ne devraient pas se poser au départ. SOA est une philosophie de construction du SI sous forme de briques élémentaires et réutilisables. Or, cette notion de réutilisabilité provient de la qualité de l’interface et passe forcément par des formats pivots (description par message d’un processus métier, qui sera véhiculé lors des appels de services). L’intérêt consiste à mettre sur pied un vocabulaire commun à toute l’entreprise et à détecter les différences. Par exemple, la notion de “client” est différente selon les services, mais certains attributs sont communs. Alors, autant utiliser ce “plus petit dénominateur commun” de façon unique et le stocker dans un référentiel. Ainsi, en cas de modification et d’évolution, l’impact sera moindre et la maintenance des données largement simplifiée. Au final, une meilleure cohérence du SI et une productivité en hausse des informaticiens. On comprend alors pourquoi le référentiel est propre à chaque entreprise, à sa culture et ses métiers, et peut difficilement être vendu “prêt à l’emploi”.

En quoi l’architecture SOA diffère-t-elle de l’architecture applicative classique ?

Dans une architecture traditionnelle, on distingue trois couches : la couche utilisateur (avec le poste de travail et les interfaces homme-machine), les traitements et les données. Avec SOA, les traitements métiers sont séparés en Services élémentaires et en Services d’orchestration. Les premiers sont les briques de base que les seconds viennent compléter pour permettre la communication et les échanges.

À quel moment et où les logiciels peuvent-ils faciliter la démarche ?

Dans les solutions des éditeurs, la couche la plus stratégique reste le transport avec des logiciels comme MQ Series d’IBM ou JMS Sonic MQ de Progress, entre autres. En outre, lorsque les services se multiplient et se comptent par centaines, des suites logicielles deviennent indispensables pour comprendre ce qui se passe et orchestrer l’ensemble. Elles permettent d’industrialiser les tâches. De même, l’entreprise devra en déployer une pour assurer une ouverture contrôlée de ses applications dans des flux B2B. Cependant, SOA ne s’achète pas, mais se construit ! Signer un chèque à un éditeur ne sert à rien au départ du projet. Bien qu’il faille planifier cet investissement pour la suite.

Un nouveau type de plugin pour Liferay 5

Une des nouveautés de liferay 5 est l’ajout d’un nouveau type de plugin, nommé hook, dans le Plugin SDK. Il impacte fortement la façon de customiser liferay car il permet de changer le comportement et l’interface de liferay de manière plus intelligente.

Je n’entre pas dans le détail de création d’un plugin hook. Vous pouvez le voir en détail dans le wiki de Liferay. Dans ce billet je voudrais donner mon opinion et formuler quelques souhaits d’évolution pour les futures versions.

D’abord j’apprécie beaucoup l’idée de séparer toutes les customisations dans un war de type plugin. Cela donne la souplesse et le dynamisme pour les SI qui veulent customiser Liferay par rapport à leur besoin métier. Pour rappel, auparavant si l’on voulait customiser Liferay, la méthode la plus utilisée était d’utiliser l’environnement EXT fourni par Liferay. Mais EXT ne peut pas fournir un livrable séparé, les parties customisées sont déployées de facon manuelle ou semi automatique via les scripts ant. Les customisations notamment dans la couche présentation (les pages jsp) sont mélangées avec les sources originales de liferay et il n’existe pas donc de moyen simple pour les enlever. On doit supprimer le war customisé et redéployer le war original. On peut maintenant regrouper toutes les customisations dans un war, que l’on peut facilement déployer et retirer à la montée de version.

Voyons de quoi le plugin hook est capable. Il permet d’« accrocher » les modifications dans liferay. Plus précisément, il permet

  • de surcharger une partie des propriétés de la configuration de liferay (portal.properties). Parmi ces propriétés on peut trouver celles qui permettent d’intercepter le système d’événement et la gestion de l’écouteur autour des modèles métiers.
  • de surcharger, ajouter la traduction
  • de surcharger les pages jsp de liferay

Quelles sont les utilisations du plugin hook ?
L’usage principal est bien sur pour customiser le comportement et l’interface de Liferay via les différentes surcharges listées ci-dessus. L’usage alternatif est de créer un plugin hook qui initialise certaines données dans Liferay. C’est très utile pour faire une démo. Un bon exemple: dans le bundle tomcat-liferay fourni sur le site de Liferay, on peut trouver le hook sevencogs qui sert à initialiser les données de la communauté exemple nommé SevenCog.

L’apparition du plugin hook dans va-t-il entrainer la fin de l’environnement EXT ?
Personnellement, je n’y crois pas. Il faut distinguer les rôles des 2 projets de Liferay Plugin SDK et EXT. EXT sert à étendre le fonctionnement interne de Liferay ainsi qu’à le customiser. Plugin SDK sert à développer les plugins de Lifray (portlet, thèmes…) et maintenant packager une partie de la customisation. EXT est encore utiliser pour l’ajout des extensions lourdes. Il y a encore des choses qu’on peut faire dans EXT mais pas avec plugin hook. Par exemple, ajouter des nouvelles pages jsps, et des nouvelles actions struts.

Ce sont aussi les fonctionnalités que je souhaite voir dans la prochaine version du projet Plugin SDK. Pour arriver à ce point là, il faut gérer la surcharge à chaud de la configuration de struts (struts-config.xml) qui n’est pas évidente. La logique voudrait alors que Liferay enleve le répertoire ext-web dans projet EXT, comme ce qu’ils ont fait à l’époque pour le répertoire portlets.

Une autre fonctionnalité de hook que je souhaite est la surcharge au niveau de l’instance de portail. Pour l’instant les customisations dans un hook impactent tous les instances portail dans liferay. Si Liferay arrive à les limiter dans le scope d’une instance portail (un genre de portal-companyId.properties par exemple) ce serait idéal, notamment dans les contexte de site en "marque blanche".

Les plugins hook sont donc une évolution majeure de Liferay qui va considérablement faciliter la customisation du portail.

Cas d’utilisation d’un ESB

Dans la vision standard d’une architecture SOA, on retrouve toujours un certain nombre d’éléments communs : des services, des clients ou consommateurs de ces services, un annuaire/registre de services, et une infrastructure technique, l’ESB, utilisée comme couche de médiation entre les fournisseurs et les consommateurs de services.

Lors de nos missions chez SQLI Consulting, nous avons identifié quatre grands cas d’utilisation d’un ESB à différents niveaux de l’entreprise.

1) Usage intra applicatif

C’est un cas d’usage limité, presque toujours implémenté avec un ESB Open Source, léger et simple à mettre en œuvre.
On le retrouve dans des applications ayant un fort besoin d’agilité, qui justifie le surcoût en performance que provoque le passage par un ESB, ou dans des applications proposant une interface multi protocoles (pour des progiciels en marque blanche par exemple) ; le module consommateur de service se trouve alors dans une autre application / système.

2) Usage tactique

L’utilisation tactique correspond à un ESB utilisé au sein d’une entité / département afin de mettre à disposition pour l’ensemble de l’entité des services réutilisables.

Les services exposés peuvent être issus :

  • De nouvelles applications reposant une sur une architecture SOA interne (exposition des services via les standards actuels)
  • D’applications existantes dont une partie du code applicatif est réutilisé pour exposer des services (exposition des services via les standards actuels)
  • De systèmes légataires, tels que les mainframes ou AS400 (exposition de services grâce à des connecteurs spécifiques)

3) Usage stratégique

La vision stratégique correspond à l’utilisation de l’ESB pour établir une communication entre les silos, dans le but d’exposer des services utilisés par des processus métier transverses. Comme pour la vision tactique, les services peuvent être issus de diverses sources, voir même de l’ESB tactique qui peut exister dans chacun des silos.

4) Communication externe

Dans ce cas d’usage, l’ESB est destiné à exposer des services pour une utilisation externe à l’entreprise

Dans ce genre d’utilisation, les aspects de sécurité doivent être l’objet d’une attention particulière. Pour cette raison, il est d’usage de ne pas utiliser un ESB interne (tactique ou stratégique), mais de dédier un ESB pour les communications avec l’extérieur. Un ESB pour la communication externe sera généralement placé dans une DMZ.

Il est à noter que les échanges inter SI se font généralement par l’intermédiaire de web services (sécurisés), et que les besoins en connectivité sont donc souvent plus limités. Ces différents cas d’utilisation se combinent dans les entreprises au fil des implémentations SOA plus ou moins stratégiques à différents niveaux du système d’information.

Les ESB en entreprise, où en est-on actuellement ?
Au travers de nos missions, nous remarquons que les deux usages majoritaires des ESB sont :

  • l’ESB départemental afin de faire communiquer différentes applications appartenant à un ou deux ensemble fonctionnel
    Même si ces projets font parfois communiquer deux silos, il n’est pas possible de les considérer comme des projets d’ESB stratégique, qui est une réflexion globale sur la communication au sein de l’ensemble du SI, et dont l’objectif est l’implémentation de bout en bout des processus métiers de l’entreprise.
  • l’ESB pour l’extérieur afin d’offrir des services aux clients/partenaires de l’entreprise.

L’usage intra applicatif ne se justifie que dans de rares cas, lorsque l’agilité de l’application est considérée comme plus importante que ses performances.
Enfin le cas de l’ESB stratégique, transverse à l’entreprise reste encore limité, principalement par le fait que la plupart des systèmes d’information n’ont pas la maturité requise pour faire émerger des services dans l’ensemble de l’entreprise.

Je pense personnellement que l’un des principaux enjeux est maintenant l’interconnexion de ces différents ESB mis en place au cours de l’évolution du SI souvent sans se préoccuper de la vision globale du SI, nécessaire à l’alignement du SI sur le métier.

Google sites !

Avez-vous déjà essayé de créer un site Web en quelques minutes, sans connaître le langage HTML ? Si vous répondez non à cette question, c’est que vous n’avez pas utilisé le service « Sites » de Google.
Beaucoup s’interrogent sur la pertinence d’utiliser Google Sites pour créer leur site Web. Cet outil apporte pourtant un ensemble de fonctionnalités intéressantes dont voici quelques exemples.

De Google Apps

Google Sites est un élément de la suite Google Apps qui permet une forte intégration des autres éléments, tels que l’insertion d’un agenda de Google Calendar pour présenter des événements à venir comme des salons ou des expositions…
Il autorise la publication des documents textuels, feuilles de calcul, présentation et formulaires de Google Docs aisément. Google site fournit des plugins qui permettent de lire un document style Word dans son site Web, de visualiser des graphismes d’une feuille de calcul style Excell ou de parcourir une présentation style Powerpoint.
Google Sites va encore plus loin et permet de développer ses propres plugins. Certains existent déjà et proposent de présenter un plan dynamique comme celui de Google Plan ou de nous informer sur le cours de la bourse, sur l’état du trafic ou sur la météo.

Web 2.0

L’évolution du Web apporte la fonctionnalité d’interagir avec le contenu d’un site. Google Sites en entreprise offre un espace de partage et de travail collaboratif plus simple à utiliser qu’un wiki. La gestion des habilitations détermine ceux qui collaborent et ceux qui seront simple invités, sans droit de modification.

En conclusion, Google Sites est une alternative à ne pas négliger. Le conseil SQLI a élaboré un exemple de site Web créé à partir de Google Sites qui présente quelques fonctionnalités très intéressantes du produit. Il est en libre accès ici.

Thierry ALBAIN

Séminaire Web sur Google Apps

Messagerie en SaaS : comment réduire jusqu’à six fois le coût de votre messagerie avec Google Apps ?

Selon une récente étude* le coût moyen d’une messagerie interne avoisine les 260 € par an et par utilisateur. À service équivalent, Google propose une solution externalisée de messagerie pour seulement 40 € par an et par utilisateur !

SQLI, partenaire intégrateur privilégié de Google, est l’une des premières entreprises françaises d’envergure à avoir adopté cette messagerie révolutionnaire. Ce Web-séminaire vous présente la démarche proposée par les équipes SQLI Consulting pour réaliser une migration vers Google Apps.

Ce séminaire s’adresse aux DSI, aux directeurs des études et aux responsables de la messagerie / outils collaboratifs, de grandes entreprises, d’organismes publics ou de PME.

Avec la participation de Google France, nous vous présenterons :

  • La solution Google Apps avec ses fonctionnalités de communication unifiée et de collaboration
  • Le ROI impressionnant de la solution
  • Un exemple de success story
  • La protection des données
  • La démarche de migration de SQLI Consulting

Invitation au web-séminaire le 10 Mars 2009 de 10h à 11h. Pour vous inscrire : merci d’indiquer par mail à Gilles Grandjean – ggrandjean@sqli.com, votre nom, prénom, société, fonction, email. Il se fera un plaisir d’enregistrer votre inscription et vous communiquera toutes les informations nécessaires pour participer à ce web-seminaire.

* Etude Forrester du 5 janvier 2009 : « Should your email live in the Cloud ? A comparative cost analysis »

Thierry ALBAIN

Gmail en panne ?

Nous avons tous pu constater une indisponibilité de la messagerie Gmail le 24 février dernier. Les journaux parlent de série noire, de vent de panique ou encore de panique sur le Web. Avec ses dizaines de millions d’utilisateurs, ses milliers de serveurs et d’entreprises utilisatrices, Gmail, le plus performant des webmails n’est pas infaillible.

Le bug dont tout le monde parle, concerne, selon Google, un nouvel algorithme assurant le stockage des données au plus proche (géographiquement parlant) du lieu de son propriétaire. La volonté de Google de stocker nos données en Europe s’en trouve ainsi confirmée une fois de plus.

Les critiques citent une indisponibilité de 2h30 de la messagerie webmail, mais selon d’autres sources, l’indisponibilité n’a jamais dépassé les 8 minutes pendant ces 2h30. Ce qui veut dire que l’envoi des mails et leur réception s’effectuait régulièrement toutes les 8 minutes (voir l’article). Il fallait utiliser le mode déconnecté de Google pour s’en apercevoir.

Je rappelle que Google s’engage sur un SLA de 99,9%, autrement dit une indisponibilité inférieure à 9 heures par an. Par ailleurs Google fait un geste commercial en offrant 15 jours gratuits aux entreprises qui possèdent la version payante de Gmail : cliquer sur ce lien.

Toutes ces réactions autour de Google sont un peu excessives, mais n’est-ce pas le prix à payer lorsque on est leader dans son domaine ?

Sortie de notre livre "Cloud Computing et SAAS"

SQLI Consulting annonce la sortie de son nouvel ouvrage ouvrage « Cloud Computing et SaaS : une rupture décisive pour l’informatique d’entreprise » écrit par Guillaume Plouin, responsable innovation chez SQLI, et préfacé par Dave Armstrong de Google.

Le cloud computing est en train de révolutionner le monde informatique. Il consiste à externaliser les infrastructures informatiques vers des prestataires spécialisés, au même titre que les entreprises externalisent la production d’électricité vers des spécialistes comme EDF. C’est un virage comparable à celui du web en 1995. Ce livre vous permettra de découvrir en détail les tenants et les aboutissants de cette nouvelle « mutation de l’informatique ».

  • La première partie présente le concept de cette « informatique dans les nuages » et celui du SaaS (Software as a Service) en expliquant ce qui les différencient.
  • La deuxième partie explique quels sont les avantages et les inconvénients du cloud computing pour l’entreprise en prenant successivement les points de vue de la direction, des utilisateurs puis des informaticiens.
  • La troisième partie décrit les étapes à franchir pour évoluer vers le cloud computing.
  • La quatrième partie propose un panorama des offres SaaS aujourd’hui disponibles.
  • La dernière partie, plus technique, décrit les architectures sous-jacentes aux applications. Elle présente les PaaS (Platform as a Service) qui permettent aux entreprises de faire héberger leurs développements spécifiques sur des architectures multi-tenants.

Cet ouvrage s’adresse à tous ceux qui souhaitent comprendre les concepts et les enjeux du cloud computing tant côté « informatique » (chefs de projet, architectes, développeurs, administrateurs…) que côté « usages » (maîtrises d’ouvrage, consultants…).

Page suivante »