La consommation grandissante des flux XML dans les infrastructures informatiques ne permet plus d’envisager la solution logicielle comme étant l’unique possibilité offerte pour traiter ce type de flux. En effet, les traitements sur les flux XML sont de plus en plus complexes et nombreux.
Ils nécessitent des capacités de mémoire et de traitements importants, pour réaliser des fonctionnalités purement techniques et qui n’apportent aucune valeur ajoutée aux applications métiers des entreprises.
Des traitements variés liés aux contenus XML
Il s’agit principalement des traitements tels que :
Transformation, adaptation de contenu
Extraction, filtrage de données
Validation des messages XML
Chiffrement et déchiffrement de données XML
Signature digitale et vérification de signature dans des documents XML
Cette consommation de flux XML est liée en partie à l’adoption désormais constatée des services Web au sein de l’informatique de nombreuses entreprises. Concernant les flux de type services Web SOAP (Simple Object Access Protocol), les traitements XML concernent également l’utilisation des standards Web-Services aboutis, quels qu’ils soient :
WS-Reliable Messaging
WS-Addressing
WS-Trust
WS-Security
WS-Policy
…
Les applicatifs doivent réaliser des traitements visant à garantir la sécurité des applications et programmes qui consomment les contenus XML. En effet, les menaces XML sont relativement simples à créer et pénalisent lourdement les victimes de telles attaques. Parmi les plus classiques, on notera par exemple :
Les dénis de service XML ou « XDoS » (XML Denial of Service)
L’accès non autorisé à des services
La compromission de systèmes informatiques (XML Virus)
Les attaques visant la confidentialité et l’intégrité des données
Outre ces contrôles sur les contenus, les applicatifs doivent réaliser d’autres traitements techniques, distincts de toute logique métier. On notera par exemple :
La gestion des habilitations pour l’accès aux services de l’infrastructure SOA,
Les ruptures protocolaires parfois nécessaires,
Le routage technique ou fonctionnel de l’information,
L’exposition et le management des services, permettant par exemple de lisser le trafic ou le rejeter si le seuil d’accès vers un service est dépassé (de manière générale ou pour un utilisateur en particulier).
Le besoin de performance et de sécurité
Les appliances (SOA – Service Oriented Architecture) ont pour principal objectif de supporter des fonctions techniques clés de l’infrastructure SOA de manière à garantir la pérennité des applications et des fournisseurs de services. Parce que les contrôles et traitements précités doivent être effectués en minimisant l’impact sur les performances de l’infrastructure SOA et en garantissant sa sécurité, une solution logicielle ne peut pas être envisagée à la différence d’une approche par « appliance ».
Les appliances consistent en des équipements de type « réseau », dédiés à des traitements applicatifs plus ou moins étoffés selon les gammes proposées par les principaux éditeurs du marché. Les appliances SOA incarnent une déclinaison particulière de cette offre dans le sens où elles sont capables d’effectuer des traitements et contrôles spécifiques aux services Web sur des trafics tels que SOAP, XML/RPC ou REST (Representational State Transfer).
Des appliances à caractère technique
Une appliance SOA est constituée d’un équipement matériel qui embarque un microcode (ou « firmware »), élément indispensable et optimisé, qui porte l’ensemble des possibilités de traitement offert par l’appliance SOA considéré.
Cette approche simplifie considérablement l’installation, le déploiement et l’évolution de l’infrastructure SOA basée sur ce type de composant. En outre, elle opère une séparation claire entre les fonctions techniques et métiers, étant précisé que les appliances SOA n’ont pas pour vocation de supporter quelque logique métier que ce soit, mais de prendre en charge des fonctionnalités exclusivement techniques.
De plus, une appliance est un système configurable et non pas programmable ; il offre dans la plupart des cas des interfaces multiples (commande en ligne et interface graphique par exemple) permettant d’implémenter les configurations requises. Ce mode d’implémentation masque la complexité des spécifications et protocoles, en synthétisant les informations requises.
La fourniture d’interfaces de configuration diverses permet d’adresser un large public :
opérateurs réseau : installation physique et paramétrage réseau de l’appliance,
responsables sécurité : configuration des politiques de sécurité (contrôle d’accès, menaces XML, protection des serveurs d’arrière-plan…),
architectes et développeurs : définition et implémentation des services.
Par rapport aux menaces XML, il existe deux approches concernant les appliances SOA :
l’approche positive consiste à rejeter, par défaut, toutes les attaques existantes. Il est cependant possible de diminuer le niveau des contrôles effectués.
l’approche négative consiste à n’effectuer aucun contrôle de sécurité. Ces contrôles sont configurés au cas par cas, selon les besoins de sécurité.
Un retour sur investissement très avantageux
Une autre caractéristique intéressante des appliances SOA, leur excellent retour sur investissement.
Les différents coûts à envisager pour effectuer une comparaison entre une appliance et une solution logicielle équivalente sont les suivants :
coûts de l’infrastructure opérationnelle complète ;
coûts des développements d’applications et de maintenance de la solution ;
coûts d’acquisition des produits ;
charges de maintenance des produits ;
coûts d’installation et de déploiement.
L’ensemble de ces coûts est bien plus important avec une solution logicielle, car celle-ci nécessite plus de ressources (humaines, logicielles et matériels) dans l’ensemble des phases de réalisation d’un projet SOA.
Ainsi, une appliance SOA embarque un microcode offrant au final une solution configurable complète, à la différence d’une solution logicielle basée sur un serveur, sur laquelle un développement spécifique doit être implémenté et maintenu.
D’une manière générale, une appliance SOA est gérée comme un équipement réseau traditionnel à l’inverse d’une solution basée sur plusieurs serveurs dont les coûts de gestion et de maintenance sont sans commune mesure.
