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".
