Distributed process runner

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates generally to software processing, and more particularly, to methods and systems for intelligently and automatically selecting and utilizing networked computer resources to collectively execute process-flow-based computing operations.

[0003] 2. Description of the Related Art

[0004] In today's fast paced computing world, more and more businesses use the World Wide Web (Web) to provide web services to consumers all over the world. In a simple scenario, a web service provider advertises the service provider's web services by registering the service provider's data with a web registry. In turn, a consumer of the web services (i.e., a client), communicates with the web registry, requesting the web registry to provide the client with information about a service provider satisfying a specific criteria transmitted by the client. The web registry then processes the request so as to locate the service provider that satisfies the particular criteria requested by the client. The registry then provides the client with the Uniform Resource Locater (URL) of the located service provider. Thereafter, if the client finds web services provided by the service provider satisfaction, the client communicates with the selected service provider. This simple scenario, however, rarely occurs.

[0005] In reality, web services are offered over the web by multiple service providers registered with several web registries for use by numerous clients. To make matters more complicated, each service provider may be implemented using different technologies (e.g., a net compatible server), each web registry may be implemented using different types of web registry documents (e.g., web service description language (WSDL), and each client can be based on different types of technologies (e.g., Java™ application based client). Further complicating the problems is that each of the service providers, web registries, and clients, may be implemented on different platforms. Accordingly, interactions between each combination of web registry, service provider, and client are rather complex as it may involve communications being based on different technologies and operating systems.

[0006] Additionally, communication between the web registries, service providers, and clients are synchronized. For instance, a service provider must ensure that the registry is up and running prior to service provider publishing the service provider's services on the web registry. In a like manner, a client must ensure that the registry is up and running prior to communicating a request for a web service. A client must further be sure that the service provider is running prior to communicating a request to the service provider. Thus far, however, such synchronization requirements have not been addressed, causing premature termination of communications between service providers, registries, and clients. In such scenarios, interactions must be restarted and the web services be re-dispatched. Additionally, the failed service provider, registry, or client must be restarted manually, requiring human intervention.

[0007] As the web services are being widespreadly used, to avoid such scenarios, the interactions between different service providers, registries, and clients are tested. Particularly, each combination of interaction between the web registries, service providers, and clients are tested to ensure the reliability of the web services as well as the web registries, service providers, and clients. This is important, as different service providers, registries, and clients can be implemented on diverse platforms using different technologies. Additionally, properly testing the interactions between the web registries, service providers, and clients must further ensure synchronization problems associated with the prior art.

[0008] Thus far, interactions between the web registries, service providers, and clients are typically performed by stand-alone computers or a network of computer resources. When using a stand-alone computer system, separate stand-alone computers are manually programmed to run tests selected by a user. Comparatively, if a network of computer resources is used, the user allocates a number of computer resources to test a particular interaction. Predominantly, the user manually selects a group of selected computer resources or adds and deletes computer resources to the network, programs the master computer system and the server, initiates the running of the user-selected test, and runs the test on the group of dedicated computer systems coupled to the server.

[0009] In either scenario, a heavy user interface is required to test the interactions, schedule the running of specific tests on the system resources, add and delete the system resources, keep track of the system resources and their respective hardware and software configurations, and maintain the system resources. Additionally, in either case, interactions are tested by dedicated system resources, designed to solely be used for testing the interactions between the registries, service providers, and clients.

[0010] By way of example, to test interactions scheduled to be performed synchronously, a test developer is required to manually initiate the testing process on a plurality of system resources following a particular menu. The menu provides the user the order in which specific tests are required to be run (e.g., synchronously, in parallel, or sequentially). Thus, testing a certain interaction requires the presence of a test developer at all times so that different tests can be initiated in accordance to the schedule set in the menu.

[0011] Furthermore, if an exception occurs during testing of an interaction between the registries, service providers, and clients, the testing process is halted. For instance, if an exception is occurred during testing an interaction between the registry and the client, the interaction is terminated, requiring that the client and the registry to be restarted. If restarting of the client and the web registry does not resolve the exception, the test developer on duty must communicate with the software programmer in charge of developing the test source code so as to resolve the exception.

[0012] Additionally, currently, if a system resource crashes or a response has not been received from a system resource during testing a particular interaction, testing the particular interaction continues indefinitely. In certain situations, to avoid such problems, testing the interaction is interrupted manually by the test developer present.

[0013] One significant limitation of the current state of testing the web services and interactions between the registries, service providers, and clients is the extent of human intervention and significant role of humans. Requiring the presence of test developers to manually initiate, schedule, and interrupt the testing is very costly, is a of waste of resources, not to mention, very time consuming. At times, human error further exacerbates this limitation. Another limitation involves wasting of computer resources, as the computer resources are solely dedicated to testing the web services and the interactions between the web registries, service providers, and clients.

[0014] In view of the foregoing, there is a need for a flexible methodology and system capable of selecting and utilizing dynamic, cross-platform computer resources to process multiple process-flow-based computer software processes using diverse technologies and platforms with minimal human intervention.

SUMMARY OF THE INVENTION

[0015] Broadly speaking, the present invention fills these needs by implementing a distributed process runner (DPR) system to manage and execute process-flow-based computer programs implementing different technologies and platforms using impromptu, cross-platform, distributed processing systems managed by a distributed processing framework (DPF) system. In one embodiment, the distributed process runner (DPR) system is a distributed test runner (DTR) system designed to manage and schedule execution of web services and interactions between web service providers, web registries, and web clients on dynamically networked cross-platform test systems implementing diverse technologies. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, or a method. Several inventive embodiments of the present invention are described below.

[0016] In one embodiment, a processing system is provided. The processing resource includes a computer system, a main processing resource, and a plurality of remaining processing resources. The computer system executes a system controller component and a service component that includes a look up service. The main processing resource executes a server controller component and is configured to register with the look up service indicating the availability of the main processing resource to process a task in a task group of a plurality of software processing task groups. Each of the plurality of remaining processing resources executes a client controller component. The plurality of remaining processing resources is configured to register with the look up service so as to indicate the availability of each of the plurality of remaining processing resources to process a given task in the software processing task groups. Each software processing task group includes a plurality of tasks with each task having a set of requirements. The system controller component searches the look up service so as to obtain data about the main processing resource and the remaining processing resources so as to provide the server controller component data about the main processing resource and the remaining processing resources. The server controller component communicates with each client controller component so as to locate a set of free remaining processing resources to execute tasks in a particular software processing task group that follow a task-flow-based schedule.

[0017] In another embodiment, a method for processing a computer software process including a task file is provided. The method includes designating a group of available processing resources to execute the task file. The task file includes task groups with each task group including a plurality of tasks. The method also includes scheduling the task groups in the task file for execution with a plurality of remaining processing resources, each running a client controller component code. Further included in the method is obtaining access to a set of free remaining processing resources of the plurality of remaining processing resources, each having a set of criteria matching a set of requirements of each task in a particular task group. The method also includes executing tasks in the particular task group when access to all the free remaining resources in the set of the free remaining processing resources have been granted. Also included is generating an execution result report.

[0018] In yet another embodiment, a process execution distributor, scheduler, and management system is provided. The system includes a main processing resource executing a server controller component. The main processing resource registers with a look up service indicating the availability of the main processing resource to schedule software processing task groups for execution. Each software processing task group includes a plurality of tasks with each task having a set of requirements. The main processing resource communicates with a system controller component so as to obtain data as to execution of a particular software processing task group configured to follow a task-flow-based schedule.

[0019] In still another embodiment, a processing resource is provided. The processing resource includes a client controller component configured to communicate with a server controller component being run on a main processing resource. The processing resource registers with a look up service indicating the availability of the processing resource to process a software processing task. The processing resource is configured to be assigned the execution of a software processing task in a plurality of software processing task files. The system controller component searches the look up service so as to obtain data about the main processing resource and the processing resource available to execute the software processing task.

[0020] Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, and like reference numerals designate like structural elements.

[0022]FIG. 1 is a block diagram illustrating a distributed test framework (DTF) system, in accordance with one embodiment of the present invention.

[0023]FIG. 2 is a block diagram illustrating the capability of the present invention to intelligently locate an available and suitable test system to execute a test suite, in accordance with another embodiment of the present invention.

[0024]FIG. 3 is a block diagram illustrating the implementation of the test system attributes to locate a suitable test system to process a test execution request, in accordance with yet another embodiment of the present invention.

[0025]FIG. 4 is a block diagram illustrating the capability of the present invention to locate an available and suitable test system to process a test execution request having a set of specific requirements, in accordance to yet another embodiment of the present invention.

[0026]FIG. 5 is a block diagram depicting the one-to-one communication between the system controller, Jini™ look up service, and a test system of a DTF system, in accordance to still another embodiment of the present invention.

[0027]FIG. 6 is a block diagram showing the interaction between the Jini look up service, system controller, and a test system, in accordance with still another embodiment of the present invention.

[0028]FIG. 7 is a block diagram showing an exemplary distributed test runner (DTR) managing and monitoring testing of an exemplary process using a plurality of test systems, in accordance with still another embodiment of the present invention.

[0029]FIG. 8 is a block diagram showing the interactions between the service controller and client controllers of the distributed test runner, in accordance with still another embodiment of the present invention.

[0030]FIG. 9A is a block diagram showing an exemplary task file, in accordance with still another embodiment of the present invention.

[0031]FIG. 9B is a block diagram showing an exemplary task group file, in accordance with still another embodiment of the present invention.

[0032]FIG. 9C is a block diagram showing of an exemplary configuration file, and a test system, in accordance with still another embodiment of the present invention.

[0033]FIG. 9D is a block diagram showing an exemplary machine.props file, and a test system, in accordance with still another embodiment of the present invention.

[0034]FIG. 10A depicts a simplified snap shot of available and busy processing resources at a given time, in accordance with still another embodiment of the present invention.

[0035]FIG. 10B depicts a simplified snap shot of available and busy processing resources at a given time, in accordance with still another embodiment of the present invention.

[0036]FIG. 10C depicts a simplified snap shot of available and busy processing resources at a given time, and a test system, in accordance with still another embodiment of the present invention.

[0037]FIG. 11 depicts a flowchart diagram of method operations performed by an exemplary distributed process runner (DPR) system, in accordance with still another embodiment of the present invention.

[0038]FIG. 12 depicts a flowchart diagram depicting method operations performed by a distributed process runner (DPR) system, in accordance with still another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0039] An invention for a distributed process runner (DPR) system to manage and schedule execution of process-flow-based processes utilizing cross-platform, dynamically networked, distributed computer systems implementing diverse technologies and operating systems is disclosed. The embodiments of the present invention are capable of intelligently and automatically selecting and utilizing computer systems of a dynamic network of distributed computer systems having either the same or different software/hardware configurations to synchronously execute process-flow-based processes.

