avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [Altrmi} Thoughts
Date Fri, 26 Apr 2002 08:49:16 GMT
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 

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 ;)


Peter Donald

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message