Classification of Constraint Types

The constraint model helps to define a classification space for constraints relevant for context-aware applications. This constraint model serves as a base for determining the methods needed for a seamless and adequate integration of context-aware applications.

The context-aware application scenarios presented in Section 2.3 showed that different con-straints at different levels of data processing arise. As an example we refer to the Rendering operator in Figure 4.1, representing a constrained domain-specific operator. This operator is typically meant to run on a GPU. The main reason for this is that a GPU allows to perform the rasterization process efficiently because of the Single Instruction Multiple Data (SIMD) pro-cessing technique. There are also other approaches which map originally Central Propro-cessing Unit (CPU)-based algorithms to a GPUs [61, 107]. We may think of CPU-based algorithms mapped to FPGA-based algorithms, as proposed by Teubner and Woods [134].

In short, it can be stated that context-aware applications often rely on highly specialized data processing operators. The execution of such operators might be restricted to specialized environments (e. g. for the Renderingoperator from Figure 4.1). To support these restrictions for highly specialized operators, the system must support the notion of constraints. Constraints are important for the correct deployment and execution of non-trivial SP graphs. This means however, that the deployment algorithm must support constraints to find an optimal set of NexusDS nodes, capable of running the operators of the SP graph. A solution to this problem is presented in Chapter 6.

4.1 Support for Context-aware Applications 115

Figure 4.2:The Constraint Space in Data Stream Processing Systems

As shown in Figure 4.2, the resulting constraint space can be subdivided horizontally, verti-cally and diagonally. Hereby, the constraint space denotes the set of possible constraints. In diagonal direction we definecapability constraintsandrequirement constraints. In horizontal direction we differentiate betweendeployment constraintsandruntime constraints. In vertical direction we identify freely modifiable constraints and bounded modifiable constraints. The resulting partitions are explained in more detail as follows:

Requirement constraints These constraints originate from users, applications, domain ex-tensions and the core system itself. These constraints define the requested features and must be matched against capability constraints. Requirement constraints are integrated as SP graph annotations and this is presented in Section 4.1.2.

Capability constraints These constraints delimit the range of possible requirement straints configurations, and thus represent the counter part to the requirement straints. Capability constraints are needed for correct architectural integration and con-straint evaluation as described in Section 4.1.2.

It is important to note that in contrast to requirement constraints no user-related capa-bility constraints exist. Users formulate requirements rather than capabilities.

The constraints described above can be overlaid by the vertical classification criteria deploy-ment constraintsandruntime constraints.

Deployment constraints This constraint type influences the deployment process of the un-derlying system. This in turn reduces the potential search space for the deployment

algorithm searching for suitable NexusDS nodes. As an example, a deployment con-straint could state that only Operator Execution Services (OESs) being executed on cer-tain NexusDS nodes and providing a certificate are permitted to participate in processing the data.

Runtime constraints Such constraints influence the runtime behavior of operators and thus influence their execution. This class of constraints has a direct connection to the actual resource consumption of the operator. E. g., aRenderingoperator can be parameterized in several ways, so that the target resolution is low if resources become lean, and high if there is enough capacity to process it accordingly. This fact in turn has a direct influence on the rendering performance as well as on the actual resource consumption.

Deployment constraintsandruntime constraintsrepresent the vertical classification criteria for the set of possible constraint types. They can be overlaid by the horizontal classification criteria (freely modifiable constraints andbounded modifiable constraints), creating six basic constraint space partitions in total.

Freely modifiable constraints In theoryfreely modifiable constraintshave no restriction re-garding their settings. However, there are restrictions. These restrictions arise depending on the underlying system, e. g., by the hardware engaged and software solutions. Thus, these constraints depend on the design of the system and originate from the system and application developers. These entities define the constraints. E. g. considering the Render-ingoperator, if the resolution parameter (being aruntime constraint) is defined as being freely modifiable, it is (theoretically) possible to define an arbitrary resolution—obviously as long as the underlying components, i. e. the GPU, support this. For deployment con-straints, e. g., arbitrary NexusDS nodes can be selected for deployment and execution of this operator as its execution is not restricted to a certain set of NexusDS nodes.

Bounded modifiable constraints These constraints are characterized by the fact that they can only be modified within predefined borders (which are not part of the restrictions that a certain software and hardware combination enforces, as illustrated earlier). This means that the values must be checked against the predefined set of allowed values, defined by the operator developer. In case of the Rendering operator, for the runtime constraints, a list of allowed values for this parameter is provided, if the resolution pa-rameter isbounded modifiable. In this case we cannot select an arbitrary resolution but have to pick one of the values contained in the list of possible values instead. For deploy-ment constraints, e. g. a set of allowed NexusDS nodes that should execute the operator can be provided.

These partitions can further be subdivided by the different scopes that occur in DSPSs. As depicted in Figure 4.2, four basic scopes are identified within such systems, namely system, domain, application and user. Each scope defines its specific constraints. However, they are not independent from each other. Going fromfine to coarse, the dependencies are: userscopes depend on application scopes, application scopes depend on domain scopes, domain scopes depend onsystem scopes. Thus, the constraint spaceuserrepresents a subset of the constraint

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.