Le Management des Web Services

Le management des web services (ou monitoring des web services), est un domaine clef du déploiement. Il concerne la définition des critères qualité pour la délivrance et l’exécution des services ainsi que la supervision en l’exploitation.

Bien que de nombreux produits (Par exemple: Ambertpoint, Actional, Blue Titan, Infravio, Confluent, HP (Talking block)…) existent déjà pour assurer des fonctionnalités de base, les standards de management des web services sont en cours de spécifications, notamment WSDM (Distributed Management) de l’OASIS et WS-Agreement de la Globus Alliance (GRID). On peut se reporter à notre liste des standards WS-*** pour les liens vers les spécifications : http://soa.orchestranetworks.com.

D’ores et déjà ces spécifications sont suffisamment détaillées pour les exploiter afin d’évaluer les possibilités existantes et futures des outils logiciels.

La suite de cette meilleure pratique présente un aperçu général sur l’architecture préconisée par les standards.

Rappel sur SNMP

Comme la suite le montre, il existe des similitudes sur les principes d’architecture entre le management des web services et celle déjà connue avec SNMP (Simple Network Management Protocol). Dans les deux approches on trouve les principes de base suivants :

• Agents spécialisés par type de ressources supervisées (base de données, réseaux, serveurs, applicatifs…) que l’on nomme des sondes SNMP.
• Outil central de supervision des agents qui assure le rôle de ‘manager’. Il communique avec les agents pour récupérer les informations sur l’état du système et pour agir sur les agents selon les besoins de management (arrêt d’une ressource, changement de l’affectation des capacités mémoires…).
• Base de données MIB (Management Information Base) qui contient l’ensemble des données collectées et les règles de supervision.

Principes généraux

Le schéma suivant présente les principes généraux de l’architecture pour le management des web services, selon les recommandations du WSDM (Web Service Distributed Management OASIS).

Architecture générale pour le management des web services

La suite du document explique le fonctionnement de cette architecture d’une part au niveau des Agents situé en proximité du endpoint et d’autre part au niveau du Manager Central qui supervise l’ensemble des Agents.

Gestion au niveau des Agents

Exposition d’une interface de management par chaque endpoint

Chaque endpoint expose une interface de services qui contient les opérations d’administration disponibles. Cette interface est soit implémentée directement au niveau du web service, soit dans un proxy XML qui agit en frontal du endpoint (activé par le handler SOAP comme montré dans la figure d’architecture).

Le standard WSDM prévoit une interface de base formée par les types de services de management suivants :

Identification du service. Cette opération renvoie les informations suivantes : nom du service, version, description sémantique.

• Etat (state). Cette opération renvoie l’état du service à un instant donné. Une liste d’états prédéfinis existe dans les standards (Web Service Management: Service Life Cycle du W3C) : Idle, Busy, Stopped, Crashed, Satured… Voir à ce sujet la spécification à l’adresse suivante : http://www.w3.org/TR/2004/NOTE-wslc-20040211/ .
• Configuration : Cette opération expose des paramètres techniques et fonctionnels susceptibles de faire varier le comportement du web service. La configuration rejoint le pattern de gestion par les contextes (context-Aware) qui consiste à permettre l’adaptation du comportement d’un même Web service selon ses contextes d’usage (performance réseau, types de consommateurs…).
• Métriques (Metrics) : Cette opération assure la mise à jour de certains compteurs d’exécution du endpoint. La norme prévoit notamment à ce jour numberOfRequest, numberOfSuccessfulRequest, numberOfFailedRequest, ResponseTime.
• Relation (Relationship) : il s’agit de définir les liaisons entre le endpoint et les autres ressources du système. Par exemple, il faut pouvoir basculer l’état du endpoint à « Stopped » si une ressource utilisée par ce web service devient indisponible (une base de données arrêtée…). De même la compatibilité de version entre endpoints peut être exprimée à ce niveau.

L’implémentation de cette interface de base doit être extensible afin de permettre le développement d’autres types de services de management nécessaires pour un contexte d’entreprise ou d’un projet particulier.

