I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Galileo Podcast Series: Rich Ajax Platform

  • submit to reddit
Artist:DZone Plays:55
Length:34:07 minutes (31.24 MB) Downloads:16834
Format:MP3 Stereo 44kHz 128Kbps (CBR) Download:Click to download

About this podcast

In the next part of our series of interviews with the people behind of some of the projects on the Galileo release train, I talk with Jochen Krause, the co-lead of the Rich Ajax Platform (RAP). We discuss what RAP is, what single-sourcing is all about, and how RAP can reduce both the visual and technical complexity of your projects. 

James Sugrue: Could you introduce yourself to the listeners, please?

Jochen Krause: My name is Jochen Krause. I'm the CEO of EclipseSource. EclipseSource is a company, obviously, focused on Eclipse. And so it came up from Innoopract, a German company, and Code 9, a Canadian company. Those have been involved with Eclipse for many years, and joined forces to be one of the leading sources of Eclipse know-how and services and products around Eclipse.

Sugrue: Has EclipseSource been around for long?

Krause: EclipseSource is pretty new. We announced it six months ago. Innoopract has been around for more than 10 years, and so we do have some history.

Sugrue:  And have you always been involved in the RAP project in Eclipse, or were you involved in other projects?

Krause: So we at Innopract started the RAP project, at Eclipse.org. We've been there from the beginning. My colleague, Jeff McAffer, was part of the original team that developed the Eclipse code base. It was made open source later. I think we joined Eclipse one year after its inception in open source. So, we've been around in Eclipse since many years now.

Sugrue: Could you describe the Rich Ajax Platform to us?

Krause: RAP is a project that aims at providing Eclipse technology and Eclipse modularity for web applications. We've been involved in web technology since the end of the '90s, and we were very impressed with the modularity and extensibility of Eclipse. And when Ajax became more mainstream and the browser implementation more stable, we saw that an Eclipse-style UI could also work in the browser.

Then we did some very serious testing and proof-of-concept development, and we came to the conclusion that it is feasible to do that, and that's how we started the RAP project at Eclipse in open source. That's three years ago now.

Sugrue: There's been a lot of advancements in web technologies in those three years, hasn't there?

Krause: Yeah, it's amazing. So, many of the things that we initially thought would never be possible on the web are now simply working.

Sugrue: It's brilliant to think how far we've come. So, if I have an RAP application, do I need to have my server set up in a particular way?

Krause: From a server point of view, that's standard JEE technology, so Servlet technology. You should have a Tomcat or Jetty or WebSphere, WebLogic, or whatever your favorite app server is, should be the right choice for RAP. We simply need Servlet specification 2.4, and I think that's a pretty decent requirement nowadays.

Sugrue: If that's all you need to do, that's a really good thing. What have the latest additions been to the RAP project for this release?

Krause: We've been working on two main priorities. The one was to make it easier to single-source applications for desktop and web. So, many people are familiar with Eclipse RCP that is providing an application platform to develop any kind of application for the desktop, using the Eclipse paradigm, extension points, all the great things that we know from Eclipse. And many people are interested in bringing at least parts of their RCP applications into the web. And we enable that, because we implement most of the Eclipse RCP APIs; but not all of them. And so one of the priorities for the Galileo release was to find out in which areas it is difficult to use a single code base for the web and the desktop and make that easier. So, that has been one of the priorities.

A second priority: If you look at RCP applications, or simply at the Eclipse IDE, it's pretty overwhelming for a user, especially if you imagine to have that app one-on-one in a browser. So, in a browser, people are used to less visual complexity. And so, there was a challenge of reusing the code on the one hand, but on the other hand providing a UI that's more suitable for the browser.

And that has been the second barriers where we've been putting in a lot of work and working with usability experts to find a way to bring RCP-style apps to the web. And at the same time, we wanted to do that in a way that is very efficient for the developer so that you don't need to rewrite the UI. And so, what we came up with is now in Galileo. And most people like it, so I'd say it was at least a big, big step forward.

