The following diagram shows a process view of TPTP Test execution. While there exists a basic RMI framework for communicating between the workbench and the session JVM on the target machine, that communication mechanism does not extend to the Test JVM.
The test runner (which is the class that the test JVM is started with) does, however, create the agent that ultimately pipes back all of the test's execution history (test log) data. The TPTP Test Service framework uses that Agent to send control messages from the Test JVM back to the workbench, where the invoked services can be carried out, and results can be returned to the called in the Test JVM. Clients of Test Services may be tests themselves, or may be test tool specific code that is part of the Test Runner.
Several new classes have been introduced to support the Test Services Framework, as shown in the diagram below. The HyadesRunner class now passes the ComptestAgent to a new class, called ServiceInvoker. ServiceInvoker keeps a reference to the ComptestAgent, and uses the ComptestAgent's control channel for making service requests to the workbench (as BinaryCustomCommand messages.) Those requests are received on the workbench side by a new (additional) listener called TestServiceAgentListener. This listener then finds the approriate service implementation (via eclipse extension point), and delegates the call to that implementation. When the service call completes, the TestServiceAgentListener sends the return result back to the Agent side, again as a BinaryCustomCommand, where is it received by a new class called ServiceCommandHandler. ServiceCommandHandler pushes the result via ServiceInvoker, which in turn notifies waiting service calls that a result has come back. Each waiting service call checks to see if the result is for that service, and if so, retrieves the result and returns.