Rickard,
It is interesting to think of the restrictions in the EJB specification
as security based. I have always thought of the restrictions as a way
to handle resource usage. You are describing the Application Server
as the big brother of an Applet Server. For Applets, a sand-box is used
to restrict access. You are indicating that EJBs would run in a similar
sort of sand-box, and if you need to do things that are not allowed in
the sand-box, you write a utility library.
This makes a lot of sense given Telkel's ambitions of providing EJB
hosting software. You want to be careful about what the hosted EJBs do,
in order to prevent them from making malicious or otherwise inappropriate
access to the environment.
I look at things a little differently. To me, the limitations in the
EJB spec are motivated much more by the need to be able to scale arbitrarily.
So, for example, if my EJBs make access directly to the file system, it
is very hard to scale them. Why? Well, the file system is typically a
very scarce resource, with often a per-process limit on the number of file
desriptors. Unless you permit the AppServer (by which I mean the compliment
of your EJB code) to control how you access the file system, you may very
quickly run into scaling limitations, in that you can only have as many
concurrent EJBs as there are file descriptors.
Another way to look at the restrictions is to consider clustering. If we
try to cluster your EJBs which make use of the file system, again we may
be in trouble. If every node in the cluster tries to run the File I/O
EJBs, then you will require a networked file system. This may work for
readonly I/O (that is, "I"), but it will quickly not scale for read-write
I/O (that is, "I/O"). If an EJB is in the middle of writing a file, and
the server crashes (and if you are running in a large cluster, then chances
are at least some nodes will crash) this file update could be incomplete.
Unfortunately, since the vast majority (all?) file systems are not XA-enabled
and don't support transactional semantics, there's nothing you can do.
You have "corrupted" your "data".
Similarly lines of argument, which look at either large numbers of EJBs
running in a single VM, or which look at large number of nodes in an AppServer
cluster, explain the other limitations in the EJB specification. For
example use of threading primitives will kill your throughput on a single
VM, and will probably be unimplementable in a clustered environment.
Which gets me back to my original point. I don't think it matters how your
package your EJB, whether into an EJB Jar, or into the "system" as a
library. You should not do file I/O in either case, and beans that rely
on this are contrary to the spec.
<vendor>
Not that our server will prevent you from running such beans: we don't.
But there is a good reason for avoiding such things, and it helps to
understand the spec. authors' motivations.
</vendor>
-jkw
Rickard Oberg wrote:
>
> On Mon, 6 Nov 2000 12:55:14 -0800, Jonathan Weedon <[EMAIL PROTECTED]>
> wrote:
> >I see this as a slippery slope. On the one hand, there is clearly the
> >opportunity to write a utility library, and to install that as part of
> >the "system", and thereby side-step the restrictions indicated in the
> >EJB specification. As you say, this is what JDBC drivers do.
>
> Exactly.
>
> >But where does one draw the line? I have heard some people say that
> >the restrictions about what I can do in EJB only apply to the class
> >listed as the bean implementation class in the deployment descriptor.
> >So, I can do File I/O in a base class, or in a delegate, right? Well,
> >no. To me, a base class or a delegate object are still part of the
> >EJB.
>
> Exactly. To me as a container implementor it boils down to which classloader
> is used to load the class, and I think this is the right way to approach it:
> if it is part of the component or application it is largely untrusted, and
> if it is part of the system it is trusted. I always think of how it would
> work in a webhotel situation where the sysadmin != app developer. In that
> case the sysadmin definitely wants to restrict what the components can do
> without having to ask for specific permissions to do more.
>
> >For example, I have been debating with some engineers at Sun whether
> >it is valid to put SQL code into a data-access-object when using
> >CMP. They argue that the DAO is not part of the CMP bean. I argue
> >that the DAO is just a way of organizing (and possibly reusing) code,
> >and is therefore part of your CMP bean, and therefore should not
> >contain direct SQL code.
>
> Hm.. don't quite follow. The DAO class would still be loaded by the EJB
> classloader and thus be affected by the EJB restrictions. As you say.
>
> Again, I think using the webhotel metaphor makes it easier to determine what
> should be allowed and what should not be allowed.
>
> >As I said, where to draw the line?
> >
> >I would be curious to see anything definitive that drew the line between
> >what is part of an "object" and what is an external "library". In Java,
> >they all seem the same to me, modulo packaging issues.
>
> And they are. The packaging *is* the holy grail IMNSHO.
>
> To me there are two main reasons where the restrictions are useful:
> 1) If it's an EJB it is portable. Period. No "well, if it does this or that
> it needs.." crap. By refactoring everything that would be potentially
> dangerous to external libraries we have the simple rule that EJB's
> themselves are always portable.
> 2) For actual security reasons in a webhotel scenario where the hosting
> party and the application party are not the same.
>
> This is the mindset that is useful IMO when thinking about these things.
> Would you agree?
>
> /Rickard
===========================================================================
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".
