Règles

Détails de l'implémentation pour utiliser WSRR comme point de création de règle (PAP, Policy Authoring Point) et WebSphere DataPower comme point d'application de règles (PEP, Policy Enforcement Point) lorsque vous créez des règles de médiation.

Règles dans WSRR

Vous pouvez utiliser WSRR pour créer toutes les règles SOA, notamment les règles d'accord sur les niveaux de licence (SLA, Service Level Agreement), les règles de médiation, les règles de contrôle et les règles personnalisées. L'interface utilisateur de Business Space vous permet de créer, de mettre à jour ou de supprimer un document de règles dans WSRR. Le document de règles peut contenir une expression de règles qui spécifie plusieurs règles pour un domaine de règles spécifique. Vous pouvez également créer un document de règles qui rassemble des règles existantes issues d'autres documents. Les règles individuelles sont consultées à l'aide identificateurs de règles, que vous spécifiez lorsque vous ajoutez des règles à votre document. Une expression de règles représente la déclaration d'une règle. Elle est équivalente à un élément <wsp:Policy> contenu dans un document WS-Policy.

Pour créer une règle de médiation dans Business Space, voir Création de règles de médiation.

Assertions de règles de médiation

Les accords sur les niveaux de licence (SLA, Service Level Agreement) proviennent d'une exigence exprimée par l'entreprise pour laquelle la qualité de service fournie par un service répond à une norme spécifique. A mesure qu'un service se conçoit, des exigences fonctionnelles sont créées pour guider la logique de ce que le service a à réaliser. Parallèlement à cela, des exigences non fonctionnelles sont spécifiées dans le cadre de l'analyse et de la conception dudit service pour qualifier la qualité de service attendue avec la fourniture du service. Par exemple, l'entreprise peut avoir un service qui fournit des informations en réponse à une requête de client transmise par Internet. La cible consiste à renvoyer la réponse dans les 3 secondes. Dans le cadre d'une opération de transaction conduite de bout en bout, il a été déterminé que ce service doit renvoyer ses informations dans les 2 secondes pour satisfaire les exigences métier non fonctionnelles.

Vous pouvez écrire une règle qui implémente des contrôles d'exécution sur les performances du service et qui agit pour garantir que le service satisfait son SLA. Par exemple, vous pouvez avoir un noeud final principal de service qui est normalement en mesure (95% du temps) de fournir une réponse de service dans les 2 secondes. L'architecte SOA crée un noeud final secondaire sur un autre serveur qui peut être utilisé comme noeud de secours automatique en cas d'indisponibilités du noeud final principal, mais est également autorisé à être utilisé pour le trafic de dépassement lorsque le noeud final principal n'est pas en mesure de faire face à la charge des transactions. Vous pouvez écrire une règle qui vérifie le temps de réponse du service et réacheminent le trafic si nécessaire pour se conformer au SLA.

Voici un autre exemple de gestion des accords sur les niveaux de service (SLA) par le biais d'une régle d'exécution, prenons une situation dans laquelle un service répond à des transactions ayant différents consommateurs, chacun ayant un niveau de priorité différent. Un exemple simple peut comporter des consommateurs "Gold" et "Bronze", dans lequel l'entreprise garantit uniquement une qualité de service spécifique aux consommateurs "Gold". Dans cet exemple, vous pouvez vérifier que si le consommateur est "Gold", il est réacheminé vers le noeud final secondaire, alors que nous laissons le consommateur "Bronze" être confronté à des temps de réponse plus longs. L'entreprise a pris cette décision car le revenu incrémentiel des consommateurs "Bronze" est insuffisant pour justifier des frais associés à des temps de réponse d'ingénierie permettant de répondre au SLA des consommateurs "Gold".

Dans un troisième exemple, vous pouvez identifier une situation dans laquelle un service conduit au mieux ses opérations, mais lorsque celui-ci détermine qu'il est phase de chargement, il se voit contraint de mettre en file d'attente voire de refuser des messages issus de services consommateurs à priorité faible. Prenons comme exemple, une routine en traitement par lots qui inonde le système avec des demandes de consommateurs à un moment inattendu. Afin de protéger la qualité de service du service, vous pouvez créer une règle d'exécution qui est active uniquement pendant les heures ouvrables et qui rejette toutes les demandes en traitement par lots arrivant durant cette période.

Plus généralement, la règle de médiation prend en compte la validation et la transformation sur le message entrant provenant du client (consommateur) avant sa présentation au serveur (fournisseur).

