11 Service Management

Description

A service is any unique component related to a test suite that is required for test execution and must be started in separate process or thread (such as RMI daemon or ORB service) before the test suite is run. Some TCKs might require many services. The ServiceManager component enables users to configure the services required to run tests.

Each test suite optionally specifies and describes a set of services that it requires to run tests. During the test suite load process, the TestSuite instantiates objects that implement the Service interface and uploads those objects to the ServiceManager component.

The ServiceManager component manages all aspects of the service life cycle. From information given by the test suite and the JavaTest harness, it determines which services are required and when they should be started. From test execution events, it also determines which services should be stopped.

The ServiceManager is available either when running the JavaTest harness or as a separate service without running the JavaTest harness.

Services-Related Work Flow

Services-related work flow of harness execution is supported in both GUI and batch mode test execution. The work flow consists of the following:

1. The ServiceManager and Service instances are instantiated after the test suite is loaded inside harness.

2. When the JavaTest harness object (Harness) starts a test run, information that the Harness has about the tests and groups of tests that should be run is provided to the ServiceManager.

3. The ServiceManager filters out services that are unnecessary for the test run based on information from the Harness and information from deployed services regarding which test paths for which the service should be started.

   The services-related workflow is performed before starting a test run in the main Harness execution thread. During this process one of the following actions is taken based on the information that the harness has about the tests and groups of tests that should be run:

   • Start services as needed.

     After being notified by the Harness that a test has started, the ServiceManager determines if a particular service should be started for running the next test. This enables "lazy" service start up, which may be useful for performance reasons.

   • Start all required services now.

     Before running any tests, the ServiceManager starts all required services.

   • Start services manually.

     Service management is turned off for the test run. The Harness assumes that the user will manually start all required services.

     
     

     Note: When running in GUI mode, the ServiceManager functionality is enabled after the user presses the Run button which blocks the Harness execution thread until it determines how services will be started. In batch mode, the ServiceManager is functionality is enabled by using an option in the command line.

     
     

4. The ServiceManager stops services either as it determines that a service is not required (all tests that require this service are completed) or at the end of test run.

   Stopping services after the test run finished is preferred.

Implementation

Because the ServiceManager component must serve different requirements, its service support design is as flexible as possible.To achieve this flexibility, the design uses abstract concepts of service, service description, service execution and service parameters. Some functionality, such as remote service management when services are instantiated and run on a remote host, has not been implemented. However the capability to implement the functionality is supported in the architecture. Additional functionality could be implemented by the test suite and set through the API, as is currently done in the JavaTest harness for other components.

The JavaTest harness provides useful default implementations of the following interfaces:

• Service - Interface describing a service.

  Service objects should be instantiated by ServiceReader. The particular implementation class should be specified so that the ServiceReader can access it. A default implementation, AntService (see Implementation of Service Interface) is provided by the JavaTest harness. Such a service is the Ant target in provided ant xml file. The benefit of such a service representation is that the service can easily be started without running the JavaTest harness.

• ServiceReader - Interface responsible for reading service definitions and parameters.

  The implementation should be provided by the test suite. A default implementation, PropertyServiceReader (see Implementations of ServiceReader Interface), is provided by the JavaTest harness. This implementation reads Service type definitions and start parameters of each particular instance, as well as maps test paths to service instances from a single property file.

• ServiceConnector and ServiceExecutor - ServiceConnector is responsible for the connection between harness representative (Service interface) and ServiceExecutor is responsible for responsible for running service in case of remote execution.

  Each executor type is related to a respective service type, such as AntService and AntServiceExecutor (see Implementation of Service Interface). Connector doesn't depend on the Service and ServiceExecutor type. Connector has a unified interface and any Connector implementation should work with any Service - ServiceExecutor pair. The JavaTest harness only provides a pseudo local connector that redirects requests to a ServiceExecutor working in the same VM. The following are available types of ServiceExecutor:

  • ThreadServiceExecutor - Executes any service described by Runnable object in a separate thread.

  • ProcessServiceExecutor - Executes in a separate process by Runnable.exec().

  • AntServiceExecutor - Extends ProcessServiceExecutor to execute ant tasks using Ant.

service.id.class=...
service.id.description=...
service.id.arg.argname=...
property.general-property-name=...
testpath.tpid.path=...
testpath.tpid.ids=[space-separated list of service IDs] 

property.port=8080
property.testuite=path_to_testsuite

service.rmid_1.class=com.foo.bar.RMIDService
service.rmid_1.description=This is first variant of service to start rmid daemon
service.rmid_1.arg.arg1=5000
service.rmid_1.arg.arg2=path_to_testsuite

service.rmid_2.class=com.foo.bar.RMIDService
service.rmid_2.description=This is second variant of service to start rmid daemon 

service.msg_service.class=com.foo.bar2.MessagingService
service.msg_service.description=messaging service
service.msg_service.arg.timeout=1000