[0040] As used herein, an “ad-hoc” or a “dynamic” network is defined as a network in which the computer resources may be part of the network temporarily and for a specific length of time (i.e., spontaneous). In one example, the DPR system of the present invention implements the Jini™ (hereinafter “Jini”) technology to provide spontaneous interaction between its components. In this manner, the computer systems attach to and detach from the ad-hoc network of processing resources (e.g., computer resources) without disturbing the DPR system. Accordingly, the computer resources of the present invention are not limited to executing processes submitted to the DPR system of present invention.

[0041] In one exemplary embodiment, the distributed process runner (DPR) is a distributed test runner (DTR) configured to manage and monitor testing of an exemplary process using a plurality of dynamic test systems. In one example, the system controller of a distributed test system framework (DTF) provides the DTR with all available data about all the test systems <b>114</b><i>a</i>-<b>114</b><i>e</i>, registered with the look up service.

[0042] In one embodiment, DTF launches a server controller on a test system having a desired platform. Thereafter, the server controller obtains all available data about the located test systems from the system controller (e.g., the Internet Protocol (IP) address for each of the test systems, operating system types, machines names, etc.). Then, the server controller designates all the remaining test systems as distributed test systems designed to execute tasks in a plurality of task files. To designate the remaining test systems, in one example, the server controller launches client server on each of the respective test system.

[0043] At this point, the server controller communicates with the client servers so as to coordinate communications. In one example, the server controller starts task execution by obtaining each task file in a task directory designated by the user. Thereafter, task-flow-based scheduling provided in each task file is implemented by the server controller to schedule each task in each task group of each task file. For instance, the server controller determines the number of tasks in the first task group of the first task file as well as their respective operating systems types. Then, the server controller searches the available test systems so as to find test systems having operating systems matching those required to execute the tasks in the first task group.

[0044] In one example, the DPR implements a distributed test framework DTF system. The DTF system is configured to manage test suite execution on cross-platform dynamically networked computer systems. In one implementation, the DTF system includes a server computer system and a plurality of ad-hoc network of processing resources configured to spontaneously interact implementing the Jini technology. The server computer system is configured to include a Jini look up service and a system controller configured to manage the processing of the submitted test suites. In one instance, the plurality of computer resources join the Jini look up service registering their respective proxies and the corresponding attributes. In one example, the system controller searches the look up service for an available suitable computer resource to process each of the submitted test suites. Once a computer resource is selected to run the test suite, the machine service component of the selected computer resource spawns a second service (e.g., process service) to execute the test suite.

[0045] As one embodiment of the present invention implements the Jini technology, a brief introduction to Jini is provided below. Nevertheless, this brief introduction to Jini should not be considered as limiting as Jini technology is well known by those skilled in the art. Jini technology is a network architecture that enables the spontaneous assembly and interaction of services and devices on a network of computer systems. Built on the Java platform, Jini technology eliminates the challenges of scale, component integration, and ad-hoc networking encountered in distributed computing environments. Jini simplifies interactions over a network by providing a fast and easy way for clients to use available services. Jini technology is also configured to be wire-protocol and transport-protocol neutral.

[0046] Summarily, Jini network technology includes a communication and programming model that enables clients and Jini services to discover and connect with each other to form an impromptu (i.e., spontaneous) Jini community. As Jini is written in Java, Jini implements the mechanism, Java Remote Method Invocation Application Program Interface (API), to move objects around the network.

[0047] In one embodiment, a Jini service is configured to employ a proxy to move around the network. As used herein, the proxy is defined as an object having service attributes and communication instructions. Through implementing discovery and join processes, the Jini services are found and thereafter registered with a look up service on a network. As used herein, registering a service is defined as sending the service proxy to all look up services on the network or a selected subset of the look up services. By way of example, the look up service is equivalent to a directory or an index of available services wherein the proxies for each of the services and their associated code are stored. When a service is requested, the proxy associated with the requested service is sent to the requesting client, thus enabling the client to use the requested service. Once dispatched, the proxy is configured to conduct all communication between the client and the Jini service.

[0048] In providing an ad-hoc network of computers, in one embodiment, Jini introduces a concept called “leasing.” That is, once a service joins the Jini network, the Jini service registers its availability for a certain period of leased time. This lease period may be renegotiated before the lease time is expired. When a service leaves the Jini network, the service entry in the look up service is removed automatically once the service's lease is expired. For further details on Jini technology, please refer to K. Arnold et al., The Jini Specification (1999) and W. Keith Edwards, Core Jini (1999).

[0049] Below is a brief introduction to Enterprise JavaBeans (EJB) application as another embodiment of the present invention implements the Enterprise JavaBeans (EJB) architecture. EJB is part of a larger overall technology known as the Java 2 Platform, Enterprise Edition (J2EE) developed by Sun Microsystems, Inc. J2EE provides architecture for developing, deploying, and executing applications in a distributed-object environment.

[0050] Summarily, EJB architecture promotes the creation of re-usable server-side behaviors or instructions in the Java language, connectors to enable access to existing enterprise systems, and easy-to-deploy program modules. The EJB architecture creates a collaborative architecture to provide services virtually anywhere, and for a wide range of customers and devices.

[0051] The EJB architecture defines a model for the development and deployment of reusable Java server components called EJB components (i.e., EJB beans). As designed, the EJB component is a non-visible server component having methods that provide business logic in a distributed application. In one example, the EJB architecture includes the EJB client and the EJB server. The EJB client is configured to provide the user-interface logic on a client machine and to make calls to remote EJB components on a server. For instance, the EJB client is provided the information as to how to find the EJB server and how to interact with the EJB components.

[0052] In one example, the EJB client does not communicate directly with the EJB component. In one aspect, the EJB container provides the client proxy objects that implement the home and remote interfaces of the component. In one example, the remote interface is configured to define the business methods that can be called by the client. In another embodiment, the client is configured to invoke the methods resulting in the updating of the database. Thus, the EJB beans are reusable components that can be accessed by client programs. The application programmer codes the business logic into the EJBs and deploys them into a J2EE compliant server. In one example, the server complying with the J2EE specification provides the required system-level services, thus allowing the application programmer to concentrate on business logic.

[0053] The EJB server (i.e., the EJB application) includes an EJB container, which in one example provides the services required by the EJB component. For instance, the EJB container may be configured to include one of an EJB home interface or EJB Remote interface and EJB beans. In one embodiment, the EJB home interface and the EJB remote interface are defined in the same Java virtual machine. In a different embodiment, the EJB home interface and the EJB remote interface may be defined on different Java virtual machines or separate physical computers.

[0054] In one example, the EJB specification defines a container as the environment in which one or more EJB components execute. In accordance to one example, the EJB container provides the infrastructure required to run distributed components thus allowing the clients and component developers to focus on programming business logic. Simply stated, the container manages the low-level communications between the clients and the EJB beans. In one example, once an EJB bean is created by a client, the client invokes methods on the EJB bean as if the EJB bean were running in the same virtual machine as the client.

[0055] Furthermore, the clients are unaware of activities on the EJB bean, since the container is configured to sit between the clients and the EJB beans. For instance, if an EJB bean is passivated, its remote reference on the client remains intact. Thus, when the client later invokes a method on the remote reference, the container activates the EJB bean to service the request.

[0056] The EJB container encapsulates:

[0057] The client runtime and generated sub classes. In one example, this allows the client to execute components on a remote server as if the components were local objects.

[0058] The naming service allows the clients to instantiate components by name. It further allows components to obtain resources (e.g., database connections, etc.) by name.

[0059] The EJB server component dispatcher, which in one example, executes the component's implementation class and provides services such as transaction management, database connection pooling, and instance lifecycle management.

[0060] In one example, three types of EJB components can be enumerated.

[0061] Stateful session Beans: A stateful session bean manages complex processes or tasks that require the accumulation of data. They further manage tasks that require more than one method call to complete but are relatively short lived, store session state information in class instance data, and have an affinity between each instance and one client from the time the client creates the instance until it is destroyed by the client or by the server.

[0062] Stateless session Beans: A stateless session bean manages tasks that do not require the keeping of client session data between method calls. Furthermore, the method invocation by a stateless session bean does not depend on data stored by previous method invocations, there is no affinity between a component instance and a particular client, and different instances of the stateless session beans are seemed identical to the client.

[0063] Entity Beans: An entity bean model is a business model that is a real-world object which methods are run on the server machine. When the entity bean method is called, the program's thread stops executing and control is passed to the server. When the method returns from the server, the local thread resumes executing. In one example, the entity beans have the following characteristics: Each instance represents a row in a persistent database relation (e.g., a table, view, etc.); and The bean has a primary key that corresponds to the database relation's key which is represented by a Java data type or class.

[0064] Each EJB component further has a transaction attribute configured to determine the manner the instances of the component participate in transactions. As designed, the EJB container provides services which can include transaction and persistence support to the EJB components. As to the transaction support, the EJB container is configured to support transactions. In one example, when the bean is deployed, the EJB container provides the necessary transaction support. In regard to the persistence support, the EJB container is configured to provide support for persistence of the EJB components, which in one embodiment, is defined as the capability of the EJB component to save and retrieve its state. In this manner, the EJB component does not have to be re-created with each use.

[0065] In one example, the EJB architecture is a three-tiered architecture in which the clients reside on the first tier, the application server and the components (i.e., EJB beans) reside on the second tier, and the databases reside on the same host as the EJB server. In accordance to one implementation, the EJB server executes methods on a component from the client or another component, retrieves data from databases, and performs other communications. The EJB server further handles the details of transactions, threads, security, database connections, and network communication. Summarily, the EJB clients request business-logic services from EJB beans running on the second-tier. The EJB beans then use the system services provided by the second-tier server to access data from existing systems in the third tier. The EJB beans apply the business rules to the data, and return the results to the clients in the first-tier.

[0066] In one example, the client contains the user interface. The business logic is configured to be separate from both the clients and the databases and resides in the same tier (i.e., second tier) as components that analyze data, perform computations, or retrieve information from data sources and processes.

[0067] As Java™ (hereinafter “Java”) programming language is implemented in Jini and EJB architecture, in a like manner, an overview of Java is provided below. In operation, a user of a typical Java based system interacts with an application layer of a system generally written by a third party developer. The application layer generally provides the user interface for the system. A Java module is used to process commands received by the application layer. A Java virtual machine is used as an interpreter to provide portability to Java applications. In general, developers design Java applications as hardware independent software modules, which are executed Java virtual machines. The Java virtual machine layer is developed to operate in conjunction with the native operating system of a particular hardware, which represents the physical hardware on which the system operates or runs. In this manner, Java applications can be ported from one hardware device to another without requiring updating of the application code.