Règles prenant en charge ce type de validation et de transformation de messages. Il est possible de spécifier des règles pour un service de fournisseur uniquement, pour une paire consommateur-fournisseur spécifique ou pour des consommateurs anonymes en rapport avec un service de fournisseur. Les règles destinées aux consommateurs anonymes offrent un moyen de définir une règle par défaut qui s'applique uniquement à des consommateurs pour lesquels aucune autre règle ne s'applique. Cette caractéristique va permettre à des règles d'être spécifiées pour des consommateurs indésirables qui ne s'identifient pas eux-mêmes. De tels services de consommateurs peuvent très bien avoir ensuite leurs transactions rejetées. Ceci peut s'avérer utile pour prévenir une attaque par saturation de pirates informatiques tentant d'inonder le système avec les transactions visant à abattre le service d'un fournisseur.

Conditions de règle de médiation

Des assertions de médiation peuvent être effectuées, ce qui permet à une règle d'exécution de contrôler l'accord sur les niveaux de service (SLA) du service, la transformation des messages du consommateur au fournisseur ou de valider le schéma du message du consommateur.

Les conditions de règles d'accord sur les niveaux de service (SLA), un type spécifique de règle de médiation, tiennent compte effectivement d'une construction classique "if-then-else" avec une condition, puis d'un ensemble d'actions à exécuter selon le mode d'évaluation de la condition. La spécification d'une condition est facultative. Si aucune condition n'est spécifiée, il s'agit alors d'une opération équivalente à une condition logique d'évaluation à True et toutes les actions spécifiées sont mises en application en conséquence.

Si spécifiée, la condition doit être une expression booléenne ou une spécification de planification ou la condition peut inclure les deux.

Planification

Si spécifiée, la planification identifie les moments où la règle s'applique. Les dates et l'heure sont évaluées par le point d'application de règles (PEP, Policy Enforcement Point) local et le fuseau horaire du point d'application de règles. Si aucune planification n'est spécifiée, la règle démarre dès qu'elle est téléchargée du point de création de règles (PAP, Policy Authoring Point) au point d'application de règles (PEP, Policy Enforcement Point), et se poursuit indéfiniment.

La planification définit une date de démarrage et une date d'arrêt, toutes deux facultatives, une période quotidienne facultative et une liste facultative de jours de la semaine. Par exemple, vous pouvez définir une planification devenant effective du 1er octobre 2012 au 30 octobre 2012, de 8h00 à 17h00 les mercredis et dimanches.

Les paramètres de planification qui peuvent être indiqués sont les suivantes :
  • StartDate - Cet attribut facultatif indique la date au format xs:date à laquelle la planification devient effective. L'attribut StartDate est inclusif et s'il est maquant, la planification devient effective immédiatement ce jour même. (Cliquez sur le lien hypertexte xs:heure pour vous informer sur cette norme de l'industrie).
  • StopDate - Cet attribut facultatif indique la date au format xs:date à laquelle la planification cesse d'être effective. La date de fin est exclusive et la date spécifiée doit être postérieure à la date de début. Si la date de fin est antérieure ou identique à la date de départ, la planification ne démarre jamais. Si cet attribut est manquant, la planification est effective indéfiniment.
  • Daily (Quotidien) - Cet élément facultatif indique la période quotidienne durant laquelle la planification est effective. Si cet attribut est manquant, la planification est effective toute la journée.
    • StartTime (Heure de début) – Si l'attribut Daily est spécifié, l'attribut StartTime est obligatoire. Il indique, au format xs:heure, l'heure à laquelle la planification démarre chaque jour. (Cliquez sur le lien hypertexte xs:heure pour vous informer sur cette norme de l'industrie).
    • StopTime (Heure de fin) – Si l'attribut Daily est spécifié, l'attribut StopTime est obligatoire. Il indique, au format xs:heure, l'heure à laquelle la planification s'arrête chaque jour. L'attribut StopTime est exclusif et si l'heure spécifiée est antérieure ou identique à l'heure de début quotidienne, la planification s'arrête le jour suivant à l'heure de fin spécifiée.
  • Weekdays (Jours de semaine) - Cet attribut facultatif indique les jours de la semaine inclus dans la planification. Si cet attribut est manquant, tous les jours de la semaine sont compris dans la planification. Cet attribut n'affecte que le début de la période quotidienne puisque l'exécution des planifications est autorisée une fois passé minuit. Par exemple, si une planification est définie pour démarrer à 23 heures et s'exécuter pendant 2 heures les mercredis, la planification se termine en réalité le jeudi à 01h00.
    • Days (Jours) - Si l'attribut Weekdays est spécifié, cet attribut est obligatoire. Il répertorie les jours de la semaine inclus dans la planification, sous la forme d'une liste de noms séparés par le signe ('+'), par exemple "Monday+Tuesday+Wednesday+Thursday+Friday+Saturday+Sunday" (lundi+mardi+mercredi+jeudi+vendredi+samedi+dimanche).

