The T-Mobile site is rather simple from a transaction processing
perspective. It hardly needs EJBs. What was the rational for using them?

You might be able to drive nails with a jackhammer, but why bother?

--Victor


Mark Galbreath wrote:


hmmm...have you considered that EJB is not all it's hype would lead one to
believe?  I co-developed the T-Mobile ecommerce site
(http://shop.t-mobile.com) using EJBs and I thought the overhead was not
worth it.  I really would not be surprised if EJBs go away and are replaced
with a more efficient model.

Mark

-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED] Behalf Of Glenn Williams
Sent: Wednesday, February 18, 2004 11:04 AM
To: [EMAIL PROTECTED]
Subject: J2EE Specification compliance


Hello,



We are refactoring our current application to use a J2EE compliant architecture and we've run into several design issues. Our objective is to reuse as much of our current architecture and application assets as makes sense.

The most challenging issue is conforming to the specification of the EJB
container which states that thread manipulation is not allowed. We are
using a rules engine to implement our business rules. The engine itself
uses synchronization and by the letter of the J2EE specification this is
not allowed. In conversations with our EJB container vendor, the author of
the rules engine, and various members of the software community we've come
to the conclusion that no one has a solid answer to this problem. Nothing
prevents us from doing it, there are no compliance checks within the
container. No yet anyway. Several people have suggested that the
specifications are "really just guidelines" and its ok to use
synchronization as long as we're not syncrhonizing beans. Others suggest
(our Ejb vendor as well) that violating the specification could have
immediate and long term affects.

The compliant architecture we've come up with involves creating a Corba
tier that can be used from within the EJB layer and will participate in
transactions. We've found evidence that this type of architecture is being
used by others as well. But it adds a layer of complexity that just doesn't
feel quite right and makes for a very hard sell to management.

We're also experiancing the same kind of design questions surrounding
singleton's, thread pool management, and session time out.

So does anyone have any real world experiance where this type of issue has
come up? If your violating the specfication how are you defining the
guidelines to do that?

Thanks.

glenn williams
eoTek

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".



=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to