Archive for the 'Interviews' Category

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.

Interview de Dave Syer, créateur de SpringBatch


Frédéric Tu et Moez Louati de SQLI Consulting ont eu l’occasion de croiser Dave Syer, créateur de SpringBatch lors de la conférence SpringOne à Anvers en mai dernier. Voici la retranscription de cette brève rencontre entre deux séminaires. J’en profite pour remercier Michael Isvy de l’avoir gentiment organisée.

Bonjour Dave, peut-on en savoir un peu plus sur toi et ton arrivée chez SpringSource ?
Depuis bientôt deux ans, je fais partie de l’équipe SpringSource. Depuis 2004 j’étais utilisateur du Spring Framework. J’ai tout de suite été charmé par ce produit. J’avais aussi l’avantage d’être en contact direct avec les équipes d’Interface 21. J’ai proposé en 2006 à SpringSource de prendre un congé sabbatiques afin de contribuer au framework sur mon temps personnel. Quand j’ai fait part à Rod Johnson de mon désir de le rejoindre pour quelques mois, il m’a fait une proposition d’embauche à la place ! Cela va faire bientot 2 ans que j’y suis et je ne le regrette aucunement.

Tu es le créateur de SpringBatch, peux-tu nous en dire un petit peu plus sur ce framework ?
Tout d’abord, ma philosophie est qu’une entreprise ne devrait jamais passer du temps à développer des composants qui ne sont pas liés à son coeur de métier ou qui ne contribuent pas à son chiffre d’affaire. Pour ce qui est de Spring Batch, ce framework répond à la problématique des batch de deux manières.

  • La première, que j’appellerais « Infrastructure » est chargé de répondre à tous les besoins bas niveau et dont le code est assez récurrent et répétitif. Cette couche propose ainsi une boite à outils de composants génériques et prêts à l’emploi pour toutes les actions habituelles de manipulation de ressources (lecture de fichiers sous différents formats, gestion des connexions, …).
  • La deuxième partie concerne le modèle haut niveau, noyau même du framework appelé « Core Domain ». Son objectif est de normaliser et gérer le cycle de vie du batch, « quelles sont les prérequis », « par quoi commencer » et « où finir ». Elle offre une architecture haut niveau de composants modulables, qui doivent répondre à des besoins assez particuliers, avec une organisation des tâches assez précises. On parle de lancement de « jobs », composé de « steps » et chacune a une définition assez fine pour le suivi. Bien évidemment, la couche d’infrastructure s’intègre complètement dans ce modèle, avec la particularité d’être compatible avec tous les aspects de gestion des lots, sauvegarde d’état, reprise, …

Quel est ton rôle dans Spring Batch et qui d’autre participe au framework ?
Je suis avant tout Consultant chez SpringSource et fondateur de Spring Batch. Je participe un peu à tous les niveaux, de la définition des objectifs, au développement tout en passant par la conception. J’y consacre environ un quart de mon temps, ce qui représente à peu près une semaine par mois. A part moi, un développeur SpringSource y travaille à plein temps. Spring Batch étant le fruit d’une collaboration avec Accenture, deux de leurs consultants consacrent une grande partie de leur temps à faire évoluer le projet, ce qui amène le noyau de l’équipe à 4 commiters. Spring Batch est déjà utilisé en production par au moins quarante à soixante projets répartis sur une quinzaine d’entreprises. Ces chiffres sont très approximatifs sachant qu’aujourd’hui (NdR 11 mai 2008), j’apprends à toute heure que de nouveaux développeurs utilisent ou évaluent mon projet.

Peux-tu nous dire quelles sont les prochaines étapes du développement de Spring Batch ?
Comme vous avez pu le voir, Spring Batch ne possède pas encore de console d’administration et de suivi. La version Spring Batch 2.0 devrait pouvoir proposer de déployer les batchs sur la plateforme S2AP. Le modèle de packaging S2AP a le mérite d’être assez claire et modulaire, permettant aux batches de s’inscrire dans ce modèle. Les batchs seront packagés en bundle, ce qui permet d’avoir un fichier facile à déployer sur la plateforme. Ensuite les lancements de batchs et le suivi pourra se faire à travers la plateforme applicative. De plus, les ressources pourront être configurées directement sur le serveur.

