EJB 3.0, un ejemplo práctico con Maven y JBoss

3
71137

Creación: 02-08-2007

Índice de contenidos

1. Introducción

Este tutorial presenta un ejemplo sencillo donde se verá como desarrollar EJBs de sesión y de entidad, inyección de dependencias, llamar a los EJBs desde una aplicación Web, definición de un DataSource, y como configurarlo y hacerlo funcionar en JBoss, y todo compilando con Maven.

Este tutorial pretende llenar un hueco que dejan otros tutoriales de EJB 3.0 ya publicados en www.adictosaltrabajo.com como:

Ya que en todos estos tutoriales se han visto partes concretas de los EJBs 3.0, con ejemplos de código, pero no se ha visto un ejemplo completo y funcionando en un servidor de aplicaciones.

Puedo recomendar especialmente el primero: EJB3 Resurrecction (de Francisco Javier Martínez Páez), ya que expone de forma clara y breve las bondades de esta nueva versión, y porque parece que por fin los EJBs empiezan a ser realmente útiles y sencillos de utilizar (en las versiones anteriores la especificación era complicada y el desarrollo de los EJBs tedioso. Si se usaban bien se les podía sacar mucho partido, pero era bastante fácil meter la pata si no se tenía un amplio conocimiento).

Espero que os resulte útil, sobre todo para los primeros contactos con EJB 3.0 y perder el miedo al «folio en blanco».

Aquí podéis encontrar un .tar.gz con todo el código del ejemplo !!!

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Asus G1 (Core 2 Duo a 2.1 GHz, 2048 MB RAM, 120 GB HD).
  • Sistema Operativo: GNU / Linux, Debian (unstable), Kernel 2.6.21, KDE 3.5
  • Jboss 4.2.1.GA
  • Maven 2.0.7
  • Java 1.6.0_02

3. Instalación del JBoss

Nos bajamos la última versión estable del JBoss (en el momento de escribir este tutorial la 4.2.1.GA) de http://labs.jboss.com/jbossas/downloads

Lo descomprimimos donde queramos, por ejemplo en /opt

$ cd /opt
$ tar -xzf <ruta_a_la_descarga>/jboss-4.2.1.GA.zip

Probamos a ejecutarlo:

$ cd /jboss-4.2.1.GA/bin
$ ./run.sh

Al final del log (lo podemos ver por consola o en <JBOSS_HOME>/server/default/log) dará un mensaje del estilo:

18:32:35,822 INFO [Server] JBoss
(MX MicroKernel) [4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA
date=200707131605)] Started in 14s:854ms

Probamos a entrar con el navegador en la dirección http://localhost:8080, y deberíamos ver:

 

4. El proyecto de Maven

Vamos a tener dos proyectos, uno con los EJBs y otro con la aplicación Web. Como ya hemos visto en otros tutoriales
(http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=mavenRelease)
vamos a crear la siguiente estructura de directorios (en cada uno tendremos un proyecto de Maven):

