Utilisateur:WikitPP/Brouillon

Anti-patron SOA

Architectures Orientées Services

Une Architecture orientée services (notée SOA pour Services Oriented Architecture) est une architecture logicielle s'appuyant sur un ensemble de services simples. Les web services disposent de ce type d'architecture. L'objectif d'une architecture orientée services est donc de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des composants, et de décrire finement le schéma d'interaction entre ces services. Un service doit répondre à un besoin métier précis. Il doit être au maximum disponible sur le réseau, et être autonome.

L'architecture SOA utilise différentes technologies de service distribué telles que REST, ou SOAP. L'ensemble des spécifications que doit adopter un SOA sont formalisées par le service component architecture (SCA) qui sont des standards proposés par le consortium OASIS. Mais ces spécifications ne décrivent pas l'architecture de l'application, ni sa gestion pendant l'exécution tels que le monitoring ou la reconfiguration.

Anti-patron

Les anti-patrons sont à des erreurs courantes d'implémentation et de conception des logiciels. Comme les autres architectures, les web services évoluent due aux exigences de l'utilisateur et du contexte, introduisant des anti-patrons dans le code. Les anti-patrons s'opposent à une conception utilisant des patrons de conception, désignés le plus souvent par le terme anglais design pattern.

Les effets dus aux anti-patrons dans les architectures orientées services sont une dégradation du design logiciel, de la qualité du service (QdS), comme les problèmes de mise à l'échelle, performance et sécurité. Ils entraînent aussi une difficulté de maintenance et d'évolution pour l'application.

Dans les systèmes orientés objets, les patterns concernent les classes, alors que dans les services orientés architectures (SOA) les patterns concernent les services. Les SOA doivent donc avoir des patterns qui leurs sont propres.

Spécification

Plusieures mesures permettent de spécifier chaque anti-patron, dont certaines transverses à plusieurs d'entre eux. Un langage spécifique (DSL) permet de définir des propriétés propres au domaine des SOA.

Métriques statiques

Les propriétés statiques qui participent à la définition d'un anti-patron SOA, sont le design, la cohésion, et le couplage. Voici une liste de propriétés à prendre en considération pour décrire un SOA, avec leur acronyme anglais. Le premier élément "ALS" est un acronyme utilisé dans le modèle d'antipattern utilisant la grammaire BNF, et correspond par exemple à Average Length Service qui se traduit par taille moyenne du service.

• (ALS) taille des signatures
• (ARIP) ratio moyen de ports identiques
• (ARIO) ration moyen des opérations identiques
• (ARIM) ration moyen de messages identiques
• (NCO) nombre d'opérations CRUD
• (NOPT) nombre d'opérations dans un port type
• (NPT) nombre de types de port
• (NVMS) nombre de verbes dans les signatures d'un message
• (NVOS) nombre de verbes dans les signatures d'une opération
• (RGTS) ratio de termes dans les signatures

• (ANP) nombre de paramètres d'une méthode"
• (ANPT) nombre des différents types de paramètre
• (NOD) nombre d'opérations
• (ANIO) nombre moyen d'opérations identiques
• (ANAO) nombre moyens d'accesseurs

• (CPL) couplage
• (COH) cohésion

Métriques dynamiques

Les métriques dynamiques caractérisent l'exécution du WS .

• (A) disponibilité
• (RT) temps de réponse

Représentation

La détection automatique d'anti-patrons a été expérimenté plusieurs fois. Une des approches, consiste à associer le code source d'une application vers un langage abstrait intermédiaire permettant d'être indépendant du langage d'implémentation d'un web service.

Grammaire BNF

La spécification d'un anti-patron est un modèle hiérarchique de règles avec des propriétés plus ou moins élevées. Les propriétés d'utilisation et conception d'un SOA sont mesurées. Pour déterminer à quelle antipattern peuvent correspondre ces mesures, un méta-langage permet de les mettre en relation. Il se base sur un ensemble de règles qui définissent quelles sont les mesures et valeurs cibles. Un ordre de grandeur permet de définir si une mesure sera faible ou forte, par exemple "RT = HIGH".

La grammaire BNF est le méta-langage utilisé pour la traduction d'anti-patrons dans la plus part des cas. L'exemple de grammaire BNF suivante décrit un anti-patron de manière générique :