Est-ce que les batchs devront obligatoirement adopter le modèle de déploiement S2AP ?
La philosophie de Spring a toujours été de pouvoir s’adapter au besoin et de très peu imposer de conyraintes à ses utilisateurs. Les projets seront libres d’adopter la future forme de packaging ou de continuer à lancer les batchs par une simple fonction main().

Penses-tu que le grid computing sera implémenté un jour dans Spring Batch ?
Beaucoup de projets ont déjà eu ce genre de besoins et ont réalisés eux même les adaptations qui vont bien. En tout cas, Spring Batch proposera dans un future proche, un travail main dans la main avec Spring Integration. Les conférences vont bientôt reprendre, je vous invite à suivre ma présentation s’intitulant « Enterprise Integration with Spring Batch » …

Interview de l’équipe française de SpringSource

La société SpringSource (ex Interface21) éditrice du framework Spring vient d’ouvrir une filiale dans l’hexagone. Nous avons rencontré Julien Dubois, directeur régional France et Michaël Isvy, responsable des activités de formation.

Quelles sont les activités de SpringSource aujourd’hui ?
SpringSource est le créateur du framework Spring ainsi que d’une dizaine de frameworks spécialisés, pour la plupart basés sur la philosophie Spring, par exemple: Spring Batch, Spring Web Flow, Spring Web Services. Depuis l’acquisition de Covalent, SpringSource a également une forte activité de développement et de support dans le monde des produits Apache, en particulier Apache Web Server, Tomcat et Active MQ. Aujourd’hui, Spring est l’un des frameworks Open-Source les plus utilisés dans le monde Java (et probablement le plus utilisé sur les nouveaux projets). Son adoption s’est faite à une vitesse fulgurante. Notre objectif est de fournir la meilleure plate-forme Java pour les applications d’entreprise, et ce sur l’ensemble du cycle de vie des applications : développement, test, déploiement et production.

Nous proposons un certain nombre de services autour de nos technologies : tout d’abord des formations, qui sont très populaires, et que grâce à Michaël nous pouvons désormais animer en Français. Ensuite nous proposons du conseil sur nos technologies : il s’agit de missions courtes, généralement durant moins d’une semaine, pour une aide précise sur un sujet très pointu. Enfin, et c’est en train de devenir notre activité principale en ce moment, nous proposons du support aux entreprises clientes : un certain nombre de grandes sociétés internationales, comme par exemple HSBC, ont ainsi pris un contrat de support chez nous. Ces clients disposent d’un support pour leurs développements et leur production, ainsi que d’un certain nombre d’outils complémentaires qui leur permettent de mieux développer et de mieux monitorer leurs applications Spring en production. (NDLR : à noter l’excellent document  »Spring in production’‘, pour ceux qui recherchent une présentation de Spring sous l’angle de l’exploitation).

Peux-tu nous présenter Spring Batch ?
Spring Batch est un framework basé sur Spring qui adresse la problématique de l’écriture de traitements longs en Java. Il est compatible avec la plupart des schedulers (lanceurs de tâches) disponibles et intègre des fonctionnalités telles que la gestion des curseurs et des transactions. C’est aujourd’hui la seule solution crédible pour l’écriture de batch dans le monde Java, qui est historiquement tourné vers le Web et les traitements interactifs de courte durée. De ce point de vue, Spring Batch est une innovation majeure puisqu’il vient combler un manque important sur la plate forme J2EE. A noter que Spring Batch est développé en partenariat avec les équipes d’Accenture.

