Ways that lead to Invocation of EJB

Usually, one is expected to obtain the object reference (Home) from the service offering the naming through the Java Naming Directory Interface then let the client have the Home Object reference, after that, make for me a new Enterprise JavaBeans (EJB) object through Home Object Interface then make an object from the EJB Object. After this, return the EJB object reference to the client, now it’s the time when you perform invocation of the business method via the EJB object reference and then send the request to the enterprise bean.

Whether or not sharing between HTTPSession can be shared between JSP and EJB.

And what is the result when an HTTPSession value is changed from the EJB?

It is possible that one passes the parameter of the HTTPSession to a method of an EJB though this can take place only when the objects available in a session are all serializable, which has to undergo pass by value consideration, meaning only values in the EJB are read and this protects such that in an event that values in the EJB are altered, there is no reflection back at the HTTPSession of the Servlet Container.

When it comes to the EJB’s Remote Interface, pass by reference method can be used because these usually are remote references.

As much as there is a possibility to pass HTTPSession as a parameter to EJB Object, it is usually not advisable as it contradicts the norms of the OOD (Object Oriented Design).

This comes out obvious as one finds himself creating coupling between front end objects and back end objects which aren’t necessary.

It is advisable that as opposed to passing the whole HTTPSession, one creates an abstraction of higher level for the API concerning the EJB; simply create a structure or a class that holds the data which you will use between your ends. Consider a case in which a non HTTP – based client is to be supported, here is when benefits from the flexibility of a higher level of abstraction will be realized.

EJBObject and EJBHome classes can be implemented using the EJB container. Is it true that all requests from particular clients let the container to create unique instance for the generated and EJBObject class?

Usually, an instance pool is usually maintained by the container which it uses for the reference of the EJB Home disregarding the request of the client. When taking consideration to the EJB Object classes, usually separate instances are created by the container for each client request; it is upon the implementation of the container to ensure that the instance pool is well maintained. It is not mandatory that the provider implements it though if it is provided by the container, then it is available. Owing to this it can be observed that it is true most providers implement this pooling functionality so as to boost the server application performance and his manner of implementation is totally at his discretion.

Can a primitive type such as int become the primary key in the entity bean?

This is not possible instead, primitive wrapper classes will do the work, and for example, one can use java.lang.Integer but not the just the int.