PoSIM Components

PoSIM offers two levels of visibility to LBS developers: a transparent API, which is similar to the JSR-179 one, and a visible API, which extends traditional JSR-179 by providing the capability to directly interact with integrated positioning systems. To interact with positioning systems in a transparent manner, simple LBSs can exploit the Policy Manager and Data Manager components.

Policy Manager.
Via Policy Manager (PM) APIs, simple LBSs can ask for pre-defined behaviors implemented as declarative policies, without any knowledge of how actually the integrated positioning systems are exploited. For example, the POWER_USAGE_LOW policy turns off all the positioning systems with high energy consumption by preserving application-specific requirements about precision and accuracy. PM is in charge of maintaining pre-defined policies and enforcing active ones; it is implemented on top of the Java-based rule engine Jess.

Data Manager.
Via the Data Manager (DM) component, PoSIM provides integrated positioning system info in an aggregated way as a single XML document, where tags are exploited to specify the content semantics, thus permitting a significantly higher level of dynamicity. PoSIM can offer location data for any integrated and currently active positioning system. Location data access retrieval is possible either on request, or specifying a time period, or via event notification. LBSs can easily specify the conditions to trigger XML document delivery. For instance, the pre-defined atLocation condition triggers location data notification only when the current physical location of the user is close to a known location, similarly to the only possibility available in JSR-179 via the proximity listener. In addition, LBSs may request DM to work as a filter, e.g., the pre-defined highAccuracy data filter discards location information with accuracy below a given threshold. Note that the proper exploitation of filtering rules permits to reduce the network overhead due to non-relevant changes of location data. PoSIM implements triggering events and filtering rules as Java classes, which can be easily sub-classed to specify specialized triggers and filters.

Let us stress that expert users, such as PoSIM administrators, can develop and deploy new policies, i.e., selection/fusion criteria, triggering events, and filtering rules. The PoSIM behavior can thus be specialized and extended with impact on neither its implementing code nor the application logic code. That permits to easily extend and personalize the PoSIM middleware. For instance, it is possible to dynamically extend PoSIM capabilities by introducing the atChanges condition that triggers location notification only when current and previous physical location differ more than a specified distance. Anyway, simple LBSs and novel developers can also work, simply and rapidly, by selecting among the existing set of most common policies, events, and filters.

Positioning System Access Facility.

Smart LBSs and PM/DM can directly control positioning systems by exploiting the lower level API of the Positioning System Access Facility (PSAF). PSAF supports API to dynamically handle the insertion/removal of positioning systems and to retrieve/control data/features of all the currently available positioning systems. The only requirement is that positioning systems provide their data/features via a specified interface.

Positioning System Wrapper.
That interface is the result of the wrapping of another PoSIM middleware component, i.e., the Positioning System Wrapper (PSW). PSAF exploits Java introspection to dynamically determine and access the set of data/features actually implemented by the underlying positioning solutions currently available in its deployment environment.

9-nov-09