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 #11977] Wed, 20 August 2008 09:22 Go to next message
Eclipse UserFriend
Originally posted by: frederic.conrotte.kaupthing.lu

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
Re: Getting rid of EJBs in OFMP [message #12016 is a reply to message #11977] Sat, 23 August 2008 10:25 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1083
Registered: July 2009
Senior Member
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/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
>
>
Re: Getting rid of EJBs in OFMP [message #569521 is a reply to message #11977] Sat, 23 August 2008 10:25 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1083
Registered: July 2009
Senior Member
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/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:Eclipse Banking Day in Frankfurt
Next Topic:OFMP Messaging Server
Goto Forum:
  


Current Time: Mon Nov 24 12:24:28 GMT 2014

Powered by FUDForum. Page generated in 0.02013 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software