Absolutely! The bean's remote interface can certainly extend an existing interface. The only restriction here is that all interfaces that it extends must have all methods throw java.rmi.RemoteException.

• Thus the Sort example can be modified by renaming the bean's remote interface to SortRemote (modifying other files as needed). Then define a new interface called Sort and move the two business methods from SortRemote to Sort:

public interface SortRemote extends Sort, javax.ejb.EJBObject {
}

public interface Sort {
    Vector sort(Vector v, Compare c) throws java.rmi.RemoteException;
    Vector merge(Vector a, Vector b, Compare c) throws
java.rmi.RemoteException;
}

• An alternative design is to have all your root classes to extend java.rmi.Remote, or some sub-class thereof (e.g., javax.ejb.EJBObject). So, you could change Sort to:

public interface Sort extends java.rmi.Remote {
  Vector sort(Vector v, Compare c) throws java.rmi.RemoteException;
  Vector merge(Vector a, Vector b, Compare c) throws java.rmi.RemoteException;
}

and then SortRemote could remain:

public interface SortRemote extends Sort, javax.ejb.EJBObject {
}

This probably is close to the previous design and does a better job of expressing the fact that Sort is actually a remote interface (although not necessarily an EJB interface). It was already implied that Sort was a remote interface, by the fact that all its methods throw RemoteException, so why not make it explicit?
• An argument to not have Sort extend java.rmi.Remote is that one may want the client to use Sort and be unaware whether the object behind Sort is remote or not. This should allow one to switch between an object-by-value and a remote object mechanism without changing the client.