AJAX Monitoring Tracing and Debugging

• 1. Motivation
• 2. Description
• 3. Competitors
• 4. Effort estimation
• 5. Dependencies
• 6. Impacts
  • 6.1. Architecture
  • 6.2. API
  • 6.3. UI
  • 6.4. Documentation
  • 6.5. Testing
  • 6.6. Performance
• 7. Risks
• 8. Additional information

1. Motivation

An AJAX application running in the browser is very complex without even considering the broader system (server side presentation systems, remote services) in which the browser participates. The live DOM of the rendered page, the raw technologies (HTML, CSS, JavaScript), the I/O systems (transport endpoints, security restrictions) and the depth of AJAX frameworks like Dojo is in some ways just as complicated as server side components and as hard to debug. The conventional tools for analyzing the client side include:

• Http transport monitoring which intercepts Http requests and responses from within the browser or at the browser perimeter in the operating system by a separate tool
• Inspecting source views of the primary web page document and/or the documents gathered by a single page interface based on a composite of script tags, (i)frames, XMLHttpRequest
• DOM inspectors/visualizations (generally tree based views of the DOM) and DOM navigation (two way UIs which associate tree/src views of the DOM with the rendered page)
• JavaScript debugging (conventional) done in process to browser with peer or split pane UIs
• RAD capabilties lend themselves to browser analysis including: JavaScript shell which provides a way to evaluate expressions in the browser execution context; browser results can be immediately previewed in an embedded browser rendering engine (preview window in Eclipse) or synthetic WYSIWYG views (Dreamweaver, Creator).

Also, in a public facing site, the AJAX developer has to deal with differences between browsers (the world is not perfect yet and neither are the AJAX frameworks which hope to shield the developer from these matters). There are no standard JavaScript debugging APIs or remote protocols let alone something which covers monitoring and tracing of the DOM; that is, there is no JMX/JPDA like solution for browsers (well maybe there can be one but more on that later).

Upon surveying the AJAX space looking at how developers are being trained in AJAX and are proceeding with AJAX and even considering what the experts and GURUs in this space such as the engineers of AJAX frameworks and products are using there are some best practices and best in breed tools. Specifically, a leading open source browser, Firefox/Mozilla which has a vibrant Plugin/Addon ecosystem is the favorite of the developer and both an OOTB solution (rich but not too elegant) for DOM Inspecting and JavaScript debugging and also the FireBug Addon vastly improves the usability of DOM Inspecting, JavaScript debugging and XMLHttpRequest tracing with a slick UI and unobtrusive browser integration.

Eclipse has tried to duplicate the features of Firefox DOM Inspecting and JavaScript debugging and add XMLHttpRequest tracing as part of an embedded Mozilla XULRunner solution with ATF project. Clearly it is a qualifying feature of an IDE to support AJAX development and capability for AJAX Monitoring Tracing and Debugging. The question for this feature definition is whether or not having such features "embedded" in the IDE is a specific qualifier (requirement), whether it is a useful solution and if not then what IS the solution which could be provided instead? Do the browsers themselves have the upper hand having a naturally better context for the developer to debug AJAX?

One basis for this feature (beyond the fact that duplicating what is there in Eclipse/ATF would be expensive and we are looking for a cost benefit tradeoff) is that a bundled browser and embedded debugger/monitor solution may contrain the developer's configuration of the browser. For example, a common use case is that a customer complains that a particular runtime environment breaks a DHTML/AJAX application. Ideally, engineering will want to reproduce the test case (same version of Mozilla, same OS, same AddOns^?/Plugins and configuration of the browser including runtime resources). Coupling the browser to the IDE (in fact embedding it) may be inflexible (if not impossible) to truely reproduce a browser runtime configuration AND debug/trace/monitor at the same time.

However, the motivation for having the debugging UIs and workflow exclusively in the IDE is that the IDE is where the rest of the developer worlflow is provided, primarily editing. The Eclipse ATF demo (e.g. MyEclipse^? Web 2.0 Browser feature) is certainly a cool demo. FireBug, for instance, does not help me edit my JavaScript..its not an editor and therefore fails to support the code portion of the code/deploy/test/debug workflow. The complexity of AJAX web pages or RIAs is that there are often dozens if not hundreds of source artifacts involved in each single page interface and it is a lot of work just navigating between and IDE and something like Firebug (as rich as the features of Firebug are). My experience with working with Firebug recently, is that it is mentally exhausting to context shift between Firebug and the IDE. It is not an issue of physical context shift (even in the Eclipse solutions there is usually a separate perspective open for the Web 2.0 browser most likely on a dual monitor). Its an issue of keeping a mental mapping of source context in Firebug to source context in IDE. This feature would combine the IDE and the native browser AJAX tools in a decoupled/remote fashion but coordinate the features of the IDE with those of native browser - playing to each others strength. The browser deals with the information model of the DOM and JavaScript combined with the native rendering and the IDE bridges the gap for the developer to the editing context.

