In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.
One of our goals for RAP 1.5 is to open the framework for alternative client implementations. After all, the messages from the server contain precise rendering commands that are not at all specific to JavaScript. Commands like “create a button with text ‘Ok‘, set its size to 190x25px, and place it at pos (23,42)” or “change the text color of the label with id ‘w47‘ to ‘#ff0000‘” can be rendered by any client that is able to create and manipulate widgets. It doesn’t have to be a JavaScript client, also clients written in other languages like Java or Objective C can implement it. Clients can render widgets with any UI technology, be it SVG or even a mobile device’s native widget set.
To allow for those cases, we exchanged the communication format with a simple predefined format based on JSON. With the M4 build published today, all responses from a RAP server are now plain JSON. This also makes the debugging much easier, since developer tools like Firebug display the structure of a message.
When designing the protocol, we took great care not to limit the exchange format to widgets. Instead, we created a generic synchronization protocol for any kind of objects. Objects are identified with a unique id, and every operation is related to a target object that is referenced by its unique id. There are different types of operations: one to create an object, one to destroy it, one to change some properties on an object, etc. Every message from the server contains a list of operations, besides some meta information.
You’ve guessed that we already have some prototypes for alternative RAP clients in progress. We’ll write about them soon…
With summer behind us and autumn almost here (in the northern hemisphere), you can feel the change in the air.
The Eclipse and Equinox teams have made Juno Milestone 2 available, however, these milestones are no longer based on the Eclipse 3.x stream. Starting with this milestone, we will be encouraging users to actively test the 4.2 stream. The Eclipse Juno release (coming June 2012) will be based on the 4.x stream.
There are a few goodies in this release including Quick-Fixes for loop refactoring:
Computer cluster, taken from http://thefullwiki.org/Parallel_programming
While most of us are busy with that latest bits of the Indigo release, some have the joy to work on one of the next new features in RAP: support for high availablity clusters.
Let me briefly mark out what we mean by clustering support and what we don’t. Load balancing clusters are used if you whish to provide your applications to a large number of users. If your application provides critical servies you may also want to make it fail safe by running it in a high availablity cluster.
A high availability cluster operates by having redundant nodes. So that if one node crashes, the service as a whole is unafected as other nodes take over the work. Whereas load balancing RAP applications is possible since ever, failover clusters put further requirements on the framework.
To be able to migrate sessions between nodes in a cluster, all session data has to be serializable. Also, the current implementation preserves the server-side execution flow within a UIThread in order to single-source RCP applications. These two form the main work areas.
All session data must be prepared for distributing sessions among cluster nodes for failsafe operation.
A new life cycle for processing requests without a UIThread was implemented and RAP can be configured to run with either of them.
The new life cycle also makes it easier to access security or transaction contexts and is conform to the JEE Specification. If you don’t use blocking dialogs or workbench features and want to be able to eventually run your application in a cluster – then this is for you.
We are a team of dedicated project leads, committers and enthusiasts who have developed innovative training, products and solutions for people working with the Eclipse runtime stack.
If you need to move forward quickly with the Indigo release, or maintain older releases for a longer period, we can help you develop and implement an optimized migration strategy.
