TPTP stellt ein automatisierbares Servicegerüst zur Verfügung, das die Unterstützung
für die Bereitstellung und den Einsatz von durch Eclipse betriebene TPTP-Services in unterschiedlichen
Umgebungen bietet. Wenn wir davon ausgehen, dass diese Services im wesentlichen
Funktionseinheiten sind, die sich selbst über Erweiterungen (mit einer
zugehörigen Spezifikation unterstützter Eigenschaften und einem Verhaltensvertrag)
publizieren, so ist es möglich, einen neuen Serviceanbieter zu erstellen und dabei
denselben Service zu implementieren. Diese Methode der Implementierung ermöglicht
eine lose und dynamische Bindung zwischen dem Serviceverbraucher und dem
Serviceanbieter.
Die Serviceabstraktionen von TPTP entsprechen nicht genau den Web-Servicestandardabstraktionen
(sie sind wesentlich leichter, einfacher und informeller), obwohl sie TPTP
einen Schritt näher an eine Rolle in der serviceorientierten Architektur bringen.
Die Konzepte und Abstraktionen, die mit dem automatisierbaren Servicegerüst eingeführt wurden,
sind synonym mit den problemorientierten Abstraktionen in jeder serviceorientierten Architektur.
Die Komponenten, die TPTP bilden, entwickeln und publizieren inkrementell Services,
die die TPTP-Plattform darauf vorbereiten, von Scripts und beliebigen Programmen außerhalb
von Eclipse befehligt zu werden. Die TPTP-Testkomponenten stellen momentan einen
Testausführungsservice für die flexible Ausführung von TPTP-Tests auf programmorientierte Weise
zur Verfügung.
Das automatisierbare Servicegerüst verfügt über eine Schichtarchitektur,
die eine lockere Verbindung zwischen Komponenten und Gerüst ermöglicht.
Der Bus, der die Serviceverbraucheranfragen in die Serviceanbieterantworten
transportiert (die Ausführung von Services) bietet an jedem Ende
Erweiterungsmöglichkeiten: Beim Client ein Adaptermodell (das Client-Ende
kann Code sein, der innerhalb einer Eclipse-Instanz ausgeführt wird, oder
Code, der außerhalb von Eclipse ausgeführt wird, wie zum Beispiel Befehlszeilenscripts)
und beim Server ein Angebotsmodell für Serviceanbieter (das Server-Ende ist
die Eclipse-Instanz, die die Plug-ins enthält, die die Serviceimplementierung zur
Verfügung stellen).
Zusätzliche Automatisierungsclientadapter können entwickelt werden,
die neue Serviceverbraucherparadigmen in die Standardschnittstellen des
Automatisierungsclients aufnehmen, der in TPTP zur Verfügung gestellt wird.
Es könnte zum Beispiel ein Automatisierungsadapter eines Web-Service-Client
von einem Fremdhersteller entwickelt werden, der automatisierbare TPTP-Services
aktiviert, die innerhalb einer Web-Servicestandardumgebung ausgeführt werden, oder
es könnte ein Jython-Client-Automatisierungsadapter geschrieben werden, um den
Verbrauch von Services von der Jython-Umgebung zu unterstützen.
Wenn neue konforme, automatisierbare Services publiziert werden,
vergrößern diese den Pool verfügbarer Services, die öffentlich von einer
TPTP Eclipse-Instanz verfügbar sind, und damit die verfügbaren Serviceanbieter,
die interessierten Verbrauchern, die das automatisierbare Servicegerüst nutzen,
mehr Funktionalität bieten können. Ein Endbenutzer kann ein Plug-in erstellen,
das einen neuen Service einfach dadurch zur Verfügung stellt, dass die entsprechenden
Erweiterungspunkte implementiert werden und mindestens eine Java-Klasse entwickelt wird.
Folglich wird dieser Service wegen der Schichtarchtiktur und der
Spezifik des Busses automatisch von ant-Scripts, shell-Scripts,
Java-Programmen und allen anderen installierten Client-Adaptern in der
Verbraucherumgebung verfügbar gemacht.
Die Light-Automatisierungsclientkomponente bietet eine Standardgruppe
von Serviceschnittstellen zur Verwendung durch Clientadapter sowie
die entsprechende Eclipse-Startstrategie für jedes Szenario. Zwei
Start- und Ausführungsstrategien werden momentan angeboten.
Eine für den Serviceverbrauch während des Prozesses und einen für den
Serviceverbrauch außerhalb des Prozesses (diese Strategie ist die typische
Strategie, bei der Clients bedient werden, die sich außerhalb einer
bestimmten Eclipse-Instanz befinden). Die Strategie für den Serviceverbrauch
innerhalb des Prozesses wird in den Situationen verwendet, in denen der Service
in derselben Eclipse-Instanz wie das aufrufende Programm ausgeführt werden soll.
Die Light-Komponente interagiert mit der komplexen Komponente
(diese Komponente wird als komplex bezeichnet, da sie eine größere Abhängigkeit
von Eclipse aufweist und daher von zusätzlichen Bibliotheken abhängt,
von denen die äußere Automatisierungsclientkomponente abstrahiert ist).
Die einzige Verbindung der Light-Komponente zu einer bestimmten Eclipse-Instanz
besteht über eine Zeichenfolge-ID, die in der Automatisierungsclientkomponenteninstanz
festgelegt werden kann. Der Automatisierungsserver, der sich innerhalb einer
Eclipse-Instanz befindet (auch als komplexe, innere Komponente oder Broker bezeichnet)
empfängt eingehende Übertragungen von der Light-Komponente des Automatisierungsclients und
leitet den Aufruf an den entsprechenden Serviceanbieter (auch als automatisierbarer Service bezeichnet)
weiter. Der Automatisierungsserver definiert einige einfache Erweiterungspunkte,
die die Dereferenzierung zwischen der Serviceanforderung und der Java-Klasse
ermöglichen, die die Anforderung bedient.
Zugehörige Tasks
Tests von Scripts und Anwendungen starten
Testausführungsservice ausführen
Zugehöriger Verweis
Unterstützte Eigenschaften für Testausführungsservice
(C) Copyright IBM Corporation 2000, 2006. Alle Rechte vorbehalten.