Eclipse RAP (Rich Ajax Platform) in the real world is covered in this case study which looks at how CAS Software AG used RAP on a recent new product offering. Eclipse Equinox is also used by CAS and covered in the case study. By making use of Eclipse RAP for the user interface, CAS was able to provide a desktop-like experience which quickly allows users to feel comfortable with the application. The user interface is designed with ergonomics in mind, making use of familiar widgets and behaviors such as drag and drop, all things users expect even from web applications.
Read Case study: Eclipse Rich Ajax Platform Use at CAS Software AG
Eclipse RAP was utilized as the user interface in the presentation layer for CAS PIA for several reasons:
- Look and Feel - they were able to build very rich, ergonomic, theme-able interfaces that were difficult to distinguish from a thick client.
- Development Efficiency - the AJAX and JavaScript is baked into ready to use components which is hidden from the developer, allowing developers to code in Java with their familiar libraries and IDE.
- Flexibility - although RAP allows developers to stay away from writing JavaScript, HTML and CSS, it’s flexible enough so that custom components and styles could be added without any issue.
- Engineering Quality - Eclipse and their products employ best practice software design and practices, no exception with RAP.
- Single Codebase - RAP can be compiled into an AJAX or RCP application.
The presentation layer also consists of an OSGi runtime which provides modularity and reusability amongst other CAS products. CAS chose the Eclipse Equinox project as their implementation provider for OSGi and is defined as:
...an implementation of the OSGi R4 core framework specification, a set of bundles that implement various optional OSGi services and other infrastructure for running OSGi-based systems.
More generally, the goal of the Equinox project is to be a first class OSGi community and foster the vision of Eclipse as a landscape of bundles. As part of this, it is responsible for developing and delivering the OSGi framework implementation used for all of Eclipse.
The case study zooms in how they unit tested their Eclipse RAP components, created custom user interface components, issues they experienced during development, and their lessons learned.
Community comments
from server to client actions
by Alex Ignacio da Silva,
Re: from server to client actions
by craig w,
Re: from server to client actions
by Christian Janz,
from server to client actions
by Alex Ignacio da Silva,
Your message is awaiting moderation. Thank you for participating in the discussion.
"The only feature CAS hopes RAP will provide in the future is the ability to trigger actions in the client from the server."
Could you please give an example of what kind of such features you would like to implement that isn't now possible with RAP? I once made a prototype application that could send server notifications to the client from time to time, which the client displayed on its status area.
Re: from server to client actions
by craig w,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Alex - someone from CAS should be posting a response soon.
Re: from server to client actions
by Christian Janz,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hello,
thanks for your comment. The quote "The only feature CAS hopes RAP will provide in the future is the ability to trigger actions in the client from the server" is a bit misleading. RAP provides the so called UICallbacks which allow the server to push information to the browser client. In CAS PIA we use UICallbacks for several features, e.g. notifying the user about a newly arrived e-Mail.
In (local) testing environment the UICallbacks work well, but in production scenario there arise some problems with them: For example the client-side request needed for the callbacks is blocked by some HTTP proxies. A second problem is that long-running callbacks (for example the mail notification callback) can "die" because of connection losses or protocol timeouts. Because RAP uses one XmlHttpRequest for all registered UICallbacks and because this request isn't restarted after interruption, all data sent from server to client by all the different callback actions doesn't arrive at client side any more.
In summary for short-time server-to-client-actions we still use the RAP UICallbacks, but we avoid long-running ones.