Home » Archived » OFMP » Getting rid of EJBs in OFMP
| Getting rid of EJBs in OFMP [message #11977] |
Wed, 20 August 2008 05:22  |
Eclipse User |
|
|
|
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 06:25  |
| Eclipse User |
|
|
|
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 06:25 |
| Eclipse User |
|
|
|
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
>
>
|
|
|
Goto Forum:
Current Time: Fri May 02 12:32:01 EDT 2025
Powered by FUDForum. Page generated in 0.02969 seconds |
Home