Re: J2EE Specification compliance

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