[0068] Unlike most programming languages, in which a program is compiled into machine-dependent, executable program code, Java classes are compiled into machine independent byte code class files which are executed by a machine-dependent virtual machine. The virtual machine provides a level of abstraction between the machine independence of the byte code classes and the machine-dependent instruction set of the underlying computer hardware. A class loader is responsible for loading the byte code class files as needed, and an interpreter or just-in-time compiler provides for the transformation of byte codes into machine code.

[0069] More specifically, Java is a programming language designed to generate applications that can run on all hardware platforms, small, medium and large, without modification. Developed by Sun, Java has been promoted and geared heavily for the Web, both for public Web sites and intranets. Generally, Java programs can be called from within HTML documents or launched standalone. When a Java program runs from a Web page, it is called a “Java applet,” and when run on a Web server, the application is called a “servlet.”

[0070] Java is an interpreted language. The source code of a Java program is compiled into an intermediate language called “byte code”. The byte code is then converted (interpreted) into machine code at runtime. Upon finding a Java applet, the Web browser invokes a Java interpreter (Java Virtual Machine), which translates the byte code into machine code and runs it. Thus, Java programs are not dependent on any specific hardware and will run in any computer with the Java Virtual Machine software. On the server side, Java programs can also be compiled into machine language for faster performance. However a compiled Java program loses hardware independence as a result.

[0071] Keeping these brief overviews to Jini, EJB architecture, and Java as they relate to the present invention in mind, for ease of understanding, a detailed description of the Distributed Processing Framework System is provided in Section I, and a detailed description of the Distributed Process Runner will be provided in Section II

[0072] I. Distributed Processing Framework System

[0073] reference is now made to FIG. 1 illustrating a block diagram of a distributed test framework (DTF) system <b>100</b>, in accordance with one embodiment of the present invention. As shown, physically, the DTF system <b>100</b> includes two groups of computer systems: (1) a system server group <b>101</b>, and (2) a test system group <b>114</b>′. The system server group <b>101</b> includes a service component <b>102</b> and a system controller <b>108</b>. The service component <b>102</b> is configured to contain a Jini look up service <b>104</b> and a Remote Method Invocation (RMI) <b>106</b>. In one embodiment, the RMI is designed to handle various communication needs. Comparatively, the Jini look up service <b>104</b> is a dedicated process running on the master computer system, server, and is configured to function as a central registry. As used herein, the master computer system is defined as the computer system running the system controller <b>108</b>. As designed, in one embodiment, the master computer is configured to include both the system controller <b>108</b> and the service component <b>102</b>. However, in a different implementation, each of the system controller <b>108</b> and the service component <b>102</b> may be included and run by separate computer systems. As designed, the look up service <b>104</b> is configured to enable the system controller <b>108</b> to locate available computer systems of an ad-hoc network of computer systems to execute a given test execution request using the test system registerable attributes. For instance, the look up service <b>104</b> includes registerable attributes, which identify the test machine platform, operating system, and other software and hardware characteristics.

[0074] The illustrated system controller <b>108</b> includes a communication module <b>110</b> and a test suite management module <b>112</b>. The communication module <b>110</b> manages the communication between the system controller <b>108</b> and the distributed test systems <b>114</b>. For instance, the communication module <b>110</b> is responsible for locating available test systems <b>114</b>, running test execution requests, and gathering information regarding the status of the test systems <b>114</b>. In one example, the system controller <b>108</b> manages the communication with the distributed test systems <b>114</b> by implementing a plurality of threads. In this manner, the system controller <b>108</b> has the capability to communicate with a plurality of test systems <b>114</b> in parallel. However, it must be noted that in a different embodiment, the system controller <b>108</b> may implement any suitable mechanism to manage the communication between the system controller <b>108</b> and the distributed test systems <b>114</b> (e.g., Jini, RMI, TCP/IP Sockets, etc.).

[0075] The test suite management module <b>112</b> is responsible for managing the processing of the submitted test suites and the test execution requests. As used herein a test suite is a comprehensive list of data files having commands specifically programmed to initiate a number of functional aspects of the software product being tested. For instance, if the software product being tested is a word processing program, the test suite may activate a spell check command, a cut test command, a paste command, etc. Thus, once the test suite is executed, the test results reveal whether any of the tested commands failed to operate as intended. Also as used herein, once submitted for processing, each test suite becomes a “test execution request.” As the processing of different portions of the test suite can be assigned to different test machines, the test suites may be divided into a plurality of test execution requests (i.e., jobs).

[0076] By way of example, the test suite management module <b>112</b> maintains an inqueue directory designed to include almost all the submitted test execution requests. Once the system controller <b>108</b> is initiated, the system controller <b>108</b> is configured to read each test execution request from files held in the inqueue directory. Once a test execution request is read, it is put into either a wait queue configured to hold test execution requests waiting to be executed or an execution queue designed to hold test execution requests currently being executed. Further information regarding managing the inqueue directory, wait queue, and execution queue will be provided below. As illustrated, in one example, the test suite management module <b>112</b> is configured to manage the software applications and user interfaces implemented for job submission, queue watching, job administration, etc., as shown in <b>116</b>.

[0077] The test system group <b>114</b>′ includes a plurality of test systems <b>114</b> having similar or diverse hardware and software configuration. Although shown as a group, the test systems <b>114</b> are not necessarily limited to testing. In fact, the test systems <b>114</b> can be computers or systems used by employees of a company for normal desktop work. So long as the test systems <b>114</b> are associated with the networked group, the processing power of these test systems <b>114</b> can be used. In one embodiment, the test systems <b>114</b> can be used during normal working hours when the test systems <b>114</b> are running, for example, business applications, or during off hours, thus tapping into potentially huge processing resources that would otherwise be left unused. It should therefore be appreciated that test systems <b>114</b> do not necessarily have to be solely dedicated to testing or processing for the system server group <b>101</b>.

[0078] In one embodiment, the test systems <b>114</b> are configured to execute the test execution requests dispatched by the system controller <b>108</b>. Each of the test systems <b>114</b> runs an agent process (not shown in this Figure) designed to register the respective test system <b>114</b> with the Jini look up service <b>104</b>. In this manner, the agent process for each test system <b>114</b> advertises the availability of the associated test system <b>114</b>. As will be discussed in further detail below, a machine service component of the agent is used to establish communication between the associated test system <b>114</b> and the system controller <b>108</b>. Specifically, by implementing the Jini attributes, the machine service registers the test system <b>114</b> characteristics with the Jini look up service <b>104</b>. The test system <b>114</b> attributes are subsequently used by the system controller <b>108</b> to locate a test system <b>114</b> suitable to execute a specific test execution request.

[0079] While the DTF system <b>100</b> of the present invention can physically be divided into two groups, logically, the DTF system <b>100</b> of the present invention is comprised of three over all parts: (1) Job submission and other user interfaces; (2) Test scheduler and system controller; and (3) Test execution on remote or local systems.

[0080] For the most part, the job submission and other user interfaces component is a job queuing system having a variety of applications and user interfaces. As designed, the job submission component is configured to perform several tasks such as handling job submission, managing queues, administrating jobs, and administrating the ad-hoc network of the distributed test systems.

[0081] By way of example, in one implementation, the user interface may be as follows:

[0082] Launch system controller: In one embodiment, launching the system controller <b>108</b> is performed by running an appropriate shell script. As designed, the shell script is configured to launch the Jini and RMI support servers.

[0083] Kill system controller: Finds substantially all the processes, and once found kills each of the processes, individually.

[0084] Submit jobs: Before the system controller <b>108</b> is launched, an Extensible Markup Language (XML) formatted test-execution-request file is created in the inqueue directory (e.g., that is preferably part of the test suite management module). In this manner, once the system Controller <b>108</b> is launched, the system controller <b>108</b> scans the inqueue directory, thus entering almost each and every test execution request into the in-queue (the in-queue being an actual queue, as contrasted with the inqueue directory).

[0085] Check queue: In one embodiment, a stopgap Graphical User Interface (GUI) is provided.

[0086] Cancel/administer a job: In one implementation, a stopgap GUI is implemented.

[0087] Other administrative tasks: In one exemplary embodiment, additional user interfaces are included. For instance, in certain cases, the system controller <b>108</b> is configured to implement various input files.

[0088] The second logical component, the test scheduler and system controller, includes the system controller <b>108</b> configured to perform the function of managing the job queues and dispatching the test execution requests to test system <b>114</b> for processing. Thus, the system controller <b>108</b> is configured to manage both; the wait queue (i.e., the queue containing the test execution requests waiting to be executed) and the execution queue (i.e., the queue containing test execution requests currently being executed). In one embodiment, the in-queue is analogous to the wait queue.

[0089] As designed, the test scheduler and system controller component is configured to include four modules:

[0090] Suite MGR: This module maintains a list of the available test suites stored in a known location in the file system. As designed, the test suite descriptions are stored in an XML formatted file in a suite directory.

[0091] Log MGR: This module is configured to handle the logging of activities inside the system controller <b>108</b> by implementing a plurality of log files having XML format. For instance, this is particularly useful for debug tracing and system statistics charting.

[0092] Queue MGR: This module is designed to maintain the two queues, wait queue (i.e., the in-queue) and the execution queue. Specifically, while a job is in any of the queues, an XML formatted file is kept in the queue directory reflecting the current status of the job. Each test execution request is configured to have a list of attributes describing the system characteristics required to execute the test execution request.

[0093] Scheduler: This module is configured to manage the dispatch of the test execution requests from the wait queue to the execution queue. In one embodiment, a job is dispatched when (a) the time to execute the job has been reached, and (b) a test system <b>114</b> having the required characteristics is available to execute the job.

[0094] Reference is made to a block diagram depicted in FIG. 2 wherein the capability of the present invention to intelligently locate a test system <b>114</b> available to execute a test suite is illustrated, in accordance with one embodiment of the present invention. As shown, an inqueue directory <b>116</b> contains a plurality of test execution requests <b>116</b><i>a</i>, <b>116</b><i>b</i>, and <b>116</b><i>c</i>. In accordance with one embodiment of the present invention, once the system controller <b>108</b> is initiated, the system controller <b>108</b> is designed to read each test execution request <b>116</b><i>a</i>-<b>116</b><i>c </i>contained within the inqueue directory <b>116</b>. As shown, each test suite request <b>116</b><i>a</i>-<b>116</b><i>c </i>must be executed by a test system <b>114</b> capable of running the test execution request requirements. For instance, each of the test execution requests <b>116</b><i>a</i>, <b>116</b><i>b</i>, and <b>116</b><i>c </i>must be run on a Solaris IA™ test system, a Microsoft (MS) windows test system, or a LinuX™ test system, respectively. As will be described in more detail below, the DTF system <b>100</b> of the present invention has the capability to advantageously locate an available test system from a plurality of ad-hoc network of test systems <b>114</b><i>a</i>, <b>114</b><i>b</i>, <b>114</b><i>c</i>, and <b>114</b><i>d </i>to execute each of the test execution requests <b>116</b><i>a</i>-<b>116</b><i>c. </i>

