Expert one one one study note (1)

1.Using EJB makes applications harder to test

2. Using EJB makes applications harder to deploy
       Complex classloader issues.
       Complex deployment descriptors.
       Slower development-deployment-test cycles.
3. Using EJB with remote interfaces may hamper practicing OO design


  Interface granularity and method signatures dictated by the desire to minimize the number of remote method calls. If business objects are naturally fine-grained (as is often the case), this results in unnatural design.
   The need for serialization determining the design of objects that will be communicated over RMI. For example, we must decide how much data should be returned with each serializable object – should we traverse associations and, if so, to what depth? We are also
forced to write additional code to extract data needed by remote clients from any objects
that are not serializable.
   A discontinuity in an application's business objects at the point of remote invocation.



   To allow remote access to application components
This is a compelling argument if remote access over RMI/IIOP is required. However, if web services style remoting is required, there's no need to use EJB.

  To allow application components to be spread across multiple physical servers EJBs offer excellent support for distributed applications. If we are building a distributed application, rather than adding web services to an application that isn't necessarily distributed internally, EJB is the obvious choice.

   To support multiple Java or CORBA client types
If we need to develop a Java GUI client (using Swing or another windowing technology), EJB is a very good solution. EJB is interoperable with CORBA's IIOP and thus is a good solution
for serving CORBA clients. As there is no web tier in such applications, the EJB tier provides the necessary middle tier. Otherwise, we return to the days of client-server applications and
limited scalability because of inability to pool resources such as database connections on behalf of multiple clients.

  To implement message consumers when an asynchronous model is appropriate Message-driven beans make particularly simple JMS message consumers. This is a rare case in which EJB is "the simplest thing that could possibly work".



The availability of declarative transaction management via CMT is the most compelling reason for using EJB.