adam bien's blog

It seems to be a pre assumption, that an EJB should have only one view - either @Remote or @Local. The views are not only useful for distribution, but also for the expression of visibility and private / public contracts in particular. A ServiceFacade is the only artifact, which is allowed to be visible from outside the container, so it can come with @Remote. Others, like, Services are not allowed to be exposed directly to the outside world.

If you are using @Remote interfaces, all the parameters and return values have to be copied. This is what the spec says. The application servers provide their own proprietary and not-portable solutions to pass the the parameters and return values "per reference" and not "per value". The business @Local interfaces have the "per reference" semantics as well. All parameters and return values are returned directly and not copied.

The @Local and @Remote interfaces can be aligned with the private (or more precisely package-wide) and public visibility and so the principle of encapsulation / data hiding as well. @Remote is visible to the outside world, and @Local is not. Therefore @Remote could be considered as public and @Local as package-wide visibility. 

Especially the public contracts of a ServiceFacade should remain as stable as possible, every change could break potentially many clients. However, there is often needed, to provide a pragmatic access to the component's API, without breaking the API. This is easily achievable with EJB 3:

• You have to provide both interfaces @Local and @Remote
• @Remote interface defines the public contract
• @Local inherits from the @Remote. @Local can remain empty at the beginning
• The Bean implements the @Local interface and exposes both. 

public interface BookOrderingServiceLocal extends BookOrderingServiceRemote{
    public void cancelOrder(String id);
}

public interface BookOrderingServiceRemote {
    public void order(String isbn,String name);
    public Object referenceTest(Object reference);
}

@Stateless
@Local(BookOrderingServiceLocal.class)
@Remote(BookOrderingServiceRemote.class)
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class BookOrderingServiceBean implements BookOrderingServiceLocal {
 

I have still no idea, why a Session Bean with two views was considered as an anti-pattern. I used that since several years - the approach works perfectly and is application server independent. 

[See also: Dual View Facade Strategy on page 60 in Real World Java EE Patterns]