[0095] As shown in the embodiment depicted in FIG. 2, each of the test systems <b>114</b><i>a</i>-<b>114</b><i>d </i>has a different software and hardware configuration. For instance, while the test system <b>114</b><i>a </i>is run on Solaris IA™ and the test system <b>114</b><i>b </i>is run on Linux™, the test systems <b>114</b><i>c </i>and <b>114</b><i>d </i>are programmed to run on Solaris, MS windows, and Solaris™, respectively. As will be discussed in more detail below, the machine service for each test system <b>114</b><i>a</i>-<b>114</b><i>c </i>registers the respective test system <b>114</b><i>a</i>-<b>114</b><i>c </i>with the Jini look up service using the Jini attributes. Particularly, the embodiments of the present invention are configured to register the hardware and software configuration for each test system <b>114</b><i>a</i>-<b>114</b><i>d </i>with the Jini look up service <b>104</b>. In this manner, the system controller <b>108</b> can search the Jini look up service <b>104</b> implementing the test execution request requirements as search criteria. Thus, as shown in the example of FIG. 2, the system controller <b>108</b> of the present invention selects the test systems <b>114</b><i>a</i>, <b>114</b><i>c</i>, and <b>114</b><i>b </i>to execute the test suite requests <b>116</b><i>a</i>-<b>116</b><i>c</i>, respectively.

[0096] Implementing the test system attributes to locate a suitable test system to run a test execution request can further be understood with respect to the block diagram shown in FIG. 3, in accordance with one embodiment of the present invention. As shown, the test systems <b>114</b><i>b </i>and <b>114</b><i>a</i>, the system controller <b>108</b>, and the Jini look up service <b>104</b> communicate to each other using Jini. In one example, the system controller <b>108</b>, the Jini look up service <b>104</b>, and the test systems <b>114</b><i>a </i>and <b>114</b><i>b </i>and all the other resources that are Jini enabled form a virtual Jini community <b>118</b>.

[0097] As shown, the test system <b>114</b><i>a </i>runs an agent process <b>120</b><i>a </i>responsible for notifying the Jini look up service <b>104</b> of the existence and configuration of the test system <b>114</b><i>a</i>. In one example, the agent <b>120</b><i>a </i>is also designed to export a downloadable image of itself. Beneficially, the downloadable image allows the system controller <b>108</b> to ask the test system <b>114</b><i>a </i>to initiate running a test execution request while interacting with the test system <b>114</b><i>a </i>as the test execution request is being processed.

[0098] The illustrated agent <b>120</b><i>a </i>involves two Jini services, machine service <b>114</b><i>a</i>-MS and test service <b>114</b><i>a</i>-TS. The function of the machine service <b>114</b><i>a</i>-MS is to advertise the availability of the test system <b>114</b><i>a</i>, the characteristics of the test system <b>114</b><i>a</i>, and the ability of the test system <b>114</b><i>a </i>to launch a test execution request. Additionally, the machine service <b>114</b><i>a</i>-MS is designed to be present on the test machine <b>114</b><i>a </i>at all times. As such, the machine service <b>114</b><i>a</i>-MS is initiated on the test system <b>114</b><i>a </i>at the start-up time and is configured to remain active on the test system <b>114</b><i>a </i>until the test system <b>114</b><i>a </i>is shut down.

[0099] Comparatively, the test service <b>114</b><i>a</i>-TS is a module configured to encapsulate the test execution request. As designed, the test service <b>114</b><i>a</i>-TS is spawned by the machine service <b>114</b><i>a</i>-MS and is subsequently launched when the machine service <b>114</b><i>a</i>-MS receives a request to start running a test execution request from the system controller <b>108</b>. Specifically, the new test service <b>114</b><i>a</i>-TS is spawned based on the test execution request type. By way of example, in one embodiment, the machine service <b>114</b><i>a</i>-MS spawns separate test systems <b>114</b><i>a</i>-TS when running, ant based test suites, shell-type test suites, and other test suites such as Tonga-type, JCK-type, JTREG-type, etc. However, one having ordinary skill in the art must appreciate that in a different example, the machine services of the DTF system of the present invention are configured to spawn other suitable test systems. As shown, similar to test system <b>114</b><i>a</i>, the test system <b>114</b><i>b </i>is configured to include an agent <b>120</b><i>b </i>designed to include a machine system <b>114</b><i>b</i>-MS and a test system <b>114</b><i>b</i>-TS.

[0100] As will be discussed in more detail below and as shown in the implementation of FIG. 3, the machine service <b>114</b><i>a</i>-MS and test service <b>114</b><i>a</i>-TS, respectively, register Jini attributes <b>104</b><i>a</i>-MS.A and <b>104</b><i>a</i>-TS.A of the test system <b>114</b><i>a </i>with the Jini look up service <b>104</b>. For instance, in one embodiment, the sequence of events in registering the machine service <b>114</b><i>a</i>-MS and test service <b>114</b><i>a</i>-TS may be as follows: Once the test-system <b>114</b><i>a </i>discovers and joins the Jini community <b>118</b>, the test service <b>114</b><i>a</i>-MS of the test system <b>114</b><i>a </i>registers with the Jini look up service <b>104</b>. In this manner, the machine service <b>114</b><i>a</i>-MS registers a machine service proxy <b>104</b><i>a</i>-MS.P and the attributes <b>104</b><i>a</i>-MS.A of the machine service <b>114</b><i>a</i>-MS with the look up service <b>104</b>. The Jini attributes <b>104</b><i>a</i>-MS.A are then used by the system controller <b>108</b> to locate a test service having attributes suitable to run the test execution request.

[0101] Once the test system <b>114</b><i>a </i>has been selected to run the test execution request, the machine service <b>114</b><i>a</i>-MS spawns a test service <b>114</b><i>a</i>-TS having the same type as the test execution request. As discussed above, the machine service <b>114</b><i>a</i>-MS is configured to spawn a matching test service <b>114</b><i>a</i>-TS for each test execution request type. For example, the test system <b>114</b><i>a </i>may have the attributes to run a Tonga test execution request and a JTREG type test execution request. In such a situation, the Jini look up service <b>104</b> will include two test services each running a different type of test execution request. As a consequence, when the processing of one type of test execution request has concluded, the test service <b>114</b><i>a</i>-TS having substantially the same type can be terminated. Thus, for the most part, the test service <b>104</b><i>a</i>-TS, <b>104</b><i>a</i>-TS.A, and <b>104</b>-TS.P are designed to substantially exist while the test system <b>114</b><i>a </i>is running a test execution request. In this manner, the system controller <b>108</b> can determine whether the test system <b>114</b><i>a </i>is processing a test execution request. Specifically, this is achieved by the system controller <b>108</b> simply querying the Jini look up service <b>104</b> as to whether the test system <b>114</b><i>a </i>has an associated existing test service.

[0102] In addition to registering the attributes <b>104</b><i>a</i>-MS.A and <b>104</b><i>a</i>-TS.A, the machine service <b>114</b><i>a</i>-MS and the test system <b>114</b><i>a</i>-TS are configured to respectively register a corresponding machine service proxy <b>104</b>-MS.P and a respective test service proxy <b>104</b>-TS.P with the Jini look up service <b>104</b>. As designed, the system controller <b>108</b> implements the machine service proxy <b>104</b>-MS.P and the test service proxy <b>104</b>-TS.P to communicate with the test system <b>114</b><i>a</i>. Particularly, once the system controller <b>108</b> has selected the test system <b>114</b><i>a </i>to run the test execution request, the system controller <b>108</b> downloads the machine service proxy <b>104</b>-MS.P from the Jini look up service <b>104</b>. Once the machine service proxy <b>104</b>-MS.P is downloaded, the system controller <b>108</b> starts communicating with the machine service proxy <b>104</b>-MS.P rather than communicating directly with the corresponding test system <b>114</b><i>a </i>or the machine service <b>114</b><i>a</i>-MS.

[0103] In a like manner, the test service proxy <b>104</b>-TS.P is the communication channel between the system controller <b>108</b> and the test service <b>114</b><i>a</i>-TS. Thus, similar to the machine service <b>114</b><i>a</i>-MS, the system controller <b>108</b> downloads the test service proxy <b>104</b>-TS.P from the Jini look up service <b>104</b>. Thereafter, the system controller communicates with the test service proxy <b>104</b>-TS.P as if communicating with the test system <b>114</b><i>a </i>or the test service <b>114</b><i>a</i>-TS. As shown, in the same manner, the machine service <b>114</b><i>b</i>-MS and test service <b>114</b><i>b</i>-TS register their respective machine service proxy <b>104</b><i>b</i>-MS.P and machine service attributes <b>104</b><i>b</i>-MS.A as well as the respective test service proxy <b>104</b><i>b</i>-TS.P and test service attributes <b>104</b><i>b</i>-TS.A with the Jini look up service <b>104</b>.

[0104] The capability of the present invention to determine the availability of a test system to process a test execution request having a set of specific requirements can further be understood with reference to the block diagram of FIG. 4, in accordance to one embodiment of the present invention. As illustrated, a plurality of test systems <b>114</b><i>a</i>-<b>114</b>_nrespectively ng a PC <b>100</b>, Sparc, PC <b>99</b>, Macintosh, PC <b>100</b>, and Macintosh are registered with the Jini look up service <b>104</b>. That is, for each test system <b>114</b><i>a</i>-<b>114</b>_n, the Jini look up service <b>104</b> contains an associated machine service <b>104</b><i>a</i>-MS to <b>104</b>_n-MS. In a like manner, for each machine service <b>104</b><i>a</i>-MS to <b>104</b>_n-MS, the Jini look up service <b>104</b> includes a corresponding machine service proxy <b>104</b><i>a</i>-MS.P to <b>104</b>_n-MS.P and the associated machine service attributes <b>104</b><i>a</i>-MS.A to <b>104</b>_n-MS.A.

[0105] Although for each test system <b>114</b><i>a</i>-<b>114</b>_na machine service entry can be found in the Jini look up service <b>104</b>, only test systems <b>114</b><i>a</i>, <b>114</b><i>b </i>and <b>114</b><i>e </i>have associated test services <b>104</b><i>a</i>-TS, <b>104</b><i>b</i>-TS, and <b>104</b><i>e</i>-TS. Further more, as shown, for each of the test systems <b>114</b><i>a</i>, <b>114</b><i>b </i>and <b>114</b><i>e</i>, the Jini look up service <b>104</b> includes the corresponding test system proxy <b>104</b><i>a</i>-TS.P, <b>104</b><i>b</i>-TS.P, and <b>104</b><i>c</i>-TS.P and the respective test system attributes <b>104</b><i>a</i>-TS.A, <b>104</b><i>b</i>-TS.A, and <b>104</b><i>c</i>-TS.A. In one embodiment, having associated test systems in the Jini look up service are the indications of the busy status of the test systems <b>114</b><i>a</i>, <b>114</b><i>b</i>, and <b>114</b><i>e</i>, respectively.

