viernes, 29 de diciembre de 2017

Ejemplos de Microservicios con Java

  No hay comentarios.
Recuerdo un tiempo que  la gente (nivel usuario) pensaba que una computadora era siempre Windows + Office, hasta lo llamaban "Microsoft":
- ¿Tu compu tiene Microsoft ?
- ¿Office o Windows?
- Microsoft XP .

La gente pensaba así por default.

Y algo así lo estoy viendo ahora con esta nueva tecnología llamada Microservicios: Solo se hace con SpringBoot.

Pues bien, en este post mostraré  tres (03) frameworks en Java que permiten hacer Microservicios, sin usar SpringBoot.

miércoles, 27 de diciembre de 2017

Java EE 8: Bean Validation

  No hay comentarios.
En Java EE 8, el api Bean Validation ha venido con mejoras.
Por ejemplo, ahora podemos validar un campo de tipo java.time.LocalDate

    @Past
    private LocalDate fechaIngreso;



También, determinar los límites de una lista:

    @NotEmpty
    private List<@Size(min = 1, max = 15) String> proyectos;



Al igual que un nuevo tipo de validación (y así evitar log RegEx)

    @Email
    private String email;



Podemos evaluar los campos validados desde el mismo Java (aquí un ejemplo desde una prueba unitaria):

    @Test
    public void testMemberWithNoValues() {
        Empleado e = new Empleado();
        e.setEmail("abc@");
        e.setDni("12345678");
        e.setProyectos(Arrays.asList("Proyecto 1", "Proy2", "Proy3"));

        // validate the input
        ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
        Validator validator = factory.getValidator();
        Set<ConstraintViolation<Empleado>> vs = validator.validate(e);
        vs.forEach((v) -> {
            System.out.println("--->" + v.getPropertyPath() + ":" + v.getMessage());
        });
    }



Ahora bien, este mismo Bean con validación puede ser usado dentro de un JSF:

    <h:body>
        <h:form>
            <h:outputLabel for="nombre" value="Nombre"/>
            <h:inputText id="nombre" value="#{formBean.empleado.nombre}" /><br/>
            <h:outputLabel for="email" value="Email"/>
            <h:inputText id="email" value="#{formBean.empleado.email}" /><br/>
            <h:outputLabel for="dni" value="DNI"/>
            <h:inputText id="dni" value="#{formBean.empleado.dni}" /><br/>

            <br/>
            <h:commandButton value="Enviar" />
        </h:form>
    </h:body>



Código fuente

Puedes ver este ejemplo en acción con este código fuente completo:
https://bitbucket.org/apuntesdejava/novedades-javaee-8/src/master/bean-validation/?at=master

lunes, 20 de noviembre de 2017

jueves, 16 de noviembre de 2017

lunes, 18 de septiembre de 2017

viernes, 15 de septiembre de 2017

Opinión: La alternativa de Java EE

  No hay comentarios.

Si vamos a usar un servidor Java EE (perfil completo) para implementar una solución, recomiendo utilizar todas las funcionalidades que vienen en la especificación: EJB, JPA, JMS, etc. Pero hay veces que no podemos contar con un servidor de ese tipo ya que, por ejemplo, el cliente no conoce más allá del Tomcat, o no exista gente que podría administrar un servidor como GlassFish, Payara, Weblogic, etc.

Entonces, llegamos a extrañar las funcionalidades dadas por Java EE, y optamos por otros frameworks que sí nos ayudan en nuestros momentos de limitaciones de servidor.

Spring ayudó mucho desde un inicio cuando no se contaba con servidores Java EE OpenSource completos. Caló tan fuerte entre los desarrolladores, que practicamente se ha hecho un "estándar" alterno a Java EE. Cuando los arquitectos de Java EE "despertó" y mejoró las especificaciones en la versión 5, pienso yo, ya era muy tarde. Tomcat siguió siendo el servidor "estándar" para aplicaciones "Java EE", con Spring (y de paso Hibernate) ya que el Tomcat no podía ejecutar EJB. Nadie extrañó (ni se enteró) de JPA 1.0, EJB 3.0, JSF 2.0 (que el ambiente MVC fue tomado por Apache con su framework Struts)

Ahora, esta nueva generación que aprende a programar en Java web, lo hace fuera del estándar oficial, solo usando el "estándar" Spring.

Aún así, agradecemos a los ingenieros de Spring por dar alternativas a desarrollar aplicaciones Java.

Esta semana Oracle decidió liberar a Java EE y entregárselo a Eclipse Foundation (Opening Up Java EE - An Update) y esto permitirá sacar de sus goznes a la versión 8 que tantos estamos esperando.

¿qué opino? No soy partidiario de Spring ni de Eclipse, pero - por el bien de los desarrolladores de Java - es mejor esto que seguir estancados con Oracle después que compró Sun Microsystems.

Java es un lenguaje y plataforma que tiene más de 20 años en el mercado... y con estas liberaciones (ah! NetBeans ya está en el Github bajo Apache Foundation) creo que seguiremos teniendo a Java para rato.

Finalmente, mi pregunta es: ¿Oracle aún emitirá certificaciones para Java EE?


lunes, 21 de agosto de 2017

jueves, 10 de agosto de 2017

miércoles, 26 de julio de 2017

lunes, 5 de junio de 2017

DataSources en una aplicación Java EE

  9 comentarios
Todas las aplicaciones en Java EE va a necesitar - al menos - una conexión a una base de datos relacional.

Según el Diseño de Patrones, la conexión a base de datos debe estar fuera de la aplicación que estamos construyendo.

Según el estándar de Java EE, la conexión a la base de datos debe estar basada en un Pool de Conexiones y que esté administrado por el Contenedor Java EE.

Esta conexión a la base de datos es a través de los DataSource del Contenedor Java EE.
En este post veremos que existen tres maneras para implementar un DataSource, con sus ventajas y desventajas, dependiendo de lo que uno desea para su propia implementación.



jueves, 6 de abril de 2017

sábado, 1 de abril de 2017

Payara Micro

  1 comentario
Ya estamos en una época en que no necesitamos de grandes servidores de aplicaciones para hacer funcionar una pequeña aplicación. Montar todo un entorno es cada vez más simple. Por ejemplo se está usando Docker para montar un entorno especializado únicamente para un fin: o base de datos, o servidor de aplicaciones, etc. Así se ahorran costos para configurar grandes entornos.

En el mundo de Java EE, hay alternativas para hacer aplicaciones más pequeñas y no depender de todo un servidor. De esta manera podemos tener microservicios en lugar de una aplicación monolítica. Spring Boot es una alternativa: unos cuantos scripts y ya tenemos una aplicación Spring listo para ejecutarse desde cualquier contenedor standalone.

Pero en este post escribiré de otra propuesta: Payara Micro.