Analyzing and Understanding Web 2.0 Apps

In the best Web 2.0 world, everything you need to build an application is already there and waiting for you. All you have to do is glue the stuff together. But in the real Web 2.0 world, that "stuff " may not fit together the way you intended, requiring that you actually have to analyze and understand your application.

This is the problem that Emre Kiciman, a researcher in the Cybersecurity and Systems Management group at Microsoft Research, is tackling.

In a research project he calls Ajax View, Kiciman is focusing on the reliability of Web services -- and using Ajax to do so.

"The goal of the Ajax View project," he says, "is to improve the visibility that Web-application developers have into how their applications are running inside end user’s browsers out in the real world. Having detailed, code-level monitoring can help developers discover, understand, and fix the bugs that are affecting real users. "

In a paper entitled Live Monitoring: Using Adaptive Instrumentation and Analysis to Debug and Maintain Web Applications, Kiciman and his colleague Helen Wang explain that Ajax View involves inserting a proxy between a Web application and a user’s browser. The proxy dynamically rewrites the code and injects instrumentation code, which reports back to the Web service any observations it has made about the application’s behavior in the wild, thereby enabling the developer to improve the code as necessary.

"With the Web 2.0 model," he goes on to explain, "you have much more dynamic code and content being sent out to the browsers. Is it fast? Is it slow? Is it failing? You don’t know until your users complain. A lot of the challenges of code complexity when you start to write large programs -- trying to run your programs across heterogeneous environments, different browsers, different types of computers, as well as dependencies on third-party services and software that’s not under your control -- those issues all are cropping up in Web applications just as they have with conventional software."

The instrumentation code injected by the proxy provides a number of advantages, says Kiciman. For one thing, the instrumentation code runs with the rest of the application inside the browser and you can see almost any part of the application’s behavior. You can check for assertions and memory leaks, for instance.

He adds that the process boils down to three steps as precursors to improving Web applications:

• Instrumentation
• Observation
• Analysis

"The first piece is determining how you’re going to gather the data you care about," Kiciman says. "You decide what data you want to collect and then how you can grab that from inside the JavaScript environment. There are limitations inside the browser, so you can’t get full knowledge of everything. You’re limited by the security model of the JavaScript sandbox.

"The second thing is you determine what’s going to get reported back about this data, and then you figure out how to distribute this. Does everyone have to run the whole policy at once, or can it be split up?

"There’s a question of adaptation. When do I want to turn on this instrumentation? Do I want it to be always running, or do I want it to be reacting to a particular issue? Will you turn on part of the policy and get information about part of the program and use that to follow a trail and turn on instrumentation in the second or third part?"

"An important thing to note is that Ajax View isn’t actually changing anything about the security model," says Kiciman. "The browser is still enforcing what it thinks is an appropriate boundary around the application. We’re just taking advantage of the current visibility that the Web page can get about its own behavior. The security model and the boundary of what the Web site is allowed to do has already been set by the browser, and we’re operating in those limits."

Posted by Jon Erickson at 09:58 AM  Permalink