[0106] For instance, at this point, when the system controller <b>108</b> receives a test execution request requiring to be processed by a PC <b>100</b>, the system controller <b>108</b> searches for an available PC <b>100</b> test system. While searching the Jini look up service <b>104</b>, the system controller <b>108</b> will first locate the machine service <b>104</b><i>a</i>-MS. Despite machine service <b>104</b><i>a</i>-MS having the required attribute (i.e., being a PC <b>100</b>), the system controller <b>108</b> will have to by pass this entry, as the test system <b>114</b><i>a </i>is busy. The system controller <b>108</b> detects the unavailability of test system <b>114</b><i>a </i>by the Jini look up service <b>104</b> including the test service <b>104</b><i>a</i>-TS associated with the test system <b>114</b><i>a</i>. Subsequently, in search of the next available PC <b>100</b> test system, the system controller locates machine service <b>104</b><i>c</i>-MS. However, this time, the Jini look up service does not include a test system associated with the test system <b>114</b><i>c</i>, revealing the test system <b>114</b><i>c </i>availability to execute the test execution request.

[0107] As will be discussed in more detail below, in one implementation, the lack of a corresponding test service in the Jini look up service <b>104</b> occurs once the test execution request has concluded and the test service <b>104</b><i>a</i>-TS lease with the Jini look up service <b>104</b> has expired. Thus, once the test service <b>104</b><i>a</i>-TS and its associated proxy <b>104</b><i>a</i>-TS.P and attributes <b>104</b><i>a</i>-TS.A have been removed from the Jini look up service <b>104</b>, the test system <b>114</b><i>a </i>can then be selected to execute a different test execution request. Depending on the type of the test execution request, a different or the same type of test service <b>114</b><i>a</i>-TS is spawned by the machine service <b>114</b><i>a</i>-MS, again indicating the busy status of the test system <b>114</b><i>a. </i>

[0108] Reference is now made to FIG. 5 depicting the one-to-one communication between the system controller <b>108</b>, Jini look up service <b>104</b>, and test system <b>114</b> of the DTF system, in accordance with one embodiment of the present invention. As shown, enabled by the Jini technology, a machine service <b>114</b>-MS component of the test system <b>114</b> discovers the Jini look up service <b>104</b>. Thereafter, the machine service <b>114</b>-MS joins the Jini look up service <b>104</b> by registering a plurality of Jini attributes <b>104</b>-MS.A and a machine system proxy <b>104</b>-MS.P with the Jini look up service <b>104</b>.

[0109] Seeking a test system to execute a given test execution request, the system controller <b>108</b> discovers the Jini look up service <b>104</b>. Subsequently, the system controller <b>108</b> searches the Jini look up service <b>104</b> for a test system suitable to run the test execution request. Once the system controller <b>108</b> has determined that the machine service attributes <b>104</b>-MS.A of the test system <b>114</b> matches to that required to run the test execution request, the system controller <b>108</b> downloads the machine service proxy <b>104</b>-MS.P from the Jini look up service <b>104</b>. From then on, the system controller <b>108</b> starts communicating with the machine service proxy <b>104</b>-MS.P as if communicating with the machine service <b>114</b>-MS. At this point, the system controller <b>108</b> communicates with the machine service proxy <b>104</b>-MS.P requesting the execution of the test execution request.

[0110] Subsequent to receiving this request, the machine service <b>114</b>-MS spawns a test service <b>114</b>-TS which type matches that required by the test execution request. Next, a test service proxy <b>104</b>-TS.P and a set of test service attributes <b>104</b>-TS.A of the test service <b>114</b>-TS are then registered with the Jini look up service <b>104</b>. Thereafter, the system controller <b>108</b> downloads the test service proxy <b>104</b>-TS.P and communicates with the test system proxy <b>104</b>-TS.P as if communicating with the test system <b>114</b>-TS. Then, the test service <b>114</b>-TS receives the test execution command from the system controller <b>108</b>, thus initiating the test execution request.

[0111] As was discussed in more detail above, once the test execution has concluded, the test service <b>114</b>-TS lease with the Jini look up service <b>104</b> expires, thus triggering the removal of the test system proxy <b>104</b>-TS.P and test system attributes <b>104</b>-TS.A from the Jini look up service <b>104</b>. In this manner, the system controller <b>108</b> associates the availability of the test system <b>114</b> to run the next test execution request with the test system <b>114</b> lacking of a registered test service proxy <b>104</b>-TS.P.

[0112] Proceeding to the block diagram of FIG. 6, the interaction between the Jini look up service <b>104</b>, system controller <b>108</b>, and test system <b>114</b> can further be understood, in accordance with one implementation of the present invention. As discussed in more detail above, the test system <b>114</b> includes a machine service <b>114</b>-MS and a test service <b>114</b>-TS. As designed, the machine service <b>114</b>-MS includes a lease manager <b>124</b>, a launch manager <b>122</b>, and an attribute manager <b>120</b> while the test system <b>114</b>-TS includes a call back <b>126</b>, a report manager <b>128</b>, and a lease manager <b>130</b>.

[0113] In one example, the interaction between the DTF system components starts by the test system <b>114</b> discovering the Jini look up service <b>104</b>. Subsequent to this discovery, the machine service <b>114</b>-MS communicates with the attribute manager <b>120</b>, obtaining the test system <b>114</b> attributes. Thereafter, the machine service <b>114</b>-MS joins the Jini look up service <b>104</b> by registering the machine service <b>114</b>-MS proxy and machine service attributes with the Jini look up service <b>104</b>. As part of registering the machine service <b>114</b>-MS with the look up service <b>104</b>, the lease manager <b>124</b> leases the machine service <b>114</b> for a specific period of time. That is, the lease manager <b>124</b> registers the availability of the test system <b>114</b> to execute a test execution request for a specific period of time. However, before the leased period is expired, the lease manager <b>124</b> can renew the lease with the Jini look up service <b>104</b>. In this manner, once the test system <b>114</b> is removed from the ad-hoc network of the distributed test systems, the machine service proxy, machine service attributes, test service proxy, and test service attributes are automatically removed from the Jini look up service <b>104</b> as soon as the lease is expired.

[0114] At this point, the system controller <b>108</b> scans the in-queue directory, reading the required attributes for running the first test execution request in the in-queue (i.e., the wait queue). The system controller <b>108</b> then searches the Jini look up service <b>104</b>, looking for a test system having attributes matching to that required by the test execution request (or computer process) to be processed. Once the system controller <b>108</b> determines that the test system <b>114</b> is a suitable test system to run the test execution request, the system controller <b>108</b> downloads the machine service proxy for the test system <b>114</b> from the Jini look up service <b>104</b>. As shown in the embodiment of FIG. 6, once the machine service proxy is downloaded, the system controller <b>108</b> use the proxy communication <b>105</b> to communicate with the machine service proxy as if communicating with the test system <b>114</b>. At this point, the test execution is initiated by the system controller <b>108</b> dispatching a start execution request to the machine service <b>114</b>-MS.

[0115] Once the launch manager <b>122</b> component of the machine service <b>114</b>-MS receives the system controller <b>108</b> request to start test execution, the launch manager <b>122</b> spawns the appropriate test service <b>114</b>-TS. Specifically, the test service <b>114</b>-TS type spawned by the launch manager <b>122</b> is determined by the test execution request requirements dispatched by the system controller <b>108</b>. Irrespective of the test service <b>114</b>-TS type, the lease manager <b>130</b> of the test system <b>114</b>-TS is configured to register the test system attributes and a test system proxy with the Jini look up service <b>104</b>. Again, like the machine service <b>114</b>-MS, the test service <b>114</b>-TS registers its availability to execute the test execution request with the Jini look up service <b>104</b> for a specified lease period. At this point, the system controller <b>108</b> downloads the test service proxy from the Jini look up service <b>104</b> and communicates with the test system proxy as if the system controller <b>108</b> is communicating with the test service <b>114</b>-TS.

[0116] Once the test service <b>114</b>-TS starts executing the job, the test service <b>114</b>-TS sends an event to the system controller <b>108</b> indicating the commencement of the test execution request processing. In one embodiment, the test service <b>114</b>-TS is designed to send additional events during the running of the test execution request and upon its conclusion. At the conclusion of running the test execution request, the call back component <b>126</b> is configured to communicate with the lease manager <b>130</b> signaling the conclusion of processing the test execution request. Once the lease manager <b>130</b> receives such communication, the lease manager <b>130</b> communicates with the Jini look up service <b>104</b> signaling the expiration of the test suite <b>114</b>-TS lease with the Jini look up service <b>104</b>. Upon the expiration of the test suite <b>114</b>-TS lease with the Jini look up service <b>104</b>, the test suite <b>114</b> proxy and test suite <b>114</b> attribute entries are removed from the Jini look up service <b>104</b>, thus pointing out the availability of the test system <b>114</b> for processing another suitable job.

[0117] The test result data generated by the processing of the test execution request are collected, categorized, and maintained by the report manager <b>128</b>. In one embodiment, the report manager <b>128</b> analyzes and generates a test report implementing the test result data. Thus, in one embodiment of the present invention, the test systems <b>114</b> of the DTF system generate test reports using the results generated by the processing of an associated test execution request. However, in a different embodiment, the test results generated by each test system <b>114</b> may be utilized so as to create a test result summary report, covering the test results produced by each of the test systems <b>114</b>.

[0118] I. Distributed Process Runner

[0119] Reference is made to a simplified block diagram of FIG. 7 illustrating an exemplary distributed test runner (DTR) <b>150</b> managing and monitoring testing of an exemplary process using a plurality of test systems <b>114</b><i>a</i>-<b>114</b><i>e</i>, in accordance with one embodiment of the present invention. As shown, the system controller <b>108</b> of the DTF <b>101</b> provides the DTR <b>150</b> with all available data about all the test systems <b>114</b><i>a</i>-<b>114</b><i>e</i>, registered with the Jini look up service. The DTR is shown to include a plurality of task directories <b>151</b>, <b>151</b>′, and <b>151</b>″, each of which is designed to include a plurality of task files scheduled for execution. As shown, an exemplary directory <b>151</b> includes task files <b>151</b><i>a</i>-<b>151</b><i>e </i>to be tested by the test systems <b>114</b><i>a</i>-<b>114</b><i>e. </i>

