It was well understood by the development community that a mechanism to provide fine-grained, local access to persistent objects was needed. The dependent object implementation ultimately fell into unfavorable status because of its awkward implementation style. Enter local interfaces. By adding an additional interface to an entity EJB, developers would not have to change the techniques which they've already mastered. Local interfaces allow developers to take existing entity EJBs and quickly separate the way in which the bean is accessed by placing different operations into the remote or local interfaces.
Local interfaces provide all sorts of benefits and headaches that are discussed below.
By leaving all business operations as part of a remote interface, containers that provided local optimized access to a method would be breaking RMI semantics. Developers that code to a remote method invocation expect certain behavioral factors to occur such as input and return parameters being passed by value. Runtime optimizations of a remote method invocation into a local call that has parameters passed by reference would fundamentally break the semantics driven by the interface. Compilers can provide stronger type checking for clients that make use of local interfaces. Since local interfaces have different semantics than remote interfaces, compilers can provide some minimal type checking and constraint analysis around how a client is attempting to use a local interface.