testpath.1.path=api/java_rmi
testpath.1.ids=ant rmid_1

testpath.2.path=api/foo_bar
testpath.2.ids=rmid_2 msg_service

<Services>
<property file="local.properties"/>
<property name="port" value="8080"/>
<property name="testsuite" value="${root}/tests"/>
...................................
<service id="rmid_1" class="com.foo.bar.RMIDService" description="This is first variant of service to start rmid daemon">
<arg name="arg1" value="5000"/>
<arg name="arg2" value="${testsuite}"/>
</service>
<service id="rmid_2" class="com.foo.bar.RMIDService" description="This is second variant of service to start rmid daemon">
</service>
<service id="msg_service" class="com.foo.bar2.MessagingService" description="messaging service">
<arg name="timeout" value="1000"/>
</service> 
..................................
<testpath path="api/java_rmi">
<service refid="ant"/>
<service refid="rmid_1">
</testpath>
<testpath path="api/foo_bar">
<service refid="rmid_2"/>
<service refid="msg_service"/>
</testpath>
.....................................
</Services> 

<service id="any_uniq_id _you_want" 
class="com.sun.javatest.services.AntService"><arg name="ant.bin" value="~/apache-ant/bin/ant"/>
<arg name="ant.targets" value="rmid-target run-tests"/>
<arg name="ant.workdir" value="directory_to_start_ant_from"/>
<arg name="ant.env.JAVA_HOME" value="path to JDK"/>
<arg name="option1" value="-buildfile ${lib}/build.xml"/>
<arg name="option2" value="-verbose"/>
</service>

string=[string | ${string}]*

key1=
key2=value2
key3=value31_${key1}_value32_${key2}_value33

key1=value1
key2=value2
key3=value31_value1_value32_value2_value33

Service Management Architecture

The architecture of the Service Management feature of the JavaTest harness consists of five components:

• ServiceManager

• Service

• ServiceExecutor

• Connector

• ParamResolver

Figure 11-1 illustrates the relationship between these components.

Figure 11-1 Service Management Architecture

Description of "Figure 11-1 Service Management Architecture"

1. ServiceManager - Instantiated for each test suite instance.

   The same test suite, opened two times in different tabs, is interpreted as two different test suites and will have different ServiceManager objects. ServiceManager objects accomplish the following functions:

   • Are notified of all Harness events.

   • Manage a set of services.

   • Provide methods to achieve service's state, info and data to the JavaTest harness and test suite.

   • Provide methods for external configuration by JavaTest and test suite.

   • Start and stop services

   • Count which services and when should be started and stopped.

2. Service - Root service interface.

   Service interface has two main goals:

   • Contains service information, execution parameters, and test mapping.

   • Provides start, stop, other operating methods, are invoked by ServiceManager, and are delegated through Connector to ServiceExecutor.

3. ServiceExecutor - Root interface for the service executor.

   Method invocations from Service go through Connector and are executed by ServiceExecutor. The Service and ServiceExecutor implementation types have a 1:n relationship. Consequently, each Service implementation can have different ServiceExecutors for different situations (such as local and remote execution). ServiceExecutor implementations can execute a service as separate process, as a thread, or in any other required manner. Service and ServiceExecutor types must be coordinated to perform message exchange correctly.

4. Connector - Interface that determines common connection methods between Service and ServiceExecutor, such as sendMessage or getOutputStream methods.

   Particular implementation should not be related with concrete Service and ServiceExecutor realizations. Connector is harness-side component, and we have no any interface for agent side part, because on those side such component (and it's incoming events) manages ServiceExecutor. Agent-side component is not under any management, so there is no need for it to have API.

5. ParamResolver - Component, related with ServiceExecutor. Connector, that sends commands to a service and provides the parameters for this command execution.

   The parameters are decoded by ParamResolver and passed to ServiceExecutor. For example, if a connector sends "$host_name" param, it should be resolved by the ParamResolver. Implementations of ParamResolver should be interoperable with ServiceExecutor. How and what to resolve depends on the implementations of both components.

Service execution is divided into 3 components (Service, Connector, ServiceExecutor), because it must be able to implement remote services start-up and execution by any test suite. It is not possible to implement this feature directly in the JavaTest harness and its agent, as requirements from different customers vary.

Separate Services Start Up

To simplify service start-up (in case there is no remote environment or you don't want to use the JavaTest harness to run the Service management feature), a separate entry point is available inside the JavaTest harness, such as ServicesMain, that performs the following operations:

1. Takes the test suite path as input.

2. Instantiates all found Services, ServiceExecutors, and local Connectors.

3. Invokes the Service.start methods.

Services are unmanageable in this case and must be stopped by shutdown hook. Figure 11-2 illustrates the sequence of performing a separate services start-up.

Figure 11-2 Separate Service Start-Up

Description of "Figure 11-2 Separate Service Start-Up"