[news.eclipse.technology.ofmp] Re: Getting rid of EJBs in OFMP

[Werner Keil <werner.keil@xxxxxxx>]

Actually that is another good point I might get a chance to join/meet
you in Frankfurt (or otherwise)

I have at least one EJB 2.1 app I am responsible for and upgrading that
to another technology (at least EB3) is also on our long term agenda.

Studies or evaluations to back this decision are certainly welcome and I
could even justify them for a Frankfurt trip (though the date is not so
good for me as I am already scheduled to speak in Berlin on the 13th,
also about JCP with a couple of other Spec Leads, so discussing things
like Monetary System before that would be a great match on the other hand)

Werner

Frederic Conrotte wrote:
> Hi,
> 
> 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.
> 
> 
> Performances with our remote tests suites:
> - RMI: 85,9 sec
> - Springhttp 92,6 sec
> - Hessian: problems with serializer/deserializer
> 
> 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.
> 
> Here is a fairly good protocols performance benchmark:
> http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/
> 
> Next step: move from current JBoss AS to raw Equinox server
> 
> Regarding Equinox server side architectures, you can find a good abstract in 
> this document:
> http://www.eclipse.org/equinox/documents/eclipsist2007/EclipseSummitTurkey2007-OSGiEquinoxExplained.pdf 
> page 21
> 
> To get rid of JBoss WAR deployers, we will embed an HTTP Server in Equinox 
> (like Jetty):
> http://www.eclipse.org/equinox/server/http_in_equinox.php
> 
> Spring-OSGi did a fairly good job integrating web apps servlets with OSGi 
> HTTP Service, we will likely use it:
> http://static.springframework.org/osgi/docs/1.1.1/reference/html/web.html
> 
> Any questions/remarks are welcome.
> 
> Frederic 
> 
>