jWebSocket Forum

[Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
rpc non-blocking call  XML
Forum Index » Getting Started
Author Message
Anonymous



Hello !
I'am really interesting by the remote proc call. I'd like to implement this functionnality with GWT, making a kind of wrapper of jwebsocket.
So i'd like to now if the functionality is already avaible for testing purpose in the trunk ?
It 'd be very nice if you can give us some informations about this functionnality ! Do you have any idea about a date of the 1.0 release ?
Thanks
aschulze

jWebSocket Owner
[Avatar]

Joined: 16/03/2010 18:15:55
Messages: 375
Location: Germany, Herzogenrath
Offline

Hi,

we updated the jWebSocket Server and its RPC plug-in to now support multi threaded RPC calls. You'll find the update in the latest Nightly Build 0.10.0726 in our download section. The RPC demo web page also contains a checkbox to compare single-threaded and multi-threaded calls. Especially when you invoke time consuming methods you will notice a significant improvement.

Beside the web page demo we also updated the RPC documentation in the developer guide on our web page. Have fun!
Feedback appreciated.

Best Regards
Alex
[WWW]
Quentin

jWebSocket Forum User

Joined: 22/07/2010 00:01:01
Messages: 37
Location: Paris, France
Offline

Thanks for the reactivity, that's really nice.
I'll make some test and give you a feedback asap !
[WWW]
Quentin

jWebSocket Forum User

Joined: 22/07/2010 00:01:01
Messages: 37
Location: Paris, France
Offline

Hey aschulze !
I've got some questions/suggestions :

1°) first of all it seems that the exemple sources RPCPlugIn.java & DemoRPCServer.java files are missing from the source file http://jwebsocket.googlecode.com/svn/trunk/jWebSocketDownloads/jWebSocket-0.10/jWebSocketFullSources-0.10.zip (there is no <module>jWebSocketPlugins</module> in the pom.xml).

2°) I think adding strings to the hashMap grantedProcs could be improved ! What about removing the hashMap and add an annotation over each methode, such as

3°) I also think the DemoRPCServer should really have an interface, something like "RpcCallable". This interface won't do anything, except that the call signature will be something like :


4°) How can I do if I have 10 "RpcCallable" classes such as DemoRPCServer ? (DemoRPCServer1, DemoRPCServer2 etc...)
I designed a small comet server with rpc call, and I made it following 2 ways :
- with a HashMap of "RpcCallable" function, and you automatically get the wright "RpcCallable" object with the class name.
for instance


- and/or you just add a package name, and you look in this package the wright class
so for exemple you have a package :
myRpcCallableFunctions.mySubPck1.DemoRPCServer
myRpcCallableFunctions.mySubPck2.DemoRPCServer2

in the server plugin you set something like

and client should be able to call functions like: "mySubPck1.DemoRPCServer.getMd5"
But with this solution, you need to add a superClass with a specific constructor containing access to the server informations, since the class is dynamically created

5°) Could you add an exemple of Server 2 Client rpc ?

6°) I have probably not used enought jwebsocket, but what is the best thing to do if I need to create my own RPCPlugin ? I simply create a new plugin which extends RPCPlugin ?

Tell me what do you think about these first impressions, (or if something isn't clear enought !)

Regards

PS : I just forget to say that the way we use the C2S and C2C rpc in js is just awsome ! Thanks for this work !

This message was edited 4 times. Last update was at 29/07/2010 09:58:48

[WWW]
aschulze

jWebSocket Owner
[Avatar]

Joined: 16/03/2010 18:15:55
Messages: 375
Location: Germany, Herzogenrath
Offline

Hi Quentin,

first off, thanks a lot for your detailed feedback. We will discuss your fair suggestions in the team as soon as possible and will get back to you ASAP. We also will prepare some more comprehensive demos and extend our tutorials accordingly.

Thanks in advance for your patience.
Alex
[WWW]
Anonymous



Hello aschulze,
As I'm building my application with jwebsocket and gwt, I really need some specific features for rpc.
I'd know if you have any plans in progress about new functionnality (make a call with various arguments ? Why is the final call method commented ? also calling a method with other parameters than String ?).
If the team is ok, I could help to make some evolutions to the RPCPlugin. I can write a clean code to make sure it goes following the same philosphy than the rest of the project.

I'm definitively not yet a master-jwebsocket, but I already make my own comet server with rpc (C2S/S2C) (http://code.google.com/p/avriserver/), so I already have a little experience for this part of the job.

Tell me what do you think.

Quentin
Quentin

jWebSocket Forum User

Joined: 22/07/2010 00:01:01
Messages: 37
Location: Paris, France
Offline

Sorry I wasn't logged
[WWW]
aschulze

jWebSocket Owner
[Avatar]

Joined: 16/03/2010 18:15:55
Messages: 375
Location: Germany, Herzogenrath
Offline

Hi Quentin,

first off, thanks for your patience. As promised attached you'll find my answers to all your fair comments.
I discussed your request with the team and we all would be glad to win you as a contributor to our project.
But first let me make the following suggestions to come to a solution for your jWebSocket requirements.

1) To simplify the module structure in v0.10 we consolidated all the included plug-ins in the jWebSocketServer module - except the samples plug-in which demonstrates an "external" custom plug-in. So you will find the RPC-Plug-ins in the jWebSocket Server package now.

