New Java-RPC implem

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

New Java-RPC implem

Jean-Baptiste BRIAUD -- Novlog
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Derrell Lipman
On Mon, Jan 18, 2010 at 04:21, Jean-Baptiste BRIAUD -- Novlog <[hidden email]> wrote:
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" ?

We're going to get multiple implementations of JSON-RPC in each language. This will be especially true as we all move towards the new JSON-RPC spec currently being developed. We really ought to have a standardized hierarchy that allows for this. In the mean time, I'd give it a name with either your initials or with something descriptive. I, too, have a new Java RPC implementation which is not yet committed to the contrib repository. Mine is intended to be very, very simple (I went the opposite direction you did), so I might consider calling it either RpcJavaDJL or RpcJavaSimple.

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Petr Kobalíček
In reply to this post by Jean-Baptiste BRIAUD -- Novlog
Hi Jean,

Is it possible to specify some schema and serialize / deserialize data
based on this schema?

I'm currently developing own json-rpc implementation, because there is
no json-lib that allows this. I based code on the older rpc (author
granted to use apache licence for final product), but it's hell for me
(I'm far from the completion). My needs are probably different than
others so transient keyword is not enough for me - I need to serialize
different keys in different contexts/controllers, for example if I
want only list of some objects, I want to serialize only few members,
but if I want to edit/save object, I want to serialize nearly all
members, how this is solved in your code or in other libs?

Thanks

--
Best regards
- Petr Kobalicek <http://kobalicek.com>


On Mon, Jan 18, 2010 at 10:21 AM, Jean-Baptiste BRIAUD -- Novlog
<[hidden email]> wrote:

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Jean-Baptiste BRIAUD -- Novlog

On Jan 18, 2010, at 20:50 , Petr Kobalíček wrote:

> Hi Jean,
>
Hi Petr,

> Is it possible to specify some schema and serialize / deserialize data
> based on this schema?
>
What are you calling "a schema" ? There are no "schema" in Java ...
We are serialize/deserialize classes. Nothing special in that classes.
Nothing to implement, really nothing that should make that class different because of serialization.
Only transient standard java keyword is used to mark attribute you statically don't want to serialize/deserialize.

> I'm currently developing own json-rpc implementation, because there is
> no json-lib that allows this. I based code on the older rpc (author
> granted to use apache licence for final product), but it's hell for me
> (I'm far from the completion). My needs are probably different than
> others so transient keyword is not enough for me - I need to serialize
> different keys in different contexts/controllers, for example if I
> want only list of some objects, I want to serialize only few members,
> but if I want to edit/save object, I want to serialize nearly all
> members, how this is solved in your code or in other libs?

That's exactly what we are doing !
That's what I try to explain by using static and dynamic way to include/exclude attribute.
Static way is the use of transient keyword. A transient will never ever been serialized or serialized.
You exclude that attribute "by construction" in the class, at compile-time.
Dynamic way is a way to include/exclude attribute depending on something that can change at run-time.

We coupled that with OpenJPA FetchPlan, I can tell you, it is an "atomic design", it simply annihilate some problem :-)
and it is very efficient : only useful data use the network bandwidth. No waste.

Say you have a Customer class :
public class Customer {
        protected String name;
        protected transient int specialCRC;
        potected String address;
}

That specialCRC could be siomething you compute only on server side and you don't want on client side.
Satically at compile-time, you exclude for ever that attribute that won't be used on client side : transient.

Then, depending on the business usecase, you cant the Customer's instance with both name and address, or only with name, ...
That is choosen dynamically.
That dynamic (run-time) choice can have short or long live.
Long live is the live of the serializer. So you can exclude "nearly for ever" without having to touch the Customer's class source file.
Short live is the live of a call, the one that we are using with FetchPlan.

Hope this helps !


>
> Thanks
>
> --
> Best regards
> - Petr Kobalicek <http://kobalicek.com>
>
>
> On Mon, Jan 18, 2010 at 10:21 AM, Jean-Baptiste BRIAUD -- Novlog
> <[hidden email]> wrote:
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Jean-Baptiste BRIAUD -- Novlog
In reply to this post by Derrell Lipman

On Jan 18, 2010, at 19:56 , Derrell Lipman wrote:

On Mon, Jan 18, 2010 at 04:21, Jean-Baptiste BRIAUD -- Novlog <[hidden email]> wrote:
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" ?

We're going to get multiple implementations of JSON-RPC in each language.
This could be cool for the qooxdoo community.
Initially, I clearly explain our intent to provide a replacement of current Java-RPC witch is outdated on a Java point of view.
The danger is the proliferation of very similar implementation, that just cut community force instead of focusing it.

On the other hand, lots of flowers blossoming in the qooxdoo garden could be cool if all species are clearly identify, just not to mix everything that could lost visitors.

We really ought to have a standardized hierarchy that allows for this.
Yes.

[CUT]

I, too, have a new Java RPC implementation which is not yet committed to the contrib repository.
Mine is intended to be very, very simple 
Could you please elaborate ?
All the benefit I mentioned in my previous email doesn't mean it is complex to use.

Our implementation is very simple to use, it will be difficult to be simpler :
- nothing special to do in the classes to serialized/deserialize. Using transient keyword is just plain old Java standard for serialization.
  Also see other email to understand different way to express (compile-time or run-time) you want/don't want some attribute in the serialization.
- here is a Controller example :

import java.rmi.Remote;
import java.rmi.RemoteException;

public class CustomerController implements Remote {

    public Customer[] methodTemplate(/*, HERE THE PARAM */) throws RemoteException {}
}

You see ? Nothing outside standard JDK to import, only RMI packages.

(I went the opposite direction you did)
What do you mean by "the opposite direction" ?
If yours is based on JavaBean model (ours is based on attributes witch look like simpler), then I thing the name of our two implementations should use that difference in the name to help clarifying.

Javabean RPC or Bean RPC for yours
POJO RPC or Simple Java Class RPCfor ours.
I'm not sure POJO is a known acronym so that name could deserve our implementation.
POJO stand for Plain Old Java Object.

What do you think ?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Petr Kobalíček
In reply to this post by Jean-Baptiste BRIAUD -- Novlog
Hi Jean,

Thanks for response, I'm definitely interested about your json-rpc
implementation!

Can you send me some link where I can download it? I'd like to study
it before I will try to use it.

Thanks

--
Best regards
- Petr Kobalicek <http://kobalicek.com>

On Tue, Jan 19, 2010 at 9:16 AM, Jean-Baptiste BRIAUD -- Novlog
<[hidden email]> wrote:

>
> On Jan 18, 2010, at 20:50 , Petr Kobalíček wrote:
>
>> Hi Jean,
>>
> Hi Petr,
>
>> Is it possible to specify some schema and serialize / deserialize data
>> based on this schema?
>>
> What are you calling "a schema" ? There are no "schema" in Java ...
> We are serialize/deserialize classes. Nothing special in that classes.
> Nothing to implement, really nothing that should make that class different because of serialization.
> Only transient standard java keyword is used to mark attribute you statically don't want to serialize/deserialize.
>
>> I'm currently developing own json-rpc implementation, because there is
>> no json-lib that allows this. I based code on the older rpc (author
>> granted to use apache licence for final product), but it's hell for me
>> (I'm far from the completion). My needs are probably different than
>> others so transient keyword is not enough for me - I need to serialize
>> different keys in different contexts/controllers, for example if I
>> want only list of some objects, I want to serialize only few members,
>> but if I want to edit/save object, I want to serialize nearly all
>> members, how this is solved in your code or in other libs?
>
> That's exactly what we are doing !
> That's what I try to explain by using static and dynamic way to include/exclude attribute.
> Static way is the use of transient keyword. A transient will never ever been serialized or serialized.
> You exclude that attribute "by construction" in the class, at compile-time.
> Dynamic way is a way to include/exclude attribute depending on something that can change at run-time.
>
> We coupled that with OpenJPA FetchPlan, I can tell you, it is an "atomic design", it simply annihilate some problem :-)
> and it is very efficient : only useful data use the network bandwidth. No waste.
>
> Say you have a Customer class :
> public class Customer {
>        protected String name;
>        protected transient int specialCRC;
>        potected String address;
> }
>
> That specialCRC could be siomething you compute only on server side and you don't want on client side.
> Satically at compile-time, you exclude for ever that attribute that won't be used on client side : transient.
>
> Then, depending on the business usecase, you cant the Customer's instance with both name and address, or only with name, ...
> That is choosen dynamically.
> That dynamic (run-time) choice can have short or long live.
> Long live is the live of the serializer. So you can exclude "nearly for ever" without having to touch the Customer's class source file.
> Short live is the live of a call, the one that we are using with FetchPlan.
>
> Hope this helps !
>
>
>>
>> Thanks
>>
>> --
>> Best regards
>> - Petr Kobalicek <http://kobalicek.com>
>>
>>
>> On Mon, Jan 18, 2010 at 10:21 AM, Jean-Baptiste BRIAUD -- Novlog
>> <[hidden email]> wrote:
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Jean-Baptiste BRIAUD -- Novlog
On Jan 19, 2010, at 09:45 , Petr Kobalíček wrote:

> Hi Jean,
>
> Thanks for response, I'm definitely interested about your json-rpc
> implementation!
>
Here the very first draft of the "doc".
I would really appreciate any feedback on the lib itself but also, don't hesitate to provide us a new version of that doc with all your first time user notes.

> Can you send me some link where I can download it? I'd like to study
> it before I will try to use it.
>
There are no link currently, but I release for you a tmp version until it is included as a qooxdoo contrib.
the lib is one jar file of 82Ko.
json-rpc-0.8-tmp.jar

I named it 0.8 because it has been tested only on qx 0.8 even if I don't think it would make a difference.
it also named with a tmp to clearly show it is a temporary state before qx contrib is done.
This library is, until included as a Qooxdoo contribution,
dual-licensed under the GNU Lesser General Public License (LGPL) and the Eclipse Public License (EPL).

I hope this is correct for you.

I'll send you the file by email

Here's the "doc" :

Java JSON Qx RPC library Copyright Novlog
http://www.novlog.com

This library is, until included as a Qooxdoo contribution,
dual-licensed under the GNU Lesser General Public License (LGPL) and the Eclipse Public License (EPL).

Check http://qooxdoo.org/license

Contribution:
This contribution is provided by Novlog company.
http://www.novlog.com

Autors (alphabetical order):
Loic BRESSON
Jean-Baptiste BRIAUD

What is it for and how to use it ?
This Java library contains 2 differents sub library (could be used and packaged separately if needed).
One for Java -> JSON serialization and JSON -> Java deserialization.
One for RPC from Qooxdoo JSON RPC. See http://qooxdoo.org/documentation/1.0/rpc

Serialization compile without RPC but RPC need serialization as a dependency.

The serialization process is based on attributes introspection.
No need to add extra getter/setter only for serialization.
Keep your classes as clean as possible.

To forbid serialization of an atribute, just use the Java transient standard keyword where needed for the classes.
http://en.wikibooks.org/wiki/Java_Programming/Keywords/transient

Important note : you may not have access to the source code of classes you want to serialize.
In that case, transient keyword is not a solution for you but see later for a way to do that.

This serialization had been designed in a context where data come from a DB, then to a qooxdoo screen and then to a DB,
in other words, a business application.

You can have a getAge() method that doesn't correspond to an attribute and serialization ill not call it wasting CPU time.
In that case, if you still want to pass the age even if it is not an attribute, use the dynamic mechanism explained later.

Serialization works in 2 steps :
1.1. from Java to a Map of attribute name / attribute value.
1.2. from that map to JSON

This is also true for deserialization :
2.1. from JSON to a Map of attribute name / attribute value.
2.2. from that map to Java

You can have access to that process and hook it up so you can add/remove or even rename attributes in the map.

Why is it powerful ?

Adding an attribute at step 2.1 is really powerful.
You can add a Java technical attribute that won't be seen on client side.
For example, you can use that to pass a persistent context to all the controller's method.
This will allow you to manage at a Java generic level all the persistence order like commit,
rollback in case of error and even to call several controller's method passing away the context,
in order to ensure all theses calls are in the same DB transaction.

Removing an attribute at step 2.1 can be powerful too.
Depending on the persistence framework you are using (we, at Novlog, are using OpenJPa),
it can be very important not to serialize unretreived attributes.
By "unretreived" I mean attribute that was not read from DB.
No need to consume network bandwidth with all that null values
(attribute name take one byte each letter before an optional gz compression).
So, coupled with your persistence framework, you can remove all unretreived attributes from serialization.

Another usage of removing attribute at step 2.1 is when you don't have access to the source code of the class you want to serialize.
Instead of using transient very efficient (compile-time) way to ell witch attribute you don't want,
you can do it at the expense of the CPU (run-time) by removing attribute in the map.

No need to give example of a class to serialize, there absolutly nothing to do,
except transient keyword, but you could had used it without using our lib.

How to code a Controller ?
A Controller is a class that hodl methods to called remotly.
Like OO design advice you to do so or web services or even SOA magic powder,
a Controller allow you to group RPC method by business common point. CustomerController for example.

import java.rmi.Remote;
import java.rmi.RemoteException;

public class CustomerController implements Remote {

    public Customer[] methodTemplate(final ControllerContext cc, ANY OTHER PARAM YOU WANT) throws RemoteException {}
}


Now some config :
Ammend web.xml for the novlog.rpc.JsonRpcServlet.

Nothing more to do if you don't need the dynamic way of filtering attributes.

If you want to dynamically filter map of attributes, you'll have to subclass novlog.rpc.JsonRpcServlet.

In that subclass, one way to always exclude some attribute is to override the doGetJavaSerializer() method.
This method is a factory for the Java serializer.

    @Override
    protected JavaSerializer doGetJavaSerializer() {
        final List<String> excludeFromSerialization = new ArrayList<String>() {
            {
                add("pcInheritedFieldCount");
                add("pcFieldNames");
                add("pcFieldTypes");
                add("pcFieldFlags");
                add("pcPCSuperclass");
                add("pcVersionInit");
                add("serialVersionUID");
                add("READ_WRITE_OK");
                add("LOAD_REQUIRED");
                add("READ_OK");
                add("CHECK_READ");
                add("MEDIATE_READ");
                add("CHECK_WRITE");
                add("MEDIATE_WRITE");
                add("SERIALIZABLE");
                add("DESERIALIZED");
            }
        };

        return  new JavaSerializer(excludeFromSerialization, "^class\\$L.*", null, null);
    }
   
Here we asked to always remove READ_OK attribute for example.
We also ask to always remove attributes that match the following regex : "^class\\$L.*".

Note : we ask (at run-time) to *always* remove thoses attributes. This method is called only once by the lib.

Then, there is also a way to ask for some removal but not always. Here how to do it.
You have to override the handleRPC method.
Here is an example.

    @Override
    protected String handleRPC(final HttpServletRequest request, final String requestString) throws ServletException {

        final ControllerContext cc = new ControllerContext();

        String result = null;
        try {
            final Map<String, Object> requestMap = extractRequestMap(requestString);
            // Here is the intermediate map you can modfy as you want before Controller's execution

            Map<String, Object> responseIntermediateObject;

            try {
            // You can pass as many parameters as you want on this method. Only requestMap is requested.
            // The rest represent any other extra parameter on the controller's method.
            // So, here, ControllerContext is pass to the controller's method but doesn't came from JSON.
                final Object methodResult = executeRequest(requestMap, cc);
               
                responseIntermediateObject = buildResponse(requestMap, methodResult, cc.getAllFields());
            } catch (RpcException e) {
                responseIntermediateObject = buildResponse(requestMap, e);
            } catch (RemoteException e) {
                responseIntermediateObject = buildResponse(requestMap, e);
            }

            result = jsonSerializer.serialize(responseIntermediateObject);

        } finally {
            cc.close();
        }
        return result;
    }
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Loïc Bresson -- Novlog
Hi.
I just want to add some precisions to the doc.

Jean-Baptiste BRIAUD -- Novlog wrote:

> [...]
> Serialization compile without RPC but RPC need serialization as a dependency.
>
> The serialization process is based on attributes introspection.
> No need to add extra getter/setter only for serialization.
> Keep your classes as clean as possible.
>
> To forbid serialization of an atribute, just use the Java transient standard keyword where needed for the classes.
> http://en.wikibooks.org/wiki/Java_Programming/Keywords/transient
>
> Important note : you may not have access to the source code of classes you want to serialize.
> In that case, transient keyword is not a solution for you but see later for a way to do that.
>
> This serialization had been designed in a context where data come from a DB, then to a qooxdoo screen and then to a DB,
> in other words, a business application.
>
> You can have a getAge() method that doesn't correspond to an attribute and serialization ill not call it wasting CPU time.
> In that case, if you still want to pass the age even if it is not an attribute, use the dynamic mechanism explained later.
>
> Serialization works in 2 steps :
> 1.1. from Java to a Map of attribute name / attribute value.
Or a List if the serialized Object is an array or a collection with one dimension (List or Set). You can also have a "simple" type like a String, a primitive, null, or a Date.

> 1.2. from that map to JSON
>
> This is also true for deserialization :
> 2.1. from JSON to a Map of attribute name / attribute value.
> 2.2. from that map to Java
>
> You can have access to that process and hook it up so you can add/remove or even rename attributes in the map.
>
> Why is it powerful ?
>
> Adding an attribute at step 2.1 is really powerful.
> You can add a Java technical attribute that won't be seen on client side.
> For example, you can use that to pass a persistent context to all the controller's method.
> This will allow you to manage at a Java generic level all the persistence order like commit,
> rollback in case of error and even to call several controller's method passing away the context,
> in order to ensure all theses calls are in the same DB transaction.
>
> Removing an attribute at step 2.1 can be powerful too.
> Depending on the persistence framework you are using (we, at Novlog, are using OpenJPa),
> it can be very important not to serialize unretreived attributes.
> By "unretreived" I mean attribute that was not read from DB.
> No need to consume network bandwidth with all that null values
> (attribute name take one byte each letter before an optional gz compression).
> So, coupled with your persistence framework, you can remove all unretreived attributes from serialization.
>
> Another usage of removing attribute at step 2.1 is when you don't have access to the source code of the class you want to serialize.
> Instead of using transient very efficient (compile-time) way to ell witch attribute you don't want,
> you can do it at the expense of the CPU (run-time) by removing attribute in the map.
>
> No need to give example of a class to serialize, there absolutly nothing to do,
> except transient keyword, but you could had used it without using our lib.
>
> How to code a Controller ?
> A Controller is a class that hodl methods to called remotly.
> Like OO design advice you to do so or web services or even SOA magic powder,
> a Controller allow you to group RPC method by business common point. CustomerController for example.
>
> import java.rmi.Remote;
> import java.rmi.RemoteException;
>
> public class CustomerController implements Remote {
>
>     public Customer[] methodTemplate(final ControllerContext cc, ANY OTHER PARAM YOU WANT) throws RemoteException {}
> }
To avoid confusion, the method template should be understand as:
public ReturnType methodTemplate(/*any extra argument that does not come from the client request (one, several, or none)*/  ,
                                 /*any argument that must come from the client request (one, several, or none)*/) throws RemoteException
{ ... }

Currently arguments that does not come from the json request must be put before the ones that come from the request.
The method must declare a RemoteException, in order to differentiate errors explicitly thrown by the developer from technical/bug errors (like an unexpected NullPointerException).

>
>
> Now some config :
> Ammend web.xml for the novlog.rpc.JsonRpcServlet.
>
> Nothing more to do if you don't need the dynamic way of filtering attributes.
>
> If you want to dynamically filter map of attributes, you'll have to subclass novlog.rpc.JsonRpcServlet.
>
> In that subclass, one way to always exclude some attribute is to override the doGetJavaSerializer() method.
> This method is a factory for the Java serializer.
>
>     @Override
>     protected JavaSerializer doGetJavaSerializer() {
>         final List<String> excludeFromSerialization = new ArrayList<String>() {
>             {
>                 add("pcInheritedFieldCount");
>                 add("pcFieldNames");
>                 add("pcFieldTypes");
>                 add("pcFieldFlags");
>                 add("pcPCSuperclass");
>                 add("pcVersionInit");
>                 add("serialVersionUID");
>                 add("READ_WRITE_OK");
>                 add("LOAD_REQUIRED");
>                 add("READ_OK");
>                 add("CHECK_READ");
>                 add("MEDIATE_READ");
>                 add("CHECK_WRITE");
>                 add("MEDIATE_WRITE");
>                 add("SERIALIZABLE");
>                 add("DESERIALIZED");
>             }
>         };
>
>         return  new JavaSerializer(excludeFromSerialization, "^class\\$L.*", null, null);
>     }
>    
> Here we asked to always remove READ_OK attribute for example.
> We also ask to always remove attributes that match the following regex : "^class\\$L.*".

The first and second arguments of new JavaSerializer(excludeFromSerialization, "^class\\$L.*", null, null) are the attributes we want to exclude from *serialization*.
The third and fourth arguments of the constructor are what we want to exclude from *unserialization*. Here we do not want to exclude anything from unserialization, so they are null.

>
> Note : we ask (at run-time) to *always* remove thoses attributes. This method is called only once by the lib.
>
> Then, there is also a way to ask for some removal but not always. Here how to do it.
> You have to override the handleRPC method.
> Here is an example.
>
>     @Override
>     protected String handleRPC(final HttpServletRequest request, final String requestString) throws ServletException {
>
>         final ControllerContext cc = new ControllerContext();
>
>         String result = null;
>         try {
>             final Map<String, Object> requestMap = extractRequestMap(requestString);
>             // Here is the intermediate map you can modfy as you want before Controller's execution
>
>             Map<String, Object> responseIntermediateObject;
>
>             try {
>             // You can pass as many parameters as you want on this method. Only requestMap is requested.
>             // The rest represent any other extra parameter on the controller's method.
>             // So, here, ControllerContext is pass to the controller's method but doesn't came from JSON.
>                 final Object methodResult = executeRequest(requestMap, cc);
>                
>                 responseIntermediateObject = buildResponse(requestMap, methodResult, cc.getAllFields());
/*
  Here the third argument ( cc.getAllFields() ) is a Map<Class, List<String>>. This corresponds to the list of attributes we want to serialize for each given class of the Map.
If a class is not present in the map, the algorithm will search if its superclass is present. If nothing is found, then no attribute will be serialized.
As this can conflict with the list/pattern of attributes to exclude, this takes priority on everything, i.e. the list/pattern of attributes to always exclude will be ignored
if you give a not-null Map as the third argument of buildResponse. (if the given Map is null, the serialization will look at the list/pattern of attributes to exclude)
*/

>             } catch (RpcException e) {
>                 responseIntermediateObject = buildResponse(requestMap, e);
>             } catch (RemoteException e) {
>                 responseIntermediateObject = buildResponse(requestMap, e);
>             }
>
>             result = jsonSerializer.serialize(responseIntermediateObject);
>
>         } finally {
>             cc.close();
>         }
>         return result;
>     }

The above example illustrates two things at the same time:
- the addition of an extra argument to the invoked method: executeRequest(requestMap, cc);
- for each class, the exact definition of the attributes we want to serialize: buildResponse(requestMap, methodResult, cc.getAllFields());

If you just want to add extra arguments to the invoked method, you can just override handleRPC like this:
        @Override
        protected String handleRPC(final HttpServletRequest request, final String requestString) throws ServletException {
                // cc is the extra argument.
          final ControllerContext cc = new ControllerContext();

                // doHandleRpc already does all the mechanic seen above, but without the definition for each class of the attributes to serialize.
                // You can put as many extra arguments as you want, here we just have cc.
                return doHandleRpc(requestString, cc);
        }

If you want to do nothing of those two things, then there's no need to override handleRpc.



HTH.
Cheers.

--
Loïc Bresson


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Fabian Jakobs
Administrator
In reply to this post by Jean-Baptiste BRIAUD -- Novlog
Hi Jean-Baptiste,
> There are no link currently, but I release for you a tmp version until it is included as a qooxdoo contrib.
> the lib is one jar file of 82Ko.
> json-rpc-0.8-tmp.jar
>
> I named it 0.8 because it has been tested only on qx 0.8 even if I don't think it would make a difference.
> it also named with a tmp to clearly show it is a temporary state before qx contrib is done.
> This library is, until included as a Qooxdoo contribution,
> dual-licensed under the GNU Lesser General Public License (LGPL) and the Eclipse Public License (EPL).
>  

The RPC client code has not been touched between 0.8 and 1.0 so you can
safely assume that it will work for 1.0 as well.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Derrell Lipman
In reply to this post by Jean-Baptiste BRIAUD -- Novlog
On Tue, Jan 19, 2010 at 03:37, Jean-Baptiste BRIAUD -- Novlog <[hidden email]> wrote:

On Jan 18, 2010, at 19:56 , Derrell Lipman wrote:

On Mon, Jan 18, 2010 at 04:21, Jean-Baptiste BRIAUD -- Novlog <[hidden email]> wrote:
I, too, have a new Java RPC implementation which is not yet committed to the contrib repository. Mine is intended to be very, very simple 
Could you please elaborate ?
All the benefit I mentioned in my previous email doesn't mean it is complex to use.

Nope, I wasn't implying that. What I meant is that it has no "extra" features, so it's a very small code base. I'm making use of org.json.simple.*, and my JSON-RPC server code is in three classes, JsonRpc (the server itself); JsonRpcError (the class for errors thrown by rpc methods); and AbstractRpcClass (extended by classes implementing rpc methods). The total code size is 636 lines, probably at least half of which is comments. It's therefore simple to read and understand.

It may actually be more complex to use than yours, as I don't serialize arbitrary classes -- rather the rpc methods are given as input, and build responses as output, based on JSONObject and JSONArray classes -- so for sophisticated applications, it is probably more work to use this. I wrote it as a project for getting more experience writing Java. Don't worry about this as "competition" :-) since it's more likely to be used as example code for a very basic JSON-RPC server than in any large-scale deployments. It also doesn't currently support qooxdoo Dates.
 
