Java Tutorial - Java Scipt :
Home, Remote, and Local Interfaces
There are number of interfaces linked with EJBs, each of which tells the EJB container how the EJB expects to interact with a client:
Home interface. The home interface tells a client how to work with the EJB container. The home interface is used by a client to ask the EJB container to perform certain actions. These are usually acts such as creating
an EJB, locating EJBs by some criteria, or removing an EJB. The home interface’s operations are largely management related.
Remote interface. The remote interface spells out what things a remote client can do with an EJB. When the client wants to work with a specific EJB, it uses the remote interface (or its local counterpart as we will see). The remote interface exposes a business-oriented component view into the EJB. This means that the operations in the remote interface are generally business methods.
Local interface. In version 2.0 of the EJB specification, local interfaces were added to parallel the remote versions. The local interface offers optimized access for clients co-located within the same JVM as the EJB. Local interfaces give developers the option to gain performance when working with EJBs that are co-located within the same JVM. One caveat is that this means that you can only take advantage of local interfaces from within server-side clients and that care must be taken to ensure hat this locality is guaranteed. It is easy for local interfaces to break during
a refactoring of the deployment architecture. By and large, these performance gains are the result of switching from a pass-by-value model to a pass-by-reference model. Both client and EJB developers need to be aware of this, because objects passed as a parameter can be inadvertently modified. This can work out to your advantage, as nonserializable parameters can be used in local interface methods. One of the original goals of the J2EE EJB specifications has been to shield the developer from the distinctions between a local and a remote object, but this has proven to be unworkable due in part to the fundamental differences between a remote and a local component. Local interfaces are a recapitulation to this unavoidable fact. There is a positive side to this separation—it is utilized in J2EE applications to resurrect scoping. ColocatedvEJBs can be more tightly coupled and expose methods for local
consumption without having to make them publicly accessible. The result is a pseudo-package/public component interface on the EJB level. Please note that this is a way to manage method visibility, not to restrict
of method access, which should remain in the hands of declarative container-managed authentication and access control. An EJB container combines information provided in the deployment descriptor to generate a managed implementation of the EJB. Usually, there is a platform-independent descriptor file that conveys standard information such as what the Java classname is for a particular interface, what type of EJB it is, or what transactional support is required for so-and-so method. In addition, there is platform-specific descriptor file that provides important cues about the EJB for the EJB container. Here, we’ll find such information as what JNDI names to bind an EJB under, how to persist an EJB, and so on.
