Why do we need separate Remote and Local interfaces for EJB 3.0 session beans

Question

I was wondering why do we need separate Remote and Local intefaces for EJB 3.0 Session beans. I guess most of the time they would both be defining the same contract. Why cant I have a common interface and in my Bean I should just be able to say that I want this bean to be accessed remotely and/or locally.

thanks Vikas

Introgression

Answer 1

This is what the EJB spec says:

The choice between the local and the remote programming model is a design decision that the Bean Provider makes when developing the enterprise bean.
While it is possible to provide both a remote client view and a local client view for an enterprise bean, more typically only one or the other will be provided.

JSR220 Chapter 3

So when writing a bean think about who is the client, it's very unlikely that a local client will need the same methods or even the same bean that a remote one.

Williawilliam

Answer 2

I don't agree that at design time remote and local should be treated as trivially inter-changable.

First, there are overheads in remote invocation, so when designing remote interfaces you need to consider carefully whether you've got the granularity and parameter sizes right. So a reminder this is going to be comparatively expensive is helpful as a designer.

Also, Given that remote interfaces parameters are passed by value and local interface parameters are passed by reference there are fundamental semantic differences between the two cases hence you might choose to design the two interfaces differently.

Marche

I agree that in many cases I might have to design different interfaces for the two but in the cases where I have the same interface for the two I should be able to annotate it with both Local and Remote. Advantage of this is that my client does not have to worry about whether its a local or remote invocation (except when he is specifying the jndi name). It will get the same interface in both the cases so it can treat both of them equally. – Introgression

Well, for better or worse, the spec authors didn't agree that such "local/remote independence" is desirable. Personally, I tend to agree with the spec authors about this. – Marche

Answer 3

The notion of "location transparency" is a dangerous anti-pattern. Your design absolutely needs to know if it's making a local call or a remote call, for many reasons (error handling and performance being the most obvious).

Remote EJB interfaces are distinct from their local counterparts because the exception signature needs to be different to accomodate the networking-related errors that can only occur on a remote call. Saddling the remote-handling baggage to the Local interface (as was the case in EJB 1) makes the code horrible. EJB 2 introduced separate Local interfaces to simplify programming for EJBs that were always local.

Bereave

I think the question is, why can't I choose this when declare injection? – Formality

Answer 4

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

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

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

This is my thought. Somebody please let me know your thoughts to validate this.

Hipolitohipp

This is an interesting idea, did you find out that your idea is correct? That it is in fact will not generate overhead. I have a similar questions about this, #6362437 . I was hoping that you can provide some thoughts here. tyvm – Mini

Answer 5

Clients access a session or entity bean through the bean's interfaces. The EJB container generates the interface implementations to enforce and manage this behavior, acting as a conduit for communication between the client and the bean. In versions before the EJB 2.0 specification, all beans were defined and implemented as distributed, remote components. As a result, the two interfaces required of beans were termed the home interface (which, in general, defines life cycle methods) and the remote interface (which, in general, defines functional business methods).

 Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.

 Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.

 When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:

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. Unexpected side effects can result if you ignore this distinction and do not code accordingly. Typically, the decision to use local or remote access is affected by:

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.

Scalability — Remote access is inherently scalable and should be used if scalability is an important factor. With the advent of local interfaces in the EJB 2.0 specification, most sources recommend that entity beans should almost always be based on local access. With local interfaces, most performance issues regarding very fine-grained data access go away. If the client is remote, the standard design pattern has the client use a remote interface to access a session bean, which then acts as a liaison to the entity bean. The session bean communicates with the entity bean through a local interface (from a patterns viewpoint, this technique is called a Session Façade, and it can actually be used in either a remote or local context).

Rotary

Nice text, except that session beans don't communicate with entity beans. The names are a bit confusing perhaps, but these days session beans community with an entity manager to obtain (JPA) entities. – Revue

Answer 6

A good reason is because you access an EJB through its interface. This way you pass parameter by value when using a remote interface and by reference when using a local interface. And do you know why this behavior ? it makes sense: maybe you do want a remote application access your business object and because pass by reference reduces network latency. Remember: 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.

Companionway

… because pass by value reduces network latency. I imagine you typed this a bit too quickly, because it’s just the other way round: pass by reference reduces network traffic (minor detail) :) – Protozoon