Michaël, peux-tu nous présenter Spring Security ? Quel est ton rôle sur ce projet ?
Spring Security est le nouveau nom du framework Acegi Security crée par Ben Alex (SpringSource, Australie). C’est un framework qui permet de gérer les authentifications et autorisations de façon beaucoup plus évoluée qu’avec une sécurité J2EE « classique ». Il offre des mécanismes très souples (à base d’expressions régulières) pour poser les contrôles d’accès. Je suis commiter sur ce projet et je travaille en ce moment sur la refonte de la documentation. D’ailleurs, nous venons de sortir Spring Security 2.0. Cette nouvelle version est beaucoup plus facile d’utilisation que la précédente.

Pouvez-vous nous parler de SpringOne ?
SpringOne est la grande conférence annuelle européenne regroupant les utilisateurs de nos technologies. Elle réunit pendant deux journées l’ensemble de la communauté Spring autour de séminaires techniques animés par les meilleurs spécialistes. L’édition 2008 se tiendra les 11 et 12 juin prochains à Anvers en Belgique. Si vous voulez un avant-goût de la conférence vous pouvez aller voir notre vidéo sur YouTube ou les nombreuses présentations données lors des éditions précédentes qui sont disponibles sur parleys.com. Pour voir l’agenda de cette année et pour vous inscrire, allez sur le site de la conférence – rendez-vous à Anvers !

Julien, pourrais-tu nous décrire ton parcours ?
J’ai un parcours assez atypique pour quelqu’un qui fait du développement, vu que j’ai fait une école de commerce, l’ICN à Nancy. Pour ma défense, mon sujet de fin d’étude était sur le serveur Web Apache, c’était finalement assez prémonitoire vu que 10 ans plus tard je travaille pour la société qui emploie les principaux développeurs du projet ! Par la suite, j’ai travaillé dans quelques grandes SSII, et mon dernier poste avant SpringSource était chez un grand éditeur de logiciels français, Cegedim, chez qui j’étais responsable d’une équipe de développement de 25 personnes. Cette équipe était, bien entendu, spécialisée dans les développements JEE et grande utilisatrice de Spring. Enfin, je suis peut-être plus connu pour l’ouvrage que j’ai co-écrit, intitulé « Spring par la pratique », qui a été publié chez Eyrolles en 2006. J’ai toujours beaucoup aimé partager ma passion pour Java et Spring, et je suis très heureux de voir que ce livre a plu a beaucoup de gens. Nous en sommes au 3ème tirage ! C’est ainsi que j’ai rencontré Rod Johnson, qui a bien voulu nous écrire la préface. A l’époque je n’aurais jamais cru qu’il serait un jour mon patron ! (Lien vers l’ouvrage Spring par la pratique sur le site d’Amazon)

Et toi Michaël, comment es-tu arrivé chez SpringSource ?
C’est une longue histoire ! J’ai commencé ma carrière par 4 ans de développement Java « classique ». J’ai ensuite travaillé chez Sysdeo comme consultant et formateur pendant 3 ans (avant même qu’elle ne devienne une filiale de Sqli). J’écrivais aussi quelques articles pour des journaux comme Programmez!. En octobre 2006, lors de la sortie de Spring 2.0, j’ai interviewé quelques personnes du projet Spring pour l’écriture de mon article. Je suis resté en contact avec eux, et il y a quelques mois, on m’a proposé d’aider Julien à monter le bureau français de SpringSource. Compte tenu de mon engouement pour les projets Spring et les ambiances internationales, c’est quelque chose que je pouvais difficilement refuser !

A quand un runtime Spring qui concurrence vraiment JEE ?
Tout d’abord, je précise que Spring n’est pas concurrent de JEE, SpringSource étant d’ailleurs impliqué dans la conception de JEE 6 : nous sommes membres à part entière de la JSR 316, qui définit JEE 6, et nous sommes très heureux des perspectives offertes par JEE 6. Par contre, il est vrai que nous croyons que les serveurs d’applications JEE d’aujourd’hui manquent de modularité.. Suite au rachat de Covalent, qui est un contributeur de Tomcat, et à notre adhésion à la fondation Eclipse, qui propose un runtime OSGi de grande qualité, la rumeur d’un runtime Spring est omniprésente. Pour l’instant, cependant, nous restons maîtres de notre roadmap et aucune annonce officielle n’a été faite à ce jour. Cela reste donc une rumeur !