Our implementation is very simple to use, it will be difficult to be simpler :
- nothing special to do in the classes to serialized/deserialize. Using transient keyword is just plain old Java standard for serialization.
  Also see other email to understand different way to express (compile-time or run-time) you want/don't want some attribute in the serialization.
- here is a Controller example :

import java.rmi.Remote;
import java.rmi.RemoteException;

public class CustomerController implements Remote {

    public Customer[] methodTemplate(/*, HERE THE PARAM */) throws RemoteException {}
}

You see ? Nothing outside standard JDK to import, only RMI packages.

Yup, it sounds nice. I look forward to looking at what you've done.

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Jean-Baptiste BRIAUD -- Novlog

On Jan 19, 2010, at 15:39 , Derrell Lipman wrote:

On Tue, Jan 19, 2010 at 03:37, Jean-Baptiste BRIAUD -- Novlog <[hidden email]> wrote:

Don't worry about this as "competition" :-)
I'm not as I do think this could be cool for the qooxdoo community.


Yup, it sounds nice. I look forward to looking at what you've done.
Files available on demand by email until on qx contrib.

Also, there is still a name to find...
Several ideas :
* java-rpc-2 
* java-json-rpc

Maybe the last one look better since it clearly express what it does : a Java JSON-RPC ...

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: New Java-RPC implem

