Enterprise Erlang Beams?

[Mikael Karlsson]

Hi,

sorry for a bit slow response on this topic but I hope things are not (dead)  
cold.

I had a some kind of analogy in mind, but the idea is quite vague. What I like 
about EJB containers is the transaction support that means that you should 
not need to worry about the transaction yourself. It comes "for free" in some 
kind of declarative manner.

Leaving out all the problems with security, for the moment, the analogy would 
be to spawn off a gen_server  (or gen_fsm for a stateful session bean?) as a 
worker thread within a transaction. Parts of the contents of the server State 
could map to the persistent store and be used at commit/fallback time, 
without the gen_server explicitly taking part in the transaction. 

One could maybe even have some kind of persistent behaviour were the 
gen_server is spawned with a state that is restored from the database. (It 
could be spawned on another node as well.)

Regards
Mikael

Wed 03 september 2003 08:56 Vlad Dumitrescu wrote:
> Hello,
>
> 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.
>
> regards,
> /Vlad