Il n'y aura pas de SI purement SOA

Vous trouverez ci-dessous la transcription d’une interview réalisée pour 01 DSI et publiée dans le numéro du 18 janvier de 01 Informatique.
La version complète en PDF de cette interview est aussi disponible ici.

01DSI : SOA a été l’un des thèmes récurrents de l’année 2007. Sa réalité dans les entreprises est pourtant beaucoup plus modeste. Comment expliquer cette différence ?

Aujourd’hui, les barrières technologiques sont tombées. HTTP, XML, IP… Toutes ces technologies nous permettent d’envisager des architectures orientées services. Reste que pour faire collaborer deux services, il faut qu’ils s’échangent des paramètres, qu’ils aient un langage, un référentiel communs. Et là, on tombe dans la problématique classique de l’urbanisation du SI. Qu’est-ce qui est dans le référentiel ? Qu’est-ce qui n’y est pas ? Qui est propriétaire des données? Bref, envisager un SI complètement SOA implique de passer au crible l’ensemble des processus et des données de l’entreprise. La tâche est immense, voire impossible d’un point de vue pratique. Du coup, aujourd’hui, les projets SOA qui avancent sont de petits projets ou, au moins, des projets à périmètre restreint, de type éditique ou CRM, par exemple. Avec ce type de projets, l’ambition est mesurée mais le risque maîtrisé, car on ne propage pas les problématiques d’une application à une autre.

01DSI : L’urbanisation est donc directement mise en cause… Que font les urbanistes alors ?

Rapprochons le rôle de l’urbaniste de celui de l’architecte. Comme dans la « vraie vie », l’urbaniste s’occupe du cadre dans lequel l’architecte va construire ses applications. L’architecte s’occupe de l’intérêt du projet, l’urbaniste de l’intérêt général. Or, en France, l’expérience montre que les urbanistes en sont encore souvent à cartographier le système, pas à édicter les règles d’évolution du SI en fonction d’une vision métier stratégique.

01DSI : Il n’y a pas d’issue alors ?

Si, bien sûr, mais je ne pense pas que l’on voie un jour des SI purement SOA. En matière d’urbanisation, il y a deux approches. L’une, plus française, est l’approche top-down. Elle est excellente d’un point de vue théorique mais ses bénéfices en termes de ROI ne sont perceptibles qu’à long terme, ce qui revient à dire qu’elle est difficile à faire passer auprès des directions financières. La seconde, plus anglo-saxonne, de type bottom-up , est plus risquée à terme mais bénéficie d’un ROI plus rapide. En fait l’approche topdown est un piège si on la pense au niveau global. Le SI est stratifié, historique. pratiquement, le top-down ne peut s’appliquer qu’à un niveau local. Il faut donc arbitrer entre les deux approches. Et cet arbitrage est particulièrement complexe.

01DSI : Malgré ces freins, l’arrivée de SOA, mais aussi, les offres SaaS, les services Web, marque-t-elle la fin des progiciels ?

Certainement pas. Mais ils vont devoir évoluer et le processus est d’ailleurs déjà engagé. Les éditeurs vont devoir donner accès à leurs briques élémentaires. Les boîtes noires qu’ils étaient doivent se transformer en boîtes blanches. C’est d’ailleurs l’une des clés du succès de SOA.

01DSI : Une bonne nouvelle quand même sur le front du SOA ?

Oui, sans doute. La complexité des SI augmente parce que les métiers sont toujours plus exigeants. SOA ne réduit pas cette complexité mais accroît l’agilité du SI vis-à-vis de ces demandes croissantes. Du coup, la bonne nouvelle, c’est que les informaticiens ont du travail pour longtemps…


Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64,072 hits