Registry service for use in a distributed processing framework system and methods for implementing the same6961937Abstract A method for advertising an availability of a processing resource to execute a process is provided. The method includes enabling a registry service and the processing resource to register with the registry service. The processing resource is configured to be one of numbers of network interconnected resources. Also included in the method is enabling a system controller code to find and select a suitable and available processing resource registered with the registry service to execute the process. The system controller code is configured to be executed on a computer that is networked with the number of interconnected resources. The method further includes enabling the system controller code to communicate with a selected processing resource and updating a status of the processing resource in the registry service upon a termination of executing the process. Claims 1. A method for advertising an availability of a processing resource to execute a process, the method comprising: Description BACKGROUND OF THE INVENTION
The second logical component, the test scheduler and system controller, includes the system controller 108 configured to perform the function of managing the job queues and dispatching the test execution requests to test system 114 for processing. Thus, the system controller 108 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. As designed, the test scheduler and system controller component is configured to include four modules:
In accordance with one implementation, the requirements for a DTF system are provided below in Table 1.
Reference is made to a block diagram depicted in FIG. 2 wherein the capability of the DTF system to intelligently locate a test system 114 available to execute a test suite is illustrated, in accordance with one embodiment of the present invention. As shown, an inqueue directory 116 contains a plurality of test execution requests 116a, 116b, and 116c. In accordance with one embodiment of the present invention, once the system controller 108 is initiated, the system controller 108 is designed to read each test execution request 116a-116c contained within the inqueue directory 116. As shown, each test suite request 116a-116c must be executed by a test system 114 capable of running the test execution request requirements. For instance, each of the test execution requests 116a, 116b, and 116c must be run on a Solaris IA™ test system, a Wintel™ test system, or a Linux™ test system, respectively. As will be described in more detail below, the DTF system 100 has the capability to advantageously locate an available test system from a plurality of ad-hoc network of test systems 114a, 114b, 114c, and 114d to execute each of the test execution requests 116a-116c. As shown, in the embodiment depicted in FIG. 2, each of the test systems 114a-114d has a different software and hardware configuration. For instance, while the test system 114a is run on Wintel™ and the test system 114b is run on Linux™, the test systems 114c and 114d are programmed to run on Solaris IA™ and Solaris™, respectively. As will be discussed in more detail below, the machine service for each test system 114a-114c registers the respective test system 114a-114c 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 114a-114d with the Jini look up service 104. In this manner, the system controller 108 can search the Jini look up service 104 implementing the test execution request requirements as search criteria. Thus, as shown in the example of FIG. 2, the system controller 108 of the DTF system selects the test systems 114c, 114a, and 114b to execute the test suite requests 116a-116c, respectively. 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 114b and 114a, the system controller 108, and the Jini look up service 104 communicate to each other using Jini. In one example, the system controller 108, the Jini look up service 104, and the test systems 114a and 114b and all the other resources that are Jini capable form a virtual Jini community 118. As shown, the test system 114a runs an agent process 120a responsible for notifying the Jini look up service 104 of the existence and configuration of the test system 114a. In one example, the agent 120a is also designed to export a downloadable image of itself. Beneficially, the downloadable image allows the system controller 108 to ask the test system 114a to initiate running a test execution request and meanwhile interact with the test system 114a as the test execution request is being processed. The illustrated agent 120a involves two Jini services, machine service 114a-MS and test service 114a-TS. The function of the machine service 114a-MS is to advertise the availability of the test system 114a, the characteristics of the test system 114a, and the ability of the test system 114a to launch a test execution request. Additionally, the machine service 114a-MS is designed to be present on the test machine 114a at all times. As such, the machine service 114a-MS is initiated on the test system 114a at the start-up time and is configured to remain active on the test system 114a until the test system 114a is shut down. Comparatively, the test service 114a-TS is a module configured to encapsulate the test execution request. As designed, the test service 114a-TS is spawned by the machine service 114a-MS and is subsequently launched when the machine service 114a-MS receives a request to start running a test execution request from the system controller 108. Specifically, the new test service 114a-TS is spawned based on the test execution request type. By way of example, in one embodiment, the machine service 114a-MS spawns separate test systems 114a-TS when running Tonga-type, JCK-type, JTREG-type, and shell-type test suites. However, one having ordinary skill in the art must appreciate that in a different example, the machine services of the DTF system of are configured to spawn other suitable test systems. As shown, similar to test system 114a, the test system 114b is configured to include an agent 120b designed to include a machine system 114b-MS and a test system 114b-TS. As will be discussed in more detail below and as shown in the implementation of FIG. 3, the machine service 114a-MS and test service 114a-TS respectively register Jini attributes 104a-MS.A and 104a-TS.A of the test system 114a with the Jini look up service 104. For instance, in one embodiment, the sequence of events in registering the machine service 114a-MS and test service 114a-TS may be as follows: Once the test-system 114a discovers and joins the Jini community 118, the test service 114a-MS of the test system 114a registers with the Jini look up service 104. In this manner, the machine service 114a-MS registers a machine service proxy 104a-MS.P and the attributes 104a-MS.A of the machine service 114a-MS with the look up service 104. The Jini attributes 104a-MS.A are used by the system controller 108 to locate a test service having attributes suitable to run the test execution request. Once the test system 114a has been selected to run the test execution request, the machine service 114a-MS spawns a test service 114a-TS having the same type as the test execution request. As discussed above, the machine service 114a-MS is configured to spawn a matching test service 114a-TS for each test execution request type. For example, the test system 114a may have the attributes to run a Tonga test execution request and a JTREG type test execution request. Thus, in such a situation, the Jini look up service 104 will include two test services each running a different type of test execution request. In this manner, when the processing of the test execution request has concluded, the test service 114a-TS having substantially the same type can be terminated. Thus, for the most part, the test service 104a-TS , 104a-TS.A, and 104-TS.P are designed to substantially exist while the test system 114a is running a test execution request. In this manner, the system controller 108 can determine whether the test system 114a is processing a test execution request. Specifically, this is achieved by the system controller 108 simply querying the Jini look up service 104 as to whether the test system 114a has an associated existing test service. In addition to registering the attributes 104a-MS.A and 104a-TS.A, the machine service 114a-MS and the test system 114a-TS are configured to respectively register a corresponding machine service proxy 104-MS.P and a respective test service proxy 104-TS.P with the Jini look up service 104. As designed, the system controller 108 implements the machine service proxy 104-MS.P and the test service proxy 104-TS.P to communicate with the test system 114a. Particularly, once the system controller 108 has selected the test system 114a to run the test execution request, the system controller 108 downloads the machine service proxy 104-MS.P from the Jini look up service 104. Once the machine service proxy 104-MS.P is downloaded, the system controller 108 starts communicating with the machine service proxy 104-MS.P rather than communicating directly with the corresponding test system 114a or the machine service 114a-MS. In a like manner, the test service proxy 104-TS.P is the communication channel between the system controller 108 and the test service 114a-TS. Thus, similar to the machine service 114a-MS, the system controller 108 downloads the test service proxy 104-TS.P from the Jini look up service 104. Thereafter, the system controller communicates with the test service proxy 104-TS.P as if it were communicating with the test system 114a or the test service 114a-TS. As shown, in the same manner, the machine service 114b-MS and test service 114b-TS register their respective machine service proxy 104b-MS.P and machine service attributes 104b-MS.A as well as the respective test service proxy 104b-TS.P and test service attributes 104b-TS.A with the Jini look up service 104. The capability 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 114a-114n respectively being a PC 100, Macintosh, PC 99, Macintosh, PC 100, and Macintosh are registered with the Jini look up service 104. That is, for each test system 114a-114n, the Jini look up service 104 contains an associated machine service 104a-MS to 104n-MS. In a like manner, for each machine service 104a-MS to 104n-MS, the Jini look up service 104 includes a corresponding machine service proxy 104a-MS.P to 104n-MS.P and the associated machine service attributes 104a-MS.A to 104n-MS.A. Although for each test system 114a-114n a machine service entry can be found in the Jini look up service 104, only test systems 114a, 114b and 114e have associated test services 104a-TS , 104b-TS, and 104e-TS. Further more, as shown, for each of the test systems 114a, 114b and 114e, the Jini look up service 104 includes the corresponding test system proxy 104a-TS.P, 104b-TS.P, and 104c-TS.P and the respective test system attributes 104a-TS.A, 104b-TS.A, and 104c-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 114a, 114b, and 114e, respectively. For instance, at this point, when the system controller 108 receives a test execution request requiring to be processed by a PC 100, the system controller 108 searches for an available PC 100 test system. While searching the Jini look up service 104, the system controller 108 will first locate the machine service 104a-MS. Despite machine service 104a-MS having the required attribute (i.e., being a PC 100), the system controller 108 will have to by pass this entry, as the test system 114a is busy. The system controller 108 detects the unavailability of test system 114a by the Jini look up service 104 including the test service 104a-TS associated with the test system 114a. Subsequently, in search of the next available PC 100 test system, the system controller locates machine service 104c-MS. However, this time, the Jini look up service does not including a test system associated with the test system 114c, thus revealing the test system 114c availability to execute the test execution request. As will be discussed in more detail below, in one implementation, the lack of a corresponding test service in the Jini look up service 104 occurs once the test execution request has concluded and the test service 104a-TS lease with the Jini look up service 104 has expired. Thus, once the test service 104a-TS and its associated proxy 104a-TS.P and attributes 104a-TS.A have been removed from the Jini look up service 104, the test system 114a 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 114a-TS is spawned by the machine service 114a-MS, again indicating the busy status of the test system 114a. Reference is now made to FIG. 5 depicting the one-to-one communication between the system controller 108, Jini look up service 104, and test system 114 of the DTF system, in accordance with one embodiment of the present invention. As shown, enabled by the Jini technology, a machine service 114-MS component of the test system 114 discovers the Jini look up service 104. Thereafter, the machine service 114-MS joins the Jini look up service 104 by registering a plurality of Jini attributes 104-MS.A and a machine system proxy 104-MS.P with the Jini look up service 104. Seeking a test system to execute a given test execution request, the system controller 108 discovers the Jini look up service 104. Subsequently, the system controller 108 searches the Jini look up service 104 for a test system suitable to run the test execution request. Once the system controller 108 has determined that the test system 114 has machine service attributes 104-MS.A matching to that required to run the test execution request, the system controller 108 downloads the machine service proxy 104-MS.P from the Jini look up service 104. From then on, the system controller 108 starts communicating with the machine service proxy 104-MS.P as if communicating with the machine service 114-MS. At this point, the system controller 108 communicates with the machine service proxy 104-MS.P requesting the execution of the test execution request. Subsequent to receiving this request, the machine service 114-MS spawns a test service 114-TS which type matches that required by the test execution request. Next, a test service proxy 104-TS.P and test service attributes 104-TS.A of the test service 114-TS are then registered with the Jini look up service 104. Thereafter, the system controller 108 downloads the test service proxy 104-TS.P and communicates with the test system proxy 104-TS.P as if communicating with the test system 114-TS. Then, the test service 114-TS receives the test execution command from the system controller 108, thus initiating the test execution request. As was discussed in more detail above, once the test execution has concluded, the test service 114-TS lease with the Jini look up service 104 expires, thus triggering the removal of the test system proxy 104-TS.P and test system attributes 104-TS.A from the Jini look up service 104. In this manner, the system controller 108 associates the availability of the test system 114 to run the next test execution request with the test system 114 lacking of a registered test service proxy 104-TS.P. Proceeding to the block diagram of FIG. 6, the interaction between the Jini look up service 104, system controller 108, and test system 114 can further be understood, in accordance with one implementation of the present invention. As discussed in more detail above, the test system 114 includes a machine service 114-MS and a test service 114-TS. As designed, the machine service 114-MS includes a lease manager 124, a launch manager 122, and an attribute manager 120 while the test system 114-TS includes a call back 126, a report manager 128, and a lease manager 130. In one example, the interaction between the DTF system components starts by the test system 114 discovering the Jini look up service 104. Subsequent to this discovery, the machine service 114-MS communicates with the attribute manager 120, obtaining the test system 114 attributes. Thereafter, the machine service 114-MS joins the Jini look up service 104 by registering the machine service 114-MS proxy and machine service attributes with the Jini look up service 104. As part of registering the machine service 114-MS with the look up service 104, the lease manager 124 leases the machine service 114 for a specific period of time. That is, the lease manager 124 registers the availability of the test system 114 to execute a test execution request for a specific period of time. However, before the leased period is expired, the lease manager 124 can renew the lease with the Jini look up service 104. In this manner, once the test system 114 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 104 as soon as the lease is expired. At this point, the system controller 108 scans the inqueue directory, reading the required attributes for running the first test execution request in the in-queue (i.e., the wait queue). The system controller 108 then searches the Jini look up service 104, 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 108 determines that the test system 114 is a suitable test system to run the test execution request, the system controller 108 downloads the machine service proxy for the test system 114 from the Jini look up service 104. As soon as the machine service proxy is downloaded, the system controller 108 communicates with the machine service proxy as if communicating with the test system 114. At this point, the test execution is initiated by the system controller 108 dispatching a start execution request to the machine service 114-MS. Once the launch manager 122 component of the machine service 114-MS receives the system controller 108 request to start test execution, the launch manager 122 spawns the appropriate test service 114-TS. Specifically, the test service 114-TS type spawned by the launch manager 122 is determined by the test execution request requirements dispatched by the system controller 108. Irrespective of the test service 114-TS type, the lease manager 130 of the test system 114-TS is configured to register the test system attributes and a test system proxy with the Jini look up service 104. Again, like the machine service 114-MS, the test service 114-TS registers its availability to execute the test execution request with the Jini look up service 104 for a specified lease period. At this point, the system controller 108 downloads the test service proxy from the Jini look up service 104 and communicates with the test system proxy as if the system controller 108 is communicating with the test service 114-TS. Once the test service 114-TS starts executing the job, the test service 114-TS sends an event to the system controller 108 indicating the commencement of the test execution request processing. In one embodiment, the test service 114-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 126 is configured to communicate with the lease manager 130 signaling the conclusion of processing the test execution request. Once the lease manager 130 receives such communication, the lease manager 130 communicates with the Jini look up service 104 signaling the expiration of the test suite 114-TS lease with the Jini look up service 104. Upon the expiration of the test suite 114-TS lease with the Jini look up service 104, the test suite 114 proxy and test suite 114 attribute entries are removed from the Jini look up service 104, thus pointing out the availability of the test system 114 for processing another suitable job. The test result data generated by the processing of the test execution request are collected, categorized, and maintained by the report manager 128. In one embodiment, the report manager 128 analyzes and generates a test report implementing the test result data. Thus, in one embodiment, the test systems 114 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 114 may be utilized so as to create a test result summary report, covering the test results produced by each of the test systems 114. User interfaces implemented in test execution request submission, test execution request scheduling and execution, and managing the ad-hoc network of the distributed resources can further be understood with reference to a DTF utility graphical user interface (GUI) 200 illustrated in FIG. 7, in accordance with one embodiment of the present invention. As shown in the example of FIG. 7, the DTF utility GUI 200 may include a tool bar 201 containing a plurality of pull down menus such as "File" 202 and "Help" 204. As further illustrated, in one implementation, the DTF utility GUI 200 enables a user of the master computer system (i.e., the server) to monitor and obtain information regarding different components of the DTF system. For instance, in the embodiment of FIG. 6, the DTF utility GUI 200 is configured to provide information regarding the status of a scheduler 206, machines 208, and logs 210 components of the DTF system. However, in a different embodiment, the DTF utility GUI 200 may provide the user with the real-time status of any of the components of the DTF system. The scheduler 206 shown in the DTF utility GUTI 200 is configured to gather and maintain data in a temporary data holding place such as a queue. In one embodiment, the scheduler 206 keeps track of the status of the submitted test execution requests by maintaining an in-queue 212, an active queue 222, and a completed queue 240. The exemplary in-queue 212 includes a job name field 214 and a suite name field 216 for maintaining job name and the corresponding test suite name for each job entry 215a-215g. As shown, while job names for job entries 215a and 215b are substantially identical to the corresponding test suite name for job entries 215a and 215b, job names for the job entries 215c-215g are not identical to the test suite names for the job entries 215c-215d. For the most part, this occurs because for execution purposes, a test suite may be divided into test execution requests (i.e., jobs) expediting the processing of the test suite. In one embodiment, to reduce the extent of human interaction, the test execution requests are submitted to the DTF system through the system controller 108. Specifically, once the system controller 108 is initiated, the system controller 108 is configured to scan the XML files within the inqueue directory and then read the XML files including a "testrequest" tag. Then, these test execution requests and their test suites are used to initialize the in-queue 212. However, one of ordinary skill in the art must appreciate that in a different implementation, any appropriate mechanism may be used to place the test execution requests into the in-queue 212. As shown, the DTF utility GUI 200 provides the user of the master computer system (i.e., the server) the capability to initiate the processing of any of the job entries 215a-215g using a start job button 220. Similarly, the user of the master computer system is given the opportunity to delete any of the job entries 215a-215g and their associated suite names through implementing a remove job button 218. While in-queue 212 contains the test execution requests waiting to be executed by the suitable test system, the active queue 222 contains the test execution requests currently being executed. As illustrated, the active queue 222 implements a plurality of fields such as job name 224, suite name 226, host name 228, start 230, stop 232, elapsed 234, and status 236 to monitor the jobs during the execution. Thus, in the depicted example, a job entry 225 having a job name "java-net-client 4" and a suite name "java-net-client 4" started executing on 13:15:56 on June 21 and is configured to be executed until 16:00:00 on December 31. As shown, the status 236 for the job entry 225 indicates that the job entry 225 is in "execution" by the test system "ultracos." Similar to the in-queue 212, the active queue 222 provides a master computer user an opportunity to terminate the execution of the jobs by pressing a kill job button 238. In a like manner, the completed queue 240 contains a plurality of fields, job name 242, suite name 244, host name 246, start 248, stop 250, elapsed 252, and status 254 field configured to collect and maintain data concerning the status of completed jobs. As indicated in the status 254 field for both job entries, the execution of a job entry 256 and a job entry 258 has concluded. Also, as depicted, the elapsed time for each job entry 256 and 258 is shown to be about 9 seconds. Again, a restart selected task 260 button is configured to provide the user of the master computer service the opportunity to re-run the completed job. Thus, in one embodiment, by selecting a completed job, while pressing a restart selected task button 260, the completed job will be removed from the completed queue 240 and is placed in the inqueue 212. In this manner, the completed job can be run again. A DTF utility GUI 200′ depicting in FIG. 8 provides information regarding the status of machines 208 of the DTF system, in accordance with one embodiment of the present invention. Specifically, the DTF utility GUI 200′ is configured to provide a list of test machines creating the impromptu Jini community of test systems. The machines list 266 includes a plurality of fields such as host name 268, host address 270, operating system (OS) name 272, OS architecture 274, and OS version 276. For instance, in the embodiment illustrated in FIG. 7, the machine list 266 includes one machine entry 278 having a host name "ultracos," and a Java™ binary host address 129,144,176.88. Additionally, as shown, the machine entry 278 has a version 5.7 Sun™ Solaris operating system with a Sparc architecture. The illustrated DTF utility GUI 200′ also provides the master computer user an update list 280 button, giving the user the opportunity to update the status of the machines list 266, when needed or if necessary. Reference is now made to DTF utility GUI 200" illustrating the contents of the logs 210 component of the DTF system, in accordance with one embodiment of the present invention. As shown, the logs 210 component includes a list entitled a DTF log information 262. For instance, in the implementation depicted in FIG. 9, the logs 210 component is configured to maintain a list of certain actions performed by some of the DTF system components (e.g., scheduler, machine service lookup service, etc.). It must be noted that the DTF utility may be implemented on master computer systems (i.e., servers) having different platforms and environments. For instance, in one implementation, the DTF utility may be run in a Windows™ environment, and be launched by using the Programs submenu of Windows™ Start menu. Reference is now made to a flow chart diagram 300 of FIG. 10 illustrating a method operations implemented to execute a process by the distributed process framework system, in accordance with one embodiment of the present invention. The method begins in operation 302 in which a group of resources as part of a community available to execute software processing jobs is designated. In one embodiment, this task is achieved by the group of resources joining a look up service implementing a proxy and a set of attributes associated with each of the resources. By way of example, the group of resources may include a plurality of ad-hoc networked computer systems, which register with Jini look up service, indicating their availability to execute a software process job. In one implementation, computer systems are test systems configured to process a test execution request (e.g., a job). Each of the test systems registers with the Jini look up service using a machine service designed to have a proxy and a set of attributes. Proceeding to operation 304, the processing of a set of jobs is scheduled with the resources of the community. In one embodiment, each of the software processing jobs contained within the inqueue directory are scanned and depending on availability of a resource to execute the software processing job, is read either into a wait queue or an execution queue. Next, in operation 306, access to specific resources are negotiated for each of the scheduled jobs. That is, a system controller searches the look up service seeking an available resource having the attributes substantially similar to that required by the software processing job. Once such resource has been located, the system controller communicates with the resource by obtaining machine service proxy associated with the located resource. Next, in operation 308, each of the scheduled jobs is executed when a suitable resource becomes available. That is, after obtaining the proxy from the look up service, the system controller dispatches a software processing job execution request, initiating the processing of the software processing job. In one embodiment, when executing a test execution request, the machine service spawns a test service configured to include a proxy and a set of attributes. Once the test service is spawned, its proxy and the attributes are registered with the Jini look up service. At this point, the system controller obtains the proxy so as to initiate the test execution request. Next, in operation 310, a report identifying the results of the process execution is generated. Thus, beneficially, the distributed process framework system allows a software process be executed by a group of ad-hoc network of resources such that substantially minimum administration is required. In this manner, adding and deleting of resources have almost minimum effect on the execution of a software processing job. The method operations implemented in executing a test suite by the distributed test framework system is shown in a flow chart diagram 400 illustrated in FIG. 11, in accordance with one embodiment of the present invention. The method begins with operation 402 in which a system controller to distribute and manage a test suite submitted for execution is provided. As discussed in more detail above, the system controller maintains a suite directory wherein the description of each test suite is kept in an XML formatted file. Next, in operation 404 a look up service is established, which in one embodiment is a Jini look up service. In one example, the Jini look up service is a dedicated process, which runs on a particular computer system. For instance, the Jini look up service may be run on the system server, which includes the system controller. Subsequently, a community of resources is set up in operation 406. Each of the resources is configured to include an associated machine service designed to have a set of attributes and a proxy. For instance, in one embodiment, the resources are test systems having similar or dissimilar software and hardware configuration. The test systems software and/or hardware configuration are registerable attributes, which are used by the system controller to locate and select an available suitable test system. Proceeding to operation 408, each proxy and each set of attributes are registered with the look up service. In operation 410, the test suite is scheduled for execution. For instance, each of the test suites stored in the XML formatted in-queue directory are read by the system controller and placed in an inqueue queue. Next, in operation 412, the look up service is searched for a test system having attributes matching the set of attributes associated with the test suite to be executed. Continuing to operation 414, a machine service is selected to execute the test suite using the test suite attributes as criteria. Thereafter, in operation 416, the proxy associated with the selected test system is obtained. In one embodiment, this task is achieved by the system controller downloading the selected test system proxy. Moving to operation 418, the proxy is used to communicate with the test system. For instance, the system controller communicates with the selected test system proxy as if communicating with the test system. In one implementation, the system controller dispatches a test execution request to the proxy, initiating the test suite execution. The test suite is next executed implementing the test service type spawned by the machine service. In one example, the machine service spawns the test service configured to have a test service proxy and the set of attributes. Once spawned, the test service proxy and the set of attributes are registered with the Jini look up service, indicating the unavailability of the test machine to execute a test suite requiring similar configuration. Continuing to operation 422, a determination is made as to whether there are any more test suites to be executed. If a determination is made that more test suites exist to be executed, the method continues to operation 412 in which the look up service is searched for a test system having attributes matching to that required by the test suite being executed. However, if it is determined that all the test suits have been executed, the method moves to operation 422, in which a test suite execution summary report is generated. II. Registry Service for Use in a Distributed Process Framework System With the description of the DPF system in mind, reference is now made to a flow chart diagram 500 of FIG. 12 depicting a method operations implemented by a registry service of the present invention to provide spontaneous assembly of the processing resources as well as the spontaneous interaction of the processing resources and the system controller of a DPF system, in accordance with one embodiment of the present invention. As shown, the method begins in operation 502 in which the registry service, which in one embodiment is the Jini look up service, is enabled. In one implementation, this operation is performed by turning on a system running the look up service. Next, in operation 504, the processing resource is enabled so as to join the look up service. By way of example, this occurs by turning on the processing resource and registering the machine service and the set of machine service attributes of the processing resource with the look up service. Moving to operation 506, the system controller is enabled to find and select a suitable and available processing resource that has registered with the look up service to execute a job. In one instance, the system controller communicates with the look up service in search of an available and suitable processing resource. Specifically, the system controller searches the look up service for a processing resource having a set of attributes configured to substantially match the requirements of the job being processed. Thereafter, in operation 508, the system controller is enabled to communicate with the selected processing resource. By way of example, once the system controller finds a machine service having a set of attributes substantially matching the job requirements, the system controller downloads the machine service proxy from the look up service. Thereafter, the system controller uses the machine service proxy to start communicating with the machine service of the selected processing resource as if communicating with the machine service. At this point, the machine service spawns a process service having a type substantially the same as the type of the job being executed. Once spawned, the process service proxy and process service attributes are registered with the look up service revealing the unavailability of the processing resource to execute a job having substantially similar requirements. Next, in operation 510, the status of the selected processing resource is updated upon the termination of the job execution. That is, upon the termination of job execution, the process service proxy and the process service attributes are removed from the look up service revealing the availability of the processing resource to execute a job having substantially similar requirements. Proceeding to operation 512, a determination is made as to whether the look up service has been terminated. For instance, it is determined whether the system running the look up service is still running. If the look up service has been terminated, the method concludes. However, if the look up service has not been terminated, the method continues to operation 514 in which a determination is made as to whether the processing resource registration with the look up service has been renewed. If it is determined that the processing resource registration has been renewed, the method continues to operation 504. In the alternative, the method ends. Implementing a look up service to enable the spontaneous assembly of test systems as well as spontaneous interaction between a plurality of test systems and the system controller can further be understood with respect to a flow chart diagram 600 of a method operations depicted in FIG. 13, in accordance with one embodiment of the present invention. As shown, the method begins in operation 602 in which the look up service is launched on a system. In one example, this is achieved by setting up the look up service on a computer system. For instance, where the look up service is run in a Solaris environment, the exemplary script in table 2 can be used to startup look up service.
As shown, the machine name corresponds to the name of the computer system running the look up service. In a different embodiment, on a Solaris computer system, the look up service may be started as shown in Table 3. As shown, once a Solaris computer system has been located, a root directory/home/user/knight of the DTF is called (Knight being an exemplary name given to the DTF system). At that point, the runLookupServer.ksh is called.
Thus, for instance, the look up service start up code can be:
Continuing to operation 604, a determination is made as to whether there are any test systems requesting to register with the look up service. Until it is determined that there is a test system requesting registration with the look up service, the method returns to operation 604. Once it is determined that a test system is requesting registration, the method continues to operation 606 in which the look up service obtains the machine service proxy and the set of machine service attributes for the test system requesting registration. Subsequently, the method returns to operation 604 in which it is determined whether there are any other test systems requesting registration with the look up service. In one embodiment, an AttributeManager is implemented to register the machine service attributes with the look up service. As designed, in one example, an AttributeManager includes an Attribute Package having a plurality of attribute entry classes. In one implementation, the Attribute Package includes approximately about 30 attribute entry classes. However, in a different implementation, the Attribute Package may include any appropriate number of attribute entry classes. A plurality of attribute entry classes are provided below in Table 4.
In one exemplary embodiment, the AttributeManager of the machine service is almost the only object used to provide an interface between the machine service and the look up service. However, in a different implementation, any suitable mechanism may be used to provide communication between the machine service and the look up service. Subsequent to instanciating the AttributeManager, in one instance, the machine service attributes which values are obtainable during the run time are attained. Then, using a an exemplary dialog box, attributes may be entered or modified manually. As designed, in one embodiment, the machine service AttributeManager includes a machine service interface, an example of which is provided in Table 5.
An Entry Array resulting from running the machine service interface can be implemented by the machine service to register the registerable attributes (both, manual and automatic) of the test system with the look up service so as to promote the availability of the machine service to execute a process. As shown in Table 6, in one instance, a Joinmanager class is implemented to register the machine service with the Jini look up service.
In one example, a second interface exports nearly all the manual and automatic attributes of the test system. For instance, an AgentService component of the test system provides a remote method to deliver the resulting array to a TestController component of the system controller. Another exemplary interface between the AttributeManager and the machine service is provide below in Table 7.
With a continued reference to FIG. 13, running in parallel to operation 604, in operation 608 in which the look up service receives a request from the system controller to process a test suite having a set of requirements and a test suite type. Next, in operation 610, the system controller searches the look up service for a test system having a set of machine service attributes matching the set of test suite requirements. For instance, in accordance to one embodiment, a TestController component of the system controller matches an array of attribute template with the entries in the Jini look up service. In another implementation, a ServiceTemplate class is utilized to locate a machine service having substantially similar attributes. As an example, the methods provided in Table 8 can be implemented to search for a test system having Windows 98 and Javatest.
In a different embodiment, the test system having Windows 98 and Javatest may be found implementing the method shown in Table 9.
Thereafter, in operation 614, the look up service obtains the test service proxy and the set of test service attributes for the selected test system. Specifically, this occurs after the machine service spawns the test service having the test service proxy and the set of test service attributes. In accordance with one example, a type of the test service is configured to match the type of the test execution request. As shown below in Table 10, the embodiments of the DTF system have been configured to include about four types of test service.
However, it must be appreciated that in a different embodiment, other test service types can be included. For instance, the AttributeManager class includes a method "misc.testservice.type" entry configured to support new types of test systems as the machine service is required to create a matching test system type. In one example, the test service registers with the Jini look up service utilizing an array of entries resulting from the running of the method shown in Table 11.
In accordance with one implementation, the test service includes the following classes: TestTypeService, TestTypeServiceWithLeases, TestTypeServiceBackend, TongaServiceProxy, ShellServiceProxy, JtRegServiceProxy, and JCKServiceProxy. The generic code for each of the different test types have been defined separately in TestTypeService, TestTypeServiceWithLeases, and TestTypeServiceBackend classes. Additionally, the code for each test type is configured to include a separate corresponding proxy. For instance, the DPF system is configured to include a TongaServiceProxy for Tonga test type and a ShellServiceProxy for a Shell test type. In addition to the above-mentioned classes, the test service further includes a BackendProtocol interface and a TestTypeServicelnterface interface. With continued reference to FIG. 13, in operation 616, the system controller is provided with the test service proxy and the set of attributes of the test service for the selected test system. Then, upon the termination of the test suite execution, in operation 618, the test system proxy and the set of test system attributes are removed from the look up service. Specifically, once the processing of the test execution request has concluded, the test service lease with the look up service is terminated. In this manner, the non-existence of the test service proxy and test service attributes in the Jini look up service serves as an indication of the availability of the test system to process a test execution request having similar requirements. Thus, beneficially, the embodiments of the look up service enable the system controller to readily determine the availability of a test system to process a type of test execution request. Moving to operation 620, a determination is made as to whether any requests to remove a machine service proxy and the set of machine service attributes of a test system from the look up service, has been received. If it is determined that the look up service has not received such a request, the method continues to operation 608. In the alternative, if a request to remove a machine service proxy and the set of machine service attributes for a test system has been received, the operation continues to operation 622, in which the machine service proxy and the set of machine service attributes of the test system being deleted are deleted from the look up service. Thereafter, the method continues to operation 608 in which the look up service receives a different request to process a test suite having a set of requirements. Thus, advantageously, the registry service of the embodiments of the present invention enables spontaneous assembly and interaction between processing resources of a dynamic ad-hoc group of networked processing resources and system controller irrespective of the location and configuration of the processing resource. Additionally, the registry service of the present invention enables the system controller to search for and locate an available and suitable processing resource having untapped resources to process the processing job irrespective of the main purpose of the processing resource. Thus, in one envisioned embodiment, a plurality of processing resources (e.g., computer systems) connected through an intranet of a company, having different hardware/software configurations and platforms and defined in the same or different buildings or campuses can be coupled to a system running the registry service and the controller code. In this manner, the untapped resources of the plurality of registered processing resources can be accessed during day or night to execute a job without allocating each of the processing resources to process execution, solely. Consequently, the unused resources of each of the plurality of processing resources can execute subparts of a job, in parallel, thus significantly reducing the overall execution time of the job to mere seconds or hours, which typically may take days, weeks, or months. The advantages of the present invention are numerous. Most notably, acting substantially like a database of processing resources, the registry service of the present invention enables the system controller to intelligently locate a processing resource to execute a process. Additionally, the present invention enables implementing an ad-hoc network of computer resources to execute a process wherein the attaching and detaching of a computer resource has substantially minimum or no effect on the process execution. Furthermore, the embodiments of the present invention enable implementation of processing resources, which are not solely limited to be used by the distributed process framework system of the present invention. As such, the registry service of the DPF system substantially eliminates the waste of resources associated with the prior art. Another advantage of the registry service of the present invention is that in contrast to the prior art, the registry service of the present invention enables the distributed process framework system to be highly scalable. Yet another benefit of the present invention is that the registry service of the present invention provides a DPF system requiring substantially minimal/none administration. Still another benefit of the present invention is that the registry service of the present invention allows the ad-hoc network of distributed processing resources in conjunction with the system controller to create a self-healing network. Yet another benefit of the present invention is that the service registry of the present invention enables the network of the processing resources to span over a large geographical area. Although the present invention mainly describes exemplary embodiments of a registry service for use in a distributed test framework system designed to execute a test suite, it must be understood by one having ordinary skill in the art that the registry service of the present invention may be used in a distributed process framework system implemented to run any computer process. Additionally, although in one example the DTF and/or the DPF systems are called "KNigHT," in a different embodiment, the DTF and/or DPF systems can be called any arbitrary name. Furthermore, although the embodiments of the present invention have been shown to include one registry service, in a different embodiment multiple registry services may be implemented. Furthermore, 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, Transport Commit Protocol/Internet Protocol 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.). 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.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||