Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Peter Donald <peter@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: Re: [Altrmi} Thoughts
Date: Fri, 26 Apr 2002 18:49:16 +1000
References: <20020426061349.18257.qmail@web13408.mail.yahoo.com>
In-Reply-To: <20020426061349.18257.qmail@web13408.mail.yahoo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200204261849.16314.peter@apache.org>

On Fri, 26 Apr 2002 16:13, Paul Hammant wrote:
> > Basically I would like a simple API for making invocations on objects=
=2E It
> > should not be tied to any particular Object model or any transport la=
yer
> > (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 hav=
e
> 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 f=
ar
> 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 usag=
e 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=20
proxies and the actual transport. So in my view the generated proxies wou=
ld=20
actually use this layer to do the actual transportation/work.

The reason for this level of separation is that it would make it easier t=
o=20
support alternative models of distribution. ie If you wanted to write an =
EJB=20
server (where the EJBs don't actually deal with external transport layer =
and=20
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=20
end up doing something like

Incoming call --> AltRMI interface --> discrete call objects (like I prop=
osed)=20
--> specific EJB object

So I guess this model is less for end users and more for people who want =
to=20
build middleware based on AltRMI. Heh - if you went this way you could ev=
en=20
build regular RMI on top of this ;)

> > The reason for this architecture is that it would allow you to reliab=
ly
> > scale up as you are no longer tied to the single-thread per call mode=
l
> > 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 mul=
tiple=20
calls without waiting for a response. ie You could end up with sequencing=
=20
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=20
will just take longer to get a repsonse. I am not saying that this is nee=
ded=20
for regular clients but for certain systems it can be useful. (One of the=
=20
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 ;)

--=20
Cheers,

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>