Introducing eclipse rap


Published on

Introducing eclipse rap

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 1. First of all, what is Eclipse RAP? It’s the Eclipse Rich Ajax Platform 2. It allows you to build web app “the Eclipse way” 3. RAP is to the web as RCP to the desktop. It inherits all the goodness from building a RCP app, such as extension...SWT/JFace, as you may know, JFace is a layer sits on top of SWT to provide MVC programming model, and of course, the componentied OSGi design that we have talked a lot about in our study group 4. For tooling support, RAP tooling has become a default component of the RCP bundle in Helios, it includes RAP target platform, launching, debugging, exporting war, many many other features
  • 1. As u can see below, the only difference between the architecture of RCP and RAP is the implementation of SWT and RWT 2. but the implementations for RWT are web specific. For example, Display.getDefault() returns a session-based Display 3. No SWT APIs are changed, 4. And RWT is not a patch fragment to SWT, I thought it is a patch fragment, bu some reader of my blog post clarified this with me
  • 1. The RWT client is implemented using the qooxdoo library. Qooxdoo is a JavaScript toolkit with an advanced client-server communication layer. 2. When initializing the page, a static set of JavaScript codes is downloaded by the client. You don’t need to touch any JavaScript code unless you are building customized widgets. 3. That determines the whole RWT architecture is server-centric, I will explain more about it in the next slide. 4. The RWT server is based on server-side Equinox. I give a thumb up on this. With Equinox, building a servlet is a process of building servlet plugins. You specify a path and a servlet implementation, Equinox will glue them together. This is extremely useful in adding/removing restful web services.
  • 1. I find it necessary to explain a little more how RAP is distinguished from other Ajax frameworks. I mentioned that RAP is a server-centric Ajax framework. What exactly is that? 2. In a server-centric framework, all processing is done on the server, the client browser is only used for data presentation. This is different from any client-centric framework such as GWT which compiles all Java widget codes to JavaScript codes and they are downloaded by the browser. 2. In a server-centric framework, the client waits for instructions from the server to create widgets on demand. The server sends a command to the client, and the client finishes the requests. 3. Both framework have pros and cons. Server-centric framework leaves small and static footprints on the browser, have less JavaScript codes on the client, but communicate more frequent with the server. Client-centric is more flexible in implementing the client side codes but requires developers to step deep into low-level implementations of client-to-server communication, e.g., the asynchronous callback.
  • 1. Thanks to RWT, RAP brings RCP apps to the web with little code changes. You basically need to make adjustment, such as making your implementation session-based. But you still reuse most of the RCP codes. We call this single sourcing. 2. RAP app also has all the benefits of a OSGi-based app. 2. First of all, building web-app is a process of building plug-ins and bundles. During implementations, you always think how can I make this component extensible, how can I hide this implementation details from other components. Then in the end you build an extensible and highly decoupled web apps. 3. UI side... 4. Server side... 5. Another cool stuff I wanna mention is, OSGi allows you to dynamically enabling/disabling bundles, I am thinking if we need to upgrade a web app, we prob. don’t even need to restart the server. Just pop up the OSGi console, disable the old plugins and enable the new ones. Fascinating!
  • 1. For a Java-based rich AJAX application, testing the UI widgets is always a headache. Like GWT, as far as I remember, testing the widgets has to rely on external JavaScript libraries such as JsUnit. RAP has the RAPTestCase which allows you to test the widgets and layouts. Also all the SWT testing tools can be reused, like Selenium, or SWTBot. 2. Performance... 3. RAP is extremely easy to deploy on an OSGi based server such as the Spring dm Server, now it’s under the Eclipse Virgo project, also it has an embedded Jetty from server-side Equinox. To deploy a RAP app on a J2EE container, you have to include the Servlet Bridge, which distribute requests to Equinox.
  • 1. In this section, I am going to talk about why I chose RAP to implement CodeFaces and my experience of using RAP. 2. First take a look at this requirement, there are four key terms here: an IDE way, explore codes, multiple source control systems, and browser. 3. One of the keys to make this app a success, we can also call it “the domain”, is its ability to adapt to multiple source control systems. We need a framework that can facilitate us to implement such extensibility. 4. extensible system a really common OSGi pattern. It means the ability to add/remove implementations in a system. For example, you can make a menu extensible so that people can contribute menu items to it; Another example is Eclipse, take Mylyn as an example, probably some of you have heard of or are using Mylyn, it has extension points on the issue tracking system connectors, such as Jira or Bugzilla, to its task management UI. 5. Back to CodeFaces, this domain requires us to have the flexibility to extend its functions to multiple source control systems. That’s why we chose OSGi and Equinox.
  • 0. Let’s walk through an example on how to gradually refactor to an extension point. We will take building the scm connector for CodeFaces as an example. I am not sure if anyone is already familiar with building extension points? You specify some input/output in the extension schema, fill in the extensions content in the plugin.xml, and use the Equinox APIs to get back the extension points information. You can achieve highly decoupled system in the end because the control is inverted. I will explain more. 1. The key is to implement the extension points in small steps. Don’t rush to come up with an extension points from the beginning. You may end up with an extension point that is not generic enough for all the extensions. 2. Extension point can exist in places with a strategy pattern. For example, we have different strategies (different algorithms) of SCMConnector in this example, github or subversion. 3. For the first strategy implementation, just leave the strategy in the code. At this point, you should only care about this strategy implementation and try to make the whole system work. Building up the UI, building the backend. You ain’t gonna need an extension point at this point. 4. After you finish building up everything around your first strategy. Then you start to think about the 2nd strategy, for instance, I want a 2nd strategy called subversion connector. Adjust the strategy interface if necessary, build a factory to create this strategy and refer to it by an ID, in this case, the GitHubConnector is referred by its ID “GitHub”. 5. Next you can go ahead and build up the extension point schema, in this example, we know that the input is the connector ID and the output is a SCMConnector implementation. We specify those in the schema. Then we put the extensions in the plugin.xml. In the factory implementation, we read the extension point implementations by using Equinox’s APIs. We instantiate classes as necessary. 6. The last step, and many people may forget about this step, is to refactor the extension implementations out to a new project. Because the strategy implementation is referred by ID, which is a string, in other words, implementations are being pushed to the host, instead of the host is pulling implementations. You are referring classes by an ID. This is very similar to Spring. The host doesn’t refer to any specific implementation of the strategy anymore. The control is inverted. In OSGi world, extensions is an implementation of the inversion of control pattern. And it’s more flexible, you have full control of the creation lifecycle.
  • 1. RAP is not bug free, I fired two bugs when I was using it 2. Building....we built an widget that can make cross domain ajax call, since GitHub has API call limit per IP, we put this limit to the client side 3. Documentations is incomplete for some parts, I spend a lot of time on figuring the CSS for theming.
  • Introducing eclipse rap

    1. 1. Introducing Eclipse RAP <ul><li>Owen Ou </li></ul><ul><li>@JingwenOwenOu </li></ul>
    2. 2. What’s RAP? <ul><li>Eclipse Rich Ajax Platform (RAP) </li></ul><ul><li>build rich web clients “the Eclipse way” </li></ul><ul><li>RAP to the web as RCP to the desktop </li></ul><ul><li>extension point model, event-driven SWT/JFace APIs, componentized OSGi design </li></ul><ul><li>RAP tooling is a default component of the RCP bundle </li></ul>
    3. 3. Architecture <ul><li>only difference is the implementation of SWT/RWT </li></ul><ul><li>RWT is a bundle providing web-specific implementation of SWT, e.g., Display.getDefault() returns a session-based Display </li></ul><ul><li>same APIs as SWT </li></ul><ul><li>not a patch fragment to SWT </li></ul>
    4. 4. RWT <ul><li>client bases on qooxdoo ( /) </li></ul><ul><li>Static JavaScript library downloaded by client (server-centric) </li></ul><ul><li>server bases on server-side Equinox :-), e.g., restful web service </li></ul><ul><li>Java code entirely runs on server </li></ul>
    5. 5. Server-centric vs. Client centric
    6. 6. Benefits of RAP <ul><li>bringing RCP apps to the web with a single code base -> single sourcing </li></ul><ul><li>OSGi & Equinox!! </li></ul><ul><li>a process of building plug-ins and bundles </li></ul><ul><li>UI side: contributing widget plugins </li></ul><ul><li>Server side: contributing servlet plugins (server-side equinox) </li></ul><ul><li>Others, for example, dynamically enabling/disabling bundles, zero downtime upgrade?? </li></ul>
    7. 7. More about RAP <ul><li>UI Testing: RAPTestCase, SWT testing tools can be reused, e.g., Selenium, SWTBot </li></ul><ul><li>Performance: minor drop down due to more frequent communications with the server ( </li></ul><ul><li>Deployment: Spring dm Server :-); embedded Jetty; need “Servlet Bridge” to run on a J2EE container </li></ul>
    8. 8. RAP in practice: CodeFaces <ul><li>Use case: an IDE way to explore codes from multiple source control systems on your browser ( ) </li></ul><ul><li>@JingwenOwenOu & @nondeterminism </li></ul><ul><li>Ages: 7 weeks, 10 - 15 hours per week </li></ul><ul><li>RAP, Ruby/JRuby, Tomcat (Plans: Spring dm, Eclipse Link) </li></ul><ul><li>load balancing on Rackspace cloud </li></ul><ul><li>an IDE way, explore codes, multiple source control systems , browser </li></ul><ul><li>the OSGi pattern: extensible system - the ability to add/remove implementations in a system </li></ul>
    9. 9. Demo
    10. 10. Example: refactoring to extension points <ul><li>Keys: small steps, no rush to make it an extension point upfront, gradually </li></ul><ul><li>Identify your extension points (code smell), for example exists in places with a strategy pattern. </li></ul><ul><li>For the first implementation, leave your strategy in the code (YAGNAEP): SCMConnector connector = new GitHubConnector(); </li></ul><ul><li>At some point, you realize you need a second strategy, adjust the interface if necessary, create a factory, refer to the strategy by a String, e.g., an ID: SCMConnector connector = SCMConnectorFactory.create(“GitHub”); SCMConnector connector = SCMConnectorFactory.create(“Subversion”); </li></ul><ul><li>Build up the extension point schema, put extensions in plugin.xml, and in the factory, use Platform.getExtensionRegistry() to read extension point implementations. </li></ul><ul><li>Refactor the extensions out to a new project if necessary. Control is already inverted. Highly decoupled system is achieved! org.codefaces.core org.codefaces.core.github org.codefaces.core.subversion </li></ul>
    11. 11. RAP in practice: Lessons Learnt <ul><li>RAP is not bug-free: Bug 317685 - Images loaded from ext. points don't work behind session based load balancers Bug 319224 - [UICallback] Hanging UICallback request at startup </li></ul><ul><li>Building customized widget is not easy: qooxdoo to build the widget + how to communicate between the widget and the server </li></ul><ul><li>Documentation is unclear for some parts, e.g., the CSS theming, have to use Firebug </li></ul>
    12. 12. Questions?