Passionné de nouvelles technologies...
la mise en place d'architecture de services informatisés est mon métier...
L'émergence et la popularité grandissante des technologies objet (méthodes, architectures et langages) influence fortement l'agencement des systèmes. La mise en place d'un nouveau système doit être progressive, faisant migrer les systèmes actuels vers de nouvelles architectures (CORBA, ActiveX COM/DCOM, JavaBeans RMI).
Les architectures de ces nouveaux systèmes doivent mettre en avant le respect des
concepts immanents objet afin de garantir l'obtention des
facteurs qualité.
Les architectures actuelles visent l'interopérabilité des systèmes et des Hommes tout en respectant l'identité et les origines de chacun.
Chaque métier (Banques, Informatiques, Constructeurs de matériel, Éleveurs,
etc.) met à la disposition d'autres métiers un ensemble d'objets capables d'interagir entre eux, ou d'être assemblés et spécialisés pour répondre aux besoins spécifiques de chacun. L'objectif étant de pouvoir fournir rapidement une multitude de services intégrables et adaptables pour chaque spécificité de métier, pour chaque organisation, pour chaque politique et stratégie de société.
Deux stratégies peuvent être envisagée :
- parler le même langage, adopter un comportement identique, et s'associer autours d'une architecture et d'une politique commune,
- fournir des interfaces de conversion pour permettre à des systèmes hétérogènes d'interopérer.
L'optimum se situe probablement à mis chemin entre ces deux extrêmes. Créer des systèmes spécifiques capables de communiquer facilement entre eux.
L'évolution des systèmes ont fait apparaître dans un premier temps des protocoles de communication standards (Réseau TCP/IP, HTTP, IIOP etc.), des spécifications d'interface standards (IDL, HTML, Interfaces ActiveX ou JavaBean etc.) et des passerelles d'interaction ou modules de conversion adaptés aux particularités de chaque système.
Architecture de services d'objets distribués
-
L'Objet client est pro-actif. Il exprime des besoins. Il est demandeur de services.
-
L'Annuaire des communications permet de retrouver l'Objet serveur délivrant le service demandé
par l'Objet client. Il se base sur les catalogues des services et/ou les catalogues des objets. Il met en communication un
Objet client avec un Objet serveur.
Il a la responsabilité de synchroniser les différentes demandes de service appartenant à une même
transaction.
L'identification des acteurs, de leurs affectations fonctionnelles et
de leurs localisations permet de paramétrer l'accès aux objets et à leurs services,
la distribution de ces objets et la temporisation des demandes de service.
Il est ainsi possible de découpler les objets et services métier de l'organisation opérationnelle et fonctionnelle, et de réguler les flux de travail.
Le service initial d'accès aux objets est l'identification d'un acteur.
Cette objet acteur identifié habilitera l'accès aux objets et à leurs services.
-
Le Catalogue des services recense l'ensemble des services des objets. Il connaît l'identification et localisation de chaque objet de son catalogue.
Il intègre la procédure à suivre pour transmettre une demande de service à un objet (Protocole de communication).
-
L'Objet serveur est spécialisé, distribué, distant et indépendant. Il répond aux demandes de service de ses Objets clients. Ses demandes de service sont conformes aux spécifications inscrites dans les
Catalogues de services. L'Objet serveur s'identifie, se localise et décrit ses services dans des catalogues des services et/ou des catalogues d'objets.
Un même objet peut être tantôt client (demandeur de services), tantôt serveur (fournisseur de service). Il cumule les propriétés des objets client et des objets serveur.
Pour déléguer un service , il nous faut
- identifier le service => Annuaire des services d'objets disponibles,
- identifier les objets capables de rendre ce service => Annuaire des services d'objets,
- connaître les conditions de souscription au service => Règles d'acceptation des demandes de service par le Serveur,
- sélectionner un objet => Règles de sélection de services par le Client,
- demander le service => Protocole de communication entre le Client et le Serveur,
- recevoir l'accusé de prise en compte du service => Synchronisation des demandes de service
Dans une architecture objet on ne différencie pas les notions de client (maître) et de serveur (esclave). Chaque objet est tantôt client tantôt serveur.
On peut en déduire que chaque objet doit
- créer des objets,
- référencer des objets,
- s'identifier dans un ou plusieurs Annuaire de services,
- préciser dans quelles conditions il accepte de rendre chaque service,
- réceptionner et synchroniser les demandes de service,
- savoir interroger chaque serveur pour déterminer les conditions d'obtention d'un service,
- savoir formuler une demande de service adaptée aux conditions du serveur,
- recevoir un accusée de prise en compte du service,
- détruire ses objets.
Une infrastructure de communication doit permettre transmettre et de synchroniser les demandes de service dans des conditions acceptables.
Les principes d'architecture de services sont cohérents avec les principes de gestion de production.
Chaque objet
- a un identifiant unique complété par un numéro d'archive,
- est cataloguée dans des annuaires de services,
- décrit ses services et ses conditions d'exploitation (introspection),
- peut être référencé d'autres objets,
- peut référencer plusieurs objets,
- est persistant,
- n'a d'existence que parce qu'il est référencé par au moins un autre objet,
- présente une séparation claire entre l'interface et l'implémentation,
- permet une abstraction simplificatrice de ses mécanismes et de son architecture.
Objet
Un objet est
ACIDe. Un objet rend au moins un service.
Un objet est identifié de manière unique, non ambiguë. L'identification d'un objet est identique durant toute sa durée de vie.
Un objet présente un ensemble de propriétés :
- d'introspection : fournir son identifiant, présenter ses services et leurs caractéristiques d'utilisation),
- d'interaction : recevoir et émettre des
messages synchrones ou asynchrones),
- de composition ou d'assemblage avec d'autres objets avec réacheminement de message vers les objets assemblés,
- de persistance.
Un objet est généralement hébergé dans un ou plusieurs
serveurs d'objet.
Serveur d'objets
Un serveur d'objet est un
objet qui a pour responsabilité de fournir une interface de manipulation des objets qu'il est susceptible d'héberger :
- de création de nouveau objet,
- de destruction d'objet existant,
- de réception d'un objet,
- d'émission d'un objet,
- synchroniser la persistance de plusieurs objets
Un serveur d'objets fournit un ensemble de services aux objets :
- identifier et créer de nouveaux objets,
- consulter des annuaires de services d'objet,
- émettre des messages vers d'autres objets,
- recevoir des messages d'autres objets,
- empiler des messages en attende de fin de transaction,
- persister et s'historiser dans des états successifs,
- se restaurer dans un état cohérent historisé,
- se présenter (affichage, impression, caractéristiques de ses services).
Dans une architecture à objets distribués, un objet peut transiter d'un serveur d'objets vers un autres serveurs d'objets ou même coexister dans plusieurs serveurs d'objets. Si un message est envoyé à un objet distribué dans plusieurs serveurs d'objet, les objets dupliqués doivent rester homogène, identique, synchrone. Un mécanisme de
synchronisation de l'états de ces objets est donc nécessaire (neutralisation d'objet et distribution des modifications d'état d'objet).
Annuaire de services
Un annuaire de service permet de recenser l'ensemble des services offerts par des objets. Chaque objet nouvellement crée ou chaque objet changeant d'état peut se faire répertorier ou dérépertorier dans un ou plusieurs annuaires de services. L'objet présente les services qu'il met à la disposition d'autres objets connectés à cette annuaire.
Un même service peut être rendu par plusieurs objets. Chaque objet demandeur possède ses règles de choix de l'objet cible.
Un annuaire de services permet de retrouver un service d'après les caractéristiques de chaque service.
Service d'identification d'objets
Un service permet à d'autres objet créateur d'objet d'obtenir une identification unique pour chaque nouvel objet.
Il peut exister différents services d'identification d'objet mais il ne doivent pas pouvoir donner le même identifiant. L'identifiant d'un objet peut être calculé à partir de l'identifiant du service d'identification et d'un chrono d'identification. Ce service d'identification est synchrone. C'est à dire que deux transactions différentes nécessitant la création d'objets ne peuvent appeler ce service simultanément.
Synchronisation des demandes de service
Une demande de service ou un envoi de
message à un objet peut entraîner l'envoi d'autres messages par l'objet récepteur et ainsi de suite une cascade de messages synchrones peuvent être émis et réceptionnés.
Cet ensemble de messages forme une transaction. Une transaction débute lors de l'émission d'un message synchrone et se termine lorsque l'ensemble des messages synchrones ont été pris en compte.
Si une anomalie survient lors de la prise en compte d'un de ces messages alors l'ensemble des objets impliqués par cette transaction de messages doivent retrouver leur état initial, et l'ensemble des messages asynchrones ignorés. Chaque message et chaque objet est donc porteur d'une identification de transaction. Tous les messages issus d'une même transaction porte le même identifiant de transaction. Tous les objets impliqués par un ou plusieurs messages d'une même transaction neutralise la prise en compte d'autres messages.
Les messages doivent pouvoir être stockés dans une file d'attente de fin de transaction.
Protocole de communication
Le protocole de communication fédère l'ensemble de ces objets.
Ce protocole permet à chaque objets d'émettre et de réceptionner des demandes de services compréhensibles.
En fonction des protocoles et des caractéristiques des réseaux utilisés et des spécificités d'implantation de chaque objet des interfaces sont nécessaires pour transcrire les demandes de services et les objets conformément à un protocole de communication homogène.
Dans le cadre d'une architecture à objets distribués où les objets doivent pouvoir transiter vers différents serveur d'objet hétérogène la spécification des objets doit être transmissible. C'est à dire que la spécification de la fabrication des objets doit être homogène et normalisée.
Il nous faut donc établir un
langage commun de spécification d'objet .
Langage de spécification d'objet
Ce langage doit permettre de décrire les objets :
- les services
- identification du service
- nature du service synchrone ou asynchrone
- type des valeurs du message (demande de service)
(Date, Heure, Estampillage, Chaîne de caractères, Entier, Décimal, Booléen etc. identifiant d'objet)
- algorithme de manipulation des propriétés
- comparaison, affectation de valeurs,
- construction, conditions d'envoi et d'enchaînement de messages etc.
- les attributs
- identification de l'attribut
- nature de la propriété persistante ou temporaire à une transaction
- type d'attribut
(Date, Heure, Estampillage, Chaîne de caractères, Entier, Décimal, etc. identifiant d'objet)
- cardinalité de l'attribut
Ce langage doit permettre de décrire les services. C'est à dire une succession ordonnée de services au travers de
messages délégués aux différents objets référencés ou identifiés par les attributs internes de l'objet :
- l'affectation d'attribut local au service ou interne à l'objet,
- les conditions d'appel de message (Si condition alors appeler service 1 sinon appeler service 2 ),
- les boucles d'appel (Si condition alors appeler service tant que condition),
- l'interception des erreurs (Appeler service 1 et si erreur appeler service 2).
Dans l'architecture CORBA (Common Object Request Broker Architecture) organisée par le consortium international appelé l'OMG (Object Management Group) un ensemble de services facilites la mise en œuvre d'architectures à objets distribués :
- Le service de Nommage fournit un système de désignation pour retrouver les objets à partir de noms symboliques. Il gère des associations entre des noms symboliques et des références d'objet. Il fixe un convention de structuration des noms et des chemins d'accès. Ce service est constitué d'un graphe de contextes de nommage interconnectés ; chaque contexte gère une liste d'associations nom-référence. A l'intérieur d'un contexte chaque nom doit être unique mais un objet peut être désigné par plusieurs noms dans un ou plusieurs contextes.
- Le service Vendeur enregistrent les services des objets en les caractérisant par un ensemble de propriétés. Le service résout alors les demandes des clients en fonctions des offres.
- Le service Evénements permet aux objets client de produire des événements asynchrones à destination d'autres objets serveurs. Le service Evénement permet de dissocier les objets impliqués dans une communication. Ainsi les objets clients n'ont pas besoin de connaître tous les objets intéressés par leurs événements.
- Le service Propriétés permet d'associer dynamiquement des valeurs nommées à des objets. Ces valeurs représentent des attributs de l'objet spécifiques aux besoins des objets client.
- Le service Cycle de vie permet la création, la copie, le déplacement et la destruction des objets.
- Le service Relations gère des associations dynamiques reliant les objets. Ce service permet de parcourir les graphes d'objets et de supporter les contraintes d'intégrité référentielles entre ces objets. Ce service fournit une palette variée de types de relations : l'appartenance, l'inclusion, la référence, l'auteur, l'emploi, etc.
- Le service Externalisation permet d'obtenir la représentation d'un objet sous forme d'un flux. L'externalisation est l'opération qui stocke un objet dans un flux. L'internalisation est l'opération qui crée un objet à partir d'un flux. Ce mécanisme peut être utilisé pour faire de la persistance d'objet ou de la migration d'objet.
- Le service Persistance permet de stocker les objets de manière stable sur tout type de support rémanent (SGBD, système de fichiers, etc.). L'objet peut se sauvegarder ou se restaurer.
- Le service Interrogation permet d'interroger les attributs des objets. Ce service repose sur un langage d'interrogation des objets.
- Le service Collections permet de manipuler de manière uniforme des objets sous la forme d'ensembles. Les collections les plus spécifiques sont les listes, les piles et les dictionnaires etc.
- Le service Transaction assure l'exécution de traitements transactionnels mettant en oeuvre de multiples objets. Il gère aussi bien les transactions horizontales que celle imbriquées. Une transaction permet de faire en sorte qu'un ensemble d'opérations soit vu comme une opération atomique.
- Le service Concurrence d'accès fournit des mécanismes de verrous pour contrôler et ordonnancer les invocations concurrentes d'opération sur les objets.
- Le service Sécurité fournit les fonctions systèmes permettant d'identifier et d'authentifier les clients des objets, de chiffrer et de certifier les communications, d'auditer et de surveiller les utilisations des objets, et finalement, de contrôler et de gérer les autorisations d'accès aux objets.
- Le service Licences permet de mesurer, contrôler et limiter l'utilisation des objets. Ce service fournit aussi des informations pour facturer les objets clients et rémunérer les objets serveurs. Le contrôle des licences peut s'effectuer à chaque session, à chaque invocation ou à chaque création d'un objet.
- Le service Temps permet d'obtenir une horloge globale, de mesurer le temps et de synchroniser les objets
(Référence : CORBA Des concepts à la pratique InterEditions Jean-Marc Geib, Christian Gransart, Phillipe Merle)
CV : LUCK Paul-Alexandre
EMail : paulalexandre.luck@free.fr