| Getting rid of EJBs in OFMP [message #569418] |
Wed, 20 August 2008 05:22 |
Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.03351 seconds
Home