This is an interesting idea, at least in theory. EJB is server-based, so there's no reason the server couldn't be implemented in Smalltalk, as long as it understood the required remote invocations.

The question is where this leaves you in interoperability. If you wanted to write all your beans in Smalltalk, you could do this no problem, but why are you doing it? Once you need mixed Smalltalk and Java, you run into the problem that two EJB servers don't really interoperate very well (even if they're both in Java). The biggest issue would be the transaction service, but I suspect there are a lot of smaller ones as well.

Then there's the question of what you want to achieve by having EJB, other than buzzword-compliance <grin>

--AlanKnight

-------

There are a couple of things you can do in a well-designed EJB system that would make a Smalltalk server attractive.  First, most of the EJB vendors are moving (some quickly, some slowly) towards distributed transactions.  A ''really cool'' thing would be to have an EJB written in Java be able to call another EJB written in Smalltalk, running in a different server, and wrap both of these up within the same XA transaction.  

This would allow 'legacy' Smalltalk code to interoperate with new Java code.  Secondly, if you 
''like'' writing in Smalltalk, you could continue to do so, with your co-workers blithely writing Java clients with no knowledge of 
''how'' you implemented your server.

KyleBrown

-------

What do you mean "moving" towards distributed transactions. It's mandated as part of the spec. I would think that all of them have to have at least shells of transaction services that are supposed to be filled in as drivers that can satisfy it become available. Now, if you have a transaction service that's compatible in both Smalltalk and Java (e.g. Visigenic (I think)) then you get that, without any issue of whether either or both of them is using EJB.

(Side issue: distributed transactions are a couple of orders of magnitude slower than normal transactions, so mandating them for every operation, whether it's necessary or not seems like a questionable idea).

Anyway, the point I was making was that you need the two servers to be compatible, including the transaction service and anything else that they need to communicate. Right now that's not the case between two Java EJB servers, so getting it between Java and Smalltalk isn't going to be any easier. You'd have to target a particular EJB server. For example, IBM could do that between WebSphere's EJBs and a WebSphere Smalltalk EJB server, since they control all the pieces and can make them interoperable. Doing it in general would be much trickier.  They're talking about defining something in the EJB 2.0 spec to make two Java servers interoperable, but that's not going to be out for quite some time.

I think we agree that it'd be useful to be able to fit into such a structure, it's just not clear to me how that can be achieved outside of a particular vendor's EJB server.

--AlanKnight

----

Yup.  The current EJB spec is sufficiently vague that cross-vendor compatibility is probably a pipe dream.  However, as you point out, it would be possible for a particular vendor to engineer a system like you've described that would work.  Later when the EJB spec catches up we can think about other things.

KyleBrown

(p.s. thanks for signing this, Alan)

----

Where does the CORBA Component Model fit into this.  I heard that the EJB API
is based off of work being done on the CORBA component model.  Maybe one day EJB servers will just look like CORBA servers to everybody else.

DaveTauzell

''Other way round. There were several proposals for the CORBA component framework , and EJB was the one that was selected by the OMG. EJB is officially part of CORBA.''