Enterprise Erlang Beams?
Wed Sep 3 08:56:47 CEST 2003
First, let me remind you that I am no J2EE "power user" either. So I may be dead
wrong, but this is what I think and I welcome criticism.
----- Original Message -----
From: "Mikael Karlsson"
> Wed 27 augusti 2003 10:36 Vlad Dumitrescu wrote:
> > - I don't think it would be good to try to imitate J2EE.
> OK, I guess you would like to have some kind of transaction support still?
Yes, of course. What I meant was that I think it is the application server's
functionality that has to be replicated, not necessarily by using anything
similar to Java beans. Maybe you didn't mean that either, but it wasn't clear
(the name Erlang Beams is a pun against such an analogy) and I think it is
important to point it out.
> > - An aspect where Java has the upper hand is security: JVM is acting as a
> > sandbox, while BeamVM isn't. This might be important.
> I am not sure I understand why this is important on the server side. What
> security issues are adressed by the JVM that makes an Erlang implementation
> too risky? Is it programming mistakes or vulnerability to external attacks?
Both. That it is so simple in a distributed environment such as Erlang to run on
another node something like os:cmd("rm -rf /") is giving me shivers. If
malevolent code sneaks into the system, then everything is wide open.
Programming errors might not be as destructive, but they can happen.
An EJB can't do some things that a regular bean can:
- no threading
- no graphics
- can't be a network server (**)
- can't write to static fields (*)
- no IO (**)
- can't load native libraries (***)
- can't use 'this' as argument ore return value (**)
- no loopback calls (i.e. EJB are non-reentrant) (*)
I marked with stars according to how much I think each of those are related to
security issues. Except for the last one (I think), Java EE and the app server
enforce these limitations. Something similar should be present in any other
implementation of an app server.
Of course, it's possible to equate EJB = Erlang process, and set the
responsibility of not doing anything "bad" to the programmers, but I wouldn't
want to use such an app server in a production environment. Not even if it was
me who wrote all code.
I think too that an Erlang app server could be a very good product, but there
are still issues to be solved. Hopefully this discussion will lead to some
advances. I'm glad you started it.
More information about the erlang-questions