Présentation de l'infrastructure des services automatisables


TPTP fournit une infrastructure de services automatisables servant de support à la fourniture et à l'utilisation de services TPTP hébergés par Eclipse à partir d'environnements différents. Ces services étant essentiellement des composants "boîte noire" se publiant eux-mêmes via des extensions (avec une spécification associée pour les propriétés prises en charge et un contrat comportemental), il est possible de créer un nouveau fournisseur de services implémentant le même service. Ce type d'implémentation permet une liaison souple et dynamique entre les utilisateurs du service et le fournisseur de services.

Les abstractions des services TPTP ne sont pas rigoureusement identiques à celles d'un service Web standard (elles sont beaucoup plus légères, plus simples et informelles) bien qu'elles orientent TPTP vers un rôle d'acteur dans une architecture orientée services. Les concepts et les abstractions présentées avec l'infrastructure des services automatisables sont synonymes des abstractions de haut niveau dans une architecture orientée services.

Les dispositifs composant TPTP développent et publient des services de manière incrémentielle, permettant ainsi le contrôle de la plateforme TPTP à partir de scripts et de programmes arbitraires en dehors d'Eclipse. Les fonctions de test TPTP offrent un service d'exécution de test pour l'exécution flexible de tests TPTP similaire à un programme.

Architecture de l'infrastructure

L'infrastructure de services automatisables dispose d'une architecture en couches qui permet une certaine liberté de couplage entre les composants de l'infrastructure. Le bus qui achemine les demandes du consommateur du service vers les réponses du fournisseur de services (l'exécution des services) apporte une extensibilité à chaque extrémité via un modèle d'adaptateur à l'extrémité client (par exemple du code s'exécutant dans une instance Eclipse ou en dehors d'Eclipse, tel que des scripts de ligne de commande) et un fournisseur de services offrant un modèle à l'extrémité serveur (c'est-à-dire l'instance Eclipse hébergeant les plug-ins fournissant les implémentations du service).

D'autres adaptateurs du client d'automatisation peuvent être développés pour adapter les nouveaux paradigmes du consommateur du service aux interfaces du client d'automatisation standard fournies dans TPTP. Par exemple, un adaptateur d'automatisation de client de service Web peut être développé par un tiers pour permettre l'exécution des services automatisables TPTP à partir d'un environnement de services Web standard ou un adaptateur d'automatisation du client Jython peut être écrit pour prendre en charge la consommation de services à partir de l'environnement Jython.

Avec la publication des nouveaux services automatisables conformes, le pool de services disponibles publiquement à partir d'une instance Eclipse TPTP augmente, de même que le nombre de fournisseurs de services disponibles pouvant fournir cette fonctionnalité aux consommateurs intéressés alimentant ainsi l'infrastructure des services automatisables. Pour créer un plug-in offrant un nouveau service, il suffit à l'utilisateur final d'implémenter les points d'extension appropriés et de développer au moins une classe Java. En conséquence, ce service est automatiquement mis à disposition à partir de scripts ant, de scripts de shell et de programmes Java, ainsi que de tout autre adaptateur de client installé dans l'environnement de consommation en raison de l'architecture en couches et de la nature du bus.

Le composant de client d'automatisation léger fournit un jeu standard d'interfaces de services destinées aux adaptateurs de client ainsi qu'une stratégie de lancement d'Eclipse appropriée suivant le scénario. Deux stratégies de lancement et d'exécution sont actuellement proposées, l'une pour la consommation de services internes au processus et l'autre pour la consommation de services hors processus (la stratégie hors processus est la stratégie classique, offrant des services aux clients hors d'une instance Eclipse particulière). La stratégie interne au processus est employée dans des cas où il est souhaitable que le service soit exécuté dans la même instance Eclipse que l'appelant.

Le composant léger interagit avec le composant lourd (lourd car il a une plus grande dépendance d'Eclipse et ainsi donc des dépendances de bibliothèques supplémentaires que le composant du client d'automatisation externe n'a pas). Le seul couplage du composant léger à une instance Eclipse particulière s'effectue via un identificateur de chaîne pouvant être défini sur l'instance du composant du client d'automatisation. Le serveur d'automatisation hébergé sur une instance Eclipse (également connu comme composant interne lourd ou courtier) reçoit la communication entrante du composant du client d'automatisation léger et distribue l'appel au fournisseur de services approprié (également connu comme service automatisable). Le serveur d'automatisation définit des points d'extension simples permettant l'adressage indirect entre le service demandé et la classe Java assurant la demande.

Tâches connexes
Lancement des tests à partir de scripts et d'applications
Exécution du service d'exécution de test

Référence connexe
Propriétés prises en charge par le service d'exécution de test