I am trying to understand what the purpose and why we need the different client views in EJB. Could someone try to explain?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am trying to understand what the purpose and why we need the different client views in EJB. Could someone try to explain?
Remote client view
When your EJB and its clients will be in a distributed environment – meaning EJBs and clients will reside on separate Java virtual machines. Example : EJBs hosted on a WebSphere Application Server and Servlets that consume EJB APIs hosted on a Tomcat server.
Local client view
Only when it is guaranteed that other enterprise beans or clients will only address the bean within a single JVM. Example, EJBs as well as the Servlets deployed on the same WebSphere server.
No-Interface view
Is almost same as local client view, but there are differences. Your bean class is not required to implement client view interfaces in this case. All public methods of the bean class are automatically exposed to the caller. no-interface view always acquires an EJB reference – just like local or remote views – either through injection or JNDI lookup; but, Java type of the EJB reference is the bean class type rather than the type of a local interface. This is a convenience introduced as part of Java EE6.
Difference between local client view and no-interface view
In case of no-interface view, the client and the target bean must be packaged in the same application (EAR). In case of local view, client can be packaged in a separate application than the enterprise application. So, this gives more flexibility in terms of fine-graining your components.
You may use local client view vs no-interface view depending on your API usage scenario. It is very likely for no-interface view to receive flexible features in future specs.
Reason
Historically or otherwise, a client wishing to use EJB services was supposed to “look up” the bean on the container ( with certain initial contexts ). That was because all invocations are made through a special EJB reference(proxy) provided by the container. This allows the container to provide all the additional bean services such as pooling, container-managed transactions etc. So, a client can not explicitly instantiate an EJB with
newoperator. The client view is provided via certain interfaces that the client would have access to. The proxy realization at server side is done based on these interfaces. Different client views are defined to suite different deployment scenarios as mentioned above.