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.
L'inertie inhérente aux grosses structures ou le manque de moyen des petites entreprises ne permet donc pas forcément de s'impliquer dans la mise en place d'une telle machinerie, d'où l'émergence depuis fin 2007 de solutions orientées outils plutôt que produit plus adaptées à des besoins très localisés ou plus limités fonctionnellement.
Ces initiatives commencent à se faire une place dans le paysage informatique principalement parce qu'elles sont faciles à mettre en place et à prendre en main, sans qu'elles s'interdisent d'évoluer vers des solutions plus transverses.
On les appelle indifféremment frameworks d'intégration, de médiation, de routage, de messaging, d'échange, d'implémentation de pattern EIP ou 'ESB light' qui a mon sens n'est pas l'expression la plus adaptée.
Qu'est ce que c'est ?
Comme son nom l'indique on parle ici de framework Java, c'est à dire un ensemble d'API et d'outils cohérents permettant de développer certaines fonctionnalités ou composants applicatifs. Et c'est là tout l'intérêt de ces solutions, elles sont auto-contenues et n'ont besoin que des socles d'infrastructure ou de middleware bas niveau pour s'exécuter.
Concrètement n'importe quelle application, qu'elle soit batch, web, standalone, peut s'intégrer dans les flux de l'entreprise en embarquant simplement quelques librairies supplémentaires, sans avoir à toucher à l'infrastucture ou au parc applicatif existants.
Mais me direz-vous, on peut d'ores et déjà le faire aujourd'hui, en utilisant par exemple JMS pour transmettre ou recevoir des messages. La réponse est évidemment oui, on peut tout faire à partir d'un langage aussi riche que Java, tout comme on peut ré-implémenter le protocole HTTP à partir des fonctions de bas niveau TCP. L'intégration d'applications ne se limite heureusement pas à poster des messages sur des files mais doit prendre en charge l'ensemble des flux d'informations de bout en bout.
On imagine très bien par exemple que JMS seul n'apporte pas de réponse à la problématique suivante : "agréger toutes les 10 minutes les données qui viennent d'un service Web et d'une file JMS et les envoyer par sms si leur taille est inférieure à 250 caractères, par mail sinon, tout en conservant une piste d'audit technique cohérente permettant de tracer les échanges".
Il apparaît clairement sur cet exemple qu'il faut un niveau d'abstraction supplémentaire pour implémenter rapidement des flux complexes sans avoir à développer ses propres composants. C'est exactement le positionnement des framewoks d'intégration.
Pourquoi pas un ESB ?
La question ne doit pas être simplement "dois-je mettre en place un ESB ou dois-je utiliser un framework d'intégration ?" mais plutôt "quels sont mes besoins et sur quel existant dois-je m'appuyer ?".
Si une politique de gestion des échanges est déjà en place dans l'entreprise et qu'elle repose sur un bus et des standards, la question ne se pose pas, on se cale sur la stratégie définie, on procède par une approche top-down ou bottom-up (cf. article précédent) et on se lance.
En revanche si les règles d'urbanisation ne sont pas clairement établies, que les applications sont de petite taille ou très orientée 'intégration' sans toutefois être les candidates idéales à la mise en place des préceptes SOA (réutilisabilité réduite, interfaces non contractualisées), alors on est en droit de se poser des questions sur la pertinence de l'utilisation d'un ESB.
Ensuite les quelques arguments suivants permettent de s'orienter vers l'une ou l'autre des solutions :
Le coût de mise en place
L'utilisation d'un ESB est une décision particulièrement structurante pour l'entreprise et doit faire partie d'une stratégie à moyen ou long terme. Le choix doit être gérer comme un projet à part entière, de l'expression de besoins jusqu'à sa mise en fonction. On imagine donc bien que l'impact financier n'a aucune commune mesure avec un choix de librairies qui tient plus d'une définition des normes et standards afférentes au projet ou dans un cas plus général communes au pôle études.
Les délais
Comme indiqué dans le point précédent, la mise en place d'un ESB se gère comme un projet transverse, avec bon nombre d'intervenants et de phases. On ne parle pas de quelques jours mais bien de plusieurs mois, calendrier souvent incompatible avec le démarrage d'un projet d'intégration.
Les impacts organisationnels
On distingue principalement deux types d'impacts en terme d'organisation :
- les impacts sur la gouvernance du SI : une fois l'ESB en place, il faut définir l'ensemble des règles permettant de s'intégrer dans une démarche stratégique globale visant à rationaliser les flux inter-applicatifs. Pour ce faire il est nécessaire de mettre en place une organisation spécifique et dédiée chargée de définir ces règles, de contrôler leur mise en place et d'évangéliser les équipes d'études
- les impacts d'exploitation : le paramétrage technique, la supervision des flux, la maintenance, l'optimisation des échanges, la disponibilité de la plateforme, toutes ces facettes sont propres au produit et se doivent d'être définies et maîtrisées par les équipes en charge des infrastructures et des composants de socle middleware
Les impacts techniques et applicatifs
Quelque soit la typologie de bus employée, il est nécessaire de mettre en place une infrastructure dédiée, efficace et fiable. Il est également fortement probable que certaines applications doivent être modifiée, voire refondue, pour s'intégrer au nouvel environnement.
L'un dans l'autre
Faire le choix de partir sur une solution construite sur un framework d'intégration n'implique pas de se fermer la voie des ESB. Chaque produit est suffisamment ouvert pour permettre de s'intégrer dans bus existant via l'utilisation de standards tels que JBI ou OSGI. Il est donc envisageable de définir une trajectoire qui permette de minimiser les coûts de démarrage d'un projet tout en évitant au maximum le rework nécessaire à son intégration future.
En outre il est tout à fait envisageable d'avoir le meilleur des deux mondes en utilisant pour les échanges intra-applicatif un framework tout en exposants les services de plus haut niveau via un ESB.
Les approches et les concepts
L'objectif des solutions d'intégration dites 'légères' reste la possibilité de définir et d'implémenter simplement les échanges entre services ou applications, de manière distribuée et indépendante des technologies de transport. En outre les quelques principes mis en œuvre au travers de ces produits sont la non-intrusivité vis à vis de l'existant, la maintenabilité, l'évolutivité et la 'configurabilité'.
Les mécanismes utilisés par les frameworks pour répondre à ces besoins sont les suivants :
- les échanges sont définis par des 'langages' de haut niveau, adaptés au contexte. Il s'agit essentiellement de fichiers de configuration ou de langages dédiés (Domain Specific Language)
- les concepts manipulés sont simples dans leur forme et fortement configurables : l'idée commune est de partir de la description d'une problématique sous forme de patterns EIP (cf. http://www.eaipatterns.com/) ou en langage naturel et de rapidement pouvoir les prototyper. On trouvera les notions de message, adaptateurs, points de connexion, canaux, processeurs et quelques autres, tous relativement simple à appréhender.
- les différents composants constitutifs des échanges sont découplés entre eux
- l'adaptation des données entre les différents composants est prise en charge par le framework, soit nativement, soit en proposant la possibilité d'implémenter ces transformations de manière indépendante et autonome
Les produits
Il n'existe à l'heure actuelle que 3 solutions de ce type sur le marché :
- Spring-integration : http://www.springsource.org/spring-integration
- Apache Camel : http://camel.apache.org/
- OpenAdaptor : https://www.openadaptor.org/
Ces produits sont tous libres d'utilisation et partagent de nombreuses caractéristiques tant sur leur utilisation que sur leurs fonctionnalités. Un futur article présentera sur ce blog une petite étude comparative entre deux de ces solutions.
Les inconvénients
Les deux principaux reproches que l'on peut faire à ce type d'approche sont :
- la décentralisation : même si cet aspect peut être vu au contraire comme un avantage, il peut vite devenir difficile de gérer un système d'échange de données complexe et fortement réparti. Sans centralisation la gestion des impacts doit être réalisée manuellement par introspection exhaustive des composants déployés. En outre, sauf à définir une politique de piste d'audit commune et centralisée, obtenir une vue synthétique des échanges et de leur contenu peut s'avérer rapidement impossible.
- La manque d'outillage : ce point reste, d'une manière générale, un handicap des solutions gratuites par rapport aux produits commerciaux. Il n'existe pas vraiment (voire pas du tout) d'outils permettant de définir les échanges, de gérer les éléments de configuration, de suivre les flux, d'exploiter ou de déployer les différents composants. La jeunesse de ces produit peut aussi laisser penser que cet état des choses n'est que temporaire et que la communauté grandissante d'utilisateurs prendra rapidement en charge ces différents aspects.
En bref
Loin d'être une solution de repli ou 'bon marché' face aux machines que sont les ESB, le framework d'intégration représente une véritable opportunité pour les systèmes d'informations de développer leurs flux applicatifs à moindre coût tout en s'intégrant dans une démarche de rationalisation. Tout en évitant le syndrôme du marteau qui écrase la mouche, ces frameworks orientés intégration évitent de réinventer la roue et proposent la glue permettant d'interconnecter facilement les différents sous-systèmes logiciels et middleware.
Comparée à une solution interne où le stockage et l’accès aux mails ne sont possibles qu’à partir du réseau d’entreprise, la solution SaaS de Google Apps parait peu sécurisée. Il n’en est rien.
On reproche à Google, comme aux autres fournisseurs de solutions gratuites de messagerie sur le Web, de lire le contenu des messages. Il est facile de s’en apercevoir à cause de la publicité associée à notre messagerie. En fait, les robots de Google lisent le contenu de nos mails pour cibler les thèmes des publicités affichées.
Google assure la sécurité du transport des messages entre le navigateur client et ses serveurs en chiffrant les communications avec HTTPS. C’est une option qui est facultative, mais nécessaire et qui ne réduit pas la performance de la solution.
Google gère l’authentification en proposant une page d’identification. Dans ce cas, seule l’empreinte des mots de passe est stockée chez Google.
La sécurité concerne aussi le stockage des messages. Certaines entreprises autorisent leurs employés à laisser sur le serveur de mails, leurs messages tant que la taille globale n’excède pas quelques dizaines de Mo. Une fois la capacité atteinte, il devient impossible d’envoyer de nouveaux messages.
La solution Google Apps est fournie avec un antivirus performant qui analyse le contenu à risque des messages ainsi que les pièces jointes avant leur téléchargement. La différence avec un antivirus local est que Google parcourt les messages et les pièces jointes avant de les transmettre.
Google a passé la série d’examen « SAS 70 type 2 ». C’est un audit de conformité en matière de protection des informations stratégiques tout au long du cycle de vie des données. Cette certification assure de la mise en œuvre de contrôles et de sauvegardes efficaces.
Derniers commentaires