2) You are right, the way this is done is only temporary and is supposed to be controlled by the jWebSocket.xml configuration file as all other configuration in jWebSocket as well. From jWebSocket v0.10 every plug-in supports it's own individual set of config settings in the jWebSocket.xml (see e.g. FileSystemPlugIn as example). In addition to your suggestion each method should be granted to a certain set of user roles and in case of bigger RPC libraries it should also be possible to add your own "external" jars. What I'm thinking of to make it secure, flexible and extensible is...

In the FileSystem PlugIn you'll already find an example of how to use the getSetting method to obtain the settings from the jWebSocket.xml file specifically for each plug-in. The jars could be loaded by our .jar loader either from the class path (e.g. from Tomcat's lib folder in case of a web app or from %JWEBSOCKET_HOME%/libs in case of a stand-aone implementation).

3) I agree! We should exactly do that, it makes perfect sense.

4) Each plug-in already has it's own individual map of config settings. This can perfectly be used to load the required .jars with your RPC codes at run-time and control the grantedProcs list. What do you think about that approach?

5) There's already an RRPC example available in the RPC-Demo, i.e. the server or a certain client can send a RPC request to another client, just start two browser clients with the RPC demo and pass the correct target Id to address the "remote RPC client". You will see how one client can trigger a call on another client already. Internally this is done in the "onRRPC" callback implemented in the RPCClientPlugIn in jWebSocket.js. If you like, of course, I will introduce you into the details...

6) I think the best idea is to take the interface you suggested, create a separate (custom-specific) jar which contains classes that implement the new interface, link the jar to the jWebSocket server as described above and register its classes and methods to the server to make it available to the users/to the public.

So my first impression of what you suggested is awesome. I hope I could merge it with our approach in terms of configuration and security and that it is an appropriate way for you.

I'm looking forward to discussing the details with you.

Best Regards
Alex

This message was edited 1 time. Last update was at 09/08/2010 13:35:28

[WWW]
Quentin

jWebSocket Forum User

Joined: 22/07/2010 00:01:01
Messages: 37
Location: Paris, France
Offline

Hi alex,
1°) ok thanks, I found it, wasn't sure it was the good one, so many folder in the trunk
2°) sounds good !
Just a couple of things :
putting a <setting key="jar:MyOwnRPCLibrary.jar"></setting> without anything inside the <setting> tag make the server fail to start :



Also, I don't understand where the plugin settings are loaded ? When I try ta getSetting("jar"), I've got a "null" return, with the following setting


(I'm Trying a simple getSetting("jars") inside the PRCPlugin Constructor)

4° - 6° yes, sure, I was confused because you loaded the class directly inside the RPCPlugIn() for test purpose, but it make better sense if we loaded this informations from the xml file.

5° ok, but what is the sourceId the server should send to the client ?
Because I can see in the client source
- a rpc method, to send a C2S request
- a rrpc method, to send a C2C request
- a onrrpc method, to execute the C2C request,
- nothing for S2C

So is a S2C a specific C2C call, as following ?



Btw, this part of the client could be, I think, improved for the function onRRPC :

by something like (very "raw" solution) :

I made some benchmark for my comet server, and it appears that eval really sucks (above all with IE)
Tell me what do you think

Thanks for your help,

Quentin

This message was edited 4 times. Last update was at 10/08/2010 14:58:40

[WWW]
aschulze

jWebSocket Owner
[Avatar]

Joined: 16/03/2010 18:15:55
Messages: 375
Location: Germany, Herzogenrath
Offline

Hi Quentin,

ok, sounds like a great plan - and I'm really glad that you are so enthusiastic - but some of the things you already tried need to be implemented first - I made a suggestion However, it looks like we agree to the discussed approach, so I will put some final spec together now for the various tasks and then we can decide how to effectively share the work. Your contribution will be much appreciated.

I will get back to you tomorrow. Thanks in advance.

Best Regards
Alex
[WWW]
aschulze

jWebSocket Owner
[Avatar]

Joined: 16/03/2010 18:15:55
Messages: 375
Location: Germany, Herzogenrath
Offline

Hi Quentin,

as promised I spent some thoughts on the concrete implementation. Before we go into the details let's agree to some common wording and infrastructural items.
Please consider this as a draft on our way to the final spec. But when I start thinking it always get a bit bigger than expected ;-)

