Architecture

Identité d’une entité : aspect technique

Publié le : Auteur: Hugues VAN EYLEN Laisser un commentaire
Projection entité

Le précédent billet s’intéressait à la notion d’identité d’une entité d’un point de vue modélisation du métier. Dans ce nouveau billet on va ajouter la dimension technologique, regarder les objets informatiques qui sont utilisés pour représenter les entités et s’interroger sur la projection de la notion d’identité dans cette dimension.

Identité et architecture en couche

Pour concrétiser cette analyse, on va considérer une architecture d’application en couche classique et regarder la projection d’une entité sur cette architecture :

projection_entite

Chaque couche accueillera une vue de l’entité en regard des responsabilités que cette couche a à sa charge :

  • Persistance : cette couche a pour rôle de sauvegarder les données de l’entité au-delà de l’exécution de l’application qui a produit ces données. Elle est classiquement réalisée au travers de la technologie des bases de données et une entité devient en général une table.
  • Métier : cette couche a pour rôle de réaliser les traitements métier qui s’appuient sur les données des entités qu’ils manipulent au travers des règles métiers implémentées. Cette couche est classiquement réalisée dans un langage de programmation donné (Java, C++, Cobol, etc.) et une entité devient une classe Java, une structure Cobol, etc.
  • Services : cette couche a pour rôle de proposer une façade d’accès aux traitements métiers de granularités variées présents dans la couche métier et d’en assurer la distribution à la couche présentation ou à d’autres systèmes. Les services fournissent des vues sur les entités au travers des données d’entrées / sorties des opérations qu’ils proposent. Cette couche est souvent bâtie sur un middleware de distribution (WSDL, etc.) et une entité ou une vue sur cette entité devient un schéma XML, un fichier, un flux de données, etc. appelé aussi Data Transfer Object (DTO).
  • Présentation : cette couche a pour rôle de réaliser les interactions utilisateur et de gérer le dialogue homme-machine. Les entités deviennent ici des formulaires composés de champs présentant les données de l’entité. Ces formulaires sont construits dans un langage de programmation et les entités sont donc ici aussi des classes java, des divisions HTML, etc.

Cette architecture étant posée, intéressons-nous dans ce contexte aux différentes identités définies dans le billet précédent :

  • Identité interne publique : cette identité étant établie pour faciliter l’usage du système par ces acteurs, on retrouvera celle-ci dans toutes les couches :

o   Persistance : il s’agit ici d’une donnée de l’entité sur laquelle on placera probablement un index vu son usage de recherche. En revanche, pour respecter le principe d’encapsulation, cette identité ne doit pas être utilisée pour réaliser des clés étrangères au sein de la base. On peut en revanche placer la contrainte de donnée obligatoire vu qu’elle est de la responsabilité du système.

o   Métier : C’est la couche où les règles métiers sont réalisées et on trouve ici l’implémentation de la règle métier construisant cette identité interne publique. La garantie de l’unicité, du caractère obligatoire et de l’immuabilité sont du ressort de cette couche. L’identité est ici réalisée comme un attribut de la classe représentant l’entité.

o   Services : Pour cette couche, cette identité peut être utilisée pour réaliser des liens entre les vues des entités et être fournie aux consommateurs des services.

o   Présentation : L’objectif est que cette identité soit perçue des acteurs et qu’ils se basent dessus pour identifier de manière partagée avec le système l’entité sous-jacente. Cette identité doit donc être fournie aux acteurs et une interaction de recherche fermée sur cette identité doit être proposée.

  • Identité externe publique : cette identité est de la responsabilité de l’environnement du système et échappe à son contrôle.

o   Persistance : c’est une donnée de recherche sur laquelle un index aura son intérêt. En revanche, comme indiqué pour l’identité interne, cette identité ne doit jamais être utilisée comme contrainte de clé étrangère pour réaliser des liens entre tables.