Derrell Lipman
On Tue, Jan 19, 2010 at 09:58, Jean-Baptiste BRIAUD -- Novlog <[hidden email]> wrote:
Files available on demand by email until on qx contrib.

That's ok. I'll wait until it's committed in contrib.
 
Also, there is still a name to find...
Several ideas :
* java-rpc-2 
* java-json-rpc

All of the current implementations are RpcX where X is the language of the implementation. Until we have a multi-level hierarchy (which Andreas Ecker has in the past been opposed, to but maybe by now he's come to realize that it'd be quite useful for organization of contribs) it's probably worthwhile to keep the naming consistent and go with RpcJavaSomething... but I'd be careful with what the "Something" is. Calling it RpcJava2 could ultimately confuse people later when we have implementations based on both the current JSON-RPC "spec" and the upcoming JSON-RPC version 2 spec.

Derrell


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: [qooxdoo-devel] New Java-RPC implem

Andreas Ecker
Howdy!

On Tue, 2010-01-19 at 10:09 -0500, Derrell Lipman wrote:
> On Tue, Jan 19, 2010 at 09:58, Jean-Baptiste BRIAUD -- Novlog
> <[hidden email]> wrote:

>        
>         Also, there is still a name to find...
>         Several ideas :
>         * java-rpc-2
>         * java-json-rpc
>
> All of the current implementations are RpcX where X is the language of
> the implementation. Until we have a multi-level hierarchy (which
> Andreas Ecker has in the past been opposed, to but maybe by now he's
> come to realize that it'd be quite useful for organization of
> contribs) it's probably worthwhile to keep the naming consistent and
> go with RpcJavaSomething... but I'd be careful with what the
> "Something" is. Calling it RpcJava2 could ultimately confuse people
> later when we have implementations based on both the current JSON-RPC
> "spec" and the upcoming JSON-RPC version 2 spec.

I would also object to call this RpcJava2. To me your RPC Java
implementation appears to be an alternative to the original one, not
necessarily a successor. Is this correct? As Derrell noted, it may also
misleading due to the version 2 of JSON-RPC.

No matter what the hierarchy of contributions would be within the code
repository, your contribution, as any other, should have a unique,
meaningful name. What do you think is special about your implementation
that could make it into the "Something" part in RpcJavaSomething - no,
not your initials ;-) ?

TTYL,

Andreas




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel