Getting rid of EJBs in OFMPhttps://www.eclipse.org/forums/index.php/mv/msg/179359/569418/#msg_569418
In our way for an OSGi based "Stackless Stack" architecture, we are getting
rid of our EJB containers.

Pro: Who needs full EJB container just for SLSBs ?
Cons: All OSGi bundles exposing services will have to be deployed thru web
server, but web server is required anyway to expose services thru Web
services.

A standard EJB container offers the following services:
1- Transaction management
=> replaced by an opensource XA capable transaction manager like Jencks's
Geronimo TM.
2- Persistence
=> replaced by iBatis or any other ORM
3- Remoting
=> replaced by Spring Remoting supported protocols
4- Thread management
=> Most stateless service objects don't need to use a single thread model;
they simply don't run into complex concurrency issues. If concurrency is
involved, it's the programmer's responsability to handle it properly.
5- Declarative security
=> done using Spring Security (Acegi)
6- Instance pooling =>
When only one new service object has to be created-in the common case when a
service object depends
only on shared resources such as DataSources-benchmarking indicates that
creating a Spring prototype
performs quite well, and is an acceptable overhead in normal usage. Problem:
in the case of prototypes, any configured destruction lifecycle callbacks
will not be called. I would advise to stay with the default singleton scope
and avoid state to be kept in Service beans.

After several try, performance are quite even between RMI and SpringHttp,
obvious since Springhttp is just exporting RMI thru HTTP protocol.

Both RMI and Springhttp can be deployed at the same time on the server.
For remote Java-to-Java calls on intranet, we will use RMI to avoid http
protocol overhead.
For remote Java-to-Java calls thru the internet, we will use Springhttp to
solve tunneling, compression, encryption problems.
For remote cross-platform calls, a JAX-RPC solution like Apache CXF.