Détection d'anti-patrons de conception dans les 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 services web 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[1]. Mais ces spécifications ne décrivent pas l'architecture de l'application, ni sa gestion pendant l'exécution, tel que le monitoring ou la reconfiguration[2].

Les anti-patrons sont des erreurs courantes d'implémentation et de conception des logiciels[3]. Comme les autres architectures, les web services évoluent dû 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)[4], 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 architectures orientées services (SOA) les patterns concernent les services. Les SOA doivent donc avoir des patterns qui leur sont propres[5].

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 abréviation en anglais. Le premier élément « ALS » est une abréviation utilisée dans le modèle d'anti-patron 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

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

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

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 service web[6].

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 anti-patron 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 plupart des cas. L'exemple de grammaire BNF suivant 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

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 services. 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ée dans le cadre de la détection de patrons de conception au cœur d'applications d'envergure. L'introspection repose cette fois sur des requêtes SQL, couplées à des expressions rationnelles.

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[7]. L'algorithme de comparaison se base sur un score de similarité pour identifier les candidats qui varient par rapport aux 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[8].

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 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[9] 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 services web au cours de travaux de recherche[10], SODA obtient une précision supérieure à 90% et un rappel de 100% lors de la détection.

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 certains services qui réalisent de simples récupérations ou accèdent à des données. Les DataServices contiennent habituellement des méthodes d’accès avec de petits paramètres 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 est un ensemble de services avec une faible cohésion qui sont fermement couplés. Ces services sont peu réutilisables. En raison d'une architecture complexe, leur temps de réponse est très grand et leur disponibilité faible.

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 correspond à plusieurs services qui échangent énormément de petites données de type primitif habituellement avec un anti-patron DataService. Il est aussi caractérisé par un nombre important d'invocations de méthode. Les anti-patrons ChattyService échangent énormément entre eux.

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

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 est un service très utilisé par d'autres 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 à cause du 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 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 alias MessageChain dans les systèmes orientés objet correspond à 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înes de dépendances 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};
};