what happens if remote interface is accessed locally?

Local Versus Remote Interface (EJB)

Use remote client view when you need to be sure that parameters passed between your EJB and the client (and/or other enterprise beans) should be passed "by value" instead of "by reference."

With pass-by-value, the bean will have its own copy of the data, completely separated from the copy of the data at the client.




With local client view, you can do pass-by-reference, which means your bean, as well as the client, will work directly with one copy of the data.

Any changes made by the bean will be seen by the client and vice versa.

Pass-by-reference eliminates time/system expenses for copying data variables, which provides a performance advantage.




If you create an entity bean, you need to remember that it's usually used with a local client view.

If your entity bean needs to provide access to a client outside of the existing JVM (i.e., a remote client), you typically use a session bean with a remote client view.

This is the so-called Session Facade pattern, the goal of which is that the session bean provides the remote client access to the entity bean.


Returning a remote object is somewhat expensive, taking time to transfer the object to the client and create copies. Speaking of returning remote objects, it is necessary to remember that you must not return a remote interface from a local interface method. Never!


Local client view can only be accessed:

When enterprise beans are packaged within the same EJB-JAR package.

When enterprise beans are packaged within different EJB-JAR packages, but everything is still packaged within the same application's EAR package

When a web component in a WAR file is packaged within the same application's EAR package.



Local client view cannot be accessed:

When an EJB or web component is packaged in a different application's EAR packages.

When a web component is deployed in a web container, and EJBs are deployed in an EJB container, and these containers are separated (even if they are running on the same machine).



when using local interfaces, you still have to go through JNDI and do lookup (as is the case with remote interfaces), but this time you get a reference to a real Java object on the heap, instead of a stub to a remote object.



To combine remote and local client view, and to precisely divide methods by interface, making some only remote and others only local.
it is necessary to consider all of your enterprise beans in detail, to see which are using remote client view, and see if it's possible to create some additional methods that will relieve the client of a few remote method calls, instead of doing the same operations in only one remote method.



http://onjava.com/onjava/2004/11/03/localremote.html




EJB home interface: Used by an EJB client to gain access to the bean

Remote home interface (EJBHome):Used by a remote client to access the EJB through the RMI-IIOP protocol.

Local home interface (EJBLocalHome): Used by a local client (that runs inside the same JVM) to access the EJB.


References:
http://publib.boulder.ibm.com/infocenter/radhelp/v7r5/index.jsp?topic=%2Fcom.ibm.jee5.doc%2Ftopics%2Fcejb3vejb21.html




when your business needs all your methods in the Local also need to be exposed to the remote clients, then

have your Local interface defined with the methods.
have your remote interface with empty but extending the local interface
have all the actual business logic and other implementations in Local
have your remote bean implementation just delegate to the local bean implementation

a work around for achieving @Local & @Remote to same interface.
This method can be accessed locally if required and remotely if required, with out any performance overhead

http://stackoverflow.com/questions/1385717/why-do-we-need-separate-remote-and-local-interfaces-for-ejb-3-0-session-beans




The beans must run in the same VM — they are, after all, local. Parameters are sent by reference rather than being copied, as is the case for remote interfaces and objects

The type of client — Unless you always expect the client to be a Web component or another bean, choose remote access.

Whether the beans are tightly or loosely coupled — If beans depend on each other and interact frequently, consider local access.

remote access involves the process of turning an object into a byte stream - marshaling - and the process of turning a byte stream into an object - unmarshaling.

This additional step - Marshaling and unmarshaling - slows down the performance of the application.


http://stackoverflow.com/questions/1385717/why-do-we-need-separate-remote-and-local-interfaces-for-ejb-3-0-session-beans



Clients access enterprise beans either through a no-interface view or through a business interface

A no-interface view of an enterprise bean exposes the public methods of the enterprise bean implementation class to clients.
Clients using the no-interface view of an enterprise bean may invoke any public methods in the enterprise bean implementation class or any superclasses of the implementation class.


A business interface is a standard Java programming language interface that contains the business methods of the enterprise bean.

Session beans can have more than one business interface
Session beans should, but are not required to, implement their business interface or interfaces.


The client of an enterprise bean obtains a reference to an instance of an enterprise bean

through either dependency injection, using Java programming language annotations,

or JNDI lookup, using the Java Naming and Directory Interface syntax to find the enterprise bean instance.

Dependency injection is the simplest way of obtaining an enterprise bean reference.
Clients that run within a Java EE server-managed environment, JavaServer Faces web applications, JAX-RS web services, other enterprise beans, or Java EE application clients, support dependency injection using the javax.ejb.EJB annotation.

Applications that run outside a Java EE server-managed environment, such as Java SE applications, must perform an explicit lookup. JNDI supports a global syntax for identifying Java EE components to simplify this explicit lookup.


Deciding on Remote or Local Access

the type of client access allowed by the enterprise beans: remote, local, or web service.

Whether to allow local or remote access depends on the following factors.

Tight or loose coupling of related beans

Tightly coupled beans depend on one another.
For example, if a session bean that processes sales orders calls a session bean that emails a confirmation message to the customer, these beans are tightly coupled. Tightly coupled beans are good candidates for local access.
Because they fit together as a logical unit, they typically call each other often and would benefit from the increased performance that is possible with local access.