Même si l’outil de management propose un langage de développement (par exemple un langage de règles) pour développer les opérations de l’interface de management, il ne doit pas l’imposer. Il doit être possible de faire un développement dans tous types de langage (Xpath, WS-Policy, Java, C#...).

Les opérations de management sont donc elles-mêmes exposées sous la forme d’un flux SOAP-XML.

En WSDL 2.0 (on rappelle que le portType devient Interface), il est possible de faire de l’héritage entre interface. C’est particulièrement intéressant afin de dissocier physiquement l’interface qui contient les opérations fonctionnelles de celle qui contient les opérations de management. Cette approche permet aussi de mutualiser une même interface de management pour plusieurs endpoints.

Persistance au niveau de l’agent

L’agent dispose de sa propre capacité de persistance. En effet, il doit par exemple gérer ses compteurs de la partie « Métriques » de l’interface de managemLocalisation de l’agent et gestion locale

Comme nous l’avons déjà indiqué, l’agent est soit un proxy XML qui s’exécute en frontal du endpoint, soit directement situé dans le portType (ou l’interface en WSDL 2.0) du web service. Ce choix d’implémentation ne doit pas être imposé par l’outil de management. Il dépend d’une stratégie plus large d’architecture.

L’agent assure un management local du endpoint auquel il est associé. Les règles et principes de gestion centralisés sont traités par le manager.

L’agent doit savoir si l’exécution du endpoint peut être soumis à un choix dynamique de routage (information du Service Level Objectives au niveau du Manager Central). Si un choix dynamique existe, l’appel est routé vers le Manager Central qui détermine, à partir des règles centralisées, la politique d’exécution (par exemple, choix d’un serveur physique d’exécution particulier parmi une liste de serveur candidat). Evidemment, un mécanisme de cache entre le Manager Central et les agents est possibles afin d’optimiser les performances (l’agent dispose alors d’une copie temporaire de la règles de routage centrale).
ent mais aussi persister son état.

Au niveau de l’implémentation, l’agent accède généralement à la base de données centrale sous le contrôle du Manager Central (de la même façon qu’une sonde SMNP peut se persister dans une base MIB centrale).

Gestion au niveau du Manager Central

Le Manager Central supervise l’ensemble des agents et assure les fonctions de base détaillées dans ce paragraphe : Relationship, Reporting – Statistique, SLA-SLO, Règles centralisées.

Il communique avec les agents selon deux modes :

• Question / Réponse : le manager interroge une opération de management exposée par un agent. Par exemple, il récupère la valeur ‘numberOfRequest’ d’un agent sur une plage de temps particulière.
• Subscribe / Publish : le manager s’abonne à des évènements émis par les agents. Par exemple, le manager doit connaître immédiatement le changement d’état d’un endpoint afin de déclencher des règles centrales de gestion des pannes. Techniquement, la mise en œuvre se fait selon un principe de fonction call-back exposée par le Manager Central ou/et par un pooling assuré par le Manager Central. Cette architecture renvoie aux principes ESB (Entreprise Service Bus) et plus généralement à l’EDA (Event Driven Architecture).

Relationship

Le Manager Central intervient dans la gestion des dépendances de ressources. Par exemple, si un endpoint bascule sont état à ‘Stopped’, alors tous les endpoints qui en dépendent doivent automatiquement être basculé dans un état approprié.
La gestion des ces relations est aussi intéressante pour analyser les causes d’un dysfonctionnement dans une chaîne d’appel entre endpoints et/ou avec les autres ressources du système qui ne sont pas des web services (cause root).

Reporting - Statistique

Le Manager Central prend en charge les calculs statistiques et cross-agents. Ils récupérèrent les données persistées par les agents et lancent les opérations de calcul selon les besoins des administrateurs.

SLA – SLO

L’ensemble des paramètres qui définissent la relation entre un consommateur et un fournisseur de endpoint est définit dans un document (XML Schema, XPath) nommé Service Level Agreement (SLA) et/ou également Service Level Objectives (SLO). Par exemple, le nombre de CPU allouées pour l’exécution d’un service est une propriété du SLO. Ces paramètres sont ensuite utilisés soit par les agents, soit par le Manager Central au niveau des règles centralisées (paragraphe suivant).

A ce niveau la norme WS-Agreement fixe progressivement une grammaire pour définir les critères des SLA-SLO (voir directement la spécification : http://www.gridforum.org/Meetings/GGF11/Documents/draft-ggf-graap-agreement.pdf ).

Règles centralisées

Ces règles définissent le comportement centralisé du management des web services. Par exemple, la stratégie de routage d’un web service en fonction du niveau de disponibilité des différentes ressources ne peut pas être délégués à un agent.

Autres fonctionnalités de management

Acheminement de bout en bout

La mise en place du standard WS-Reliable Messaging, pour la garantie d’acheminement de bout en bout des messages, n’est pas du ressort d’une plate-forme de management de web service même si sa disponibilité peut être un plus.

Dans le modèle type d’infrastructure web services, les outils de génération SOAP (CapeClear, Systinet…) ou directement les serveurs d’application semblent plus légitimes pour implémenter l’acheminement de bout en bout.

Management d’autres ressources que les web services

En plus du management des endpoints web service, la plate-forme de management doit être susceptible de monitorer les flux http/HMTL. Au-delà de ces types de flux, une interconnexion avec les plates-formes classiques d’administration comme HP-Openview, Tivoli… est nécessaire. Par exemple, il peut être pertinent de disposer d’un Manager Central capable d’interpréter les résultats de sondes SNMP (ou de prendre le charge une traduction automatique de ces sondes en SOAP-XML).

Dans la distance, les ressources non web services (base de données, système d’exploitation…) exposeront de plus en plus des interfaces SOAP de management et seront ainsi supervisées par la plate-forme de management des web services (les sondes SNMP deviendront des sondes SOAP-XML). Un mouvement de rationalisation et d’unification vers l’exposition d’interface de management SOAP est en cours.

WS-Security et firewall XML

L’implémentation des standards WS-Security (et les autres associés comme WS-Trust…) n’est pas de la responsabilité évidente d’une plate-forme d’administration des web services.

De même les services de vérification de la conformité d’une instance XML vis-à-vis d’un schéma de référence n’est pas obligatoirement du ressort de la plate-forme de management. Par contre, l’interfaçage avec les outils qui implémentent ces standards et fonctionnalités est évidemment indispensable.

Gestion de l’accounting et de la facturation

La plate-forme de management assure naturellement un comptabilisation (accounting) de l’exécution des web services, a minima, au niveau des flux XML et au niveau métier si des opérations de management sont correctement développées.

C’est à partir de cet accounting que les règles de facturation peuvent être déclenchées. Il n’est pas évident que le module de facturation soit de la responsabilité immédiate d’une plate-forme d’administration. Néanmoins, son existence peut être un plus même si dans la pratique les règles de facturation utilisées sont très spécifiques au métier exercé par l’entreprise.

Gestion de l’activation de services

L’activation de services consiste à créer un SLA – SLO entre un consommateur et un web service et de gérer son état (en cours, valide, invalide…). Cette fonction est donc de la responsabilité de la plate-forme d’administration.

La capacité de gérer des SLA – SLO type (ou cadre) ou mieux encore par adaptation en cascade (hiérarchie de SLA – SLO) est un point important pour contrôler l’intégrité des données entre plusieurs SLA – SLO. Cette mode de gestion est par exemple disponible via le module logiciel EBX.Platform spécialisé dans la configuration des données XML (voir http://www.orchestranetworks.com/fr/product/applications_soa.cfm).
Les schémas XML utilisés pour créer les SLA – SLO doivent être extensifs afin de tenir compte du contexte particulier de l’entreprise et/ou d’un projet. Leur format de départ peut néanmoins s’inspirer (à terme respecter) des standards comme par exemple WS-Agreement déjà cité précédemment.

Gestion du paramétrage

La gestion du paramétrage des web services est un élément qui concoure au management. Il s’agit d’agir sur la configuration du endpoint, au sens où la norme WSDM le propose (cf. première partie de ce document).

La capacité de la plate-forme de management à traiter le paramétrage et/ou à intégrer des modules ad hoc spécialisés dans le paramétrage est à étudier. Ici également, l’intégration d’un module logiciel spécialisé dans cette fonction est intéressante (voir http://www.orchestranetworks.com/fr/product/applications_soa.cfm).

Suivi de bout en bout de processus

Le suivi de plusieurs appels à des endpoints dans le cadre d’un même processus est à prendre en charge, a priori, par le Manager Central puisqu’il s’agit de disposer d’une vision cross-agents. A ce jour, les standards n’abordent pas clairement ce point.
Evidemment, la capacité des agents et du manager à analyser les headers SOAP pour identifier les contextes est une condition nécessaire. De même la capacité à manager une conversation standard en BPEL est un point à étudier : reconnaissance d’une conversation BPEL et/ou d’un contexte (WS-Context, WS-RF).

Synthèse des fonctionnalités attendues

Services de base offerts par défaut

Il s’agit essentiellement des fonctions de métrologie qui consistent à comptabiliser les flux SOAP. La mise en place est généralement ‘immédiate’ mais la valeur assez limitée. Il faut prévoir le développement d’opérations de comptage qui agissent au niveau de la logique applicative afin de produire un reporting métier (agent de management positionné au niveau de l’applicatif : voir schéma d’architecture présenté au début de ce document).

Politique d’exécution des services

Il s’agit de définir les règles qui permettent de décider, en fonction d’un niveau de disponibilité des ressources d’exploitation, la meilleure stratégie d’exécution des requêtes SOAP : traitement immédiat, gestion de priorité, rejet, choix d’un serveur d’exécution, activation d’un endpoint de substitution…

Allégement des flux SOAP

Cette fonctionnalité participe aux mécanismes de paramétrage du web service. Il s’agit de pouvoir paramétrer les données du flux SOAP (SOAP-Response) qui seront passés aux consommateurs ou non selon le contexte d’exécution. Par exemple, en fonction que le consommateur dispose d’une connexion réseau à haut débit ou pas, les données multimédias de la réponse SOAP sont envoyées ou non.

Mode de gestion des SLA

La configuration des contrats de services entre un endpoint et un consommateur doit s’appuyer sur un outil métier qui ne nécessite pas d’intervention informatique systématique (ne pas coder directement du XSD ou Xpath ou WS-Policy…). La gestion documentaire des contrats doit permettre la création de contrat cadre puis la spécialisation en cascade (filiation) selon les types de services, types de consommateurs, types d’usage…

Contrôle de version

Il s’agit de pouvoir définir des dates de fin de validité sur chaque endpoint. A partir de cette date le endpoint bascule dans un état ‘deprecated’ et son exécution n’est plus possible. Selon la politique d’exécution retenue (paragraphe précédent) un endpoint de substitution (nommé précédemment endpoint de secours) peut alors prendre la place du endpoint ‘deprecated’. Cette définition peut se faire de manière générale ou relativement à un contrat de service particulier (ou contrat cadre…) comme indiqué au paragraphe précédent.

Il s’agit aussi de contrôler la conformité d’une version présente dans l’instance de Schema réceptionnée via le SOAP Request avec une version de Schema attendue pour le endpoint. Le compteur de version est soit la targetnamespace, soit l’attribute version (voir Meilleure pratique sur la gestion des versions des web services).

De manière optionnelle, le contrôle de conformité s’étend au-delà du compteur de version et prend aussi en charge la vérification de la conformité de la structure du message selon le Schema XML qui le définit. C’est une fonction optionnelle car déjà traitée au niveau des parseurs SOAP.

Sécurité

Il s’agit d’une part de vérifier que la console d’administration et la plate-forme dans son ensemble ne peut pas faire l’objet d’une attaque. Il s’agit d’autre part de tester le chiffrement sélectif via WS-Security (soit directement via l’outil, soit par son interfaçage avec une implémentation WS-Security ad hoc).