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.
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
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved. (C) Copyright IBM France 2000, 2006. Tous droits réservés.