Hi,
Few words on our new Java-RPC implementation :
We are in the process of delivering a qooxdoo contrib for a new Java-RPC.
The contrib name is not set.
Should it be "Java RPC 2" ?
* Allow extra params to be added or removed on the servlet (or a filter),
before reaching the Controller.
You could manage the login/password at a generic level, so even if you pass
that 2 params on client side,
that 2 params won't be seen in the Controller.
This 2 params could be consumed in your authentication servlet.
* Param could also be pass to the controller without having beeing passed by
client side.
This allow us to pass a transaction manager from OpenJPA to all method of all
Controller.
* 2 times quicker than current implem on our very first small tests.
* based on attributes introspection rather than getter/setter : won't call
anymore *all* getter for serialization.
All non transient attributes will be serialized.
* Very "eco-java-friendly" (c) : nothing is added unless it is really needed :
- use Java transient keyword, no extra annotation needed
- use default included in the JDK RMI exception for the controller. No
extra exception or interface added.
Use java.rmi.Remote interface (an empty interface) that Controller must
implement.
Use java.rmi.RemoteException as the exception to be thrown by remote method.
In case it is thrown, this will be seen as an error on client side.
* Compatible with current implem on client side point of view. No qooxdoo code
will need to be change.
Our implementation pass Derell client side test code.
On the server side, Controller code from current implem will need small
refactoring (RemoteException and the Remote interface).
Business object from current code will need deeper refactoring since all
getter/setter added only for the shake of serialization can be removed.
You may have to add transient modificator to some attributes you don't want to
serialize.
* On a design point of view, we are also using internally, json.org
implementation, slightly modify for the date.
We have designed 2 separate library (can be package separately) one for
serialization and one for remote call.
* Important design point : serialization is done in 2 steps : java object ->
Map of attribute's name/ value -> JSON
and back from JSON -> Map of attribute's name/ value -> java object.
This is done so one can modify standard behavior at the map step.
That step allow you to add/remove/rename/change value of any attributes before
JSON or before java object.
There are also 2 ways of doing that : each call (fully dynamically, like it
depends on some criteria, any attribute value, wind direction, ...)
or for the life of the serializer (like rules that would be always true for
your application).
PS : I assumed Controller is a known concept, but feel free to ask question.
Hope this will help.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