[0120] As shown, a first task to be performed by the DTR <b>150</b> is launching of a Server controller <b>152</b> on a test system having a desired platform. In accordance with one embodiment, the test systems <b>114</b><i>a</i>-<b>114</b><i>e </i>are searched so as to find a test system having the desired platform. For instance, in the embodiment of FIG. 7, the test system <b>114</b><i>a </i>is shown to have the desired Solaris IA platform. Once the test system <b>114</b><i>a </i>having the desired platform is located, the server controller <b>152</b> is launched on the test system <b>114</b><i>a</i>. In one example, the server controller <b>152</b> is a software code that is launched using the Internet. However, in a different embodiment, the server controller may be launched using any suitable mechanism.

[0121] Thereafter, the server controller <b>152</b> obtains all existing data about all of the available test system <b>114</b><i>b</i>-<b>114</b><i>e </i>from the DTF system controller <b>108</b>. In one example, the data obtained may include the IP Address for each of the test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>, operating system types, machines names, etc. Then, the server controller <b>152</b> designates all the remaining test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>as distributed test systems selected to execute the tasks. To designate the remaining test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>, the server controller <b>152</b> launches client server <b>154</b><i>b</i>-<b>154</b><i>e </i>on each of the respective test system <b>114</b><i>b</i>-<b>114</b><i>e</i>. In one instance, the client servers <b>154</b><i>b</i>-<b>154</b><i>e </i>are software code launched on the respective test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>using the Internet.

[0122] At this point, the server controller <b>152</b> can communicate with the client servers <b>154</b><i>b</i>-<b>154</b><i>e</i>. In one example, the server controller <b>152</b> communicates with the client servers <b>154</b><i>b</i>-<b>154</b><i>e </i>using a respective thread. In a different embodiment, the server controller <b>152</b> may implement any appropriate mechanism capable of providing communication between the client controllers <b>154</b><i>b</i>-<b>154</b><i>e </i>and the server controller (e.g., soap over http, socket communication, message queues, Remote Method Invocation (RMI), etc.).

[0123] As illustrated, the task directory <b>151</b> in DTR <b>150</b> includes a plurality of task files <b>151</b><i>a</i>-<b>151</b><i>e</i>, scheduled to be tested by the test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>. In one embodiment, after the server controller <b>152</b> has been launched, the server controller <b>152</b> reads and obtains each task file <b>151</b><i>a</i>-<b>151</b><i>e </i>in the task directory <b>151</b>. Thereafter, task-flow-based scheduling, as provided in each task file <b>151</b><i>a</i>-<b>15</b><i>e</i>, is implemented by the server controller <b>152</b> to schedule each task in each task group in each task file <b>151</b><i>a</i>-<b>151</b><i>e</i>. In one example, the server controller <b>152</b> initiates assigning tasks starting with a first task group in the task file <b>151</b><i>a</i>. At this point, the server controller <b>152</b> determines the number of tasks in the first task group and the types of each respective operating system. Then, the server controller <b>152</b> searches the available test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>so as to find test systems having operating systems matching those required to execute the tasks in the first task group. For instance, the first task group includes four tasks to be executed on Linux, Mac <b>10</b>, Windows, and Solaris operating systems. At this point, the server controller <b>152</b> searches the available test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>, looking for four test systems that have Linux, Mac <b>10</b>, Windows, and Solaris operating systems, and are simultaneously available to execute the four tasks. Assuming that the test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>are all simultaneously available, the server controller <b>152</b> can select the test systems <b>114</b><i>b</i>, <b>114</b><i>c</i>, <b>114</b><i>e</i>, and <b>114</b><i>d </i>to respectively execute each of the four tasks.

[0124] Continuing to FIG. 8, the interactions between the server controller <b>152</b> and client controllers <b>154</b><i>b</i>-<i>e </i>of the DTR system of the present invention can further be understood, in accordance with one embodiment. As shown, the server controller <b>152</b> launched on the test system <b>114</b><i>a </i>has designated test system <b>114</b><i>b</i>-<b>114</b><i>e</i>, as test systems of the dynamic cross-platform network of test systems available for executing tasks. As such, the client controllers <b>154</b><i>b</i>-<b>154</b><i>e </i>have been respectively launched on each of the test systems <b>114</b><i>b</i>-<b>114</b><i>e. </i>

[0125] After the server controller <b>152</b> has been launched on the test system <b>114</b><i>a</i>, as illustrated, the server controller <b>152</b> communicates with the system controller <b>108</b> of the DTF <b>101</b>, requesting that the system controller <b>108</b> provide the server controller <b>152</b> with all available data about all available test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>of the ad-hoc distributed test systems registered with the Jini look up service. Once the server controller <b>152</b> has been provided the requested data, control is passed from the system controller <b>108</b> of the DTF to the server controller <b>152</b> launched on the test system <b>114</b><i>a. </i>

[0126] In accordance with one embodiment of the present invention, the server controller <b>152</b> is configured to manage scheduling and execution of tasks on test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>. In one implementation, as shown in the embodiment of FIG. 8, the server controller <b>152</b> includes a task manager module <b>152</b><i>a </i>and a scheduler module <b>152</b><i>b</i>. According to one embodiment, the task manager module <b>152</b><i>a </i>is designed to look through each of the task files <b>151</b><i>a</i>-<b>151</b><i>e </i>defined in the task directory <b>151</b>, and assign each task, in each of the task groups TG<b>1</b> through TG<b>3</b> to test systems available to execute tasks. The task manager module <b>152</b><i>b </i>then communicates with the scheduler module <b>152</b><i>b</i>, requesting that the scheduler module <b>152</b><i>b </i>arrange a task in a particular task group in a given task file for execution.

[0127] By way of example, the task directory <b>151</b> is shown to include several task files <b>151</b><i>b</i>-<b>151</b><i>e</i>. As shown, the first task file <b>151</b><i>a </i>has three task groups, the second task file <b>151</b><i>b </i>has two task groups, and the third task file <b>151</b><i>c </i>has one task group, etc. In one embodiment, the task manager module <b>152</b><i>a </i>starts with the first task file <b>151</b><i>a </i>in a selected directory, <b>151</b>. The first task file <b>151</b><i>a </i>includes three task groups, with each task group including a plurality of tasks. At this point, the task manager <b>152</b><i>b </i>communicates with the scheduler module <b>152</b><i>b</i>, requesting that the execution of the first task group in the first task file <b>151</b><i>a </i>be initiated. As will be described in more detail below, the embodiments of the present invention start executing the plurality of tasks in the task group once all the test systems required to test each task in the task group are simultaneously available to execute their respective tasks. For instance, if only two test systems having two of the required platforms are available to execute two of the tasks in the TG<b>1</b>, the server controller <b>152</b> sets the two available test systems aside. However, server controller waits until the test systems having requirements (e.g., operating systems) matching those required by the remaining tasks. Meanwhile, the server controller <b>152</b> may proceed to execute the next task group TG<b>2</b>, if the TG<b>2</b> can be executed independently of task group TG<b>1</b>. Once, the scheduler module <b>152</b><i>b </i>has located the required test systems that are all simultaneously available, the scheduler module <b>152</b><i>b </i>assigns the execution of a particular task to a test system having the matching platform (e.g., test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>).

[0128] In one example, the server controller <b>152</b> creates a new thread when initiating the execution of a new task group. Once the execution of the task group has concluded, the server controller <b>152</b> terminates that thread. In another embodiment, the server controller may implement a different mechanism to keep track of the tasks in each task group (e.g., enterprise java beans (e.g., session beans), Pre-initialized thread pools, etc.).

[0129] In one embodiment, once the test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>have finished executing their respective assigned tasks, the test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>may store their task execution results in each of their respective storage. In another embodiment, the server controller <b>152</b> may communicate to the user inquiring the user as to user's preference. At this point, once the server controller <b>152</b> has obtained a feedback from the user, the server controller <b>152</b> communicates user's preference to the client servers <b>154</b><i>b</i>-<i>e</i>. For instance, the user may request that the results be stored to either, a results directory <b>153</b>, on each of their respective storage, or any other appropriate storage selected by the user.

[0130] It must be appreciated by one of ordinary skill in the art that although the embodiments of the present invention have been shown to implement each of the server controller, server controller, and client controllers on different computers, in one embodiment, the server controller, server controller, and client controllers can be launched on the same computers.

[0131] FIGS. <b>9</b>A-<b>9</b>D are simplified illustrations of an exemplary task file <b>151</b><i>a</i>, a task group file <b>158</b>, a configuration file <b>174</b>, and a machine.props file <b>176</b>, in accordance with one embodiment of the present invention. The task file <b>151</b><i>a </i>of the embodiment of FIG. 9A is shown to have three task groups <b>156</b><i>a</i>-<b>156</b><i>c</i>. As shown, the first task group <b>156</b><i>a </i>includes four tasks A, B, C, and D. As shown, the task-flow-based processing implemented in the task group <b>156</b><i>a </i>shows that tasks A and C are independent tasks, and as such, can be executed in parallel. Task B, is shown to be dependent on task A, and task D is illustrated to be executed after both tasks C and D have concluded.

[0132] Tasks E, F, and G in the second task group <b>156</b><i>b </i>are shown to have a sequential task-flow-base, while tasks H, I, J, K, and L of the third task group <b>156</b><i>c </i>are required to follow a more complicated task-flow-based arrangement. As shown, tasks H, J, and L can be executed in parallel while task I can be executed after execution of task H has concluded. In a like manner, task K can be executed after execution of tasks J, I, and L, have concluded. In the embodiment shown in FIG. 9A, if there exist enough available test systems with the desired operating systems, the task groups <b>156</b><i>a</i>-<b>156</b><i>c </i>can be executed in parallel.

[0133] Continuing to FIG. 9B, an exemplary task group file <b>158</b> is shown. As illustrated, the task A <b>160</b> is assigned to be executed by an abstract machine M<b>1</b>, task B <b>162</b> is assigned to an abstract machine M<b>2</b>, task C <b>164</b> is assigned to abstract machine M<b>3</b>, and task D <b>166</b> assigned to abstract machine M<b>4</b>. The benefit of using the abstract machine information M<b>1</b>-M<b>4</b> rather than actual test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>, is that abstract machine M<b>1</b> can be a Linux machine in one configuration but in the next configuration be substituted for a Solaris IA machine. In this manner, the tests can be re-run in multiple configurations by having entries in the configuration file (e.g., platform file) without having to make any changes or modification to the task file. Additionally, machine information is generated at runtime, thus, depending on the configuration requested, the user may select a configuration at any time by simply changing the configuration according to their requirement without having to modify any tests or task files.

[0134] As discussed with regards to the embodiment of FIG. 9A, task B is configured to be executed after execution of task A has concluded. Thus, the embodiments of the present invention use a “Wait” variable to ensure that the task-flow-based arrangement in each task group and task file is followed properly. As shown in a box <b>163</b><i>b</i>, the task B <b>162</b> should wait until the execution of task A has concluded. In a like manner, execution of task D <b>166</b> cannot start until both task C and Task B in box <b>163</b><i>d </i>have concluded.

