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.
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.
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.
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.
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.
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 | 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.
|
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. |
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.
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. |