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".