Figure 3.1: Simplified Operator Graph of an Interactive and Location-Aware Visualization Pipeline for Mobile Client Devices.
logic, (I-B)integration of custom services, (I-C)dealing with heterogeneous system topology, (II-A) structured and unstructured data support, (II-B) deployment and execution specifications, (II-C) exploiting mobile devices as data source and execution nodes as well as (III-A) access control, (III-B)process control, and (III-C)granularity controlfor data.
To address these new requirements we have developed a highlyflexible and distributed DSPS targeting these requirements. This DSPS is referred to as NexusDS throughout this thesis. It should be noted that although the DSPS architecture and its related concepts is referred to as NexusDS, the concepts presented are general. The concepts presented can be used in order to create aflexible DSPS that targets the requirements from Section 2.4, which are imposed on a flexible DSPS.
NexusDS features a flexible operator model, constraint-based operator distribution and de-ployment, management of heterogeneous system topologies, data access control mechanisms, and aSOA-based P2P approach for dynamic, on-demand scale out. The goal of NexusDS is to support a large variety of context-aware applications as presented in Section 2.3. Other exam-ple scenarios are conceivable however, like location based information systems [102], mobile games [104], or even factory management applications [47]. Thereby, NexusDS is based on the AWM, a shared, global context model as presented in Section 2.5.2.1.
3.2 Adaptation Requirement 77
Figure 3.2:Adaptation Problem for Domain-Specific Data Stream Applications
Figure 3.1 shows the example scenario of a location-aware visualization pipeline. The fi-nal result of the process is an image stream showing the surrounding of a possibly low-performance mobile client device. First, the streams of the continuously changing user, bus, and taxi positions and the static geographic objects are merged andfiltered on the restriction of the user’s proximity. Then, the mapping step assigns graphical primitives to thefiltered data, such as triangles, points, etc. Finally, a rendering operator transforms the stream of graphic primitives into an image stream that can be displayed on the client. Preferably, the render-ing step is executed on specialized graphics hardware (GPU). User interaction, such as rotatrender-ing and panning the scene, can be modeled as parameter updates for the operators, e. g. the camera parameters of the rendering operator.
To deal with the distributed nature of the different data streams in this scenario, it is clearly desirable to make use of a DSPS. Avisualization pipeline, as depicted in Figure 3.1, generally consists of three steps: Filtering, Mapping, and Rendering[65, 154]. These steps map nicely to complex operators of a stream processing system. However, this is far from reality since DSPSs are not designed to support domain-specific applications. The operator’s origins are different and so are their respective constraints. Filteringcan be realized byexploiting already existing operators(from a DB’s point of view aselection) present in state-of-the-art DSPSs. For Mappingdomain-specific knowledge is necessary. Mapping does not need a specific execution environment to run, in contrast to Rendering. As with Mapping, also Rendering is a domain-specific operator but has constraints with respect to the target runtime environment making a constrained domain-specific operatorout of it, i. e. a GPU is needed.
According to the sample scenario the DSPS must adapt to new requirements in terms of operators, changing deployment and runtime specifications, or even changing system topolo-gies and security restrictions. Although research has brought up many efficient techniques,
an adaptation problem in the domain of DSPS is still persisting. The adaptation problem is depicted in Figure 3.2 and is explained ahead.
On the left side a generic DSPS is depicted (in bold letters), whereas on the right side a domain-specific and context-aware data stream application is displayed (in italic letters). In principle three approaches exist to integrate such an application into DSPSs to exploit existing functionality: Either 1madapt the DSPSto meet the specific requirements of the domain-aware application, 2madapt the domain-specific application to exploit system functionality where possible, or 3madapt both, the DSPS and the context-aware application, meeting somewhere in the middle. This case is depicted by theDomain-specific DSPS.
Case 1mconsiders adapting a DSPS to an application. In this case, a DSPS must either be built from scratch or an existing one must be modified to achieve a deep integration of the application in question into the DSPS. Neither of these two alternatives is desirable, as building a DSPS from scratch means a big investment—in terms of time and maybe money—
and includes a high failure probability. To extend an existing DSPS or even building up a DSPS from scratch needs a profound knowledge of the system specifics. A prominent example is PIPES [79], a framework offering building blocks that must be implemented with domain-specific code. But before the system can be used, its missing features must be implemented by an expert. This, however, is a non-trivial and cumbersome task.
For case 2mthe domain-specific application must be adapted to an existing and concrete DSPS. This reduces the re-usability of the domain-specific application automatically since the application is tailored to the specific DSPS. This is because the application might rely on spe-cific functionalities which are only offered by a certain DSPS. In this scenario, DSPSs capabil-ities are exploited to carry out tasks a DSPS can handle. The domain-specific data processing must then be performed within the application or outsourced to other, maybe remote, sites.
However, an obvious issue with this approach is potentially redundant code which is spread across many different applications, in each specific domain. Another problem is the fact that devices running domain-specific applications are often not well-suited to do so. This mainly originates from computing performance and energy constraints.
Considering case 3m, the domain-specific applications as well as the DSPS are adapted to meetsomewhere in the middle(denoted by the dashed box in Figure 3.2). Therefore, the appli-cation outsources parts of the domain-specific appliappli-cation logic to integrate it into the DSPS.
In turn, the DSPS must consider the domain-specific constraints of the application. Assum-ing the user wants the application to be executed exclusively on nodes he trusts for security reasons, the design of a DSPS is crucial for the flexibility with integration of domain-specific applications. This has mainly two reasons: The integration should be as easy as possible un-burdening the developer from cumbersome tasks. At the same time, the system must provide adequate extension mechanisms in terms of extension points. NexusDS is our proposal of such a DSPS which provides basic data stream processing functionality, but at the same time provides extensions for the integration of domain-specific functionality.
3.3 Related Work and System Classification 79