Übersicht über das automatisierbare Servicegerüst


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.

Gerüstarchitektur

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