Data logic & Business logic if ur application is heavy on data logic than the business logic in the sense that it handles huge data. But at the same time, it doesn’t involve complex business logics & doesn’t represent a complicated transaction system, it is better to go for servlets itself.
Network call with EJB Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.
Implementing middle tier services EJB has a middle tier, which implements services such as instance pooling, transactions, security etc. The required services can be implemented in the non-EJB environment and tailored to the needs of our application with the required changes in the settings & the code without going for EJB. Example: Proper handling of objects, which makes Garbage Collection efficiently happening through out, user transaction etc.
EJBs are costly in terms of development. We require having a set of deployment descriptors and Home & Remote interfaces. We require taking care of setting the right TX attribute for the business methods. And also, Deployment & maintenance will be costly in terms of time and resources. In the case of java components, we don’t require to do what ever mentioned above.
But, when we have IDEs like WSAD, this point is not fully valid as these IDEs facilitate many things that we require to do.
Resource pooling without EJBs Almost all major J2EE servers allow us to get connection pooling and thread pooling whether we use java components or EJB components.
Originally posted by Augg Stine: Data logic & Business logic if ur application is heavy on data logic than the business logic in the sense that it handles huge data. But at the same time, it doesn’t involve complex business logics & doesn’t represent a complicated transaction system, it is better to go for servlets itself.
Thanks for replying me and I agree with your points.
But In the above you have mentioned that use of servlets if appln is heavy on data logic. Do you mean More Records in the table/More Transactions in the table for this 'DATA LOGIC'. Assume that if the Customer records are more,then will you go for Customer Entity Bean or Customer DAO object + servlets.