The following is a list of the most relevant terms ordered not alphabetically; but by level of abstraction, from more abstract to more concrete, so it can be read from top to bottom as a manual which describes the idea behind GWE, its new concepts and the problem it addresses.
A group of processes that has no execution dependencies on each other. Each of the processes in such a group can run in any order, at any time and in any cluster or compute node. In contrast, an "inter-dependent" processes may be a group in which the processes would have to execute in a particular order because the execution of process "n+1" depends on the result of process "n". In summary, each one of these processes are atomic and the most common thing that may bundle them together is a higher level of abstraction problem which they are part of.
The execution of a group of processes without sequentiality (as with a single batch script) and/or resources constrains (as with a single compute resource). This does not mean that these processes necessarily will execute at the same time in their own dedicated compute nodes; this only means that they will not have the constraints previously mentioned.
A particular user's authentication information to access a group of network enabled compute and data-storage resources.
A system intended to run on a cluster head node as a daemon process. This system is the heart of GWE and it will coordinate all parallelization related operations for that cluster and provide interfaces to enable communication with other daemons and clients for external coordination of parallelization related operations as a part of a GWE Grid .
A cluster that has a GWE Daemon running in its head node.
A a collection of GWE Enabled Clusters defined by a user to work together towards the target of getting his/her processes executed. Such collection of GWE Enabled Clusters will automatically and transparently (without further user intervention) coordinate their actions with each other to achieve that goal. (Feature not released yet).
An application built on top of a GWE Client API , which communicates with GWE Daemons to submit requests to it and/or monitor (in real time or on demand) status information on authorized resources and activities which the daemon is responsible for or aware as a part of a greater GWE Grid .
A small proxy application running on each compute node of a cluster leased for usage to a GWE Daemon . The operation of these small applications are completely transparent from the end users point of view and their overall existence is only relevant to a GWE Daemon , as it is only an internal aid to it to fulfill its functions.
The GWE unit of work from the end user's point of view. This unit of work represent a collection of inter-independent processes invocations the end user wants a particular GWE Grid to execute using specific scheduling criterias (latter feature not released yet). Orders are queued in a GWE Daemon of the order's GWE Grid with a unique identifier which can be used by the user to query progress status regarding their orders.
A set of directives that set the criteria to use while executing a particular order such as whether to cache stage files, maximum amount of concurrent jobs to execute, criteria to clean up staged files, etc. This is a part of an order.
An abstract unit of information that can be translated into a collection of jobs invocations. This is a part of an order.
An easy to use, GWE proprietary, scripting language which has semantics to easily describe a great number of complex grid parallelizable process invocations. See the P2EL guide for more details.
Same as a inter-independent processes invocation, used within the GWE system as the internal system's unit of work.
An actual instance of a run of a job. There could be more than one per job if the executions failed and the job is supposed to retry.
The abstract result of the process associated with a Job . This is an abstract concept because the user has the power to define what it wants as the result of its processes. Although most likely this value will be irrelevant under normal circumstances since the execution of these processes may generate themselves the output somewhere else. By default this is the OS standard output stream the process created during its execution.
The process of requesting a particular GWE Daemon to execute an Order . This request itself does not do the actual execution of the processes that compose the order; but queues the order (as a collection of inter-independent processes ) for processing as compute resources become available in the order's GWE Grid . Orders are queued in a GWE Daemon of the order's GWE Grid with a unique identifier which can be used by the user to query progress status regarding their orders.
The operation of downloading files required to execute a process (before its execution) and of uploading files created during a process execution, from and to selected remote locations. Check the P2EL staging functions for more details $in() and $out() .
The "workspace" directory under the GWE daemon's installation directory (in the running cluster) where temporary, GWE related, files are stored such as logs, staged files and auto generated scripts.
The directory under a Workspace where staged files (downloaded and scheduled for uploading) are temporarily stored.
A Java library which provides routines to make secured remote procedure calls (RPC) to GWE Daemons .
A third party application which has been integrated with GWE through the GWE Client API in order to add grid computing capabilities to it.