tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy <>
Subject Re: OpenEJB vs JBoss
Date Fri, 16 Mar 2012 14:09:28 GMT
On 15.03.2012 08:09, Gil Teitelbaum wrote:
> Hi Romain,
> Thanks for your input.
> The things that I am most concerned about are performance and
> reliability.  I especially worry about reliability - sometimes issues
> with reliability can be hard to find.
> By the way - do you know if there any differences in running openEJB
> embedded versus as part of tomcat?
> Thanks
> Gil
> -----Original Message-----
> From: Romain Manni-Bucau []
> Sent: Thursday, March 15, 2012 9:04 AM
> To:
> Subject: Re: OpenEJB vs JBoss
> Hi,
> from what i know (but i'm not so fair) JBoss seems more complicated for
> a
> gain i don't see. OpenEJB is simple and works very well in production.
> One
> cons of  OpenEJB is it is not *officially* certified for the whole JEE 6
> stack (only webprofile) but your app should work perfectly.
> IMO you should test both (at least OpenEJB/TomEE is simple to test ;))
> - Romain
> 2012/3/15 Gil Teitelbaum<>
>> Hi,
>> Our company is trying to pick between JBoss and OpenEJB for a J2EE
>> application that would use both EJB and JMS/MDBs for a production
>> environment.
>> Would anyone be able to tell me the pros and cons of using one or the
>> other?
>> Thanks
>> Gil
Hello Gil,

First some background information to paint the picture. I will focus on the OpenEJB / JBoss
answer in a moment.

I work for a company that is one of the worlds leading manufacturers of AOI (Automated Optical
Imaging) systems. We 
service customers such as Nokia, Sony and Hella with full scale production line machines.
Throughput and high 
availability is a necessity within the industry. These machines produce relatively large quantities
of information that 
needs to be stored and run 24/7 until something breaks, which can be anything from several
weeks to several months. Over 
the last two years we have been developing a new prototype machine, which includes a robust
client server application 
based on both the standalone and embedded OpenEJB 4.x software, but also with a remote JBoss
7.x option for certain 
scenarios. Both client (Machine controller) and server are Windows 7 based.

I don't want to go into overload here, so I'll try and keep this as concise as I can. Our
client software must be able 
to operate for a reasonable amount of time should the server go down for any reason. It utilizes
an embedded 
OpenEJB/Hibernate/Derby/ActiveMQ stack to provide an entirely EJB based caching model that
is virtually identical to an 
application that is deployed on a remote standalone OpenEJB server (Not TomEE), and optionally
JBoss. Results that are 
produced by the AOI machine are pushed through the caching model to the remote server.  We
use JMS both directly over 
TCP and locally to produce a persistent and non-persistent event model.

The default server stack is OpenEJB/Hibernate/PostgreSQL/ActiveMQ/JRE6 64bit running as a
Windows service. This server 
may service several client applications (i.e.. Information produced by several machines),
and provides a complete server 
EJB application per storage unit / database. In production tests we have had up to five real
machines and at least ten 
simulated all producing data in the order of 2TB a day for periods of over a week. This is
overkill, but represents for 
us an effective stress test. The server also has the ability to hot deploy applications. We
needed this for dynamic 
database restoration and creation during runtime.

We have an option to swap out the remote OpenEJB for JBoss literally just to be on the safe
side should we require a 
clustering capability. As mentioned, the EJB application that we deploy on the client embedded
OpenEJB is identical to 
the the application deployed on the remote OpenEJB, and 'almost' identical on JBoss. The only
difference between OpenEJB 
and JBoss that we required were two small interfaced facilities classes that provide JNDI
lookups and a custom 
deployment bean for each server. The deployment beans allow us to deploy and un-deploy applications
on both servers, and 
this is unfortunately very server specific. I have to say that dynamic creation and deployment
of an application during 
runtime is significantly easier in OpenEJB than JBoss.

So to sum up, and of course this is just my slightly bias opinion, I have found OpenEJB to
be completely capable in a 
production environment and the only real issue has been to think do we really need clustering
at the remote EJB level. 
After all, we still have the option to cluster at the Hibernate/database level using PostgreSQL
(Which seems to be our 
bottleneck under load). If we do then it is nice to know we have chosen a model that is JBoss
and, with probably very 
little effort, other JEE application server compatible. So no real pros and cons either the
way, except for clustering 
if it is going to be a requirement at the get go. As long as your layers are well interfaced
then you can always swap 
things out.

I hope this helps you to form a decision.

Best regards,

Andy Gumbrecht.


*Andy Gumbrecht*
Software Developer
Orpro Vision GmbH
Hefehof 24, 31785, Hameln

+49 (0) 5151 809 44 21
+49 (0) 1704 305 671

            Orpro Vision GmbH
            Sitz der Gesellschaft: 31785, Hameln
            USt-Id-Nr: DE264453214
            Amtsgericht Hannover HRB204336
            Geschaeftsfuehrer: Roberto Gatti, Massimo Gatti, Adam Shaw


            Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige
            Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und
            vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung
sowie die unbefugte
            Weitergabe dieser Mail ist nicht gestattet.


            This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient
            (or have received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any
            unauthorized copying, disclosure, distribution or other use of the material or
parts thereof is strictly


View raw message