Workspace definitions, which define an execution environment, can be associated with jobs. A work request is processed to automatically determine that tasks that are progeny of a given job inherit the association with the workspace definition, and therefore, that the tasks should be executed using the execution environment defined in the workspace definition. However, different execution environments can be defined for progeny of a given parent job, essentially overriding the inheritance from the parent job. According to an embodiment, a set of resources associated with an execution environment is configured such that the resources are accessible by two or more computers of a group of networked computers, such as a server farm, without requiring configuring duplicate sets of the resources. Furthermore, in a server farm computing environment, an execution environment associated with one or more jobs is not reliant on being created on any given computer of the server farm. US7159217 - Mechanism for managing parallel execution of processes in a distributed computing environment - 01/02/2007 According to one aspect, a work request that specifies first and second jobs is received. The first job comprises a first task and the second job comprises a second task. The work request is processed to automatically determine whether the jobs have any dependencies that have not been satisfied. In response to a determination that the jobs have no dependencies that have not been satisfied, the jobs are caused to be executed in parallel. As a default manner of operation, the tasks included in each respective job are collectively executed in parallel, whereas tasks within a given job are not executed in parallel. In an embodiment, the tasks are executed on one or more servers of a group of networked servers. Dependencies can be specified between jobs that are constituent to a unit of work, which are automatically determined or identified by processing a work request that defines the work. For example, a second job can be specified as depending on a first job meeting a particular condition. Furthermore, sub-works of the second job are not scheduled for execution until the first job has met the condition, thus allowing the second job to be placed into an active state. First, a work request is received, which specifies a first job that includes a first set of sub-works and a second job that includes a second set of sub-works. The work request is interpreted and processed to determine that the second job has the dependency on the first job. The first job is placed into an active state to enable the first sub-works to be scheduled for execution. The second job is placed in a pending state and it is determined whether the first job has met the condition. If it has, the second job is placed into an active state and the second sub-works are scheduled for execution. In an embodiment, the first job is caused to be executed without initiation by the second job, that is, its dependent job. A work request is processed and interpreted to automatically establish job data structures associated with jobs constituent to the work and data storage structures associated with tasks constituent to the work. Further, parent-child relationships between jobs, sub-jobs and tasks are automatically established based on interpreting the work request. Once tasks are executed, log information related thereto is stored in respective data storage structures, for access and rendering upon request. Each data storage structure stores log information pertaining only to a respective task. In an embodiment, in response to receiving a request to delete a particular job, the particular job and all of its progeny sub-jobs and tasks are deleted. The work request does not include explicit commands to establish the job data and data storage structures, nor to store the log information in the data storage structures. Generally, structured work requests based on a job request language and interpreted by work management application layer provide the foregoing functionality. In embodiments, a representation of a job data structure and its constituent sub-job and/or data storage structures are rendered, along with linking mechanisms between various levels of the overall work aggregation hierarchy that is implied in an associated work request. The links can be used to traverse the hierarchy to easily access and view log information stored in data storage structures. A work request is processed and interpreted to automatically establish job data structures associated with jobs constituent to the work and data storage structures associated with tasks constituent to the work. Further, parent-child relationships between jobs, sub-jobs and tasks are automatically established based on interpreting the work request. Once tasks are executed, log information related thereto is stored in respective data storage structures, for access and rendering upon request. Each data storage structure stores log information pertaining only to a respective task. In an embodiment, in response to receiving a request to delete a particular job, the particular job and all of its progeny sub-jobs and tasks are deleted. The work request does not include explicit commands to establish the job data and data storage structures, nor to store the log information in the data storage structures. Generally, structured work requests based on a job request language and interpreted by work management application layer provide the foregoing functionality. In embodiments, a representation of a job data structure and its constituent sub-job and/or data storage structures are rendered, along with linking mechanisms between various levels of the overall work aggregation hierarchy that is implied in an associated work request. The links can be used to traverse the hierarchy to easily access and view log information stored in data storage structures. |