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 [mailto:rmannibu...@gmail.com]
Sent: Thursday, March 15, 2012 9:04 AM
To: users@openejb.apache.org
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<t...@tradertools.com>
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
andy.gumbre...@orprovision.com
www.orprovision.com
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
forbidden.
------------------------------------------------------------------------------------------------------------------------