o   Métier : les seules règles métier que l’on a à vérifier ici sont celles définies par le protocole de communication avec le système externe. Cela peut être une cause de rejet de l’entité fournie par ce système. Pour le reste cette identité deviendra soit un attribut soit une classe d’objet.

o   Services : Pour cette couche, l’identité externe est une donnée comme une autre. Toutefois, un service d’identification placé à la frontière avec ce système externe peut être proposé.

o   Présentation : c’est une donnée comme une autre mais qui peut intéresser plus particulièrement un utilisateur dont le travail de situe à la frontière avec le système externe.

  • Identité interne privée dont l’objectif est de réaliser les liens entre les entités :

o   Présentation : C’est un identifiant interne, il ne doit donc pas être divulgué à un acteur et par conséquent il ne doit apparaître dans aucun champ. Par ailleurs, les entités sont représentées ici par des objets d’IHM dans le langage de programmation retenu et ceux-ci possède une identité interne privée mais dont la portée est limité à la couche présentation. Bien sûr cette identité non plus ne doit pas être divulguée.

o   Services : Si on conçoit la portée des services comme dépassant l’intérieur du système ; i.e; comme étant proposé à des systèmes externes consommateurs, alors cette identité ne doit apparaître dans aucune des vues de cette couche sur les entités.

o   Métier : A ce niveau, la notion d’identité interne peut être multiple car le métier a en charge de reconstruire les entités dans le langage de programmation sous-jacent à partir des données relues en base de données. Le langage de programmation possède un identifiant technique interne et la couche persistance possèdera son propre identifiant. Des confusions et des problèmes peuvent apparaître ici (voir plus loin l’accès aux données).

o   Persistance : La responsabilité de produire cette identité interne privée doit être placée dans la couche de persistance réalisant le plus de liens entre entités puisque c’est la raison d’être de ce type d’identité. Ce sera donc ici, dans cette couche, que l’on place la responsabilité de  produire cette clé primaire et de s’en servir pour réaliser les contraintes de clé étrangères. On parle ici de clé technique.

Identité interne privée et système informatique d’entreprise

L’architecture en couche précédemment présentée se limitait sans vraiment le dire à une seule application informatique. Or un système informatique d’une entreprise est souvent composé de plusieurs applications. A-t-on alors plusieurs identités internes privées pour certaines des entités qui existent dans plusieurs de ces applications ? Dans un système non urbanisé, c’est la norme et amène son lot de problèmes :

  • Réaliser qu’une entité qui est présente dans deux applications correspond finalement la même réalité.
  • Réaliser des dépendances fortes entre deux applications via l’usage croisées de ces identités

Il faut donc se ramener à une seule identité interne privée de portée système informatique d’entreprise. La responsabilité de créer cette identité doit être ramenée au bloc fonctionnel en charge de la gestion de l’entité principale. Les entités ne sont pas toutes égales entre-elles. Il existe des entités racine qui représentent les points d’entrées du métier et des entités secondaires présentes uniquement parce que raccrochées à une entité principale qui en forme un agrégat. Le bloc gérant l’agrégat est responsable de l’ensemble des identités d’entités de ce bloc. Par exemple, on peut avoir un bloc Contrat et un bloc GED qui gère les documents attachés aux contrats et aux clients. Le lien entre Contrat (entité principale) et document (entité secondaire) doit être bâti sur un identifiant interne de la responsabilité du bloc Contrat et non du bloc GED qui peut par ailleurs avoir son propre identifiant interne qui doit, ici, rester de portée GED seulement. Cette pratique permet alors de changer de technologies de GED sans impacter le bloc Contrat par exemple.

Pour terminer sur ce focus, cette identité interne privée doit alors être présente dans une couche de service qui ici deviendrait de portée système. Il faut alors bien se garder de la divulguer au-delà des frontières du système informatique d’entreprise. Pour cela une taxonomie des services faisant apparaître les services d’échanges positionnés à la frontière couplée, à des règles de conception interdisant à ceux-ci de publier à l’extérieur cette identité interne, permet d’obtenir l’architecture souhaitée. Ce bloc sera en charge de la conversion d’une identité interne privée dans l’éventuelle identité externe publique si le système externe en propose une.