Last, but not least, performance is always an issue, and we've been working especially on the client-side performance. On the server side, we're already very fast. But on the client side, new browsers are pushing forward with respect to performance, but there are still the older versions of browsers still around. Especially the browsers from large, Redmond-based companies are not always very fast when it comes to Ajax. So, we've been putting some effort into making applications better-usable, faster, less memory footprint, with RAP.

Sugure: Sounds like you've been very busy. Are there some components in RCP that I can't get in RAP or that I'll never get in RAP?

Krause:  I'm careful with the word "never." But there are a few things that don't make a lot of sense. For example, all kinds of events that occur extremely often, for example, mouse move events. So event processing in RAP by default is happening on the server. So if something is happening on the client, we send it for processing to the server. Now, if you imagine mouse move events, like they happen with every little mouse move so it would be a lot of events and you get the latency between the client and the server and so that's nothing that would work too well.

So, out of the box, we also do not support drawing. Some of the more complex widgets in SWT are not created using native widgets of the operating system, but they are created by drawing on the screen, on the canvas. And that's an API that we currently do not support. We do have support for draw, but we don't expose those at APIs because it can easily lead to UIs that are very resource intense on the browser.

Sugrue: It seems that you think a lot about the components that you would provide in RAP from RCP.  At last year's Eclipse Summit, one of my favorite talks was the one about single sourcing applications. Maybe you could explain a bit about the single sourcing term.

Krause: That's funny because single sourcing is usually used in a different context - more by purchase departments than by software engineers. But, we like that term and we started using it for using the same code base for desktop and web applications or other terms. Most approaches didn't work in the past and there is a limit. So, most people are trying to generate different UIs from exactly the same code base and we don't think that this is the right approach. So, we want to get with single sourcing to a really, really large common code base, but it's not identical to our different use cases in a browser and on a desktop.

For example, how do you handle storage of data? Are you accessing local things? Are you accessing things on a server? So, what does it mean to open a file? Do you open a file on the server? Do you upload a file to the server? And those semantics are sometimes different and that's why some differences are usually needed or, in many cases, needed.

And Eclipse and OSGi provide the mechanisms to do that in a really elegant way. And that's basically what the term single sourcing describes. It's a set of best practices and, obviously, the capability to reuse a really big chunk of your code for both desktop and web.

Just to give you one number, we've been working with the Eclipse memory analyzer team from SAP to see how complicated it is to get the memory analyzer also working in a browser. I think that's a great use case because heap dumps a memory analyzer can work with are very often very big.

And if you analyze server heap dumps, if you don't need to move a gigabyte or multiple gigabytes, they heap dump to your computer, but instead analyze it close to the server where it was taken from, then that's a really great use case. And we achieved code reuse of 98.4% and 1.6% needed to be different between desktop and web.

Sugrue: That seems very, very reasonable, doesn't it? I mean, to go over 90% I would have thought was a huge achievement.

Krause:  And your mileage may vary depending on how different your web needs to be from the desktop parts. But, you can get very, very far.

Sugrue: And I know that you've got an upcoming event on Eclipse Live about how to extend your RCP application to an RAP application, but maybe you could bring us through some of the steps that I'd need to go through if I wanted to bring my OCP application to work on the browser - just like you did with the memory analyzer team.

Krause: It's pretty simple to get started. So you obviously need to download RAP and install it. With Eclipse, you can do that through Galileo. You can download the target or tools - we recommend installing the tools from the RAP web page into your Eclipse. And then you have an icon on the welcome screen that guides you through the necessary steps to make RAP available as a target. So, those people who have been working with RCP probably know what a target platform is. People who have mostly developing Java code with Eclipse are not that familiar with that word. It's basically the environment that is used to start your application with.

So, we install the RAP code as the target. And as soon as you do that and set this target to compiler, it compiles your code against the RAP code base. And what you very likely are going to see are some compile errors because we implement a lot of the API but not the complete API. So, you get a direct feedback of what's working and what's not working.

Sugrue: You mentioned that there are tools that you can get to help with your RAP development. What type of tools are they? Mostly wizards and things like that?

Krause: Yes. It's a very simple wizard that helps you set up the target and beyond that, you can basically use the same tools that you used to develop RCP apps. So, you use the PDE plug in, or bundle editor, you use the Java editor, and you get full code insight and all those features are simply working out of the box. You developed that application just as if it were in RCP app so you have that full tool support. We also have tool support for running the application. In Eclipse, there's a small J2EE Servlet container embedded. So, you can start the application from the workbench and simply run it. So, that's the kind of tools that we provide. We don't provide a visual editor for the UIs. But, you could, for example, use commercial tools or open source tools because the code is identical.

Sugrue: There's no tool that exists that converts RCP classes or an RCP application into an RAP application?

Krause: No, there is no conversion necessary.

Sugrue: So is it because I'm using a different target that's it works?

Krause: Yeah, exactly. You use a different target, but otherwise no conversion. And the rest is really a set of best practices. For example, how do you handle the non-identical code? Yeah? The identical code, that's easy. But, how can you handle code that is not identical between RCP and RAP? So, we propose that you use fragments for that. That's an OSGi approach. That, for example, SWT is using. So, you've got SWT has a so called host bundle and then one fragment per operating system. And in that sense we propose to handle the desktop and the web as different operating systems. Which I think the analogy is quite OK. And so you separate the OS specific code and fragments.

Sugrue: It sounds like it isn't that difficult at all.

Krause: No, it's not. That's a common problem, people install RAP and then the target platform is set to the RAP code. And now they get compile errors and some people don't know the way back and they are afraid that their project is broken. So, it's very simple if you go to the Eclipse preferences and search for target, you'll find a preference page for the target platform. You simply reset that to the current Eclipse installation. That's the default. So, pointing basically to the installation that you're using as the default in Eclipse as a target and you simply reset to that target platform. Then all your compile errors will go away and nothing is happening to your project code.

Sugrue: OK. Great. And are you finding there's a lot of commercial use of RAP at the moment?

Krause: There is some prominent use and there is some use that you don't see in the public. So, we're pretty happy because basically every day a new use, we get to know a new use of RAP almost every day. There is one I think pretty impressive sort of success story, that's a German CRM vendor that's providing a software as a service offering based on RAP. It's called PIA. It has a really impressive UI and it's a full fledged CRM system. So that's very nice. That's very visible.

We know of many larger companies using RAP. For example, in the context of tools that they are providing on the web, some people are using it to extend the reach of their business applications to the web. And if you follow the RAP newsgroups, you'll see that there's a lot of traffic. And if you read close enough you'll find, like you'll see that there are many applications out there.

Sugrue: And what are your plans for it the next year now that the Galileo release is all looked after?

Krause: Yeah. At Eclipse, we usually plan in terms of priorities. We haven't done that for our upcoming release. But, one topic that is ranging really high on our minds is a new implementation of our client side widget toolkit, which shall provide GWT like features. So basically, you should be able to compile your code into JavaScript and run it standalone on the client so that you can build like richer components or custom widgets completely in SWT. Or you could build a calculator completely in SWT and it would run entirely on the client. And there are other use cases where it makes a lot of sense to process the events on the server.

So, that will provide more flexibility to the developer. More control on where he's processing the events. So, that's one item that we are very likely going to address. And otherwise, we'll focus on making E4 available in a browser as well. So, that's a second priority. And RAP is a target platform for E4 and you can be sure to hear more about that in the coming months.

Sugrue: That was actually one of the things I was wondering about, was what happens to RAP when E4 does come along. So you're working very closely with E4?

Krause:  Yeah. We've been involved since the beginning. We haven't been extremely active contributing to E4. So, you could compare E4 to RCP when it comes to the platform part. So, we provide the RCP APIs and you will be able to run the E4 APIs on the web based on RAP. So, we've been contributing in some areas, for example, when it comes to multi-locale. If you have multiple users, that's a challenge that we currently have. There are other challenges, for example, regarding the handling of jobs from multiple users. Those are areas where we contribute. We have been active in the discussion about styling because you can style RAP applications with CSS.

That's something that we want to introduce for E4. Or that has been introduced for E4. And those are the areas where we have contributed, not a lot in code, but yeah, being around and now we're getting to basically deploy that E4 code on RAP. We made some progress, but we don't want to disclose too much yet, because that will be the first thing after Galileo that we will talk about.

Sugrue: What are you looking forward to in the Galileo release?

Krause: It's incredible that Eclipse as a community is able to do that kind of the release. I mean today is one day before the release and we know that we will ship in time. So, we are able as a community with its contributors from almost 100 companies to ship a release of millions of lines of code. I think we are in the area of three times more lines of codes than Open Office and four times more codes than Linux kernel. And, we are shipping that in time every year. I think that's very impressive. Feature wise, there is so much going on that is really hard to pick your favorite. What I like is the run-time part, where, for example, EclipseLink is part of the Galileo release, if I am not mistaken, it was its first time. So, we have object relational mapping now available. So, there have been some really cool improvements on in the modeling land. There are so many areas now and everybody or many people are making a lot of progress.

So, I think it's a really incredible stack of technology that you can get from Galileo. But, I don't recommend getting everything at once because we cover so many areas that an all-in-one doesn't really seem to make sense.

Sugrue: Yes, I'd agree with that. It's better to take it in chunks. Have you noticed any changes in the Eclipse ecosystem in the past year?

Krause: Yes absolutely. I think the Eclipse ecosystem is changing and I am pretty outspoken with respect to that. The initial business model for the Eclipse ecosystem was to share research and development cost and make money on selling tools that are build on the commonly developed platform. So, that worked its first couple of years, but as a matter of fact open source is in many cases today good enough for the tools that developers want or need. So, like financing the R&D is that you put into Eclipse through product sales has become much more complicated. And, that's why the Eclipse ecosystem has to change or is changing. And we are seeing that change happening. Eclipse is great and providing niches for many, many companies and they make money with it. One of the problems that I personally see is that many of the smaller companies that work in those niches have a hard time contributing back to the platform.

 So, it's really hard to develop a platform with 1000 people that have three days per year. So, the large companies that provide three people full time for one year, that's a kind of optima that you need to develop a platform. And it's great to see that we have found new, very serious contributors in Oracle and SAP, next to IBM, and they both have those strategies around contributing to Eclipse.

This is one change that has been happening over the last two years let's say. And, then another change is that companies like ours that is very, very involved. We lead or co-lead 11 projects at Eclipse. We contribute a lot to Eclipse code base and so we are providing services, maintenance, support for Eclipse, which is something that you couldn't get earlier.

And we are seeing other companies doing the same, for example, for the modeling space, for the platform approach in the search area at Eclipse, and there is another company like trying that business model with maintenance and distribution and support in that area. So, that's a new model that is coming up and I think that is very interesting, and it's providing you opportunities. And, Eclipse is used in so many companies now that really rely on Eclipse, that this is a really interesting market.

Sugrue: I think that's probably where Eclipse is going in the future. And, you can definitely see how this is working and how much it's been adopted in the industry by the Eclipse banking days and Eclipse in better days. They are very, very popular; they are always at full capacity. I's a good sign. So, what are the most interested uses of Eclipse that you have seen?

Krause: So, one of my favorites obviously is the CRM systems that's build on RAP. It's very impressive, because if you simply see it you don't think it's a web application. So, you really get a desktop usability in the browser; I have to admit that is my favorite. But, in general, Eclipse as a platform for in verticals, that's very, very powerful. I've seen a few implementations that in large companies where people build their own platform based on Eclipse, which is really, really impressive. So, those are use cases that I find very compelling.

Sugrue: Yes, definitely it's the most interesting type of thing. But, you just are seeing Eclipse pop up so many different places these days that it's very encouraging. Sometimes you don't even know it's Eclipse

Krause: Yeah it's true. I was very amazed when I saw the latest Adobe products. And, like you said it could be buildt on Eclipse, but it's looking so great. Is it really built on Eclipse? Now, I know that is built on Eclipse, but it's almost impossible to see it.

Sugrue: So, it's been great talking to you and I look forward finding more of those E4 in the coming weeks from you. But, best of luck with the rest of your work on the RAP project and it seems to be going brilliantly.