Abstract
The goal of SpatialViews (SV) is to provide a high-level programming model that allows application programmers to easily develop and maintain their mobile ad-hoc network applications. Each node in the network is assumed to have substantial computation and communication capabilities, and is aware of its spatial location. The location of a node can be queried by the user level program, i.e., a particular location may determine the actions performed by a program. Resource-constrained sensor networks are not the main target of SpatialViews . Examples for target network nodes are state-of-the-art smart phones, PDAs, notebook, and laptop computers. The language is a vehicle to study different language, compiler optimizations, and performance trade offs. Clearly, not all conceivable applications may be implemented within the framework of this programming model. Our goal is to provide a high-level programming model for a large class of mobile applications for ad-hoc networks that hides many details of the underlying volatile target networks. In this sense, SpatialViews is complementary to lower level languages such as nesC [4], SP [2] and SM [7]. A programming language approach was choosen for SpatialViews instead of a library (API) approach in order to allow more aggressive optimizations and more efficient program analyses. The SpatialViews language is an extension of a Java subset. The main program abstraction in SpatialViews is that of a space-time region of virtual network nodes that provide specific services. A SpatialViews can be thought of as a type specification that describes the desired network type and properties. This space-time region or type is called a spatial view.Thespatial view definition is declarative in nature, i.e., does not instantiate any mapping between virtual and physical nodes. This is done through as briefly discussed in the next paragraph. An iterator allows the programmer to specify actions on nodes in the spatial view. The operational semantics of the iterator is based on migration, i.e., the programmer can imagine that each iteration is performed on a different virtual node, with program migration performed implicitly between the iterations. The spatial view is instantiated by discovering and migrating to network nodes that match the type definition of the spatial view. Constraints on the discovery and migration process may be specified as part of the iterator. A time limit is a required constraint for each iterator. Each virtual node in a spatial view can be instantiated, i.e., visited at most once. Due to the volatile and mobile nature of the underlying target network, SpatialViews does not support any explicit mapping between a virtual network node and its corresponding physical node. In other words, the language does not provide names (e.) of a physical node across iterations. Any physical node that matches the virtual node type as specified in a spatial view can be an instance of that virtual node. The motivation for this restriction is the fact that any particular binding of virtual and physical nodes cannot be guaranteed to be valid during the program execution due to the volatility of the underlying network. The programming model introduced by SpatialViews could be implemented as an extension to the Java programming language through additional syntax and semantics, or through a Java package that contains class definitions that may be imported Java programs. There are advantages and disadvantages to both approaches. We chose the programming language approach which allows a better control of the semantics of the newly introduced programming model concepts.