Page Operations
Browse Space
[[ Note: main capabilities of CEI (the "EPU") are not directly 'acquired'/'linked' to other subsystems except as a sort of 'side effect' of using messages via COI. Just pointing out in case it is not clear that for CEI in particular, functional dependency is separate from triggers and direct interactions between code modules." ]]
Dependency Table
Other subsystems depend on the functionality provided by Common Execution Infrastructure as shown in the following table. Each X requires a discussion between subsystem leads and architects to clearly understand the dependency and the interface.
| Functionality |
COI |
DM |
S&A |
I A |
Notes |
|---|---|---|---|---|---|
| Virtualized computing resource provisioning, operations and maintenance | X | X | X | ? | |
| Provisioning parameterized configurations of service and application modules into compute node deployment packages | X | X | X | ? | |
| Monitoring and provisioning compute nodes based on compute resource utilization and latency of provisioning | This is functionality used to provide other functionality to subsystems (it is information used to know when to scale, other information is also used). |
||||
| On-demand scheduling of processes | X | X | X | X | Job scheduling is functionality handled in a "batch" oriented way in R1. More "capacity" will allow more processes to be run in an on-demand way. |
| Optimized scheduling of stream process subscriptions | X | Job scheduling is functionality handled in a "batch" oriented way in R1. More "capacity" would allow more processes to be run in a high priority way. Is priority based scheduling in R1? |
|||
| Extendable process execution environment that supports multiple execution formats | X | X | X | ? | VM images will represent the different execution formats. |
| An extendable set of process execution engines | Though this was a COI concern. This is referring to how a message is received in a capability container and sent to some local execution engine like MatLab etc.? See (2) |
||||
| Federation of process execution service providers, and process control interface | |||||
| Immediate-mode scheduling of processes at specified locations | See "Optimized scheduling of stream process subscriptions" above. Priority? | ||||
| Coupling of processes to the streaming environment of the Data Management subsystem | DM concern |
||||
| Coordinated and/or chained scheduling of processes | Workflow service? |
||||
| Standard process execution planning and control | X | X | X | X | |
| Standard provenance capture and reporting | X | An archive of what ran when and where? COI concern? See (1) |
|||
| Process authoring and monitoring applications that will be integrated as a user interface to the CEI include MatLab and Kepler | See "process execution engine" above. |
Notes:
- COI provides just the means for archiving the "logs" of what/when/where was executed. The right process has two parts:
- Definition and Setup of repositories
CEI provides to DM a) a specification/data model for such log entry; b) a data model/schema/specification of how a repository for such information would look like; c) a set of operations that CEI would require from that repository (e.g., read, write, query, etc). DM provides an abstract specification/models of these (and others similar) to COI for implementation/provisioning. COI picks up the appropriate technology choice to support the capabilities required by the abstract spec from DM; DM extends (if needed) the operations associated with the abstract spec to support the capabilities required by CEI. - Operation
Using CEI capabilities, the COI instantiates the necessary number of capability containers/deployable units/EPUs (depends on the specific technology used to implement the repository) to bring up the repository services required by CEI to store the "logs". CEI uses the DM implemented operations to communicate with those services and store/update/etc the "logs".
- Definition and Setup of repositories
- The set of process execution engines refers to the availability of a number of preconfigured environments within the deployable types & units that can support applications/processes written in different languages or requiring custom environments. For instance, plain Java VM, Tomcat servlet containers, Matlab scripts, etc. Similarly with note (1), the CEI is responsible for providing the specifications for a repository that would contain these entities to DM, which would abstract them and pass for implementation to COI. For instance, the set might contain groups of packages with the right dependencies that can extend a deployable type to support the necessary processes. In this example, each group could be described by a name, a list of packages, and a binary archive of those packages.