|SA Service||Common Data & Metadata Model||Data Exchange||Data Catalog||Persistent Archive||Elastic Computing||Execution Engine||Resource Management||Federated Facility||Messaging||State Management||Identity Management||Policy||Resource Catalog|
|Data Process Repository|| The data processes that are being registered in the repository will need to be translated and described in the terms of the common data and metadata format.
|| The data process service will have to notify the data catalog of the semantics of the data that is generated by the data processes.
|| Any data processing in the elastic cloud will have to be described in the data process repository.
|| Most processes that are operating and are registered in the repository will certainly be tracked by the execution engine.
|| Any resources associated with data processes will have to be managed and so must describe the capabilities of the data process so that it can be managed by the resource manager
|| A data process that is in the repository will have gone through the enrollment phase of the federated facility.
||All interactions for the Data Process Repository service with other systems will be through the messaging service.|| The state model for the processes in the repository must be registered with the state manager so that it can track data process state.
|| If there are any data process specific policies, those must be represented in the correct form and enforced in the policy service.
|| The data process repository will build up from the resource catalog.
|| Consider options allowed by sensors for alternate data configurations (e.g. ASCII or binary output etc.) Metadata will reflect configuration.
|| Is data logging considered a process? If so, should something be here?
|| Can messaging allow multiple users similar output to avoid repeating efforts (two consumers similar output)?
|| How are overlapping user requests handled?
|| see State Mgmt comment to left.
Skip to end of metadata Go to start of metadata