The intent of this feature is to provide a qualifying solution for AJAX Monitoring Tracing and Debugging in a way which can be adopted and compelling to a mass of developers truely improving (not just with demo eyecandy) their workflow. Providing a solution integrated with an popular open source platform (Firefox) and capability (Firebug) also yields a channel for NetBeans adoption. This feature can also make use of some contributed plugins to Firefox as bait for AJAX developers to consider the NetBeans solution.

There is preliminary buy-in to an IDE-Firefox/Firebug integration by the Netbeans Lifecycle team, Joe Hewitt (Firefox/Firebug) and Ted Goddard (IceSoft^?); a discussion has started with Ove Ranheim (Opera). Thus far, noone believes this would be a Frankenstein; on the contrary they like the decoupling clearly everyone would prefer to see some conventions emerging.

Additional background on this feature is that the Swing based NetBeans IDE does face challenges to native browser embedding. Beyond the shear engineering cost of developing, testing and normalizing across native components - beyond the issues of IDE stability, resource consumption and download size - there are problems with embedding AWT Canvas components and these issues are not being address until Dolphin. Eclipse works around these painting issues with SWT; however, using the Web 2.0 Browser (ATF derivative) feature in MyEclipse can result in 1GB RSS and unstable IDEs.

There is some promise in the older JDNC effort for a Web Browser component which leverages a native browser installation running out of process to Java VM integrated by a light-weight socket protocol while using a graphics context allocated by the a VM AWT component. However, it is unclear how well resourced and uptodate this JDNC component is and whether NetBeans can reliability depend on it in its architecture. Regardless, JDNC would only be a foundation for an AJAX Monitoring Tracing and Debugging solution because there is still no remote API to the browser internals the risk remains that an IDE centric solution would be more practical than native browser centric solution. The JDNC shows promise (and Rich Unger has demonstrated JDNC running in NetBeans and Dafe thinks it may work with some tweaks), there is still left the job of creating the remote debugger engine and duplicatig all the UI which may already be there in Firebug.

Another motivation to go with a decoupled browser runtime is that via the NetBeans Debugger Architecture developer solutions for heterogenous debugging and concurrent debugging should work well. That is, a developer can be debugging a Java servlet/EJB/WS on the server or an applet on the same single page interface while also debugging AJAX. In fact, given this feature, the developer can debug two different single page interfaces at the same time potentially (the debugging architecture supports that).

2. Description

In this feature the IDE would delegate debugging to native browser debugger, Firefox/Firebug initially using a connection/protocol to the browser hosting a light-wieght Http micro-middleware. However, there would be an explicit "attach/run-in-debug" semantic similar to other remote debugging solutions making it very clear that the IDE and the debugged platform (the browser) are decoupled. This may require a pseudo AJAX Debugger Session to fit into the NetBeans architecture. This solution combined the superior editing and source artifact organization features in the IDE with the slick debugging features in the browser.

