@Local and @Remote version of the same interface?

[lhoriman]

The calculator example in the tutorial looks like this:

public interface Calculator
{
 ...
}

@Local public interface CalculatorLocal extends Calculator {}

@Remote public interface CalculatorRemote extends Calculator {}

@Stateless public class CalculatorBean implements CalculatorLocal, CalculatorRemote
{
 ...
}

The idea being, as a client, you choose whether or not to use the Local or Remote version of the interface.

Why would you ever want a bean with identical Local and Remote interfaces?

I understand why you might want a bean with a Local interface only to prevent access from outside the JVM. But since JBoss optimizes a Remote call when in-process, what advantage does the above example have over:

@Remote public interface Calculator
{
 ...
}

@Stateless public class CalculatorBean implements Calculator
{
 ...
}

?

If there is no advantage, it seems like the general rule of thumb for development should be using a single interface, with either @Local if it should be local-only, or @Remote if it should be local-or-remote.

Thanks,
Jeff Schnitzer
http://subetha.tigris.org/

[elkner]

"lhoriman" wrote:
Why would you ever want a bean with identical Local and Remote interfaces?

Because I wanna make sure, that at the server the method params are passed as reference and thus avoid the serialization overhead ... ?

[lhoriman]

"elkner" wrote:

"lhoriman" wrote:
Why would you ever want a bean with identical Local and Remote interfaces?

Because I wanna make sure, that at the server the method params are passed as reference and thus avoid the serialization overhead ... ?

Which would only be the case on an appserver that did not perform the most obvious performance optimization, right?

Jeff

[lhoriman]

I'm finding that even in-process, @Remote interfaces result in serialization.

Isn't JBoss supposed to detect this case and optimize out the serialization?

Thanks,
Jeff

[epbernard]

I think it's against the J2EE compliance. But there might be a flag I'm not aware of

[lhoriman]

"epbernard" wrote:
I think it's against the J2EE compliance. But there might be a flag I'm not aware of

Yep, I'm pretty sure that optimization would violate the J2EE spec... but that's what I like about JBoss, it usually does the smart thing instead of the stupid Sun-approved thing :-)

Jeff