[0135] The embodiments of the present invention are designed to perform specific functions if a response has not been received from a test system for a predetermined period of time. As shown, using the “time out” <b>165</b> variable, any of the tasks A-D <b>160</b>-<b>166</b> can be terminated if executions of any task takes longer than 3000 seconds <b>165</b><i>a</i>-<b>165</b><i>d</i>. Subsequently, in one embodiment, the terminated tasks or processing resources running the task may be restarted.

[0136] In a like manner, the embodiments of the present invention are capable of performing a corrective action if an exception occurs during execution of any of the tasks A-D <b>160</b>-<b>166</b>. In one example, using an “exception” <b>167</b> variable, an alternative course of action is provided to the test system while running a specific task. As shown in FIG. 9B, in one embodiment, the exception <b>167</b> is anticipated to occur during execution of task C <b>164</b>. Thus, when the exception occurs, the corrective action provided is executed and the task is terminated, as shown in <b>171</b>. Accordingly, the embodiments of the present invention are capable of incorporating any exception anticipated to occur during execution of a given task or task group. In this manner, corrective actions to be performed in response to a given exception is implemented in the code, eliminating the need to communicate to the software programmer.

[0137]FIG. 9C shows an exemplary configuration file <b>174</b>, in accordance with one embodiment. As shown, the testing process is performed using test systems having platforms included in the configuration file. For instance, configuration 1 uses test systems having Mac <b>10</b><b>168</b><i>a</i>, Linux <b>168</b><i>b</i>, Windows <b>168</b><i>c</i>, and Solaris <b>168</b><i>d </i>operating systems, successively. In a different configuration, a different configuration implementing different operating systems in any selected order can be implemented. In one embodiment, the same test may be implemented using different configurations, so as to replicate scenarios where each of the web registries, service providers, and clients implement different platforms and operating systems.

[0138]FIG. 9D shows an exemplary machine.props file <b>176</b>, in accordance with one embodiment of the present invention. As shown, the machine.props file <b>176</b> includes the name <b>114</b> and operating system <b>168</b> of each of the abstract machines M<b>1</b>-M<b>4</b><b>170</b><i>a</i>-<b>170</b><i>d</i>. As shown, abstract machine M<b>1</b><b>170</b><i>a </i>is assigned to the test system <b>114</b><i>c </i>having the Mac <b>10</b> operating system <b>168</b><i>a</i>. The abstract machine M<b>2</b><b>170</b><i>b </i>is assigned to the test system <b>114</b><i>b </i>having the Linux operating system <b>168</b><i>b</i>, abstract machine M<b>3</b><b>170</b><i>c </i>is assigned test system <b>114</b><i>e </i>having the Windows operating system <b>168</b><i>c</i>, and abstract machine M<b>4</b><b>170</b><i>d </i>is assigned to test system <b>114</b><i>d </i>having the Solaris operating system <b>168</b><i>d</i>. Thus, to execute task group <b>156</b><i>a</i>, using the configuration 1 file <b>174</b>, all the test systems <b>114</b><i>c</i>, <b>114</b><i>b</i>, <b>114</b><i>e</i>, and <b>114</b><i>d </i>should be available simultaneously for the tasks A-D <b>168</b>-<b>168</b><i>d </i>in the task group <b>156</b><i>a </i>to be executed.

[0139] An exemplary &lt;taskgroups&gt; file is shown in Table 1. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An Exemplary taskgroups File</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>&lt;?xml version=“1.0”?&gt;</entry></row><row><entry>&lt;!DOCTYPE taskgroups SYSTEM “taskgroups.dtd”&gt;</entry></row><row><entry>&lt;taskgroups&gt;</entry></row><row><entry>&lt;taskgroup id=“JAXMTests” configFile=“platforms.xml” &gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;task machine=“MACHINE1” id=“task1” &gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;command&gt; ant doall &lt;/command&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;timeout&gt; 3000&lt;/timeout&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;execDir&gt;jaxm-test/test&lt;/execDir&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/task&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;task machine=“MACHINE2” id=“task2” wait=“task1”&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;command&gt; ant stopcatalina &lt;/command&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;execDir&gt;dtr-test&lt;/execDir&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/task&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;task machine=“MACHINE2” id=“task3” &gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;command&gt; ant startcatalina &lt;/command&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;timeout&gt; 3000&lt;/timeout&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;execDir&gt;dtr-test&lt;/execDir&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/task&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;task machine=“MACHINE2” id=“task4” &gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;command&gt;java com.sun.ejte.harness.StatusChecker 127.0.0.1</entry></row><row>&lt;entry /&gt;<entry>8080 index.html 3000</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>&lt;/command&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;timeout&gt;3000&lt;/timeout&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;onException&gt;exit&lt;/onException&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/task&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;task machine=“MACHINE1” id=“task5” wait=“task3,task4”&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;command&gt; ant runtest &lt;/command&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;execDir&gt;jaxm-test/test&lt;/execDir&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/task&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;task machine=“MACHINE2” id=“task6” wait=“task5”&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;command&gt; ant stopcatalina &lt;/command&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;execDir&gt;dtr-test&lt;/execDir&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/task&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>&lt;/taskgroup&gt;</entry></row><row><entry>&lt;/taskgroups&gt;</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0140] As depicted, the &lt;taskgroups&gt; file includes the configuration file “platforms.xml” shown in Table 2. “Machine <b>1</b>” is shown to be assigned the task having the task1 id. Machine <b>1</b> is assigned to execute an “ant doall” command, which in accordance with the embodiments of the present invention can be any appropriate command (e.g., execute, inquiry, clean, setup, build, deploy, etc.)

[0141] The “task id” values are implemented to control the task synchronization in the task groups. For instance, “task2” is configured to be executed after execution of task1 has completed. This is shown by assigning the value of “task1” to “wait” variable. The embodiments of the present invention are further capable of synchronizing more complex task-flow schedules (e.g., when execution of one task depends on completion of execution of more than one task). By way of example, “task5” is configured to be executed after execution of both “task3” and “task4” have completed. Thus, in one example, both tasks are assigned to variable wait, with the “task3” and “task4” being separated by a comma.

[0142] The taskgroups file further addresses the corrective action that can be taken when an exception occurs. Additionally, it is required that the predetermined period, which in this embodiment is about 3000 seconds, be implemented to interrupt execution of a task from which no response has been received.

[0143] Table 2 shows another exemplary taskgroups file. As illustrated, the exemplary taskgroups, configuration, and machine files are implemented using the extensible markup (XML) language. However, in a different embodiment, any suitable language maybe used to implement any of the files implemented (e.g., text files, property files,etc.). <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 2</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Taskgroups File</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>&lt;!ELEMENT taskgroups (taskgroup+) &gt;</entry></row><row><entry>&lt;!ELEMENT taskgroup (task+) &gt;</entry></row><row><entry>&lt;!ATTLIST taskgroup id CDATA #REQUIRED &gt;</entry></row><row><entry>&lt;!ATTLIST taskgroup configFile CDATA #REQUIRED &gt;</entry></row><row><entry>&lt;!ELEMENT task (command, timeout? ,execDir? ,onException?) &gt;</entry></row><row><entry>&lt;!ATTLIST task</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>machine ( MACHINE1|MACHINE2|MACHINE3|MACHINE4|</entry></row><row>&lt;entry /&gt;<entry>MACHINE5 )</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>“MACHINE 1”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>id CDATA #REQUIRED</entry></row><row>&lt;entry /&gt;<entry>wait CDATA #OPTIONAL &gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;!ELEMENT command (#PCDATA) &gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;!-- timeout is mentioned in seconds --&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;!ELEMENT timeout (#PCDATA) &gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;!ELEMENT execDir (#PCDATA) &gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;!ELEMENT onException (#PCDATA) &gt;</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0144] As illustrated in Table 3, the task groups in the taskgroups file <b>158</b> are to be tested using two different configurations. As shown, in configuration 1, machine <b>1</b> is required to have a Linux operating system while Machine <b>2</b> is required to have a Solaris 5.8 operating system. In configuration 2, however, machine <b>1</b> is required to have a Windows operating system while Machine <b>2</b> is required to have a Linux operating system. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 3</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Exemplary Configuration File</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;?xml version=“1.0”?&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;!DOCTYPE platforms SYSTEM “platforms.dtd”&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;platforms&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;configuration id=“1”&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;os&gt;Linux&lt;/os&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;os&gt;Solaris 5.8&lt;/os&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/configuration&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;configuration id=“2”&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;os&gt;Windows 2000&lt;/os&gt;</entry></row><row>&lt;entry /&gt;<entry>&lt;os&gt;Linux&lt;/os&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/configuration&gt;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>&lt;/platforms&gt;</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0145] Table 4 includes the machine.props file, which in this embodiment, shows that name of Machine <b>1</b> is Steffie and that has a Linux operating system. As shown, Machine <b>2</b> is called skyblue and has a SunOS operating system. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 4</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Exemplary Machine.props File</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>MACHINE1.name=steffi</entry></row><row>&lt;entry /&gt;<entry>MACHINE1=129.145.132.73</entry></row><row>&lt;entry /&gt;<entry>MACHINE1.os=Linux</entry></row><row>&lt;entry /&gt;<entry>MACHINE2.name=skyblue</entry></row><row>&lt;entry /&gt;<entry>MACHINE2=129.145.132.59</entry></row><row>&lt;entry /&gt;<entry>MACHINE2.os=SunOS</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0146] Reference is made to FIGS. <b>10</b>A-<b>10</b>C depicting simplified snap shots of available and busy processing resources at any given time, according to one embodiment of the present invention. As shown in FIG. 10A, the test systems <b>114</b> are shown to be divided into two categories of test systems, available test systems <b>114</b>′ and their respective operating systems, and busy test systems <b>114</b>″ and their respective operating systems. As discussed with respect to the embodiments of FIGS. <b>9</b>A-<b>9</b>D, all the test systems <b>114</b><i>c</i>, <b>114</b><i>b</i>, <b>114</b><i>e</i>, and <b>114</b><i>d </i>should be available simultaneously for the tasks A-C in the first task group <b>156</b><i>a </i>to be executed. However, as shown in the snapshot of FIG. 10A, while test system <b>114</b><i>c </i>and <b>114</b><i>e </i>are available, test systems <b>114</b><i>b </i>and <b>114</b><i>d </i>are currently being used to execute a different task. Thus, at this point, execution of tasks A-C in the task group <b>156</b><i>a </i>is halted until all the required test systems are available. As shown, none of the available test systems <b>114</b><i>h</i>-<i>k </i>has a Linux or Solaris operating system. As a result, a different test system cannot be substituted for any of the test systems <b>114</b><i>b </i>and <b>114</b><i>d</i>. As shown, test systems <b>114</b><i>f</i>, <b>114</b><i>l</i>, <b>114</b><i>m</i>, and <b>114</b><i>n </i>are busy.

