You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vinay Chandran <vi...@yahoo.com> on 2002/04/24 02:47:51 UTC
[Altrmi} Thoughts
Hi,
Needed some inputs on the following topics within
AltRMI :-
<1 topic="Method Invocation" >
We have method signature(string) being passed from
the client to the server for
carrying out the invocation of a specific method on
the server.
How about replacing it with a int value ,which is
nothing but a index to a method array maintained
on the server for that specific remote object & thus
in the process removing the string comparisons
involved ?
Comments ??
</1>
<2 topic="Pass-by-Reference & Pass-by-value decision "
>
Right now CallbackEnabled client stream treats ALL of
its arguments , which are interfaces ,
as pass-by-reference entities and transports its stub
instead of passing it by value(serializing) to the
server.
We might need to employ some means to indicate an
argument as either Pass-By-Reference or POV
entity in the arguments.
We can do something like:
callBackTestListenerImpl = new
CallBackTestListenerImpl(2);
//pass-by-value ..serialized across..this is the
default
addCallBackListener(callBackTestListenerImpl);
//pass-by-reference .callbacks can be made on this
reference by the server
addCallBackListener(new
PassReference(callBackTestListenerImpl));
===or===
We can use something like RMI's exportObject(..)
Therefore:
CallBackTestListenerImpl callBackTestListenerImpl_1
= new CallBackTestListenerImpl(2);
CallBackTestListenerImpl callBackTestListenerImpl_2
= new CallBackTestListenerImpl(2);
//This specific reference will be passed by value
when its passed on to the server as an argument
AltrmiHost.exposeObject(callBackTestListenerImpl_2);
addCallBackListener(callBackTestListenerImpl_1);//pass-by-value
.serialized across
addCallBackListener(callBackTestListenerImpl_2);//pass-by-reference
..
Comments?
</2>
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 24 April 2002 12:42 pm, Vinay Chandran wrote:
> >> Right now CallbackEnabled client stream treats
> >> ALL of
> >> its arguments , which are interfaces , as
> >> pass by reference
> >
> > This is only for the callback object on the
> > CallbackEnabled stream, correct?
>
> Yes.
> Other streams treats every argument as
> pass-by-value and serializes it across.
IMHO the default behavior for the callback object should be pass-by-ref,
since I think in most cases if you have a callback you would want the logic
to execute on the client. But its a very usefull addition.
> I shall look into the other improvements I talked off
> as soon as I am done with writing stub-generators
> using BCEL.
excellent!
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Paul Hammant <pa...@yahoo.com>.
Vinay,
> <snip>
> >> Right now CallbackEnabled client stream treats
> >> ALL of
> >> its arguments , which are interfaces , as
> >> pass by reference
> > This is only for the callback object on the
> > CallbackEnabled stream, correct?
>
> Yes.
> Other streams treats every argument as
> pass-by-value and serializes it across.
Not true. If a parameter going back to the server from a client originated from the client
in that AND it was a pass-by-reference boundary, then it is not serialized (or transported as is).
Instead it is swapped for a it's original refernece. Swapped in that there is an array of
the args going back to the server for each method call.
> I shall look into the other improvements I talked off
> as soon as I am done with writing stub-generators
> using BCEL.
Excelent work dude. I did not think it was possible. I am not worthy etc...
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Vinay Chandran <vi...@yahoo.com>.
hi,
<snip>
>> Right now CallbackEnabled client stream treats
>> ALL of
>> its arguments , which are interfaces , as
>> pass by reference
> This is only for the callback object on the
> CallbackEnabled stream, correct?
Yes.
Other streams treats every argument as
pass-by-value and serializes it across.
I shall look into the other improvements I talked off
as soon as I am done with writing stub-generators
using BCEL.
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Royal <pr...@apache.org>.
On Tuesday 23 April 2002 08:47 pm, Vinay Chandran wrote:
> <1 topic="Method Invocation" >
> How about replacing it with a int value ,which is
> nothing but a index to a method array maintained
> on the server for that specific remote object & thus
> in the process removing the string comparisons
> involved ?
+1
The less that can be sent is good for speed.
> <2 topic="Pass-by-Reference & Pass-by-value decision "
>
> Right now CallbackEnabled client stream treats ALL of
> its arguments , which are interfaces ,
This is only for the callback object on the CallbackEnabled stream, correct?
> //pass-by-reference .callbacks can be made on this
> reference by the server
> addCallBackListener(new
> PassReference(callBackTestListenerImpl));
If so, I prefer this syntax.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Donald <pe...@apache.org>.
On Fri, 26 Apr 2002 16:13, Paul Hammant wrote:
> > Basically I would like a simple API for making invocations on objects. It
> > should not be tied to any particular Object model or any transport layer
> > (as a matter of fact it sits right in between).
> >
> > I have attached a zip with the files in it that describe the API.
> > Basically there is 4 parts.
>
> I'll grant you that what we have is a tad more complicated than you have
> shown in the example you supplied, but I'd like to see that the general
> features match with what we have done so far. The chief difference as far
> as I can see is that we have generated proxies to make things look like
> normal java objects. Your interfaces do not illustrate an example usage of
> the interfaces, so I'll guess you intend both normal java usage and a
> reflection-like method.invoke(..) interface
Well I guess I was thinking it would be the layer between the generated
proxies and the actual transport. So in my view the generated proxies would
actually use this layer to do the actual transportation/work.
The reason for this level of separation is that it would make it easier to
support alternative models of distribution. ie If you wanted to write an EJB
server (where the EJBs don't actually deal with external transport layer and
one external "interface" may actually serve thousands of clients).
You probably can do it in your current model but it would be a PITA. You would
end up doing something like
Incoming call --> AltRMI interface --> discrete call objects (like I proposed)
--> specific EJB object
So I guess this model is less for end users and more for people who want to
build middleware based on AltRMI. Heh - if you went this way you could even
build regular RMI on top of this ;)
> > The reason for this architecture is that it would allow you to reliably
> > scale up as you are no longer tied to the single-thread per call model
> > and all sorts of goodies become apparent.
>
> We are not currently tied to any threading model. At least I think we are
> not. We can lump multiple threads on the client side together to call the
> server through the same altrmi connection.
Well what I was actually meaning was allowing the same thread to make multiple
calls without waiting for a response. ie You could end up with sequencing
like
call Method1
call Method2
call Method3
receive Method1 response
receive Method2 response
call Method4
receive Method4 response
receive Method3 response
Thus long running calls (like method3) will not tie up the whole thread - it
will just take longer to get a repsonse. I am not saying that this is needed
for regular clients but for certain systems it can be useful. (One of the
clients I work with currently has such an architecture in place).
> I think you are referring to server-side though in the context of one
> thread multiplexing though connections..
Thats another advantage ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Paul Hammant <pa...@yahoo.com>.
Peter,
> While ideas about altrmi are being gestated I would like to throw out some of
> mine. Note that this is probably not something that I can devote anytime to
> now but it is something I would find useful in long term.
:-)
> Basically I would like a simple API for making invocations on objects. It
> should not be tied to any particular Object model or any transport layer (as
> a matter of fact it sits right in between).
>
> I have attached a zip with the files in it that describe the API. Basically
> there is 4 parts.
I'll grant you that what we have is a tad more complicated than you have shown in the example you
supplied, but I'd like to see that the general features match with what we have done so far. The
chief difference as far as I can see is that we have generated proxies to make things look like
normal java objects. Your interfaces do not illustrate an example usage of the interfaces, so
I'll guess you intend both normal java usage and a reflection-like method.invoke(..) interface
> * Invocation: represents the call
> * InvocationContext: represents the context information like security id,
> transaction id etc.
We are mulling choices here but are likely to do the same.
> * Invoker: the thing that "executes" the Invocation - can be async or sync.
> * InvocationListener: The call back when running async invocations to notify
> that call has completed
>
> The reason for this architecture is that it would allow you to reliably scale
> up as you are no longer tied to the single-thread per call model and all
> sorts of goodies become apparent.
We are not currently tied to any threading model. At least I think we are not. We can lump
multiple threads on the client side together to call the server through the same altrmi
connection.
I think you are referring to server-side though in the context of one thread multiplexing though
connections..
>
> Anyways I just thought I would drop a few thoughts :)
keep em up dude...
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Altrmi} Thoughts
Posted by Peter Donald <pe...@apache.org>.
Hi,
While ideas about altrmi are being gestated I would like to throw out some of
mine. Note that this is probably not something that I can devote anytime to
now but it is something I would find useful in long term.
Basically I would like a simple API for making invocations on objects. It
should not be tied to any particular Object model or any transport layer (as
a matter of fact it sits right in between).
I have attached a zip with the files in it that describe the API. Basically
there is 4 parts.
* Invocation: represents the call
* InvocationContext: represents the context information like security id,
transaction id etc.
* Invoker: the thing that "executes" the Invocation - can be async or sync.
* InvocationListener: The call back when running async invocations to notify
that call has completed
The reason for this architecture is that it would allow you to reliably scale
up as you are no longer tied to the single-thread per call model and all
sorts of goodies become apparent.
Anyways I just thought I would drop a few thoughts :)
--
Cheers,
Peter Donald