P�ter,
I think I may have confused more than I clarified. Sorry about that.
A few explanations:
I think you are confusing "locality" with "collocality". A middleware
product should do two optimizations:
1) If a client and a server are "collocated", then there is generally no
reason to go over the network to communicate. Nor is there typically
a need to marshal/unmarshal parameters. As you point out, some
middleware implementations do not support a collocality optimization,
and therefore use the network to communicate with a peer running in
the same process. This is inefficient.
Some people think that going through the network and/or marshaling
is the only way to preserve RMI semantics, which require that arguments
be copied across calls, even in the local case. This is incorrect: argument
copying can be done MUCH more efficiently using other techniques,
and does not require either RPCs or even marshaling.
b) If two processes in a distributed system communicate with each other,
there is typically no reason to open more than one communication channel
between the two processes. So, even if my client uses 17 different EJBs
in my server, there is no reason to establish more than one TPC connection.
This is commonly referred to as "multiplexing"; meaning using the same
underlying "physical" connection for many application level "virtual"
connections. Again, many middleware products do not support this
optimization, meaning they are inefficient.
This second optimization is what I was talking about when I discussed "locality
of connectivity", which is a made up term.
A standard term in computer science is "locality of reference". This refers to a
common behavior of applications to use a relatively small number of references
(that is, memory references at the hardware level, or object references at the
software level) most of the time. This concentration of usage is what makes
memory caches useful.
Locality of reference is due to the fact that applications typically are doing the
same things over and over again. That is, applications tend to use the same
set of references repeatedly. This concentration also occurs in the behavior
of an application, meaning that the same set of routines/functions/methods are
called repeatedly, typically with the same and/or similar parameters. This
behavior is exploited by JIT compilers in general (where only routines that
are run frequently are compiled) and by HotSpot like technology in particular
(where routines are optimized with respect to the most frequent code path
traversal).
This same notion of "locality" (meaning a concentration/grouping/commonality
of behavior) can be applied to distributed systems, as I discuss below. A
middleware product that supports multiplexing and usage-based connection
management (<vendor>both of which are supported by VisiBroker, and hence
Borland AppServer</vendor>) will not have problems scaling to support large
systems, even in the face of a contly connection setup overhead.
-jkw
Kov�cs P�ter wrote:
> Jonathan,
>
> Thank you for your reply.
>
> After a few more minutes of thinking about this subject I realized that I
> had probably been too much influenced by the presentation of the CORBA
> Security Service spec which (given the highly generic approach it must
> invevitably take) basically treats security as a component-to-component
> feature -- or at least this is the way I perceived it. I overlooked the
> possibility that the RPC infrastructure used by the EJB-container (CORBA,
> RMI or whatever) is aware of the locality of the calls (or, on a lower
> level, the locality of the underlying network connections) and this
> information may be made available to the security layer, which than may use
> this information to optimize its operation. (Also, I am playing with an
> EJB-container implementation using Sun's RMI, which, to my knowledge, does
> not provide support for identifying the locality of caller and callee. This
> has probably added to my confusion/oversight too.)
>
> But at this point the question arises in me: How fine grained is connection
> locality in current implementations? Do current implementations use only one
> single notion of remote end points (eg. remote, if running on another
> network node) or are there multiple variants of remoteness (either running
> on another host or running in another process)? (Distinguishing between
> in-process and out-of-process end-points makes sense with RPC even without
> message protection, since based on such distinction, in-process clients can
> be handed local references so that the call does not have to go through the
> whole marshalling/unmarshalling procedure.)
>
> Also, could you please explain briefly the notion of "locality of
> behaviour", which I find quite intriguing, but which I seem only to vaguely
> understand. And more specifically, I cannot relate it to the
> hot-spot-technology. What is local and what is remote about hot-spot. (I
> assume you are talking about Sun's HotSpot optimizing JIT-compiler and
> similar technologies, aren't you?) (Are local those portions of byte code
> that get natively compiled, and remote those that do not? Does it make sense
> to push the analogy this far?)
>
> P�ter
>
> -----Original Message-----
> From: Jonathan K. Weedon [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 8:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Message Driven Beans]
>
> P�ter,
>
> I am not convinced that your concern is valid:
>
> But what about large distributed company-wide systems with clusters of
> EJB-containers spanning a whole headquarter and eventually several
> (specialized) branches? Is not the performance cost of message
> protection
> with EJB systems prohibitivly high in this kind of environments?
>
> I would say no, the cost is not prohibitively high.
>
> The reason is that even a large distributed system will exhibit locality of
> connectivity (new term?). In the same way that large applications exhibit
> locality of reference (which is why caches are beneficial) and locality of
> behavior (which is why hot-spot-like technology is beneficial), large
> distributed appications will tend to exhibit locality of connectivity. This
> means that in the common case, certain connections among the clusters
> will be used frequently, whereas other connections will be used rarely.
>
> Therefore, a well-designed middleware product that provides connection
> management based on connection usage patterns (basically providing a
> cache behavior for connections) will scale well. Although the cost of
> establishing message protection on a particular connection may be high,
> this cost is incurred infrequently, and only for rarely used connections.
> For the common case, a frequently used connection will remain open
> indefinitely, and therefore the setup overhead will be minimized.
>
> -jkw
>
> > --
> > Jonathan K. Weedon: Architect
> > VisiBroker, Borland AppServer
> >
> > Register now for the 12th Annual Borland Conference: July 21-25 in
> > Long Beach, California. BorCon is the best place to learn about award
> > winning technologies for implementing e-business. Register today!
> > http://www.borland.com/conf2001/
> >
> > This e-mail, and any attachments thereto, is intended only for use by
> > the addressee(s) named herein and may contain legally privileged
> > and/or confidential information. If you are not the intended
> > recipient of this e-mail, you are hereby notified that any
> > dissemination, distribution or copying of this e-mail, and any
> > attachments thereto, is strictly prohibited. If you have received
> > this e-mail in error, please immediately and permanently delete the
> > original and any copy of any e-mail and any printout thereof.
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> =========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
Jonathan K. Weedon: Architect
VisiBroker, Borland AppServer
Register now for the 12th Annual Borland Conference: July 21-25 in
Long Beach, California. BorCon is the best place to learn about award
winning technologies for implementing e-business. Register today!
http://www.borland.com/conf2001/
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended
recipient of this e-mail, you are hereby notified that any
dissemination, distribution or copying of this e-mail, and any
attachments thereto, is strictly prohibited. If you have received
this e-mail in error, please immediately and permanently delete the
original and any copy of any e-mail and any printout thereof.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
