tags:

views:

1273

answers:

4

Hi

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

+2  A: 

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 paramters are passed by value and local interface paremeters are passed by reference there are fundemental semantic differences bwtween the two cases. Hence you might choose to design the two interfaces differently.

djna
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.
Vikas Kedia
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.
djna
+1  A: 

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.

skaffman
I think the question is, why can't I choose this when declare injection?
Mykola Golubyev
+5  A: 

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.

rodrigoap
A: 

Hi,

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 value 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.

regards,

Arthur Ronald F D Garcia