rule card ::= RULE CARD:rule cardName { (rule)+ };
rule ::= RULE:ruleName { content rule };
content rule ::= operator rule rule | property | relationship
operator ::= INTER | UNION | DIFF | INCL | NEG
property ::= METRIC id metric metric value fuzziness | LEXIC id lexic ((lexic value,)+) | STRUCT id struct
id metric ::= DIT | NINTERF | NMNOPARAM | LCOM | LOC METHOD | LOC CLASS | NAD | NMD | NACC | NPRIVFIELD | id metric + id metric | id metric - id metric
value metric ::= VERY HIGH | HIGH | MEDIUM | LOW | VERY LOW | NUMBER
id lexic ::= CLASS NAME | INTERFACE NAME | METHOD NAME | FIELD NAME | PARAMETER NAME
id struct ::= USE GLOBAL VARIABLE | NO POLYMORPHISM | IS DATACLASS | ABSTRACT CLASS | ACCESSOR METHOD | FUNCTION CLASS | FUNCTION METHOD | STATIC METHOD | PROTECTED METHOD | OVERRIDDEN METHOD | INHERITED METHOD | INHERITED VARIABLE
relationship ::= rel name FROM rule cardinality TO rule cardinality
rel name ::= ASSOC | AGGREG | COMPOS
cardinality ::= ONE | MANY | ONE OR MANY | OPTIONNALY ONE
rule cardName, ruleNam

Détection

La résolution des anti-patrons permet d'améliorer la maintenance et l'évolution des SOA. Tout comme au niveau industriel, un logiciel peut être soumis à un contrôle de qualité via différents indicateurs. La qualité des SOA repose sur la détection de défauts d'architecture, et de dynamicité.

Les attributs internes peuvent être mesurés très tôt dans le cycle de développement, et de façon régulière. Par prédiction aussi, des actions correctives peuvent être entreprises lors de l'implémentation, réduisant le coût de la maintenance dans le futur.

Les spécifications d'un anti-patron sont utilisées pour sa détection. Le code doit ainsi avoir une taille raisonnable et proportionnelle à la complexité des traitements. La complexité des algorithmes doit être minimisée.

Le temps de réponse, et de disponibilité entrent en considération dans les spécifications de plusieurs anti-patrons, et sont cruciaux. Pour ces deux caractéristiques, la détection d'une mauvaise qualité de service s'effectue dynamiquement par invocation du SOA. Cette technique permet de s'affranchir des tâches de collecte et de filtrage des données d'introspection ou d'exécution interne.

Introspection de code

Les défauts de design sont identifiables statiquement par introspection du code. Cette technique permet d'en déduire la structure de l'application. Les interfaces permettent d'avoir un modèle simple du service comprenant une grande partie des spécifications.

L'analyse des ports, opérations ou messages s'appuie sur la structure et la signification du code. La structure d'une application composée de plusieurs services, est évaluée par comparaison des mesures telles que les ports, opérations, messages à l'intérieur ou entre plusieurs service. Lors du traitement le code est considéré comme de simples chaînes de caractères. La comparaison se base sur une formule de distance entre deux éléments analysés, telle que la distance de Levenstein entre deux chaînes de caractères.

La signification des éléments doit également être prise en compte dans leur analyse, en plus de la comparaison syntaxique. Des mots différents utilisés dans le code peuvent avoir des significations identiques. Les outils lexicaux WordNet ou CoreNLP permettent d'évaluer la signification des structures en regroupant les noms, adjectifs ou les synonymes entre eux. C'est une analyse sémantique.

Une solution alternative a été développé dans le cadre de la détection de patrons de conception au coeur d'applications d'envergure. L'introspection repose cette fois sur des requêtes SQL, couplées à des REGEX.

Fouille des traces d'exécution

Un mécanisme se base sur les traces d'exécution d'une application pour les objets suivants : association, héritage, classe abstraite, appel de méthode abstraite. Les traces d'exécution obtenues sont représentées sous forme de graphes et matrices qui sont comparées aux patrons de conception provenant du GoF (Gang of Four) préalablement modélisés avec ce même format de données. L'algorithme de comparaison se base sur un score de similarité pour identifier les candidats qui varient par rapport au patrons de conception architecturaux d'origine.

Une solution alternative se base sur un processus de détection dynamique de patrons de conception comportementaux. Un processus de rétro-ingénierie parcourt les traces d'exécution pour reconstruire un diagramme de scénarios sur l'application en cours d'analyse. Le principe consiste à comparer les diagrammes des patrons de conception d'origines avec les diagrammes extraits des traces d'exécution, en se basant une définition de similarité pour identifier les ressemblances.

Résultats

Pour définir l'ordre de grandeur d'une mesure détectée, il faut d'abord conserver les valeurs les plus représentatives. La propriété aura une valeur qui peut s'obtenir avec la technique du boxplot appliquée aux résultats et traduite grâce à l'échelle de Likert. Le boxplot permet de comparer les valeurs des métriques pour différentes classes et, ou systèmes, sans avoir à fixer de seuils artificiels. Il permet d’identifier également les valeurs extrêmes des métriques lorsque celles-ci elle sont en dehors des queues du boxplot. Cependant, le boxplot ne résout pas complètement le problème des seuils. Un degré de logique permet de pallier ce problème en spécifiant une marge acceptable autour des seuils identifiés, ce qui permet d'inclure les valeurs proches de la valeur seuil.