identiteInterneEtSysteme

Schématiquement, l’identité interne privée au système informatique d’entreprise est utilisé pour les échanges internes au système. On respecte ici la règle de responsabilité de gestion d’un agrégat qui donne au bloc le pouvoir de créer et garantir les caractéristiques de l’identifiant interne des entités principales. On protège les blocs–agrégat des blocs supportant des entités secondaires et pouvant utiliser des technologies dédiées. Pour terminer le bloc d’échanges externes a en charge la conversion avec les identités échangées avec l’extérieur.

Identité interne privée et accès aux données

Ce deuxième focus plonge plus avant dans la technique et particulièrement la technique dédiée à la réalisation de l’accès aux données mis en œuvre dans la couche métier. Le schéma suivant positionne la problématique :

identiteEtORM

Dans cette architecture, fondée sur une persistance en base relationnelle et un traitement de données en Java, une entité existe dans quatre objets informatiques :

  • En tant que ligne d’une table où son identité est définie par une clé primaire généralement agnostique du métier et pouvant servir d’identité interne privée.
  • En tant qu’objet lié à une session qui est un composant informatique chargé de réaliser la synchronisation entre une occurrence en table et l’objet du langage de programmation correspondant. Il masque la technique de chargement / déchargement d’objet à partir des tables.
  • En tant qu’objet détaché de cette session et qui par conséquent n’est plus synchronisé avec la ligne de la table lui correspondant.
  • En tant qu’objet transient qui n’est pas encore lié à la persistance et aucun lien avec la ligne de la table.

En termes d’identité, ce qui relie trois de ces objets est la valeur de la clé primaire renommé Id dans le programme. Pour l’objet transient c’est plus hasardeux car il ne possède pas de valeur pour cet Id. Par ailleurs, au sein de l’espace mémoire du programme, chaque objet possède sa propre identité interne au programme appelée ici référence. On voit donc ici que le problème va être de ne pas se mélanger les pinceaux avec les différentes copies de cette même entité pour éviter de perdre des données ou d’en dupliquer au gré de l’usage du système :

  • Pour la gestion des entités persistantes ; i.e dont l’id est valorisé, le composant de session propose généralement des fonctions de consolidation (merge) ou de rattachement. Un usage judicieux doit permettre d’éviter de perdre des données ou de dupliquer l’entité dans une deuxième ligne.
  • Pour la gestion de l’objet transient, ce n’est pas un problème technique mais fonctionnel qui doit alors s’appuyer sur une autre des identités de l’entité (interne visible, externe publique) ou même une recherche ouverte sur critères avec décision humaine si des ambiguïtés apparaissent pour être à même de retrouver l’équivalent persistant.

On peut enfin noter que cet exemple lié à une technologie précise ; ici une base de données relationnelle, est valable pour d’autres car à chaque fois que l’on met en place plusieurs technologies, chacune représente une entité dans ses structures et possède une identité technique. Il faut donc être à même de réaliser les correspondances entre plusieurs représentations d’une même entité au travers des couches technologiques de l’architecture choisie.

Conclusion

L’identité interne privée ne doit pas être confondue avec l’identité technique…. Toute identité interne privée est une identité technique mais l’inverse n’est pas vrai (i.e. la notion de référence d’objet java précédente). Le bloc fonctionnel responsable d’une entité principale a en charge la gestion de son identifiant interne privé qui sera généralement produit par la base de données sous-jacente. Cette identifiant peut être utilisé entre les blocs fonctionnels mais ne doit pas franchir les limites du système. Des services de recherche basés sur les identités internes visibles ou externes publiques sont mis en place et, à la frontière du système, des règles de conversion identité privé versus identité publique sont réalisées. On se rend compte finalement que l’on bien des choses à dire sur un concept qui peut sembler aussi simple que l’identité.