Expression de condition d'une règle de médiation

L'expression de condition, si spécifiée, est un élément non répétitif qui indique une expression booléenne.

L'expression se compose de trois paramètres (un attribut, un opérateur et une valeur) plus deux paramètres facultatifs d'intervalle et de limite. Si l'application de l'opérateur sur l'attribut et la valeur, plus l'intervalle et la limite, le cas échéant, s'évalue à True, l'expression est évaluée à True (Vrai). L'élément de limite n'est utilisé qu'avec les opérateurs HighLow et TokenBucket. Si non spécifiée, la valeur de Limit est 0. Si Interval n'est pas spécifié, la valeur par défaut est 60 secondes.

Les paramètres de l'expression peuvent être spécifiés comme suit :
  • Attribut - Le tableau suivant récapitule les attributs définis et leur type.
    Tableau 1. Attributs définis
    Attribut Description et Type
    ErrorCount Nombre d'erreurs observées au cours de cet intervalle de contrôle.
    MessageCount Nombre de messages réels interceptés au cours de l'intervalle de contrôle.
    InternalLatency Temps d'attente interne (temps de traitement) en secondes.
    BackendLatency Temps d'attente du dispositif au serveur, exprimé en secondes.
    TotalLatency Le total des temps d'attente d'arrière plan et interne, exprimé en secondes.
  • Opérateur - Le tableau suivant récapitule les opérateurs disponibles et leur signification :
    Tableau 2. opérateurs
    Opérateur Signification
    GreaterThan Algorithme numérique simple qui évalue à True lorsque l'attribut est supérieur à la valeur définie.
    LessThan Algorithme numérique simple qui évalue à True lorsque l'attribut est inférieur à la valeur définie.
    TokenBucket Algorithme basé sur le taux qui autorise des pics. L'algorithme est constitué d'une pile contenant une capacité maximale de jetons Limite. La pile se remplit à une vitesse constante de jetons Valeur par Intervalle, alors que pour chaque unité d'Attribut, un jeton est retiré. Cet algorithme renvoie la valeur True lorsqu'il n'y a pas de jetons dans la pile, sinon renvoie la valeur False. Voici un exemple permettant d'expliquer l'algorithme : supposons que Limite=100, Valeur=5, Intervalle=1 seconde et Attribut=MessageCount.
    1. La pile démarre pleine avec une capacité maximale de 100 jetons.
    2. A l'arrivée d'un message, l'algorithme vérifie si la pile possède des jetons.
      1. Si c'est le cas, l'algorithme renvoie False (Faux) et un seul jeton est retiré de la pile
      2. Sinon, l'algorithme renvoie True.
    3. Ce faisant, toutes les secondes, l'algorithme rajoute 5 jetons à la pile tant qu'il reste de la place.
    HighLow Algorithme qui renvoie True si l'attribut atteint le seuil supérieur spécifié comme valeur, puis continue de renvoyer True jusqu'à ce que Attribut atteigne le seuil bas spécifié comme Limite.
  • Value (Valeur) – Il s'agit d'un élément entier positif. "0" (zéro) est une valeur valide.
  • Interval - Cet élément facultatif définit l'intervalle de temps, utilisé comme une fenêtre dynamique, pour mesurer l'attribut wsme:Attribute lors de l'évaluation de l'expression, au format xs:durée. Si non spécifié, l'intervalle utilisé est de 60 secondes. Si indiqué, il convient de spécifier une valeur raisonnable, prenant en compte les fonctions configurées du point d'application de règles (PEP). Autrement dit, plus la valeur est élevée, plus le point d'application de règles requiert de mémoire pour conserver une trace de l'attribut. (Cliquez sur le lien hypertexte xs:durée pour vous informer sur cette norme de l'industrie).
  • Limit (Limite) - Cet élément entier facultatif définit l'argument Limite supplémentaire requis lorsque wsme:Operator est TokenBucket ou HighLow. L'unité dépend de la spécification de wsme:Operator.

    Si wsme:Operator est HighLow, ceci définit le seuil bas tandis que wsme:Value définit le seuil haut. Le seuil spécifié doit être inférieur à wsme:Value. Sans spécification de ce type, la valeur par défaut de Limite est 0 (zéro).

    Si wsme:Operator est TokenBucket, il définit la taille maximale de la rafale ou le nombre maximal de jetons dans la pile, alors Valeur indique la vitesse à laquelle la pile se remplit, en nombre de jetons par intervalle. Si non spécifié, la valeur par défaut de Limite est 0 (zéro) et TokenBucket est alors équivalent à une opération GreaterThan.

Action d'une règle de médiation

L'élément Mediation Action (action de médiation) indique les actions à entreprendre. Bien que la syntaxe autorise de nombreuses combinaisons, celles-ci ne sont pas toutes significatives et lorsque des actions en conflit sont spécifiées, comme demander qu'un message soit à la fois mis en file d'attente et supprimé, le point de création de règles rejette ce comportement. Les actions de la règle de médiation autorisées sont les suivantes :
  • QueueMessage – Cette action indique que des transactions sont mises en file d'attente si la condition logique est satisfaite. Le traitement de message n'est pas reconduit tant que la condition logique est satisfaite. La méthodologie de file d'attente et tous les délais d'attente associés sont comme définis par le point d'application de règles (PEP), dans ce cas WebSphere DataPower. Lorsque plusieurs actions sont spécifiées, au sein d'un même élément Action, QueueMessage doit être la première action.
  • RejectMessage – Cette action indique que des transactions sont rejetées si la condition logique est satisfaite. Les transactions continuent d'être rejetées tant que la condition logique est satisfaite. Lorsque des transactions sont rejetées, une erreur SOAP est renvoyée au service client (consommateur). Lorsque plusieurs actions sont spécifiées, au sein d'un même élément Action, RejectMessage doit être la première action. QueueMessage et RejectMessage sont mutuellement exclusif.
  • Notify - Cet élément facultatif indique qu'une notification se produit si la condition logique est satisfaite. Pour DataPower, un message est écrit dans le journal système de DataPower.
  • RouteMessage - Cet élément facultatif indique que des messages sont acheminés vers une destination de noeud final spécifiée si la condition logique est satisfaite. Les messages continuent à être acheminés vers le noeud final spécifié tant que la condition logique est satisfaite.
    • EndPoint – Ce paramètre est obligatoire si une action de RouteMessage est spécifiée. La valeur du noeud final prise en charge peut être une adresse IP, un nom d'hôte ou un hôte virtuel, comme un groupe d'équilibreurs de charge.
  • ValidateMessage - Cet élément facultatif indique que des messages est validé par rapport à la grammaire spécifiée. Les messages sont refusés lorsque la validation échoue. Vous devez indiquer XSD ou WSDL comme sous-paramètre si ValidateMessage est spécifié. SCOPE est facultatif et s'il n'est pas spécifié, SOAPBody est alors utilisé pour la validation.
    • XSD - Indique que des messages sont validés par rapport au schéma XML identifié par l'identificateur URI qu'il contient.
    • WSDL - Indique que des messages sont validés par rapport à la description de service Web (WSDL) identifié par l'identificateur URI qu'elle contient.
    • SCOPE – Indique quelle partie du message est validée. Le tableau suivant répertorie les valeurs possibles et leur signification :
      Tableau 3. Eléments ValidateMessage
      Valeur Description
      SOAPBody Contenu de l'élément Body de SOAP, sans traitement particulier pour les erreurs de SOAP. (Par défaut)
      SOAPBodyOrDetails Contenu de l'élément Details pour les erreurs SOAP, sinon le contenu de Body de SOAP.
      SOAPEnvelope Message SOAP complet, y compris l'enveloppe.
      SOAPIgnoreFaults Aucune validation si le message est une erreur SOAP, sinon contenu de Body de SOAP.
  • ExecuteXSL - Indique qu'une transformation XSL doit être exécutée avec la feuille de style et les paramètres spécifiés. Les transactions sont rejetées si l'exécution échoue. Les informations de feuille de style doivent être spécifiée, tandis que les paramètres sont facultatifs et doivent être indiqués si nécessaire par la feuille de style particulière spécifiée.
    • Stylesheet - Indique que l'opération de transformation utilise la feuille de style spécifiée par l'identificateur URI contenu. La feuille de style DOIT être un fichier XSLT.
    • Parameter - Cet élément répétitif facultatif spécifie qu'un paramètre de feuille de style doit être utilisé pour l'opération ExecuteXSL.
      • Name – Cet attribut est obligatoire pour chaque paramètre Parameter correspondant et donne le nom du paramètre.
      • Value – Cet attribut est obligatoire pour chaque paramètre Name correspondant et donne la valeur du paramètre.

Concept Concept

Commentaires


Icône d'horodatage Dernière révision: Thursday, 13 March 2014


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr25.doc/topics/csoa2_SOA_implementation.htm