a) An external "RPC library" is a .jar file with one or multiple classes inside.
b) Each class in a RPC library can contain an arbitrary number of methods with arbitrary arguments, some or all of which are supposed to be available via RPC. So the user is free to implement his logic in his favorite style.
c) The "RpcCallable" interface specifies the "call" method to call a certain method of the class (which implements RpcCallable)
d) The "call" method has only one single argument: A "token" (including the "name" field of the method and its arguments in the other fields), this keeps us compatible to what we already have and lets us benefit from the data format abstraction. "call" always returns a "Token" as result. This allows us to easily pass arguments and return results in the standardized token way. This could be assumed to be our new "RPC abstraction layer".
e) Every method in an RpcCallable instance gets called exclusively via its "call" method. The call method can either adjust method proprietary arguments to their specific types or just pass the token to the method, given that the methods accept a token as argument - which would be the simplest and recommend way.
"call" always returns a "Token" instance which can directly be returned to the requester. If a method does not return a token "call" has to convert the result into a token.
f) One or more "RPC libraries" are loaded/linked/bound at runtime, specified by the jWebSocket.xml configuration file.
g) Basically methods in the RPC library can send, delegate or forward Tokens if desired (e.g. in a cluster), controlled by the filter chain as done for all send operations.
h) The result of a method optionally can be null, resulting in a token with { result: null }. Basically RPC calls always send a response (we could discuss to optionally suppress that, in case of pure "one way calls").
i) Each method can be granted to certain roles. If a user does not belong to a role, an RPC call for that method will be rejected.
j) Each server has it's own unqiue node-id in the jWebSocket network or cluster. This will be the source-id used for RRPC calls to the clients.

If we agree to that modell, these would be the tasks that need to be done:

1) Interpret <settings> section for RPCPlugin in jWebSocket.xml to get list of .jars to be loaded (for an example please refer to FileSystemPlugIn)
2) Load .jars accordingly either from %JWEBSOCKET_HOME%/libs or %CLASSPATH% in a similar way like the plug-ins at run-time
3) Create the RpcCallable interface within the RPCPlugin package
4) Implement a "BaseRpcCallable" class which provides some convenience methods to convert tokens to proprietray arguments and vice versa (User RpcCallObjects should descend from that BaseRpcCallable class).
5) Migrate the old DemoRPCServer into the new model and provide a separate "Demo RPC library".

Looking forward to obtaining your feedback.

Best Regards
Alex

This message was edited 4 times. Last update was at 10/08/2010 16:00:44

[WWW]
Quentin

jWebSocket Forum User

Joined: 22/07/2010 00:01:01
Messages: 37
Location: Paris, France
Offline

Hi Alex,
Here is my point of view :
For me, jWebsocket should be able to make a total abstraction between jWebsocket implementation and the method inside the class in jar you want to call (except that this class should implement "RpcCallable", a little bit in the same way than the "Serializable" Interface)
That means -I think- that the use of the "token" should be reserved for the RPCPlugin (or as a parameter of a function called), and we should be able to make "pure" rpc call.
Let's say I have the following java class :



Client side could be able to do (sorry, if it's not the good syntax):


My point of view is that it's much easier to use (you don't even have to create a "call" method, it automatically call the good one if it exists),
and, if you need, you can make exactly what you say :
Server:

Client:


So I do agree with :
a)
b)
c) d) e) ... So for me it's not the simplest implementation, and we will have to re-write the same kind of code for each class
f) not sure to understand how you can know which of these objects you want to call, since they have the same class ?
Maybe with an ID parameter we have to defined throw the RpcCallable Interface ? But how the client will know this ID ?
g) ok
h) ok, indeed, could be interesting if we can make a pure "one way call" if we don't care to know if the server has correctly executed our instruction
i) ok, defined in the xml file or using annotation if the setting is allowed inside the xml file
j) ok, I'll have a look on the doc/source to get more information about node-id

Pfuii lots of idea here
Please don't hesitate to critic my point of view !

Kind regards

Quentin

This message was edited 3 times. Last update was at 10/08/2010 16:48:54

[WWW]
aschulze

jWebSocket Owner
[Avatar]

Joined: 16/03/2010 18:15:55
Messages: 375
Location: Germany, Herzogenrath
Offline

Hi Quentin,

I agree that the function calls in the way you suggest look more comprehensible and the code looks cleaner. However, on the low level communication client and server will exchange tokens. I think I understood your requirements, found a fair compromise and will provide a first peace of code tomorrow.

Best Regards
Alex

[WWW]
Quentin

jWebSocket Forum User

Joined: 22/07/2010 00:01:01
Messages: 37
Location: Paris, France
Offline

Hi Alex,
Thanks for your answer,
I'd be glad to help you and contribuate to the rpc plugin.
Maybe we could have a quick talk on GTalk, when you'll have some free time, to discuss about this plugin ? - mine is quentin.ambard at gmail
As you said, it's probably a good idea if we have a good spec which fit almost all the needs before starting eavy-coding

Kind regards

Quentin
[WWW]
Yves

jWebSocket Forum User

Joined: 10/02/2011 21:10:31
Messages: 6
Offline

Hi guys,

any progress here so far?
While searching for an answer to my question I saw this thread which made me curious.

yves
 
Forum Index » Getting Started
Go to:   
Powered by JForum 2.1.9 © JForum Team