autentia-parent
|-- pom.xml
|
|-- autentia-ejb
| `-- pom.xml
|
`-- autentia-web
`-- pom.xml

4.1 autentia-parent

Es el proyecto padre donde definimos configuración común y los módulos que componen la aplicación. Veamos el pom.xml:



    4.0.0

    com.autentia.demo
    autentia-parent
    1.0-SNAPSHOT
    pom

    autentia-parent
    Autentia Parent

        autentia-ejb
        autentia-web

                maven-compiler-plugin

                    1.5
                    1.5

            jboss-repository
            JBoss Repository
            http://repository.jboss.com/maven2
            default

Lo más interesante es ver como estamos dando de alta un repositorio de JBoss. Esto es necesario porque actualmente en los repositorio oficiales de Maven (www.ibiblio.org/maven2) no se encuentran los jar necesarios (persistencia, anotaciones, …) para trabajar con EJB 3.0. Todas estas dependencias las podremos encontrar en el repositorio de JBoss.

4.2 autentia-ejb

Es el proyecto donde tendremos nuestros EJBs con la lógica de negocio. Veamos el pom.xml



    4.0.0

        com.autentia.demo
        autentia-parent
        1.0-SNAPSHOT

    com.autentia.demo.ejb
    autentia-ejb
    1.0-SNAPSHOT
    jar

    autentia-ejb
    http://maven.apache.org

        

        

            javax.persistence
            persistence-api
            1.0
            provided

            jboss
            jboss-ejb-api
            4.2.0.GA
            provided

            junit
            junit
            3.8.1
            test

Aquí podríamos destacar como las dependencias están con scope provided. Esto es porque los jar sólo se necesitan para compilar, pero en ningún caso se deben empaquetar con la aplicación aplicación Web que use este proyecto. Los EJBs se tienen que desplegar en un servidor de aplicaciones (por supuesto compatible con EJB 3.0 JEE5) y será este el que proporciones todas estas librerías.

4.3 autentia-web

Es la aplicación Web que usará a autentia-ejb para resolver los problemas de negocio (como siempre, desde Autentia www.autentia.com, os recordamos e insistimos en la importancia de separar presentación, control y negocio: patron MVC). Veamos el pom.xml:



    4.0.0

        com.autentia.demo
        autentia-parent
        1.0-SNAPSHOT

    com.autentia.demo.web
    autentia-web
    1.0-SNAPSHOT
    war

    autentia-web Maven Webapp
    http://maven.apache.org

        autentia-web

        

            com.autentia.demo.ejb
            autentia-ejb
            1.0-SNAPSHOT
            provided

        

            javax.servlet
            servlet-api
            2.5
            provided

            jboss
            jboss-ejb-api
            4.2.0.GA
            provided

            junit
            junit
            3.8.1
            test

Nuevamente destacamos como el scope de las dependencias es provided, incluso de la dependencia interna. Esto es porque los EJBs se desplegarán en el servidor de aplicaciones de forma independiente a la aplicación Web. Es decir, cuando instalemos la aplicación Web, el servidor de aplicaciones ya debe tener los EJBs disponibles.

5. Creando el primer EJB de sesión

Vamos a crear un EJB de sesión sin estado (Stateless). Son los más sencillos y los ideales para implementar nuestras clases de servicios (lógica de negocio sin estado, que se puede invocar de forma simultánea por muchos clientes).

Todo EJB de sesión puede tener dos interfaces, una local (obligatoria) y otra remota (opcional):

  • La interfaz local define los métodos del EJB que se pueden invocar desde cualquier otro componente (otro EJB, un Servlet, …) que se encuentre en el mismo servidor de aplicaciones donde está desplegado el EJB.
  • La interfaz remota define los métodos del EJB que se pueden invocar por componentes que se encuentren fuera del servidor de aplicaciones donde esté desplegado el EJB. La interfaz remota sólo será necesaria si vamos a llamar al EJB desde otro sitio que no sea el propio servidor de aplicaciones donde está desplegado el EJB. Mi recomendación es no crearla si no la necesitamos realmente (menos código = más sencillo = más fácil de mantener).
    Si más tarde queremos añadirla y va tener los mismos método que la local, bastaría con que la interfaz remota extendiera de la interfaz local.

5.1 Greeter.java

Definimos el contrato que debe cumplir un «Saludador». El código completo se puede ver en el .tar.gz que se puede descargar en la introducción (aplicable al resto de ejemplos que veamos, marcaré con ... para indicar que en el .tar.gz se puede encontrar más código)

...

@Local
public interface Greeter {

    public String sayHi();

    public void addGreeting(String message) throws InvalidGreetingMessageException;
}

Lo importante es ver como hemos anotado la clase con @Local. Esto indica al contenedor que se trata de la interfaz local.

Si quisiéramos implementar la interfaz remota tendríamos que hacer otra interfaz y anotarla con @Remote.

¡¡¡ Ojo, una misma interfaz no puede esta anotada a la vez con @Local y @Remote !!!

5.2 DummyGreeterBean

Es nuestro primer EJB. Es un saludador un poco «tonto», que sólo sabe dar un saludo y no es capaz de acordarse de nuevos saludos:

...

@Stateless
public class DummyGreeterBean implements Greeter {

    public String sayHi() {
        return "Hi !!!    Hello World !!!";
    }

    public void addGreeting(String message) throws InvalidGreetingMessageException {
        // I can't remember more greetings  :'(
    }
}

Vemos como la clase está anotada como @Stateless, de esta forma el servidor de aplicaciones la reconoce como un EJB de sesión sin estado.

También vemos como el EJB implementa la interfaz local Greeter. Un EJB puede implementar tantas interfaces locales y/o remotas como necesitemos.

6. Creando un Servlet que use nuestro EJB

En la aplicación Web tendremos el siguiente Servlet:

6.1. GreeterServlet.java

...

public class GreeterServlet extends HttpServlet {

    private static final long serialVersionUID = 3031665322987189909L;

    private Greeter greeter = null;

    public GreeterServlet() {
        final Context context;
        try {
            context = new InitialContext();
            greeter = (Greeter)context.lookup("DummyGreeterBean/local");

        } catch (NamingException e) {
            e.printStackTrace();
        }
    }

    public void service(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {
        final PrintWriter out = res.getWriter();

        final String newGreeting = req.getParameter("addGreeting");

        try {
            greeter.addGreeting(newGreeting);
            out.println(greeter.sayHi());

        } catch (InvalidGreetingMessageException e) {
            out.println("El saludador no admite ese mensaje de saludo. El saludador dice: " + e.getMessage());
        }
    }
}

Se puede ver como el Servlet tiene una referencia (greeter) a la interfaz. Esta referencia se inicializa en la construcción del Servlet haciendo un lookup por el nombre JNDI del EJB.

El nombre JNDI será el nombre de la clase EJB (la clase que implementa la interfaz, la que está marcada con @Stateless) + «/» + «local» o «remote«, dependiendo de si queremos acceder mediante la interfaz local o la interfaz remota.

Por supuesto, para poder usar el nombre JNDI «.../remote» tendremos que haber creado la interfaz que comentábamos en el punto 5.1. anotada con @Remote.

A lo largo de los demás ejemplos que vamos a realizar, en este Servlet lo único que habría que cambiar es el nombre JNDI para ir llamando al EJBs correspondiente.

¡¡¡ Ojo, JEE 5 soporta inyección de dependencias en los Servlets, Filtros, Tags, … es decir, no sería necesario hacer el loockup en el Servlet; pero JBoss 4.2.1.GA todavía no soporta esta funcionalidad (no es totalmente JEE 5 «compliant»). JBoss 4.2.1.GA sólo soporta inyección de dependencias entre EJBs. Luego veremos un ejemplo de ello !!!

6.2. Configurando las propiedades de JNDI

Para que en el Servlet anterior funcione correctamente el lookup en el contexto, debemos poner en el CLASSPATH el fichero jndi.properties. Este fichero contiene la configuración de JNDI.

Para nuestra aplicación Web colocaremos este fichero en el directorio autentia-parent/autentia-web/src/main/resources. Cuando hagamos el empaquetado con Maven, este se encargará de poner el fichero en autentia-web/WEB-INF/classes; directorio que estará en el CLASSPATH una vez se despliegue la aplicación en el servidor de aplicaciones.

El fichero tendrá el siguiente contenido:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099

7. Creando un EJB de entidad

Bueno, nuestro «Saludador» es un poco «torpe» y no es capaz de recordar nada más que un saludo, así que vamos a crear uno nuevo con algo más de memoria 😉 Para ello vamos a usar un EJB de entidad que se encargará de guardar los mensajes de saludo en la base de datos.

Vamos a usar la tabla que ya habíamos creado en el tutorial de DTP
(http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=eclipseDtp)

7.1. Greeting.java

...

@Entity
public class Greeting {

   public static final String DEFAULT_MESSAGE = "Hi !!!    Hello World !!!";

   private Integer id = null;

   private String message = null;

   @Id
   @GeneratedValue(strategy = GenerationType.AUTO)
   public Integer getId() {
      return id;
   }

   public void setId(Integer id) {
      this.id = id;
   }

   public String getMessage() {
      return message;
   }

   public void setMessage(String message) {
      this.message = message;
   }
}

Así de sencillo, sólo tenemos un POJO anotado con @Entity y hemos indicado cual es su id con la anotación @Id. Además también hemos indicado que los valores de este campo ¡d serán generados por la base de datos (auto incremental de MySQL en nuestro caso) con la anotación @GeneratedValue.

7.2. SmartGreeterBean.java

...

@Stateless
public class SmartGreeterBean implements Greeter {

    ...

    @PersistenceContext
    private EntityManager em;

    public String sayHi() {
        final List greetings = em.createQuery("from Greeting").getResultList();

        String message = Greeting.DEFAULT_MESSAGE;

        if (greetings.size() > 0) {
            final int randomMessage = random.nextInt(greetings.size());
            message = greetings.get(randomMessage).getMessage();
        }

        return message;
    }

    public void addGreeting(String message) throws InvalidGreetingMessageException {
        if (message == null) {
            return;
        }

        final Greeting greeting = new Greeting();
        greeting.setMessage(message);

        em.persist(greeting);
    }
}

Como antes, con la notación @Stateless estamos indicando que se trata de EJB de sesión sin estado, e igual que antes implementa la interfaz local Greeter.

Con la notación @PersistenceContext le estamos indicando al servidor de aplicaciones que nos inyecte un EntityManager para poder acceder a JPA (Java Persistence Api).

Con los métodos createQuery y persist del EntityManager es como hacemos consultas o guardamos nuevos objetos en la capa de persistencia.


7.3. Configuración del proveedor de JPA

Para que nuestro EJB de entidad funcione correctamente necesitamos indicar cual será el proveedor JPA. En definitiva lo que tenemos que indicar es que «conexión» nos tienen que inyectar a través de la notación @PersistenceContext. Para ello vamos a escribir el fichero persistence.xml. Este fichero lo colocaremos dentro de del directorio
autentia-parent/autentia-ejb/src/main/resources/META-INF, de forma que cuando empaquetemos con Maven, el fichero quedará dentro del jar, en el directorio META-INF.



        org.hibernate.ejb.HibernatePersistence

        java:/autentiaDataSource

En el fichero podemos ver como indicamos el proveedor con el elemento provider. Estamos indicando que nuestro proveedor de JPA será Hibernate. Este es el valore recomendado para usar con JBoss.

A continuación, con el elemento jta-data-source, estamos indicando cual será el DataSource a utilizar. Más adelante, en el punto 10.1. Dando de alta en el DataSource veremos como damos de alta este el DataSource «autentiaDataSource».

Por último estamos indicando algunas propiedades para el proveedor de JPA. Como en nuestro caso estamos usando Hibernate, podemos pasarle cualquier propiedad típica de Hibernate, por ejemplo el dialecto de la base de datos que debe utilizar.

8. Inyección de dependencias

Ciertamente, en el punto anterior, ya hemos visto una inyección de dependencia con la anotación @PersistenceContext. Ahora vamos a ver como inyectar a un EJB otro EJB.

8.1. GreetingModerator.java

Este interfaz define el contrato que deben cumplir todos los moderadores. Simplemente tiene un método que, dado un mensaje, nos dice si este es correcto o no, según los criterios que implemente el EJB que implementa la interfaz.

...

@Local
public interface GreetingModerator {
        public boolean isValid(String message);

}

8.2. GreetingModeratorBean.java

EJB de sesión sin estado se encarga de validar si un mensaje es políticamente correcto o no. Para ello busca si en el mensaje de saludo se encuentra alguna palabra «prohibida».

...

@Stateless
public class GreetingModeratorBean implements GreetingModerator {

    final private List forbiddenWords = Arrays.asList("caca", "culo", "pedo", "pis");

    public boolean isValid(String message) {
        final String[] words = message.split(" ");
        for (String w : words) {
            if (forbiddenWords.contains(w)) {
                return false;
            }
        }
        return true;
    }
}

Es igual que los EJBs que hemos hecho hasta ahora. No hay nada que destacar.

8.3. PoliteSmartGreeterBean.java

EJB de sesión sin estado, que usa un moderador para saber si los mensajes, que va a mostrar o que le están añadiendo, son políticamente correctos.

...

@Stateless
public class PoliteSmartGreeterBean implements Greeter {

    ...

    @PersistenceContext
    private EntityManager em = null;

    @EJB
    private GreetingModerator moderator = null;

    public String sayHi() {
        final List greetings = em.createQuery("from Greeting").getResultList();

        String message = Greeting.DEFAULT_MESSAGE;

        if (greetings.size() > 0) {
            for (int chance = 0; chance < 3; chance++) {
                final int randomMessage = random.nextInt(greetings.size());
                final String storedMessage = greetings.get(randomMessage).getMessage();

                if (moderator.isValid(storedMessage)) {
                    message = storedMessage;
                    break;
                }
            }
        }
        return message;
    }

    public void addGreeting(String message) throws InvalidGreetingMessageException {
        if (message == null) {
            return;
        }

        if (!moderator.isValid(message)) {
            throw new InvalidGreetingMessageException("The greeting message is not enough polite!!!");
        }

        final Greeting greeting = new Greeting();
        greeting.setMessage(message);

        em.persist(greeting);
    }
}

Mediante la notación @EJB en el atributo moderator, es como el contenedor sabe que nos tiene que inyectar la dependencia. El contenedor determina el EJB que nos tiene que inyectar por le tipo del atributo marcado con la notación @EJB, en este caso nos inyectará un EJB de tipo GreetingModerator.

Como ya hemos indicado antes, la notación @EJB de JEE 5 también debería funcionar para Servlets, filtros, tags, … pero esta funcionalidad no está soportada por JBoss 4.2.1.GA. Por esto en el Servlet tenemos que hacer directamente un lookup en el contexto.

9.Gestión de excepciones

En el ejemplo anterior, en el EJB PoliteSmartGreeterBean, también podemos destacar como en el método addGreeting se lanza la excepción InvalidGreetinfMessageException en caso de que el moderador considere que el mensaje de saludo no es adecuado.

Podemos ver como el método addGreeting lanza directamente esta excepción, y por ningún lado vemos la típica RemoteException de versiones anteriores de EJBs.

¿Qué está pasando?

Bien, para EJB 3.0 todas las excepciones que lance un método de un EJB que sean subclases de RuntimeException o de RemoteException serán consideradas excepciones del sistema, y serán tratadas por el propio contenedor.

Por el contrario, las excepciones que sean subclases de Exception (han de ser tratadas por el «llamante» del método) serán consideradas como excepciones de la aplicación. Estas excepciones no serán tratadas por el contenedor y llegarán al cliente, sea este local o remoto, de forma que se puedan tratar (en nuestro ejemplo, en el Servlet, vemos como se hace el tratamiento de la excepción InvalidGreetingMessageException).

Precaución especialmente con los EJB dirigidos por mensaje (MDB) ya que estos no deben lanzar excepción. Será nuestra responsabilidad controlarlas.


10. Desplegando la aplicación en el JBoss


10.1. Dando de alta en el DataSource

Tenemos que configurar en el JBoss el DataSource que usarán los EJBs para acceder a la base de datos (hemos visto como lo usábamos en el punto 7.3. Configuración del proveedor de JPA). Para ello echamos en /opt/jboss-4.2.1.GA/server/default/deploy el fichero autentia-ds.xml



        autentiaDataSource
        jdbc:mysql://localhost:3306/AUTENTIA
        com.mysql.jdbc.Driver
        autentia
        autentia

Como se puede ver, en este fichero definimos la conexión a la base de datos.

¡¡¡ Ojo, es muy importante que el nombre del fichero sea ...-ds.xml, si no acaba en -ds.xml JBoss no lo reconocerá como la configuración de un DataSource !!!

10.2. Desplegando los EJBs

Basta con echar el jar en /opt/jboss-4.2.1.GA/server/default/deploy. Si JBoss está arrancado, enseguida veremos en el log un mensaje del estilo:

19:03:26,831 INFO [EJB3Deployer] Deployed:
file:/opt/jboss-4.2.1.GA/server/default/deploy/autentia-ejb-1.0-SNAPSHOT.jar

10.3. Desplegando la aplicación Web

Igualmente echamos el war en en /opt/jboss-4.2.1.GA/server/default/deploy. Si JBoss está arrancado, enseguida veremos el resultado en log.

11. Listos para probar

Ya está todo desplegado y tenemos el JBoss arrancado. Ahora para probar sólo hace falta invocar nuestro Servlet. Para ello podemos usar la URL: http://localhost:8080/autentia-web/greeterServlet.

Si lo que queremos es añadir es nuevos mensajes de saludo podemos usar la URL:
http://localhost:8080/autentia-web/greeterServlet?addGreeting=Hola%20Amigo.
Donde «Hola%20Amigo» será el mensaje de saludo que queremos añadir.

Si estamos probando el «Saludador Educado» podemos probar a usar la URL:
http://localhost:8080/autentia-web/greeterServlet?addGreeting=Hola%20caca.

12. Conclusiones

Con este tutorial hemos podido ver como desarrollar con EJB 3.0 es infinitamente más sencillo que con sus versiones anteriores.

Incluso puede resultar más sencillo que desarrollar con su equivalente: Hibernate + Spring, ya que nos ahorramos bastantes ficheros xml de configuración. Esto no quiere decir que
Hibernate o Spring vayan a desaparecer, al contrario, son robustos frameworks de desarrollo, ampliamente probados y extendidos, que seguirán evolucionando, innovando, y aportando cantidad de buenas ideas a la comunidad (claramente, si EJB 3.0 ha llegado a ser lo que es, ha sido gracias a ellos).

Ahora nos podríamos hacer la pregunta ¿he de ponerme como loco a desarrollar con EJB 3.0?, bueno, creo no, por lo menos no a lo loco. Deberíamos tener en cuenta los siguientes puntos:

  • Si ya tenemos aplicaciones desarrolladas con Hibernate y/o Spring, puede no tener sentido reescribirlas con EJB 3.0, ya que haremos un esfuerzo para obtener lo mismo. Tendremos que tener muy clara la ventaja que nos aporta para asumir el cambio.
  • Si vamos a empezar nuevos desarrollos y ya conocemos Hibernate y/o Spring, tiene mucho sentido seguir con estas tecnologías y evitar los riesgos de empezar a trabajar con una tecnología nueva para nosotros. De nuevo tendremos que tener claras las ventajas que nos aporta EJB 3.0 para afrontar el aprendizaje de esta nueva tecnología.
  • Si no sabemos ni Hibernate ni Spring ni EJB 3.0, si podría ser recomendable ir por el camino de los EJBs 3.0 ya que estos son el estándar al formar parte de la especificación de JEE.

Desde luego a lo que si que os animo es a que hagáis alguna prueba, aunque sólo sean los ejemplos de este tutorial; porque es una tecnología que realmente merece la pena, y de la que creo que vamos a oír hablar mucho, y esta vez para bien (no como sus versiones anteriores 😉

13. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software)

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com

 

Alejandro es socio fundador de Autentia y nuestro experto en Java EE, Linux y optimización de aplicaciones empresariales. Ingeniero en Informática y Certified ScrumMaster. Seguir @alejandropgarci Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid). Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

3 COMENTARIOS

  1. Hola;

    Muchas gracias por todos tus artículos. Muy didácticos.

    Te quería hacer una pregunta para ver cuál es tú opinión.

    Tengo que hacer un servicio web sencillo. El servicio debe traer datos de una BBDD Oracle y consumir otro servicio web JSON y exponer esos JSON. Se pide que para el acceso a datos se utilice JPA, y también EJB y Maven. El IDE es Eclipse. El servicio no tendría lógica de negocio, es decir sólo consume otro servicio, accede a datos y devuelve JSON. Tengo ya el código hecho pero no se cómo estructurarlo. Mi pregunta es cuál es la mejor manera de crear la estructura de la aplicación:

    -Un proyecto Maven con 2 módulos: 1-EJB + servicio web, 2-Acceso a datos (JPA)
    -Un proyecto Maven con 3 módulos: 1-EJB, 2-el servicio web , 3-Acceso a datos (JPA)
    -Dos proyectos Maven: 1-EJB + servicio web, 2-Acceso a datos (JPA)
    -Tres proyectos Maven: 1-EJB, 2-el servicio web , 3-Acceso a datos (JPA)
    -Otra manera

    Por ahora no estoy teniendo en cuenta nada del EAR.

    Disculpad si la pregunta es muy básica o si estoy equivocado en algún planteamiento. Yo soy de .NET y estoy con mi primer desarrollo en java y quiero que tenga una arquitectura correcta.

    Muchas gracias, un saludo.

    • No te preocupes que toas las preguntas son buenas.

      Lo que no se sencilla la respuesta porque depende mucho del caso. Por ejemplo, la recomendación general podría ser empezar siempre de la forma más sencilla e ir creciendo según tus evoluciones. Por ejemplo en tu caso con un sólo proyecto y un sólo módulo puede parecer suficiente.

      Si quieres hacer algo más «correcto» seguramente elegiría tu segunda opción, es decir un proyecto y tres módulos. Así tienes separada cada capa y es fácil compilar. Si el proyecto crece mucho te puedes plantear lo de crear varios proyectos, pero sólo más adelante cuando de verdad le saques partido.

      Saludo y ánimo con tus andadura en Java!

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad