Using the client jar in EJB 3 and design patterns
I'm new to EJB 3 and pretty confused with some doubts which Google didn't provide with a satisfactory answer.
I'm trying to create a framework with some base classes and some utility methods which my other applications can use. All applications are to be deployed on the same server.
When I'm trying to create a new EJB 3.0 project in eclipse, it asks if I want to create a client jar also. What purpose does this client jar serve? My ejbmodule is added as a part of the EAR file. So do I really need this client jar? Do I need to create both local and remote interfaces? Or just remote interfaces will do?
I decided to keep all the interfaces in a project called projCommon and the bean definitions in projApps. The remote interfaces which the bean classes implement are in projCommon. So projApps is dependent on projCommon.
I plan to use a delegate method defined in projCommon to invoke the bean classes. That will mean that projCommon is also dependent on projApps, rt? And lead to a circular dependency.
How exactly are EJB's directly injected?
Would be really helpful if you can kindly provide an explanation to my doubts.
Answer
When I'm trying to create a new EJB 3.0 project in eclipse, it asks if I want to create a client jar also. What purpose does this client jar serve?
An EJB client JAR file is an optional JAR file that can contain all the class files that a client program needs to use the client view of the enterprise beans that are contained in the EJB JAR file. If you decide not to create a client JAR file for an EJB module, all of the client interface classes will be in the EJB JAR file
My ejbmodule is added as a part of the EAR file. So do I really need this client jar?
You do not really need the EJB Client it just provides an easier packaging to use the EJBs from a client.
Do I need to create both local and remote interfaces? Or just remote interfaces will do?
If all your EJBs are in the same EAR then you can use local interfaces, if not you need remote interfaces. Local interfaces are more efficient, the calls are done be reference.
Some Containers (i.e. WebSphere) will optimize this at runtime for you and automatically call local interfaces if it is possible.
I decided to keep all the interfaces in a project called projCommon and the bean definitions in projApps. The remote interfaces which the bean classes implement are in projCommon. So projApps is dependent on projCommon.
I would keep my projects organized by functional areas. Make local calls within the functional areas and remote ones outside of the functional areas, This allows you to later split the functionality to be deployed on different servers to scale it. It also keeps the code more modular. This also avoids any circular dependencies.
How exactly are EJB's directly injected?
The how it works does not matter, That is going to be done by the container. The whole point of J2EE is to abstract out the how.
As per http://www.developer.com/print.php/3650661:
EJB 3 containers provide the facilities to inject various types of resources into stateless session beans. Typically, in order to perform user tasks or process requests from client applications, the business methods in the session bean require one or more types of resources. These resources can be other session beans, data sources, or message queues.
The resources that the stateless session bean is trying to use can be injected using annotations or deployment descriptors. Resources can be acquired by annotation of instance variables or annotation of the setter methods.