Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » OFMP » Getting rid of EJBs in OFMP
Getting rid of EJBs in OFMP [message #569418] Wed, 20 August 2008 05:22
Frederic Conrotte is currently offline Frederic Conrotte
Messages: 125
Registered: July 2009
Senior Member
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/Eclip seSummitTurkey2007-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
Previous Topic:OFMP Messaging Server
Next Topic:Eclipse Banking Day in Frankfurt
Goto Forum:
  


Current Time: Tue Jul 29 13:02:07 EDT 2014

Powered by FUDForum. Page generated in 0.03743 seconds