weNear Architecture
This post gives a quick idea about the architecture of weNear and highlights some of the decisions that were made. So, without further ado, let's get started...
The weNear server is intentionally kept to just the bare minimum required to make the user location available to services that the user approves. The actors in the system are of just two types:
- Handset Users: Mobile users who periodically send their location to the server, are periodically notified of nearby friends and announcements, and who are capable of broadcasting announcements themselves.
- Non-mobile Announcers: Such as stores, cinemas, or any kind of entity having a premises and which is capable of broadcasting announcements to handset users roaming within its boundaries.
Figure 1: Basic System Components
The system tries to capture certain goals for each stakeholder:
- Users:
- Never miss an interesting nearby event.
- Making it really simple to broadcast events such as garage sales, etc.
- Privacy: User location is available exclusively to friends that the user approves, and it is always possible to hide whenever you wish.
- Announcers:
- Control how long you want your announcement to live and who should receive it.
- Developers:
- Simple, straightforward API for connecting to weNear.
- Availability for many programming languages.
- Documented REST API also available for unsupported languages.
Updating User Location:
The user's handset, running the weNear client software, periodically sends its location to the server. Currently, two location providers are supported:
- If the handset has built-in GPS hardware, then the GPS coordinates are sent to the server and no further operations are required.
- If there's no GPS hardware, or if GPS satellites are out of reach for any reason, GSM cell information is used instead, and then the server uses a Geocoding Service (such as Google's or Yahoo's) to obtain the approximate GPS coordinates.
The user location, once stored at the server, is made available to approved friends and/or services. Processing is divided between the server and the client whenever the problem is found to be easier to distribute on clients instead of server nodes, provided that it doesn't consume too many resources. For instance, the problem of determining which friends are close to the user would demand of the server to maintain huge data structures, with the possibility of network communication between server nodes, but it does lend itself very well to distribution among clients, with reasonable resource consumption.
Receiving Notifications:
In addition to updating the user's location when an update request is received, the server also determines if any of the user's friends have changed their locations, and if there are any announcements matching the user's interests in the user's neighborhood. If found, such information is returned in the response.
The matching process is facilitated by dividing the map into square regions of fixed length. The region where the user's location lies is determined by a simple calculation, and then search indices maintained by the server are employed to arrive at the set of announcements that match the user's location and interests.
Figure 2: The red pin represents the user, and the yellow ones represent the corners of the surrounding regions selected by the server. Regions in different rows (latitudes) will never be perfectly aligned due to the very definition of a region. Those "notches" are less than 40 meters each, while the side of each region is 350 meters.
The Client API:
The weNear service is accessible through a simple client API, which consists of a set of methods employing a custom RMI mechanism, and which are divided logically into separate services. The client API greatly simplifies connecting to the weNear service from any environment where HTTP requests can be issued. Support for most widely used languages is planned, and additionally, a well-documented RESTful API will also be available so that client APIs for unsupported languages can be implemented by third parties.
