Applicability of EJB in a particular scenario

[Vinod Iyer]

Hi Ranchers,


I came across below qstn in a mock test

Your organization is interested in building an application that will allow users to query and read volumes of statistical data for analysis. They anticipate high volumes of traffic and want the most scalable solution. This application will be distributed in a cluster and deployed as an enterprise archive. Components should be designed so that they can be accessed remotely by other Java applications.

What Java EE component type and remote access technology is correct for this architecture?

A Servlet accessed using HTTP.
B Message-driven bean accessed using JMS.
C Stateless session bean accessed using RMI.
D Stored procedures and DAO's.


I woud suggest option C is most scalable solution. Since Session beans are pooled and also they support remote invocation . But D is given as correct option.

I am unable to digest why not C.

Anyone can throw some light on this

[Rahul Mishra]

I picked up the same question from ePractice i think while i was preparing for Part 1. The answer was incorrect.

'D' is clearly incorrect as Stored Procedures and DAO's do not have remoting capabilities on their own. You will need to build wrapper API's to make the functions available remotely.

Your answer 'C' is incorrect too.When you think of EJB, you should also think of the objectives for which it is designed. Remote accessiblity is just one of the features it provides and should not be the sole criterion for your answer. In the context of this question, the application does not need any transactional behavior as it just has to read volumes of statistical data. This should drive you away from choosing an EJB in this context if an alternate option is available.

So, now check if there is another option available which could service remote clients. Yes, the option is 'A'. It meets all the criteria of the context.By experience you will know that since servlets are stateless, they are designed to handle a higher throughput.An EJB although stateless, will have a higher container service footprint.

So, a servlet over Http is the best option.

[Kumar Ala]

If we see the question clearly "Java EE component type " surely stored procedure is not a J2ee component. Even in that case also C is the right choice.

[Ryan Fernandes]

The Answer is 'A'. Rahul Mishra's explanation is spot on even though they try to throw you off with '..deployed as an enterprise archive'

[Teja Saab]

I think the correct answer is C and here's why.

Components should be designed so that they can be accessed remotely by other Java applications.

The requirement is that the application is to be accessed remotely by a Java application. The simple rule of thumb in my opinion when we have two Java systems that need to be integrated is to use a Java technology instead of a language agnostic technology such as HTTP.

Also note that the requirement just says that the components need to be accessed remotely. That is no mention that they should be accessible only by HTTP. Also there is no indication that the client to this application can use HTTP. It just says that the application should be accessible remotely. Using an EJB allows you to expose the functionality remotely using many ways such as through RMI, exposing the EJB as a web service for invocation by service clients, CORBA interface for C++ clients if required etc. Besides, as we all know stateless session beans are scalable.

While I understand that EJBs would be an overkill for something as trivial as reading stuff from the database, I think that in the context of the requirement C is still the best answer.

Just my thoughts though.....

[deepak adlakha]

I agree with Teja. Scenario never mentioned anything about web based solution or any web client.

And they need scalable solution. SO i would also go with option C.