La siguiente interfase es utilizada como interfase de negocios ("Business Interface") en un EJB:
Clase ProteccionIntereses
import java.rmi.*; public interface ProteccionIntereses { public double calcularInteres(double capital, double tasa, double plazo) throws RemoteException; public double calcularAdeudo(double capital, String cuenta) throws RemoteException; |
La definición anterior es una simple interfase Java que declara las funciones que serán utilizadas en el EJB, la declaración del EJB seria la siguiente:
Clase InteresesBean
import javax.ejb.*; public class InteresesBean implements SessionBean, ProteccionIntereses { |
La declaración anterior es el inicio de un "Session EJB" que utiliza la "Interfase de Negocios" para obligar al EJB a cumplir con las definiciones declaradas en ésta, si los métodos definidos en el EJB difieren de aquellos de la "Interfase de Negocios" será generado un error al intentarse compilar el EJB; la utilización aplica de la misma manera para un "Entity EJB".
Porque no implementar el "Remote Interface" directamente ?
A primera vista este patrón de diseño parece que puede ser substituido por el mismo "Remote Interface" , esto es, el "Remote Interface" ya define estos métodos, porque no simplemente hacer que la clase del EJB extienda (herede/"inherit") el "Remote Interface" ? esta definición de otra interfase parece excesiva.
La especificación de EJB's prohibe esta practica por la siguiente razón :
Debido a que el "Remote Interface" extiende
EJBObject
, al utilizarse para extender un "EJB" seria necesario implementar métodos adicionales de esta interfase dentro del mismo EJB, esto hace que la clase del "EJB" defina métodos adicionales sin ser utilizados lo cual agregaría más al código ya definido en el EJB.
Este patrón de diseño es ampliamente utilizado en EJB's que definen una gran cantidad de métodos de negocio,sin embargo, en otras ocasiones el uso de este patrón de diseño efectivamente puede ser excesivo.