Type of client

If an enterprise bean is accessed by application clients, it should allow remote access.
In a production environment, these clients almost always run on machines other than those on which the GlassFish Server is running.
If an enterprise bean’s clients are web components or other enterprise beans, the type of access depends on how you want to distribute your components.

Component distribution

Java EE applications are scalable because their server-side components can be distributed across multiple machines
In a distributed application, for example, the server that the web components run on may not be the one on which the enterprise beans they access are deployed.
In this distributed scenario, the enterprise beans should allow remote access.

Performance

Owing to such factors as network latency, remote calls may be slower than local calls

If you aren’t sure which type of access an enterprise bean should have, choose remote access.
This decision gives you more flexibility. In the future, you can distribute your components to accommodate the growing demands on your application.



Although it is uncommon, it is possible for an enterprise bean to allow both remote and local access.

If this is the case, either the business interface of the bean must be explicitly designated as a business interface by being decorated with the @Remote or @Local annotations, or the bean class must explicitly designate the business interfaces by using the @Remote and @Local annotations.

The same business interface cannot be both a local and a remote business interface.


A local client has these characteristics.

It must run in the same application as the enterprise bean it accesses.

It can be a web component or another enterprise bean.

To the local client, the location of the enterprise bean it accesses is not transparent.


The no-interface view of an enterprise bean is a local view.
The public methods of the enterprise bean implementation class are exposed to local clients that access the no-interface view of the enterprise bean
Enterprise beans that use the no-interface view do not implement a business interface.



A remote client of an enterprise bean has the following traits.

It can run on a different machine and a different JVM from the enterprise bean it accesses. (It is not required to run on a different JVM.)

It can be a web component, an application client, or another enterprise bean.

To a remote client, the location of the enterprise bean is transparent.

The enterprise bean must implement a business interface. That is, remote clients may not access an enterprise bean through a no-interface view.


A web service client can access a Java EE application in two ways.
First, the client can access a web service created with JAX-WS.
Second, a web service client can invoke the business methods of a stateless session bean.
Message beans cannot be accessed by web service clients.
A web service client accesses a stateless session bean through the bean’s web service endpoint implementation class
all public methods in the bean class are accessible to web service clients

If the @WebMethod annotation is used to decorate the bean class’s methods, only those methods decorated with @WebMethod are exposed to web service clients


The type of access affects the parameters of the bean methods that are called by clients.

The following sections apply not only to method parameters but also to method return values.

The parameters of remote calls are more isolated than those of local calls

With remote calls, the client and the bean operate on different copies of a parameter object
An argument in a remote call is passed by value; it is a copy of an object
If the client changes the value of the object, the value of the copy in the bean does not change
This layer of isolation can help protect the bean if the client accidentally modifies the data.


In a local call, both the client and the bean can modify the same parameter object.
an argument in a local call is passed by reference,just like a normal method call in the Java programming language.




Because remote calls are likely to be slower than local calls, the parameters in remote methods should be relatively coarse-grained.

A coarse-grained object contains more data than a fine-grained one, so fewer access calls are required.

For the same reason, the parameters of the methods called by web service clients should also be coarse-grained.

For example, suppose that a CustomerEJB entity bean is accessed remotely.
This bean would have a single getter method that returns a CustomerDetails object, which encapsulates all of the customer's information.

But if CustomerEJB is to be accessed locally, it could have a getter method for each instance variable: getFirstName, getLastName, getPhoneNumber, and so forth. Because local calls are fast, the multiple calls to these finer-grained getter methods would not significantly degrade performance.



http://docs.oracle.com/javaee/6/tutorial/doc/gipjf.html
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts6.html

how to use instance variable in stateless EJB

we can't keep client specific data in stateless session beans.

In a stateful session bean, the instance variables represent the state of unique client-bean sessions. The interaction of the client with bean is called as conversational state.

A stateless session bean is an object that does not have an associated conversational state, but may have instance state. It does not allow concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. All instances of a stateless session bean should be considered identical by the client.


Stateless Session Beans (SLSB) are not tied to one client and there is no guarantee for one client to get the same instance with each method invocation (some containers may create and destroy beans with each method invocation session, this is an implementation-specific decision, but instances are typically pooled - and I don't mention clustered environments). In other words, although stateless beans may have instance variables, these fields are not specific to one client, so don't rely on them between remote calls.

References:
http://www.geekinterview.com/question_details/15746
http://www.coderanch.com/t/487846/EJB-JEE/java/EJB-instance-variables
http://www.theserverside.com/discussions/thread.tss?thread_id=8330


A stateless session bean is an object that does not have an associated conversational state, but may have instance state.
It does not allow concurrent access to the bean.
The contents of instance variables are not guaranteed to be preserved across method calls.
All instances of a stateless session bean should be considered identical by the client


In a stateful session bean, the instance variables represent the state of unique client-bean sessions.
The interaction is of the client with bean is called as conversational state

http://en.wikipedia.org/wiki/Session_Beans

In which OSI layer is http protocol?

HTTP is an example of an Application Layer protocol

http://mike.passwall.com/networking/netmodels/isoosi7layermodel.html#APP