The best approach, especially one which may be IDE agnostic or portable to other browsers, is not known while leveraging JavaScript(JSON)/E4X and conventional Http micro-middleware seems attractive. The goal is that the browser side plugin makes this seemless and unobtrusive (like with Firebug.

There is an inherent "chicken and the egg" issue wrt to breakpoint (a classic debugging issue) injection in a solution like Firebug. Once all the JavaScript sources are available after a page loads (or has sufficient gestures applied) the Firebug user can navigate the source in the Debugger view and set breakpoints. The problem is that this is after the page has loaded and started running in many cases. If a Breakpoint Model in the IDE can be sync'd with Firebug - that is, FireBug can bootstrap its internal breakpoint model from the IDE then it can trap early, again, improving the developers productivity.

A challenge in this solution is that the source code artifacts in the IDE may not be easily correlated to script source in the browser. This may require a user intervention or a quick and dirty free-text search for matcing lines of JavaScript. Also, there may be script source in the browser which has no correlation to source in the IDE. Similar challenges were faced in BPEL debugging efforts where it was not always the case that sufficient metadata was available from the debugging engine to correlate to src artifacts - and in that case the source artifacts were very strongly typed and structured. The solution was to ensure that the BPEL runtime had sufficient metadata cross-referenced in the runtime model. That may not be possible here with AJAX client side. As with Firebug there is no 100% solution. Closures work strangely during debug and immediate JavaScript which is dynamically evaluated is not currently debuggable (although that may be a limitation with Firebug).

It is unclear whether the remaining, conventional debugging models and views such as CallStack or Local Variable should be sync'd in the IDE. Would it be helpful to the developer in the IDE? How costly would this be? While a Callstack model and view would be very simple (and very nice to be able to have a green line annotation in the IDE source pinpointing where the debugger is) the concept of this feature is to reduce the UI effort in the IDE delegating that to the native browser tool (Firebug). There has not been consideration for this in analysis of this feature thus far but it is prudent to consider these may be come necessary if it improves the developer workflow.

It is unclear whether the navigation from the IDE to the browser is necessary in this feature (i.e. "Goto->Browser Source" or "Show in -> Browser View Source" but it is assume that navigation in both direction is helpful.

A secondary but optional aspect to this feature is to integrate with an IDE agnostic contribution to the AJAX community. A contribution in the form of an AJAX/!JavaScript library or browser plugin would not only be contribute to the NetBean AJAX solution but work as an adoption channel and means of NetBeans participating in the AJAX community. For example, an IDE agnostic Firefox capability provided by NetBeans community would be a good channel to NetBeans for the AJAX developer and establish NetBeans as a player in the AJAX space and Firefox community - much in the same way we collaborate with Ant/Maven/Subversion open source communities. If we create a compelling but simple (low cost to us or derivative of our primary AJAX solution) AddOn to Firefox which becomes popular in the Firefox community, then the Home Page for the AddOn could be a site at netBeans.org or java.net driving further interest in Sun, Java and NetBeans technology. Two for now to consider:

• "UnderFire" or "FoxChase" or "RedFox" Addon provides an innocuous tool in Firefox which can be toggled (like Firebug or perhaps just an improvement to Firebug) which when engaged will "summarize" or "classify" or maybe even "profile" a web page in terms of what capabilities it uses, how it performs, and how the page can be characterized in terms of architecture. Here is an example. While using Firebug go to Google Maps and notice in the console of Firebug you see traces of XMLHttpRequest dispatches. What is interesting is that if any site (e.g. Google Mail) is using http long polling, Http tunneling or some COMET implementation you can start to see this in the HTTP tracing. For example, in Firebug open or latent requests will show the response as 'Loading....". The new plugin or FireBug capability will produce a summary of how this site works. It may be quite compelling for a developer (and especially someone learning JavaScript) to see how pages are classified.
• Another possibility would be to provide a generic (browser Agnostic) remote "AJAX Remote Agent" non-visual library which developers can temporarily Mashup in web pages during development and testing. This capability is more of a JMX style architecture where a management agent runtime (a micro AJAX engine for management) in the form of JavaScript is injected into a page via a script tag. The AJAX Agent would connect into an XMPP backbone via JEP-124 (standard Http binding protocol for Jabber) thereby allowing an IDE or any UI which is also a XMPP/Jabber client that knows the Agent dialect to interact with the AJAX Agent, remotely monitoring, tracing and potentially debug the single page interface.

3. Competitors

Eclipse has a duplication of Firefox's DOM Monitoring Tracing and Debugging directly in the IDE via an Eclipse based UI and embedded Mozilla XUL runner.

Any attempt by the IDE to offer solutions for AJAX Monitoring Tracing and Debugging competes directly for developers attention to solutions like Firebug and similar plugins and native browser tools.

4. Effort estimation

An initial solution of correlating source navigation in the IDE with debuggable and monitored source artifacts in Firebug and coordinating a pseudo AJAX debugging "session" where debugging models for BreakPoints are sync'd between IDE and Firebug would require 1.5-3.0 engineering resource for the full Promotion lifecycle. With full engineering resources (3.0) the optional Firefox Addons, AJAX AJAX library and/or deeper sync'ing of IDE Debugger model/views could be approached.

5. Dependencies

This feature would have dependencies on a specific browser runtime (e.g. Firefox/Firebug) and the dependencies may present risks of compatibility as browser versions and plugin versions evolve - if there is not architectural contract in place.

6. Impacts

6.1. Architecture

This feature aligns well with NetBeans Debugger Architecture.

6.2. API

This feature may expose "interfaces" in the form of some Http micro-middleware which is used between the IDE and the browser. The intent is to reuse a conventional or standard based solution.

6.3. UI

This feature would leverage the existing UI of debugger architecture.

6.4. Documentation

User documentation will have to be created / edited.

6.5. Testing

Regular internal and community testing intended. Unit testing would be a challenge here as with any client server solution which is difficult to drive in an automated fashion. The assumption is that a testing harness would use XUL Runner and be scripted.

6.6. Performance

Performance should not be affected as the data model for debugging session in the IDE would be very small.

7. Risks

There is natural risk to IDE stability (AWT hangs) whenever middleware and remote protocols are integrated as part of UI.

Unit testing may be a challenge.

Having embedded language use cases may present issues for debugging breakpoint models. For example, the JSP debugger. Would it work and play well with a concurrent AJAX (JavaScript) debugging session which also wants breakpoints in the same file?

8. Additional information

See Analysis of native browser integration with FireBug and feedback from Firefox engineer.