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.
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.
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.