Architectural Integration of the Constraint Model

4.1 Support for Context-aware Applications 117 spaceapplication, the constraint spaceapplication represents a subset of the constraint space domain, and finally the constraint space domain represents a subset of the constraint space system. In the following, each scope is explained in more detail:

System related constraints Such constraints are defined by the system environment and de-fine the superset for possible constraints (see Figure 4.2). Therefore, the system specific dimensions must be determined and integrated. System relevant constraints provide a frame for domain, application and user constraints. E. g., a NexusDS node can be de-fined having an installed GPU (static information) and a total amount of 2048 megabyte (MB) of Random Access Memory (RAM) (dynamic information). The dynamic infor-mation must be observed by monitoring components, ensuring that a certain operator requiring a defined amount of RAM can be successfully executed on a certain node.

Domain related constraints The constraint space defined by thesystem relevant constraints is restricted bydomain relevant constraints. This allows a better adaptation of the sys-tem to specific domain requirements. As depicted in Figure 4.2, the domain relevant constraints are completely covered by the system relevant constraints. This means no constraints defined by the system relevant constraints can be overridden by domain relevant constraints. E. g., a developer can define an operator requiring a GPU to run effectively or define an operator to require at least 256 MB of RAM.

Application related constraints Constraints may also be defined for specific applications.

These application relevant constraints are a subset of the domain relevant constraints and allow an application to further restrict the constraint space for a specific operator.

E. g., the application may constrain the execution of specific operators to a fixed set of NexusDS nodes. This might be needed to ensure low latencies when interacting with the application by rotating or translating the rendered scene.

User related constraints Finally, user relevant constraints represent constraints defined by the user. They are completely surrounded byapplication relevant constraints. These con-straints represent a specific user preference. E. g., the user may prefer the scene rendered having a reduced resolution and more details (assuming the operator provides these set-ting capabilities). Additionally, the user may demand only trusted NexusDS nodes for the execution of the entire data processing. This may be a NexusDS node providing a specific encryption functionality.

Thus, the constraint space defines a frame for the system components and ensures its correct functioning. In the next section the integration of the constraints into NexusDS is presented.

Figure 4.3:Architectural Integration of Constraints in NexusDS

The data structure for propagating requirement constraints is represented by constraint-based SP graphs. Each layer augments the original SP graph by adding their specific require-ment constraints for deployrequire-ment and runtime. These constraints originate from applications, operator-specific meta data, services and security policies. The different concepts implement-ing the requirement constraints are context-aware applications, operators, services, and the security framework. All requirements are collected along the path from the top layer to the core layer.

On the other side,capability constraintsare the counter part to requirement constraints and delimit the possible requirement constraint configurations. Capability constraints are realized by operators, services, and resource groups, defining the available resources for operator de-ployment and runtime. The capabilities are collected in the core layer. Then, the requirements are matched with the capabilities to validate if the SP graph represents a valid configuration for the system.

4.1 Support for Context-aware Applications 119 For the requirements constraints, going top down, each NexusDS layer adds its specific requirement constraints to the SP graph. The SP graph represents the central structure to transport these constraints to the lower layers. Theuser relevant constraintsconstitute options which the corresponding context-aware application provides and are defined on the Context-aware Applications layer. This layer augments the SP graph by its specific requirement con-straints. The augmented SP graph is then passed on to the next layer, which adds its specific requirement constraints. These requirement constraints originate from dedicated services or operators from bothNexus Application ExtensionsandNexus Domain Extensions. Both layers add their application relevant constraints and domain relevant constraints respectively. The developer formulates the operator specific and service specific requirement constraints. The next and final layer augmenting the SP graph by requirement constraints is the Nexus Core layer. In this layer, the system relevant constraintsresulting from existing core operators are added to the SP graph. Additionally, in this layer the SP graph is augmented by security poli-cies. Therefore, all relevant security policies are extracted and added to the SP graph. The security framework and its related concepts are presented in detail in Chapter 5.

Now, the SP graph has been augmented by all relevant requirement constraints, symbolized by the requirements in the core layer. These requirement constraints must be validated in the next step. Thereby, the requirements should obviously not violate the capabilities. The capability constraints are also collected by the respective entities. The Communication and Monitoringlayer build the basic capabilities for deployment and runtime of operators. Besides, theNexus Application ExtensionsandNexus Domain Extensionsprovide capability constraints by, e. g. limiting the usable amount of main memory per operator. Furthermore, operators themselves provide capability constraints defined by their respective developers. These capa-bility constraints include the anatomy of the operator itself, i. e. its parameters. Additionally, a developer can limit the range of possible values for the operator’s parameter.

Only SP graphs whose requirement constraints match the capability constraints available, i. e. whose requirements are satisfied, can be deployed and executed. Thus, before SP graph deployment and execution, the requirement constraints must be matched against capability constraints a DSPS offers. These constraints naturally limit the possibilities for deployment and execution.

The requirement and capability constraints are implemented by different concepts as shown in Figure 4.3. In the next sections the concepts for realizing the constraint model are presented in detail. First, in Section 4.2 the operator model formulating requirements and defining the constraint space for the upper layers are presented. In Section 4.3 the service model is intro-duced, allowing to integrate highly specialized functionality to manipulate SP graph structures.

The resource groups are presented in Section 4.4. Finally, the concept of a constraint-aware SP graph and the matching concept of requirement constraints to capability constraints are pre-sented in Section 4.5 and Section 4.6. The security framework which is related to the constraint concept is presented in its dedicated Chapter 5.