If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: HyperLocal

HyperLocal: Blog Feed Post

F5 Friday: Hyperlocalize Applications for Everyone

 Desktops aren’t GPS-enabled but don’t let that stop you from providing hyperlocal information to all your fans.


IMAGE from macmillan buzzword dictionary  

Two people are sitting in an Internet-enabled café. Let’s call the café Starbucks. One of them is using an iPhone or iPad while having a Hoffachino to find out what’s going on in the area. One of them is using a laptop to do the same. One of these two people is likely to get more accurate responses with less work. Which one is it?

Yeah, the Apple fanbois. To be fair, it could be a Blackberry fanbois or other GPS-enabled smart phone user. The point is that it’s much easier to hyperlocalize applications targeting smart phones because of their innate location-awareness supplied by built-in GPS.

But why restrict your hyperlocal application to just mobile devices? For developers the answer is simple – because the data required to hyperlocalize an application, i.e. the location of the user, is simply easier to get from a mobile device like the iPhone or iPad or Blackberry than it is from a desktop browser. Seriously. The API calls for the application are simple and adding them to either the request or shoving into HTTP headers is just as simple.

Google Gears offers an implementation compliant with the W3C GeoLocation API specification that provides one solution, though obtaining accurate coordinates without a GPS-enabled endpoint may be trickier for the developer. image

While GeoLocation is an integral component of mobile device SDKs, there’s no complement on the desktop that provides this data. The result is that either desktop users are treated as second-class Internet citizens (how’s that for irony?) and are not provided with a hyperlocalized interface to the application or they can jump through a series of hoops to get to the same data that is offered up to mobile users automagically.


One of the key characteristics of dynamic infrastructure is in its ability to integrate and collaborate with other infrastructure components, both at provision and run-time. Part of those dynamic, run-time capabilities includes the means to intercept, inspect, and if desired modify the requests and responses that traverse the entirety of the application or service delivery chain.

Coupling the ability to perform such a task with the ability to grab location-based data gleaned from the client IP address and suddenly you have the information necessary to hyperlocalize all applications; not just those coming from a GPS-enabled smart phone or device.

There are a number of ways in which such a technique could be applied. For example, if applications are hyperlocalized already based on region, one could redirect users to the appropriate hyperlocalized location using a simple network-side script like iRules:

when HTTP_REQUEST {    
    set region [class match -value [whereis [IP::client_addr] abbrev] equals us_regions]    
    if { $region ne "" } {        
        if { $region equals "midwest" } {            
            pool $region        
        } else { 
            HTTP::redirect http://my-$region.application.com 
    } else { 
        pool default 

Or perhaps you want to take it even more granular, and get down to the exact GPS coordinates (as exacting as one can be using IP address) so you can provide detailed information on a neighborhood or nearby geographic location. This requires a bit more integration as it is the application that will need the coordinates to then use to aggregate and ultimately respond with the appropriate hyperlocalized information. There are a number of ways this could be accomplished using network-side scripting including custom HTTP headers, appending the information to the actual request, or rewriting the URI request such that the coordinates are included in the query portion of the HTTP request. The inclusion as custom headers or modification of the URI are likely least disruptive as applications not designed to leverage such data will simply ignore the additional data with no adverse affects.

    set $lat [whereis [IP::client_addr] latitude] 
    set $lon [whereis [IP::client_addr] longitude] 
    HTTP::header insert "X-Latitude" $lat 
    HTTP::header insert "X-Longitude" $lon

A hyperlocalized architecture could integrate your location without requiring additional work on your part.  Rather than ask you where you are, it would know. Which is increasingly useful if you happen to be looking up an item while you’re traveling and doing so from your mobile device.




Increasingly, location is an important piece of social networking and service-delivery. Users and customers demand more awareness from applications regarding location-based information for a variety of purposes including security. The ability to deduce location and combine it with client, network conditions and server-side variables results upon which the  policies that govern delivery of services can be based is called context-awareness. It’s the recognition that applications are not deployed – nor delivered – in a vacuum. Any number of variables may adversely impact the performance or security of an application and it is important to factor in as many of those variables as possible.

F5 BIG-IP Global Traffic Manager (GTM) and Local Traffic Manager (LTM) provide the means by which even location-based data can be extracted and leveraged to provide not only additional security but the targeted data and information increasingly demanded by consumers today. The F5-Quova partnership provides for the availability of robust GeoLocation data that can be used in a variety of ways, not the least of which is to enable application developers access to data necessary to architect innovative, modern and highly integrated applications able to take into consideration the location of a consumer – whether they’re mobile or tethered to their desk.

Application developers no doubt will wonder why they’d implement the discovery of this data external to the application. The answer is that by leveraging the capabilities of an external application delivery vehicle (an application delivery controller) the data can be combined with other contextual-information, such as the connection type and speed, that cannot be otherwise discovered by the application because of topological constraints. Applications deployed into a highly available, reliable architecture are virtualized behind an external application delivery system such as a Load balancer. Topological constraints and networking principles mean that information the application can infer from a connection are specific to the application delivery system, not the client. Network speed and type as well as performance conditions are effectively hidden by the architecture from the application developer. Thus the ability to provide truly contextually-aware data and applications is limited. By leveraging the innate network-side scripting capabilities and dynamism of the application delivery controller, a solution can be realized.

Additionally, implementing such functionality in the application delivery controller is service-oriented and allows for consistent re-use of the upstream service across all applications for which the device provides infrastructure services such as load balancing, web application security, and application acceleration/optimization. The implementation is centralized, coded once, and can subsequently be used across all applications, existing and future. Such an architectural approach reduces the complexity of the integration necessary on the application server, which will otherwise depend on an external service that may or may not impede performance or impact availability should the service become unavailable.

Modern application deployments are increasingly dependent on third-party integrations and services. It should not be overlooked that many infrastructure-hosted services are readily available from existing infrastructure components in the data center such as application delivery controllers. Integrating infrastructure services as a means to develop a more robust and relevant application using GeoLocation or other contextual data should be explored with equal alacrity as the use of third-party APIs and services.

Connect with Lori: Connect with F5:
o_linkedin[1] o_rss[1] o_facebook[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

AddThis Feed Button Bookmark and Share

Related blogs & articles:

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.