Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Eclipse Application Testing Guide
Previous Page Home Next Page

Overview of the automatable service framework

TPTP provides an automatable service framework that features support for the provision and consumption of Eclipse hosted TPTP services from disparate environments. Given that these services are fundamentally black-box components that publish themselves via extensions (with an associated specification of supported properties and a behavioral contract) it is possible to create a new service provider implementing the same service. This implemented approach allows for a loose and dynamic binding between the service consumer and service provider.

TPTP's service abstractions are not strictly the same as a standard web service abstractions (they are much more light weight, simpler and informal) although they do bring TPTP closer to playing a role in a service-oriented architecture. The concepts and abstractions introduced with the automatable services framework are synonymous to the high-level abstractions in any service-oriented architecture.

The features that compose TPTP will incrementally develop and publish services that ready the TPTP platform to be commanded from scripts and arbitrary programs outside of Eclipse. The TPTP test features currently provide a test execution service for the flexible execution of TPTP tests in a programmatic fashion.

Framework architecture

The automatable services framework has a layered architecture that enables loose coupling between components of the framework. The bus that transports service consumer requests into service provider responses (the execution of services) provides for extensibility at each end with an adapter model on the client end (the client end can be code running inside of an Eclipse instance or code running outside of Eclipse such as command line scripts) and a service provider offering model on the server end (the server end is the Eclipse instance hosting the plug-ins that provide the service implementations).

Additional automation client adapters can be developed that adapt new service consumer paradigms into the standard automation client interfaces provided in TPTP. For example, a web service client automation adapter could be developed by a third-party enabling TPTP automatable services to be executed from within a standard web services environment or a Jython client automation adapter could be written to support the consumption of services from the Jython environment.

As new conforming automatable services are published they increase the pool of available services publicly available from a TPTP Eclipse instance and therefore the available service providers that can provide functionality to interested consumers harnessing the automatable services framework. An end-user can create a plug-in that provides a new service simply by implementing the appropriate extension points and developing at least one Java class). Consequentially, this service is automatically made available from Ant scripts, shell scripts, Java programs and any other installed client adapters in the consumers environment due to the layered architecture and nature of the bus.

The lightweight automation client component provides a standard set of service interfaces for use by client adapters as well as providing the appropriate Eclipse launch strategy per the scenario. Two launch and execution strategies are currently offered, one for in-process service consumption and the other for out-of-process service consumption (the out-of-process strategy is the typical strategy, serving clients that are outside of a particular Eclipse instance). The in-process strategy is used in situations where it is desirable for the service be executed in the same Eclipse instance as the caller.

The lightweight component interacts with the heavyweight component (heavyweight since it has greater dependency on Eclipse and therefore additional library dependencies that the outside automation client component is abstracted from). The lightweight component's only coupling to a particular Eclipse instance is through a string identifier settable on the automation client component instance. The automation server hosted inside an Eclipse instance (also known as the heavyweight inside component or broker) receives incoming communication from the lightweight automation client component and marshals the call to the proper service provider (also known as an automatable service). The automation server defines some simple extension points that allow for indirection between the service requested and the Java class servicing the request.

Related tasks
Launchingtests from scripts and applications
Executingthe test execution service

Related reference
Supportedtest execution service properties

  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire