Proposal for Rich AJAX Platform (RAP)
The project has been created. Please visit the project page.
The Rich AJAX Platform RAP Project is a proposed open source project under the Eclipse Technology Project.
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology newsgroup.
With the recent ubiquity of AJAX technologies, web applications can provide the user experience end-users have demanded for a long time. Rich Client and web applications are converging with regard to functionality and usability - web applications are becoming "Rich" with respect to UI capabilities, Rich Client applications are offering better deployment and management functionality.
Eclipse has successfully entered the Rich Client world with its Rich Client Platform (RCP). RCP offers a flexible, extensible platform that is operating-system-independent while providing a user experience that is consistent with that of the native operating system. RCP also offers built in functionality to extend and update client installations.
The RAP project aims to enable developers to build rich, AJAX-enabled Web applications by using the Eclipse development model, plug-ins and a Java-only API.
See http://rap.innoopract.com/webworkbench for a demonstration of the usability and look and feel of such an application.
RAP will offer the ease of development of Eclipse, Eclipse extensibility and user experience by reusing Eclipse technology for distributed applications and by encapsulating AJAX technologies into simple-to-use Java components (as SWT encapsulates native widgets).
Web applications remain the appropriate approach for many usage scenarios, e.g. for applications with zero-install access requirements. With centralized installation and administration, web applications offer low administration and production costs. Furthermore, they can provide high scalability and good performance.
But associated with the classic approach of HTML-based web applications is a higher expenditure of resources during the development and maintenance process due to the technology mix that is involved. With AJAX this becomes an even bigger problem.
By encapsulating the AJAX technologies in a component library one major road block to a more efficient development model can be eliminated. By offering a plugin model on the server and providing Eclipse workbench UI capabilities developers can leverage their experience with Rich Client Applications and profit from the proven Eclipse development model to create Rich Internet Applications in a streamlined fashion.
With the proposed Rich AJAX Platform Eclipse enters the Area of Rich Internet Applications.
The objectives of the RAP project are to:
- Enable the development of Rich Internet Applications that are based on the Eclipse Plugin architecture. The Eclipse OSGi framework (Equinox) can run inside of a Web application. This has been demonstrated by several parties, and a subproject of the Equinox project has already been established (see http://www.eclipse.org/equinox/incubator/server/)…
- Enable AJAX UI development based on a Java component library. For enabling UI development based on a Java component library the project will receive a contribution from Innoopract (W4Toolkit), which provides a rich set of UI components, event-driven program control, a generic mechanism for updating arbitrary UI elements of a web UI based on AJAX, and a Lifecycle handling comparable to the one used in Java Server Faces. Furthermore the component library offers a mechanism for browser detection and can adapt to the capabilities of browsers by using rendering kits (NoScript, Script, AJAX). The API of the component library is not identical to the SWT API for historical reasons, but at the MVC level the API is very close to the JFace API. It is a goal to achieve the furthest possible conformance with SWT / JFace.Udate:Based on the feedback from committers and interested parties we are actively researching to adopt a full SWT API
- Provide a Web Workbench similar to the Eclipse platform workbench. As
a third building block for Eclipse-based Web applications, a Web Workbench:
- provides selection service (with session scope),
- provides extension points for action sets, workbench parts, perspectives, preference pages, etc.,
- enables plug-ins to contribute to workbench parts provided by other plug-ins (e.g. action contributions)
- Align RAP API with the Eclipse platform API, work with Eclipse teams to provide consistency for RCP and RAP.
- Work on defining the right split between Plugins with session scope vs. application scope. It is not always obvious if a specific plug-in belongs to the application or user (session) scope, e.g. preferences might be shared between all users of an application (and only administrators could change them) or could be defined (and persisted) per user (this will require authentication)..
What is the goal of RAP?
It is about enabling programmers to develop powerful, AJAX Web applications "the eclipse way" - using the plug-in mechanism, a java widget toolkit and workbench services. - without having to actually hand-code AJAX.
Where does RAP play?
RAP addresses the same kind of applications like RCP, and complements RCP technology with respect to serving as a thin client for distributed applications. RAP is targeted to enterprise applications and can be employed independently of RCP.
How does RAP compare to RCP?
|Plugin Model||OSGi||OSGi on the server (inside a webapp)|
|Widget Toolkit||SWT||WWW Widget Toolkit (W4T)|
|Model View Controller||JFace||JFace (adapted, as standard JFace has references to SWT)|
|UI Framework||Workbench||Web Workbench|
How does RAP compare to the Google Webtoolkit?
The development model of both toolkits is very similar. There are two main differences:
- GWT is running on an emulated java engine in the browser, RAP is mainly running on the serverside and only smartly refreshing the client by using AJAX. As a result eventhandling in GWT is on the client side (+ possible RPC calls to the server), whereas RAP relays most client-side events to the server for processing (solely ui related events can be processed on the client).
- With RAP being mainly server side it can access the full java api and make use of OSGi inside a web container, enabling the full usage of the eclipse plugin model. Applications can contribute to a common workbench and to other plugins. It is not easy to imagine that this can be ported to run in a browser.
Does RAP enable my RCP applications to run on the Web without any changes?
The project aims for enabling as much reuse of RCP application components as possible. However, for the first release of RAP a part of the UI of existing RCP applications needs to be rewritten (which means that core plug-ins can be reused, as long as they are multi-user capable). It shall be possible to reuse Content and Labelproviders.
How are RAP and ATF related?
Why don't you use JSF as component framework?
Because it is not possible - yet. JSF does currently not offer a generic support for AJAX, and although it is possible to use JSF with Java components only, there is no implementation available right now.
We believe that the core achievement of JSF is its Lifecyle handling. W4T lifecycle handling is very closely aligned with the JSF lifecycle handling, and it will be possible to move to JSF in the future.
Can RAP be extended?
Eclipse is about "extensible platforms and exemplary tools" - and we take that seriously. The widget library can be extended with more widgets, much the same way as SWT requires knowledge of the "native" (meaning AJAX) technologies. As the Web Workbench will be built on the plug-in model, it is extensible by design.
The initial committers will focus on evolving and hardening the RAP model by delivering support for Java development. Our agile development process will follow eclipse.org's standards for openness and transparency. Our goal is to provide the infrastructure and APIs needed to integrate task and degree-of-interest-centric UIs to any Eclipse plug-ins whose user-experience information overload. As such we will actively encourage contributions to RAP. We also plan to help improve the Eclipse platform by submitting patches and extension point suggestions. The initial committers are:
- Jochen Krause (Innoopract): project lead
- Frank Appel (Innoopract): lead architect
- Rüdiger Herrmann (Innoopract): AJAX enablement
Innoopract will make an initial code contribution that will encompass some of the core functionality for a Rich AJAX Platform including: " a rich set of UI components with a Java API " event-driven program control " a generic mechanism for updating arbitrary UI elements of a web UI based on AJAX " a Lifecycle handling comparable to the one used in Java Server Faces " a mechanism for browser detection " rendering kits that enable to adapt to browser capabilities (NoScript, Script, AJAX). Developer community We expect to extend the initial set of committers by actively supporting a developer community. Our goal is to have the initial developer community harden the core RAP functionality. As most of our planned API shall be identical to existing Eclipse API, we will make it easy for interested parties to take an active role in the project by making our planning and process transparent and remotely accessible.
Interested partiesThe following parties have expressed interest extending the platform, contributing ideas, guidance and discussion. Key contacts listed.
- iMedic - Stefan Wilczek
- Rahul Mehrotra
- Gunnar Wagenknecht
RAP is a new technology that promises to bring the Eclipse user interface and interaction model to web applications. As such, supporting and soliciting feedback from a large user community of developers is critical to creating a scalable platform and usable UIs. We plan on doing this by using the standard eclipse.org mechanisms of supporting an open project and community of early adopters.
2006-06 v0.1: Java component library for UI development
2006-09 v0.2: Basic WebWorkbench implementation, OSGi running exemplary inside web applications on selected open source servers
2007-02 v0.5: Provide all API for Release 1.0
2007-06 v1.0: Release 1.0