Home » Developing U++ » U++ Developers corner » RMI
|
Re: RMI [message #9220 is a reply to message #9215] |
Sun, 22 April 2007 10:17 |
zsolt
Messages: 697 Registered: December 2005 Location: Budapest, Hungary
|
Contributor |
|
|
I was thinking about creating some callback system for network communication, because in an event based system (GUI app) blocking calls are not the best.
BTW, RMI is used in Java internally only, because SOAP and XMLRPC is more portable and can be integrated easily in an enterprise environment.
So an ideal solution would be able to use a native C++ serialization or SOAP/XMLRPC as a transport layer as well.
[Updated on: Sun, 22 April 2007 10:18] Report message to a moderator
|
|
|
|
Re: RMI [message #9223 is a reply to message #9222] |
Sun, 22 April 2007 12:25 |
zsolt
Messages: 697 Registered: December 2005 Location: Budapest, Hungary
|
Contributor |
|
|
class RemotelyCallableClass
{
public:
RCallback1<int> doSomething;
};
class ClientSide()
{
RClient<RemotelyCallableClass> client; //some setup needed
void doSomethingRemotely()
{
client.doSomething(33);
}
};
class ServerSide()
{
public:
ServerSide()
{
server.doSomething <<= THISBACK(OnDoSomething);
//some setup (IP, port)
}
RServer<RemotelyCallableClass> server;
void OnDoSomething(int v)
{
//some processing on server
}
};
Of course this is an idea only
RCallback arguments should implement a serializable interface if they are not basic types.
The return value could be handled as a callback on the client side with something like RGate<int, int>.
I don't prefer blocking calls.
Edit: I changed RClient to RServer on server side.
[Updated on: Sun, 22 April 2007 13:07] Report message to a moderator
|
|
|
|
|
|
Re: RMI [message #9229 is a reply to message #9215] |
Sun, 22 April 2007 18:14 |
zsolt
Messages: 697 Registered: December 2005 Location: Budapest, Hungary
|
Contributor |
|
|
I was thinking a bit about it.
I think, that in some situations it could be useful, to have the same API for distributed and multi processed (multi thread/core) tasks.
[Updated on: Sun, 22 April 2007 18:14] Report message to a moderator
|
|
|
Re: RMI [message #9235 is a reply to message #9220] |
Mon, 23 April 2007 08:04 |
fallingdutch
Messages: 258 Registered: July 2006
|
Experienced Member |
|
|
zsolt wrote on Sun, 22 April 2007 10:17 | I was thinking about creating some callback system for network communication, because in an event based system (GUI app) blocking calls are not the best.
|
I am working on the same, but wanted to extend it to all Files/Devices.
On Linux: poll with read/write
on Windows ReadFile, WriteFile with OVERLAPPED and MsgWaitOnMultipleObjects
the Problem i have to solve at the moment is how to get the numbers of bytes in the buffer at a communication device on Windows. On Linux I use a nonblocking read, it returns the number of bytes read or gives the error wouldblock if nothing is in the buffer.
Do you have any Ideas?
Bas
[Updated on: Mon, 23 April 2007 08:04] Report message to a moderator
|
|
|
|
Re: RMI [message #9238 is a reply to message #9237] |
Mon, 23 April 2007 10:36 |
Ulti
Messages: 108 Registered: September 2006
|
Experienced Member |
|
|
personally like ICE very much(though ICE is not RMI,it's middleware),but it's GPLed.if U++ support RMI,then php will be easily supported(via writing PHP extension)
[Updated on: Mon, 23 April 2007 10:38] Report message to a moderator
|
|
|
Re: RMI [message #13634 is a reply to message #9215] |
Fri, 18 January 2008 09:38 |
Shire
Messages: 41 Registered: September 2006 Location: Russia, Yamal peninsula
|
Member |
|
|
Quote: |
personally like ICE very much(though ICE is not RMI,it's middleware),but it's GPLed.
|
I prefer ICE too, but it is based on STL. UPP can have its own implementation of network communication protocol.
IMHO, communication will be better, if it is based on queries, rather than RPC. Query is simple structure, consist of base types. Queries is better for asynchronous work, multi parameter passing and grouping multiple in one network packet. Handling queries can be easily chained. Query can build by accessors and query builders. Binding to other languages (USC, for example) also can be simple.
To do this, these components needed:
* serialization for marshalling queries
* platform-independent query description language (can be done by macros)
* platform-independent binary protocol description (IMHO, the most difficult part)
* local (per application) or/and global components registry (for dynamic creation)
|
|
|
Re: RMI [message #13635 is a reply to message #13634] |
Fri, 18 January 2008 10:13 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
Shire wrote on Fri, 18 January 2008 03:38 |
Quote: |
personally like ICE very much(though ICE is not RMI,it's middleware),but it's GPLed.
|
I prefer ICE too, but it is based on STL. UPP can have its own implementation of network communication protocol.
IMHO, communication will be better, if it is based on queries, rather than RPC. Query is simple structure, consist of base types. Queries is better for asynchronous work, multi parameter passing and grouping multiple in one network packet. Handling queries can be easily chained. Query can build by accessors and query builders. Binding to other languages (USC, for example) also can be simple.
To do this, these components needed:
* serialization for marshalling queries
* platform-independent query description language (can be done by macros)
* platform-independent binary protocol description (IMHO, the most difficult part)
* local (per application) or/and global components registry (for dynamic creation)
|
Interestingly, your new response to this old thread came at the moment I am about to start implementing some SOAP for/in U++
Mirek
|
|
|
|
Goto Forum:
Current Time: Wed Apr 24 20:01:39 CEST 2024
Total time taken to generate the page: 0.02407 seconds
|