[0147] Proceeding to the snapshot in FIG. 10B, test system <b>114</b><i>b </i>is shown to be free, however, test system <b>114</b><i>d </i>is till in use. As can be seen, none of the available test systems <b>114</b><i>h</i>, <b>114</b><i>m</i>, and <b>114</b><i>k </i>is shown to have a Solaris operating system. As shown, test systems <b>114</b><i>i </i>and <b>114</b><i>j </i>which were previously available for use, are no longer available. At this point, test systems <b>114</b><i>h</i>, <b>114</b><i>m</i>, and <b>114</b><i>k </i>are available, while test systems <b>114</b>L, <b>114</b><i>n</i>, <b>114</b><i>i</i>, and <b>114</b><i>j </i>are busy.

[0148] Continuing to snapshot in FIG. 10C, all four test systems <b>114</b><i>b</i>-<i>e </i>are shown to be available. As such, tasks A-D of the first task group <b>156</b><i>a </i>can now be assigned to test systems <b>114</b><i>b</i>-<b>114</b><i>e</i>, as test systems <b>114</b><i>b</i>-<b>114</b><i>e </i>have the required operating systems and are all simultaneously available. Thus, in accordance to one embodiment of the present invention, execution of a task group is initiated when all test systems necessary to execute each of the tasks in the particular task group are all available at the same time.

[0149] In accordance with one embodiment of the present invention, the DTR of the present invention implements three queues to manage and monitor the tasks to be executed. A “ToBeServiced” queue stores all tasks to be performed. An “InService” queue is implemented to store tasks currently being executed, while a “Serviced” queue is implemented to store the tasks which execution has concluded.

[0150]FIG. 11 depicts a flowchart <b>1100</b> depicting method operations performed by a distributed process runner (DPR) system, in accordance with one embodiment of the present invention. The method begins in operation <b>1102</b> in which an ad-hoc group of available processing resources are designated to execute a plurality of tasks files. Each task file may include a plurality of task groups, with each task group containing a plurality of tasks to be scheduled in accordance with a task-flow-based schedule. By way of example, this is achieved by starting up the look up service and running machine services on each of the processing resources. Then, the system controller is started on a server and all data (e.g., attributes and proxies) of each processing resource is obtained by the system controller. The server controller is launched on one of the processing resources and the client controller is launched on each of the remaining processing resources. In one example, the server controller reads all the machine related information and writes same to a machine.props file. In one example, the machine.props file includes each of the Internet protocol (IP) addresses for each of the abstract machines.

[0151] The method then proceeds to operation <b>1104</b> in which a task file is scheduled for execution with a plurality of processing resources of the ad-hoc group of available processing resources. In operation <b>1106</b>, access is obtained to the plurality of processing resources to execute a task group in the task file. Each of the processing resources has a software/hardware configuration required to execute a task in the task group. In one example, a “task.xml” file containing each technology to be provided. By way of example, the task.xml file may include the command to be executed, abstract machine name to be used to execute the task and Wait, Timeout, and OnException variables. In one example, a “TaskGenerator” utility program is implemented to read the task.xml file so as to create a list of tasks to be performed.

[0152] Proceeding to operation <b>1108</b>, when access to all the processing resources is granted, tasks in the task group are executed in accordance with the task-flow-based schedule identified in the task group. In one example, the server controller reads the task.xml file and based on the abstract machine names provided in the task.xml file, the server controller invokes a RequestHandler utility program to dispatch the command to the client controller on the specific processing machine. In one example, the client controller reads and executes the dispatched command and reports the status of execution to the RequestHandler. At this point, the server controller gets the status from the RequestHandler and schedules the next task, accordingly. Then, in operation <b>1110</b> a task execution result report is generated.

[0153] In one exemplary embodiment, the DTR system of the present invention is set up as provided in Table 5. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 5</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Exemplary Execution Procedure</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Setup</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Edit unixDTR.ksh/winDTR.ksh under DTR/cos-ws</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="56PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>DTR-TASK-HOME</entry></row><row>&lt;entry /&gt;<entry>DTR-TASK-WIN</entry></row><row>&lt;entry /&gt;<entry>RESULT-DIR-PATH</entry></row><row>&lt;entry /&gt;<entry>JAVA-HOME</entry></row><row>&lt;entry /&gt;<entry>CATALINA-HOME</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Edit information about the machines in testbed/dtr-test,</entry></row><row>&lt;entry /&gt;<entry>then do “shsetup.sh”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Provide Task Information</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Put task files under taskdir</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Providing platform (configuration) information</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Put platform.xml under config directory</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Provide task information of DTR to DTF</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;<entry>Put wsharness_list.xml to in-queue directory</entry></row><row>&lt;entry /&gt;<entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0154]FIG. 12 depicts a flowchart <b>1200</b> depicting method operations performed by a distributed process runner (DPR) system, in accordance with another embodiment of the present invention. The method begins in operation <b>1202</b> in which a look up service is established proceeding to operation <b>1204</b> in which a dynamic group of available processing resources is set up. Next, in operation <b>1206</b> a system controller is launched followed by operation <b>1208</b> in which the system controller of the distributed processing system communicating with the look up service to obtain data about each processing resource in the dynamic group of available processing resources. Continuing to operation <b>1210</b>, the system controller launches a server controller on a processing resource that has hardware/software requirements matching those of the server controller. Next, in operation <b>1212</b>, the server controller launches a client controller on each remaining processing resource.

[0155] Available data about each processing resource is then obtained in operation <b>1214</b> followed by the server controller coordinating communication with each processing resource. In one example, the server controller implements a separate thread to communicate with each client controller. Then, in operation <b>1218</b>, a task group in a task file is scheduled for execution. In operation <b>1220</b>, the ad-hoc group of available processing resources is searched for processing resources having hardware/software required to execute each task in the task group.

[0156] Continuing to operation <b>1222</b>, it is determined whether the processing resources required to execute all tasks in the task group are available. If all the processing resources are not available, the method proceeds to operation <b>1224</b> in which the method waits until all the processing resources are available.

[0157] Otherwise, the method continues to operation <b>1226</b> in which tasks in the task group are executed using the task-flow-based schedule identified in the task group. Then, the method continues to operation <b>1228</b> in which a determination is made as to whether there exists another task group to be scheduled. If another task group to be scheduled exists, the method continues to operation <b>1220</b>, otherwise, the method continues to operation <b>1230</b> in which a determination is made as to whether there exists another task file to be executed. If another task file to be executed exists, the method continues to operation <b>1218</b>.

[0158] In accordance with one implementation, the embodiments of the present invention can be used to test web services and the interactions with each combination of web service provider, web registry, and web clients, each having different software/hardware configurations. In fact, embodiments of the present invention can test interactions between multiple service providers registered with multiple web registries for use by multiple clients, each implementing different technologies.

[0159] By way of example, the processing resources used to test each interaction or web service belong to a dynamic group of undedicated processing resources having different requirements (i.e., hardware/software configurations). As such, matching the processing resources having a similar configuration as the service provider, registry, or client is rather easy. For instance, interactions between service providers implemented using different technologies, (e.g., J2EE based, .net compatible server, etc.), with different web registries (e.g., universal descriptive and discovery Interface (UDDI), electronic business XML (EDXML), etc.) using different types of web registry documents (e.g., web service description language (WSDL), simple object access protocol (SOAP), etc.), and web clients based on different types of technologies (e.g., JSPS servlet, J2EE container based client, Java™ application based client, etc.) can always be tested using processing resources having matching hardware/software configurations.

[0160] Additionally, the embodiments of the present invention can easily be implemented to test synchronization of interactions between the web registries, service providers, and clients. For instance, using the wait variable, the service provider can be ensured that the web registry is up and running prior to publishing of the service provider's services on the web registry. Using the wait variable, in a like manner, the client can easily ensure that the web registry is up and running prior to communicating a request for a web service. Similarly, the client can further be sure that the service provider is running prior to the client communicating a request to the service provider.

[0161] Additionally, the embodiments of the present invention are able to test the interactions between the components automatically, minimizing the human intervention. By way of example, using the embodiments of the present invention, the interactions are tested when all the necessary number of processing resources are simultaneously available and are task-flow-based, significantly limiting human intervention. In a like manner, the embodiment of the present invention can perform corrective actions in case an exception or a time out occurs.

[0162] The advantages of the present invention are numerous. Most notably, the present invention substantially limits human intervention in distributed testing of web services and enterprise applications using ad-hoc network of computer resources. Another advantage is that the embodiments of the present invention can be implemented to test web services offered by multiple web service providers registered with multiple registries for use by multiple clients. Each of the web service providers, registries, and clients can be implemented on different technologies and operating systems. Yet another advantage is that the embodiments of the present invention are capable of coordinating interaction between each combination of web service provider, web registry, and web client. Still another advantage is that the embodiments of the present invention can synchronize sequence of tasks pursuing a task-flow-based scheduling. Still another advantage of the present invention is that a plurality of tasks can be executed simultaneously or in parallel, implementing the ad-hoc dynamic processing resources.

[0163] Still another advantage is that attaching and detaching of a computer resource has substantially minimum or no effect on the process execution. Furthermore, the embodiments of the present invention implement computer resources, which are not limited to be used by the DPR or DPF systems. As such, the embodiments of the present invention substantially eliminate the waste of resources associated with the prior art. Another advantage of the embodiments of the present invention is that the DTR system of the present invention is highly scalable, requiring minimum/none administration. Still another benefit of the present invention is that the ad-hoc network of distributed computer resources in conjunction with the server component creates a self-healing network. Yet another benefit of the present invention is that the network of computer resources can in fact span over a large geographical area.

[0164] With the above embodiments in mind, although the present invention mainly describes exemplary embodiments of a distributed test framework system designed to execute a test suite or a distributed test runner to test a task file, it must be understood by one having ordinary skill in the art that the distributed processing framework and distributed process runner of the present invention can be implemented to run any computer process. Additionally, the embodiments of the present invention can be implemented to test J2EE application server or any other J2EE application. Furthermore, the embodiments of the present invention may be configured to implement J2EE technology (e.g., EJBs, etc.). Moreover, although the present invention is described based on the Jini technology, other network technologies having the capability to create an ad-hoc group of computer resources may be implemented (e.g., RMI, TCP/IP Sockets, etc.). Furthermore, although the present invention implements Java programming language, other programming languages may be used to implement the embodiments of the present invention (e.g., C, C₊₊, any object oriented programming language, etc.).

[0165] It should be understood that the invention may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. Furthermore, the invention may employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.

[0166] Any of the operations described herein that form part of the invention are useful machine operations. The invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, or it may be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

[0167] The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which thereafter be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

[0168] Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.