Empiriquement la détection d'anti-patron est possible. SODA (Service Oriented Detection for Antipatterns) basée sur le framework SOFA, est un outil de détection actuellement viable. Testé sur un ensemble de WSs au cours de travaux de recherche, SODA obtient une précision supérieur à 90% et un rappel de 100% lors de la détection.

Antipatterns SOA

DataService

DataService alias Dataclass dans les systèmes orientés objets correspond à un service qui contient principalement des accesseurs (Getteurs et Setteurs). Dans les applications distribuées, il peut y avoir certain services qui réalisent de simple récupération ou accède à des données à ses services à partir de ce service. DataServices contiennent habituellement des méthodes d’accès avec de petit paramètre de types primitifs. Ces services ont une forte cohésion des données.

RULE CARD: DataService {
     RULE: DataService {INTER HighDataAccessor SmallParameter PrimitiveParameter HighCohesion};
     RULE: SmallParameter {ANP LOW};
     RULE: PrimitiveParameter {ANPT HIGH};
     RULE: HighDataAccessor {ANAM VERY HIGH};
     RULE: HighCohesion {COH HIGH};
};

TheKnot

TheKnot est un ensemble de service avec une faible cohésion qui sont fermement accouplé. Ces services sont peu réutilisable. Due à une architecture complexe, leur temps de réponse est très grand et leurs disponibilités faibles.

RULE CARD: TheKnot {
     RULE: TheKnot {INTER HighCoupling LowCohesion LowAvailability HighResponse};
     RULE: HighCoupling {CPL VERY HIGH};
     RULE: LowCohesion {COH VERY LOW};
     RULE: LowAvailability {A LOW};
     RULE: HighResponse {RT HIGH};
};

ChattyService

ChattyService correspond à plusieurs services qui échange énormément de petite données de type primitif habituellement avec un l'anti-patron DataService. Il est aussi caractérisé par un nombre important d'invocations de méthode. Les anti-patrons ChattyService échange énormément entre eux.

RULE CARD: ChattyService {
     RULE: ChattyService { INTER TotalInvocation DSRuleCard};
     RULE: DSRuleCard {RULE CARD: DataService};
     RULE: TotalInvocation {NMI VERY HIGH};
};

NobodyHome

NobodyHome correspond à un service défini mais jamais utilisé par les clients. Les méthodes du service ne sont jamais invoquées même si elles sont couplées avec d'autres services. Pourtant il nécessite encore des déploiements ainsi que sa gestion malgré sa non-utilisation.

RULE CARD: NobodyHome {
     RULE: NobodyHome {INTER IncomingReference MethodInvocation};
     RULE: IncomingReference {NIR GREATER 0};
     RULE: MethodInvocation {NMI EQUAL 0};
};

BottleneckService

BottleneckService est un service très utilisé par d'autre services ou clients. Il possède une forte cohésion entrante et sortante. Son temps de réponse peut être élevé parce qu'il peut être utilisé par de nombreux clients extérieurs, lesquels ont besoin d'attendre pour avoir accès a ce service. Cependant, sa disponibilité doit être faible du au trafic.

RULE CARD: BottleneckService {
     RULE: BottleneckService {INTER LowPerformance HighCoupling};
     RULE: LowPerformance {INTER LowAvailability HighResponse};
     RULE: HighResponse {RT HIGH};
     RULE: LowAvailability {A LOW};
     RULE: HighCoupling {CPL VERY HIGH};
};

SandPile

SandPile est aussi connu sous le nom de "Fine-Grained Services". Il apparaît quand un service est composé de multiples petits services partageant une donnée commune, ce qui se traduit par une forte cohésion.

RULE CARD: SandPile {
     RULE: SandPile {COMPOS FROM ParentService ONE TO ChildService MANY};
     RULE: ChildService {ASSOC FROM ContainedService MANY TO DataSource ONE};
     RULE: ParentService {COH HIGH};
     RULE: DataSource {RULE CARD: DataService};
     RULE: ContainedService {NRO > 1};
};

ServiceChain

ServiceChain alias MessageChain dans les systèmes orientés objets corresponds à une chaîne de service. Le ServiceChain apparaît lorsque les clients demandent des invocations de services consécutifs pour atteindre leurs objectifs. Ce genre de chaîne de dépendance reflète l'invocation ultérieure de services.

RULE CARD: ServiceChain {
     RULE: ServiceChain {INTER TransitiveInvocation LowAvailability};
     RULE: TransitiveInvocation {NTMI VERY HIGH};
     RULE: LowAvailability {A LOW};
};