1 / 42

The CloudBrowser Web Application Framework

The CloudBrowser Web Application Framework. Brian McDaniel 5/2/12. Outline. Overview of Web Applications AJAX Web Applications Server-centric Web Applications CloudBrowser Web Applications Demo Implementation Evaluation Related and Future Work Conclusion. Software Trends.

chloe
Télécharger la présentation

The CloudBrowser Web Application Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The CloudBrowser Web Application Framework Brian McDaniel 5/2/12

  2. Outline • Overview of Web Applications • AJAX Web Applications • Server-centric Web Applications • CloudBrowser Web Applications • Demo • Implementation • Evaluation • Related and Future Work • Conclusion

  3. Software Trends • Applications moving from the desktop to the web. • Email (Gmail), Word Processing (Google Docs) • Users expect these applications to behave like desktop applications. • Rich user interfaces; interactivity

  4. Web Applications • The Web wasn’t designed for applications. • Originally for sharing static documents • JavaScript was added to allow some simple interactions with web pages. • The basic building blocks are repurposed to create web applications: • Document - > GUI • JavaScript -> Application Development Language

  5. Web Application Styles • Multi-page Applications • Similar browsing to static documents. • HTML dynamically generated by server. • Each view has a unique URL. • Navigating between views causes a full refresh.

  6. Single-page AJAX Applications • Single-page AJAX Applications • Initial page loaded, then AJAX requests to load additional data and modify view. • Closer to desktop application experience. Server Machine www.gmail.com AJAX Request AJAX Request Request HTTP Server Application Code AJAX Response HTML + JavaScript AJAX Response HTML + JavaScript

  7. Issues with AJAX Web Applications • Client-side state is transient. • Lost on page refresh and navigation. • Reconstructing client-side state is difficult. • No unique mapping of URLs to particular views. • Changing programs requires both client and server programming. • Model-View-Controller pattern is distributed. • Distributed controller logic. • Network programming manually handled by developer.

  8. Server-centric Web Applications Client Browser Server Machine HTML + JS DOM www.app.com HTTP Server Application Code HTML + JS Changes Modifications Events Instantiates Events Components JavaScript Engine Update Instructions Client Engine Events

  9. Issues with Existing Server-centric Frameworks • Client-side state is still transient. • Components instantiated on each request. • Client state must be manually reconstructed. • Difficult to debug due to component translation process. • Designers and developers must learn new markup and programming languages.

  10. CloudBrowser Client Browser Server Machine Client Engine (JavaScript) DOM www.app.com HTTP Server Application Code Changes Modifications Events Loads Construct Instantiates Events JavaScript Engine Virtual Browser DOM Request for DOM Update Instructions Client Engine Serialized DOM Events 10

  11. CloudBrowser • Virtual browser lifetime decoupled from client lifetime. • Clients can disconnect and reconnect – state is saved. • Provides natural co-browsing support. • Server-centric application model for developers. • Client/server communication details hidden from developer. • Applications written in pure JavaScript, HTML, and CSS. • No component translation process. • Allows use of existing client-side libraries. • No rendering/layout computation on the server.

  12. Demo – Meeting Scheduler

  13. Demo – Meeting Scheduler • 66 lines of CoffeeScript, 108 lines of HTML • Leverages existing client-side libraries: • jQuery: DOM manipulation • Bootstrap CSS: styling • Knockout.js: data bindings and templating • Moment.js: time strings • Co-browsing based application. • Real-time collaboration for free.

  14. Demo – Meeting Scheduler • Creating the “possible times” list: model = ... possibleTimes:ko.observableArray() ... <divid='timeList'style='padding-top: 20px'> <h4>Possibletimes:</h4> <ul data-bind=“foreach: possibleTimes”> <lidata-bind="text: $data"></li> </ul> <buttonid='send-mail'class='btnbtn-primary' data-bind=‘visible: possibleTimes().length != 0’> SendReminderE-mail </button> </div>

  15. Demo – Meeting Scheduler • E-mailing participants: smtp=require('nodemailer') smtp=nodemailer.createTransport'SMTP', service:'Gmail' auth: user:'cloudbrowserframework@gmail.com' pass:'topsecret' $('#send-mail').click()-> forpinmodel.participants() addr=p.email() continue ifaddr=='none' msg="Hey #{p.name()}, here are the available times:\n" msg+="\t#{time}\n"fortimeinmodel.possibleTimes() mail= from:"CloudBrowser <cloudbrowserframework@gmail.com>" to:addr subject:"Available Meeting Times" text:msg smtp.sendMail(mail)

  16. Storing Model Data • 3 ways: • All data in virtual browser. • ex: meeting scheduler • Shared data as JavaScript objects, accessible from multiple virtual browsers. • ex: chat room application • Traditional means, such as a database or file system. • Useful when model storage needs to be scaled.

  17. Implementation • Implementation Platform • Processing Client Events • Synchronization Protocol • Detecting Virtual Browser Changes • JavaScript Execution

  18. Implementation Platform • Node.js • Built on Google ‘s V8 JavaScript Engine • One language client- and server-side • Automatic integration with virtual browser • Large library ecosystem • JSDOM • Node.js W3C DOM implementation • Socket.io • 2-way socket connection between browser and server

  19. Client-side Events Client Browser Server Machine DOM HTTP Server Application Code Changes Modifications Events Events JavaScript Engine Virtual Browser DOM Update Instructions Client Engine Events

  20. Processing Client Events • Block client-side event processing. • Register capturing event listeners on those events. • Call event.stopPropagation(). • Call event.preventDefault().

  21. Synchronization Protocol Client Browser Server Machine DOM HTTP Server Application Code Changes Modifications Events Events JavaScript Engine Virtual Browser DOM Update Instructions Client Engine Events 23

  22. Synchronization Protocol:Communication • We establish RPC endpoints on the client and server.

  23. Detecting Virtual Browser Changes Client Browser Server Machine DOM HTTP Server Application Code Changes Modifications Events Events JavaScript Engine Virtual Browser DOM Update Instructions Client Engine Events 25 25

  24. Detecting Virtual Browser Changes • Changes detected using aspect-oriented programming. • Add wrapper methods (advice) around DOM manipulation methods. • Example: varoldMethod=DOM.Node.appendChild; DOM.Node.appendChild=function(){ varrv=oldMethod.apply(this,arguments); browser.emit('DOMNodeInsertedIntoDocument',{ target:arguments[0], parent:this }); returnrv; };

  25. JavaScript Execution • Each virtual browser needs a faithful JavaScript environment. • Must match existing browser environments. • Required to run existing client-side libraries. • Node.js doesn’t expose an API to provide isolated execution environments with the right semantics. • We wrote Contextify, a C++ addon for Node • Adopted upstream by JSDOM.

  26. Evaluation Goals • What is the latency cost of processing events on the server? • What’s the memory cost of instantiating virtual browsers on the server? • What’s the memory cost of adding additional clients to a virtual browser (co-browsing)? • How good is our DOM implementation?

  27. Evaluation Setup • Hardware: • Server: 2- 2.5 GHz quad-core processors, 16 GB RAM • Client: 3.00 GHz quad-core processor, 8 GB RAM • Connected by gigabit LAN. • Can’t use traditional benchmarking means. • CloudBrowser isn’t stateless. • We want to simulate user interactions with a virtual browser.

  28. Latency • Response times (Nielson, Usability Engineering) • < 100ms: feels instantaneous. • < 1 second: noticeable, but doesn’t interrupt workflow. • Keynote Internet Health report considers latency < 90ms between backbones as “good”. • Ping from Blacksburg to Austin, TX (measured by me): • ~60 ms

  29. Latency • Experimental setup: • Scripted client: • Connect to a new virtual browser. • while !done • Start clock. • Send a precomputed event. • Wait for response. • Stop clock; compute latency; save in results array.

  30. Latency

  31. Latency

  32. Virtual Browser Memory Usage • Question: what’s the memory cost of a virtual browser? • Experimental procedure: • Connect a client to a new virtual browser (cause allocation). • Force a garbage collection. • Collect V8 heap memory usage (Node.js API)

  33. Virtual Browser Memory Usage • Effect of JavaScript: • jQuery: 1.05 MB • Knockout.js: 0.33 MB • Moment.js: 103 KB • Effect of CSS: • Bootstrap: 820 KB

  34. Additional Client Memory Usage • Question: what’s the memory cost of adding clients to a single virtual browser? • Experimental procedure: • Connect a scripted client to the virtual browser. • Force a garbage collection. • Collect memory usage. • Result: ~16 KB per connected client

  35. DOM Conformance • jQuery Test Suite Results

  36. Limitations with CloudBrowser Approach • No access to computed layout • Can’t support libraries that rely on client-side layout information. • element.offsetWidth, element.offsetTop, etc. • CSS3 can eliminate this need for many use cases. • Latency-sensitive applications (e.g. games) • Not every application should be a CloudBrowser application.

  37. Limitations with CloudBrowser Implementation • DOM conformance • Lacking support for browsing pages in the wild. • As JSDOM implementation improves, so does CloudBrowser. • Multi-core scaling • Node.js is single threaded. • Need to distribute framework to multiple procceses. • Initial implementation done, but requires improvement.

  38. Related Work • ZK • Server-centric, Java-based framework. • Uses components; instantiated on each request. • ItsNat • Server-centric, Java-based framework. • Uses a DOM on server. • Applications written in HTML, CSS, and Java.

  39. Future Work • Multi-process scaling improvements. • Improved CloudBrowser API. • Improved DOM conformance. • Virtual browser management: • Persistence • Garbage collection

  40. Conclusion • CloudBrowser is a server centric web application framework where applications run in virtual browsers on the server. • User interface state is automatically preserved across navigation, refresh, and disconnection. • CloudBrowser introduces acceptable latency and memory overhead for many use cases. • The distributed nature of web applications is hidden from developers.

  41. Questions?

  42. Scaling to Multiple Processes Front-end Server app1 Server (multi-process) Virtual Browser pipe Virtual Browser pipe ClientBrowser Virtual Browser pipe app2 Server (single-process) Virtual Browser Virtual Browser

More Related