En Java como en cualquier otro lenguaje de programación, es común encontrarnos con la necesidad de realizar conversión de tipos de datos, sobre todo, aquellos tipos de datos de Entidad que tiene una relación directa con un DTO que utilizamos para enviar los datos del servidor a un cliente o aplicación web, lo que hace que tengamos que convertir la Entidad a DTO para enviarla al cliente y de DTO a Entidad para persistirla en la base de datos, lo cual es una tarea cansada y repetitiva que podemos evitar mediante el uso del patrón Converter.

Si no sabes que es un DTO te dejo la siguiente liga a mi artículo
Data Transfer Object (DTO), donde explico a detalle este patrón.

Pues como lo acabo de decir, convertir tipos de datos es una tarea que se presenta mucho en las aplicaciones, pero sobre todo en la capa de negocio o servicios, donde tenemos que enviar un tipo de dato amigable para el cliente o navegador pero en el Backend necesitamos otros tipos de datos. Para evitar esta tarea tan repetitiva se puede utilizar el patrón Converter, el cual permite encapsular la lógica de conversión de dos tipos de datos de forma bidireccional, de esta forma, evitamos tener que repetir la lógica de conversión de los tipos de datos en todas las partes del programa donde sea requerido, y en su lugar, delegamos esta responsabilidad a una clase externa.

Para analizar esta problemática, analizaremos el caso típico de la Entidad Usuario, la cual tiene por lo general un id, username, password y los roles, tal como podemos ver a continuación:

package com.oscarblancarteblog.entity;

import java.util.List;
import com.oscarblancarteblog.enums.Role;

public class User {
	
	private Long id;
	private String username;
	private String password;
	private List<Role> roles;

	/** GET & SET */
}

Esta entidad es utiliza por el Backend para persisitir la información en la base de datos, sin embargo, no es la que utilizamos para enviar a los clientes, ya que por ejemplo, el campo `roles` es de un tipo de Enumeración, el cual no puede interpretar el cliente que quizás consuma el backend por medio de un API REST, por lo que es posible que en lugar de enviarle una lista de Roles, le tendremos que mandar un lista de Strings, lo que nos obliga a crear un DTO que se ve de la siguiente manera:

import java.util.List;

public class UserDTO {
	private Long id;
	private String username;
	private String password;
	private List<String> roles;

	/* GET & SET */
}

Este DTO ya es más amigable para el cliente, pero ahora tenemos un problema, como crear el DTO a partir del Entity y luego, cuando nos lo manden de regreso para guardarlo o actualizarlo, hay que hacer el proceso inverso. Por simple que parezca, esta es un tarea que se puede repetir muchas veces en la aplicación, creando mucho código redundante y que cada repetición puede inyectar errores, además, un cambio en la Entity o en el DTO, nos obliga a refactorizar todas las secciones donde habríamos echo la conversión, por este motivo, siempre es mejor crear una clase que se encargue exclusivamente de convertir entre Entity y DTO.

Para solucionar este problema y tener un mejor orden en nuestro código, deberemos crear una clase base de la cual extiendan todos los Converters de nuestra aplicación:

package com.oscarblancarteblog.converter;

public abstract class AbstractConverter<E,D> {

	public abstract E fromDto(D dto);

	public abstract D fromEntity(E entity);
}

Esta clase abstracta define dos método, fromEntity que convierte una Entidad a DTO y fromDto que hace lo inverso, adicional , la clase define dos tipos genéricos E para representar al tipo Entidad y D para representar al DTO.

El siguiente paso es crear implementaciones concretas del Converter, por que deberá existir una implementación por cada Par Entidad-DTO. En este caso solo tenemos la clase User, por lo que crearemos el Convertidor para esta clase:

package com.oscarblancarteblog.converter;

import java.util.stream.Collectors;

import com.oscarblancarteblog.dto.UserDTO;
import com.oscarblancarteblog.entity.User;
import com.oscarblancarteblog.enums.Role;

public class UserConverter extends AbstractConverter<User, UserDTO>{

	@Override
	public User fromDto(UserDTO dto) {
		User user = new User();
		user.setId(dto.getId());
		user.setUsername(dto.getUsername());
		user.setPassword(dto.getPassword());
		
		// Prevent NullPointerException
		if(dto.getRoles()!=null) {
			user.setRoles(dto.getRoles().stream().map(rol -> Role.valueOf(rol)).collect(Collectors.toList()));
		}
		return user;
	}

	@Override
	public UserDTO fromEntity(User entity) {
		UserDTO user = new UserDTO();
		user.setId(entity.getId());
		user.setUsername(entity.getUsername());
		user.setPassword(entity.getPassword());
		
		// Prevent NullPointerException
		if(entity.getRoles()!=null) {
			user.setRoles(entity.getRoles().stream().map(rol -> rol.name()).collect(Collectors.toList()));
		}
		return user;
	}
}

Esta nueva clase se encargará de convertir los dos tipos de datos dejando en un solo lugar la lógica de conversión y evitando tener que repetir esta lógica en toda nuestro código.

Podrás observar que esta clase no tiene gran ciencia, pues es básicamente tomar los valores de un objeto y pasarlos a otro objeto pero diferente tipo de datos, nada del otro mundo.

Ahora bien, ya con esto, ¿como le haríamos para convertir los datos?, pues ya solo falta instanciar al convertidor y utilizarlo. Imaginemos que tenemos un método que consulta un usuario:

public UserDTO findUserByUsername(String username) {
	User user = userDAO.findByUsername(username);
	UserConverter converter = new UserConverter();
	return converter.fromEntity(user);
}

En este método ya podemos observar las bondades del converter, pues nos deja un código muy limpio y no tenemos que preocuparnos por convertir la Entidad a DTO. Pero que pasaría si ahora nos mandan el Usuario como DTO para actualizarlo en la base de datos:

public void save(UserDTO userDto) {
	UserConverter converter = new UserConverter();
	User userEntity = converter.fromDto(userDto);
	userDAO.save(userEntity);
}

Nuevamente vemos como el converter nos ha salvado de nuevo, pues nos olvidamos de la lógica de conversión.

Pero que pasaría ahora si en lugar de buscar un solo usuario, necesitamos que nos regrese todos los usuarios, bueno, estos nos obligaría a retornar una lista en lugar de un solo usuario, por lo que tendriamos que implementar una lógica para convertir listas. Lo primero que se nos puede ocurrir es crear un for en el servicio anterior y convertir cada uno de los objetos, crear una nueva lista a partir de los resultados y retornar el valor, pero esto traerá el mismo problema que hablamos al inicio, pues tendríamos que repetir este proceso cada vez que necesitemos convertir una lista. Por suerte contamos con una clase base llamada AbstractConverter, ¿la recuerdas?

Que te parece si entonces aprovechamos esta clase base para agregar los método de conversión de listas y de esta forma, se podrán utilizar en todos los converters:

package com.oscarblancarteblog.converter;

import java.util.List;
import java.util.stream.Collectors;

public abstract class AbstractConverter<E,D> {

	public abstract E fromDto(D dto);
	
	public abstract D fromEntity(E entity);
	
	public List<E> fromDto(List<D> dtos){
		if(dtos == null) return null;
		return dtos.stream().map(dto -> fromDto(dto)).collect(Collectors.toList());
	}
	
	public List<D> fromEntity(List<E> entities){
		if(entities == null) return null;
		return entities.stream().map(entity -> fromEntity(entity)).collect(Collectors.toList());
	}
}

Observa que hemos agregado dos nuevos métodos, fromDto y fromEntity los cuales se encargan de convertir las listas aprovechando los método abstractos previamente definidos, de esta forma, en cuanto creemos una implementación de AbstractConverter tendremos de forma automática los método para convertir listas. Ahora veamos como quedaría el ejemplo de un servicio de consulta de todos los usuarios:

public List<UserDTO> findAllUsers() {
	List<User> users = userDAO.findAllUsers();
	UserConverter converter = new UserConverter();
	return converter.fromEntity(users);
}

Observemos que esta ves solo hace falta pasar la lista al Converter para que este se encargue de iterar la lista y crearnos una nueva con todos los datos convertidos.

Ya solo nos quedaría hacer un ejemplo de convertir una lista de DTO a Entity, pero creo que ya está de más, por lo que si tienes tiempo, puedes hacer una prueba tu mismo para que veas que funcionará de la misma forma.

Composición de convertidores

Otra de las ventajas de los convertidores es que podemos utilizar un Converter dentro de otro, por ejemplo, imagina que tienes una Entidad Invoice (factura) la cual tiene asociado al usuario que la creo:

package com.oscarblancarteblog.entity;

import java.util.List;

public class Invoice {
	
	private Long id;
	private User user;
	private List<Lines> lines;
}

No te voy a aburrir nuevamente con toda la explicación, así que solo nos enfocaremos en las novedades. Dicho esto, observar que entre todos los campos que puede tener una factura, tiene una referencia al Usuario, por lo que en el converter de la factura podríamos implementar nuevamente la lógica para convertir al usuario, pero eso sería estúpido, pues ya tenemos una clase que lo hace, por lo tanto, podríamos utilizar el converter del usuario dentro del converter de la factura:

package com.oscarblancarteblog.converter;

import com.oscarblancarteblog.entity.Invoice;
import com.oscarblancarteblog.entity.User;

public class InvoiceConverter extends AbstractConverter<Invoice, InvoiceDTO>{

	private final UserConverter userConverter = new UserConverter();
	
	@Override
	public Invoice fromDto(InvoiceDTO dto) {
		
		Invoice invoice = new Invoice();
		invoice.setUser(userConverter.fromDto(dto.getUser()));
		// ... other setters
		return invoice;
	}

	@Override
	public InvoiceDTO fromEntity(Invoice entity) {
		InvoiceDTO invoice = new InvoiceDTO();
		invoice.setUser(userConverter.fromEntity(entity.getUser()));
		// ... other setters
		return invoice;
	}
}

En este nuevo converter podemos ver que hemos instanciado a UserConverter y lo hemos utilizado para convertir el usuario en lugar de volver a implementar la lógica de conversión aquí.

Conclusiones

Hemos podido comprobar que los convertidores son de gran ayuda para evitar la repetición de código que puede se tedioso y propenso a errores, además, vemos que mediante la composición podemos reutilizar los convertidores para crear convertidores más avanzados.

Solo me resta mencionar un detalle importante, y es que debemos de tener cuidado que datos regresamos al cliente, ya que por ejemplo, regresar el password de nuestros usuarios a nuestros clientes puede ser una mala idea, así que podemos omitir este campo en el converter o eliminarlo de los objetos una vez que ha sido convertido, todo dependerá de que te funcione mejor.

Finalmente, recuerda que la clase base AbstractConverter es un punto de partida importante para implementar método genéricos para todos los convertidores, por lo que debemos aprovecharla si queremos agregar nuevos método en el futuro.

The post Java Converter Pattern appeared first on Oscar Blancarte - Software Architecture.

Es habitual que algunos de los parámetros de nuestros servicios sean opcionales para el cliente, lo que provocaría la llega de estos valores en null para nuestra API, lo que puede resultar un problema para algunos parámetros que son requeridos para el correcto funcionamiento del API y que al menos debemos de tener un valor por defecto en caso de no enviarse.

NOTA: Este artículo es parte de un tutorial completo para crear API REST con JAX-RS, si quieres ver el índice completo entra aquí.

Mediante la anotación @DefaultValue podemos establecer un valor por default a algunos de nuestros parámetros que son opcionales para el cliente, lo que evita que tengan un valor nulo al llegar al API. Esta característica es especialmente buena en casos en los que el API necesita que estos parámetros tengan algún valor a pesar que el cliente no lo envíe, pues dejarlos en null puede provocar el fallo del servicio.

Imaginemos el siguiente ejemplo, tenemos que construir un servicios de consulta de clientes que permita paginar los resultados, por lo que el servicio deberá proporcionar la página actual y el número de registros esperados por página. En este ejemplo, podríamos imagina que si los valores no se definen, entonces el API debería de retornar todo, pero esto puede provocar un problema de performance, por que hay muchísimos clientes y cada cliente tiene una serie de objetos asociados que deberán ser retornados también, provocando una gran carga sobre la base de datos, es por ello, que debemos asegurarnos de que si el API no recibe estos parámetros entonces deberemos establecer un valor por default. Veamos el siguiente ejemplo:

package api.services;

import java.util.*;
import javax.ws.rs.core.*;

@Path("customers")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class CustomersService {
	
	@GET
	public Response getCustomers(
			@DefaultValue("1") @QueryParam("currentPage") int currentPage, 
			@DefaultValue("10") @QueryParam("pageSize") int pageSize) {
		
		//Validate input
		if(currentPage < 1 || pageSize < 1) {
			return Response.ok("Invalid params").build();
		}
		
		//ccreate Dataset 
		List<String> customers = new ArrayList<>();
		for(int c = 1 ; c<=100 ; c++) {
			customers.add("Customer " + c);
		}
		
		//Calculate sublist range
		int startIndex = (currentPage-1) * pageSize;
		int endIndex = startIndex + pageSize;
		
		//No more results
		if(startIndex >=customers.size()) {
			return Response.ok(new Object[0]).build();
		}
		
		//Prevent ArrayIndexOutOfBoundsException
		if(endIndex > customers.size()) {
			endIndex = customers.size();
		}
		
		//Getting sublist of elements
		List<String> filters = customers.subList(startIndex, endIndex);
		
		return Response.ok(filters)
				.header("x-size", customers.size())
				.header("x-startIndex", startIndex)
				.header("x-endIndex", endIndex)
				.build();
	}	
}

Para este ejemplo hemos definido que si el cliente no envía la página actual (currentPage) le daremos el valor de 1 por default, y para el tamaño de la página (pageSize) hemos definido el valor de 10. Esto quiere decir que en caso de que el cliente no envíe estos parámetros, regresaremos los 10 primeros registros.

También hemos retornado los headers x-size, x-startIndex, x-endIndex como metadato para el cliente, para que sepa el total de los elementos, el index del primer registro y el último respectivamente.

Veamos algunos ejemplos. En primer lugar probaremos ejecutar el servicio sin ninguno de los parámetros, para comprobar los valores por default:

Podemos comprobar que se han retornado los primeros 10 resultados.

Hora probaremos únicamente con el parámetro pageSize=3, lo que establecerá la página por default en 1, regresando los primeros 3 resultados:

Conclusiones

Los valores por default son una excelente opción para lidiar con valores requeridos por el API, pero que nos obligatorios para el cliente, sin embargo, el echo de que tengamos valores por default, no significa que no debemos validar los parámetros, pues el cliente siempre podrá enviar valores no esperados por el API que provoquen una falla o en el peor de los casos, hacer una inyección SQL.

The post Valores por defecto con @DefaultValue appeared first on Oscar Blancarte - Software Architecture.

Los bean params hacen referencia a la capacidad de JAX-RS para recibir como parámetro objetos complejos definidos por una clase, esta clase puede ser vista como un Data Transfer Object (DTO), la cual contiene una serie de propiedades recuperadas de varias partes del request, como el header, query, path y formulario.

NOTA: Este artículo es parte de un tutorial completo para crear API REST con JAX-RS, si quieres ver el índice completo entra aquí.

Los Beans params no es una característica nativa del protocolo HTTP o la arquitectura REST, si no que JAX-RS la agrega para poder mapear todos los tipos de parámetros en una sola clase, la cual podríamos ver como un DTO que concentra en un solo punto todos los parámetros esperados.

Para comprender mejor como funcionan los Beans params, imaginemos que tenemos un formulario para registrar nuevos clientes, este formulario enviara al servicio todos los campos al API por medio de @FormParams, también enviaremos como un header un token de autenticación, para identificar al usuario que está realizando la invocación, imaginemos que el cliente llego por medio de una campaña promocional, por lo que necesitamos saber si llego por facebook, google, etc. por lo que enviaremos un @QueryParam para saber de donde llego el cliente.

Este caso, podríamos crear un parámetro en Java para uno de los parámetros esperados o podríamos crear una clase como la siguiente:

package api.services;

import javax.ws.rs.*;

public class CustomerDTO {
	@CookieParam("token") 
	private String token;

	@FormParam("firstname") 
	private String firstname; 
	
	@FormParam("lastname") 
	private String lastname;
	
	@FormParam("status") 
	private String status;
	
	@QueryParam("source")
	private String source;

	/* GET and SET */
}

La clase CustomerDTO es en realidad una composición de variables que son recuperadas de varias partes de la petición. Solo en este caso hemos recuperado parámetros de las cookies (@CookieParam), form (@FormParam), query (@QueryParam), sin embargo, la idea de los @BeanParam es que se pueden utilizar cualquiera de las @xxxParam, lo que quiere decir que podemos utilizar:

• @PathParam
• @QueryParam
• @MatrixParam
• @CookieParam
• @HeaderParam

El siguiente paso es crear un método REST que reciba el @BeanParam:

package api.services;

import java.util.Map;

import javax.ws.rs.*;
import javax.ws.rs.core.*;

@Path("customers")
public class CustomersService {
	
	@POST
	@Produces(MediaType.APPLICATION_JSON)
	@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
	public Response saveCustomer(@BeanParam CustomerDTO customer) {
		
		String result = String.format("firstname = %s, lastname = %s, status = %s, token = %s, source = %s", 
				new Object[]{customer.getFirstname(), 
						customer.getLastname(),
						customer.getStatus(), 
						customer.getToken(),
						customer.getSource()});
		
		return Response.ok(result).build();
	}	
}

El formulario con el que invocaremos el servicio REST es el siguiente:

<!DOCTYPE html>
<html>
	<body>
		<p>Customer form</p>
	
		<form action="http://localhost:8080/api-0.0.1-SNAPSHOT/customers?source=google" method="post">
			<div>
				<label for="firstname" style="display:inline-block; width: 100px;">Nombre</label>
				<input id="firstname" type="text" name="firstname" />
			</div>
			<div>
				<label for="lastname" style="display:inline-block; width: 100px;">Apellido</label>
				<input id="lastname" type="text" name="lastname" />
			</div>
			<div>
				<label for="status" style="display:inline-block; width: 100px;">Estatus</label>
				<select id="status" name="status" >
					<option value="active">Activo</option>
  					<option value="inactive">Inactivo</option>
				</select>
			</div>
			<br/>
			<input type="submit" value="Guardar" />
		</form>
	</body>
</html>

Observemos que hemos agregado el query param en el action del <form>, por lo que será enviado al servidor al momento del submit.

Adicional, agregaremos la cookie token directamente desde el inspector de chrome:

Y obtendremos el siguiente resultado:

Conclusiones

Como hemos podido validar, los @BeanParam son una excelente estrategia para realizar una composición de una serie de parámetros en una sola fuente de datos, los cuales podríamos fácilmente reutilizar para más de un servicio. Además, nos evita tener que definir una serie de parámetros para poder recuperar cada uno de los valores esperados.

The post Bean Params con @BeanParam appeared first on Oscar Blancarte - Software Architecture.

Las cookies son hasta la fecha una de las formas más utilizadas que tenemos para persistir valores del lado del cliente, las cuales pueden ser recuperadas por el servidor para identificar a un usuario, darle seguimiento o simplemente para guardar algún valor que utilizaremos después.

NOTA: Este artículo es parte de un tutorial completo para crear API REST con JAX-RS, si quieres ver el índice completo entra aquí.

Todas las cookies que guardemos en el cliente serán transmitidas al servidor de forma automática al servidor en los request posteriores, lo que puede ser de grán ayuda para identificar la sesión del usuario, el estado o incluso, guardar tokens de autenticación para identificar al usuario en cada llamada.

Las cookies no es algo que podamos ver a simple vista, pues solo se pueden ver con ayuda de herramientas que monitoren el tráfico HTTP, como es el caso del inspector de elementos de Chrome u otras herramientas especializadas como es el caso de Restlet, SOAPUI, postman, etc.

Desde chrome podemos ver todas las cookies que una página ha dejado en nuestro equipo, e incuso, podríamos agregar algunas manualmente para realizar algunas pruebas. Para verlas, solo basta abrir el inspector de elementos, dirigirse a la pestaña de Application y seleccionar la opción de cookies, tal como podemos ver en la siguiente imagen:

Recuperar las Cookies con JAX-RS

Mediante el API de JAX-RS es muy fácil de recuperar las cookies del lado del servidor, ya que solo es necesario anotar con @CookieParam alguno de los parámetros del método Java en la cual queremos inyectar el valor de una cookie. Veamos el siguiente ejemplo que espera una cookie de autenticación llamado token:

package api.services;

import java.util.Map;

import javax.ws.rs.*;
import javax.ws.rs.core.*;

@Path("customers")
public class CustomersService {

	@POST
	@Produces(MediaType.TEXT_PLAIN)
	@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
	public Response saveCustomer(
			@CookieParam("token") String token) {
		
		if("1234".equals(token)) {
			return Response.ok("OK").build();
		}else {
			return Response.ok("UNAUTHORIZED").status(Response.Status.UNAUTHORIZED).build();
		}
	}
}

En este ejemplo estamos el header token, el cual deberá tener el valor 1234, de lo contrario, mandaremos un error de autenticación.

Establecer una nueva Cookie

Otra cosa que podemos hacer es establecer una nueva cookie en el cliente, por ejemplo, podríamos agregar el token en caso de que este no tenga uno, veamos cómo quedaría:

package api.services;

import java.util.Map;
import javax.ws.rs.*;
import javax.ws.rs.core.*;

@Path("customers")
public class CustomersService {

	@POST
	@Produces(MediaType.TEXT_PLAIN)
	@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
	public Response saveCustomer(
			@CookieParam("token") String token) {
		
		if(token == null) {
			NewCookie newToken = new NewCookie("token", "1234");
			return Response.ok("OK").cookie(newToken).build();
		}
		
		return Response.ok("OK").build();
	}	
}

Utilizamos la clase NewCookie para definir una nueva cookie que deberá ser creada en el cliente, demás, utilizamos el método cookie de la clase Response para enviarla al cliente.

Conclusiones

A pesar de que las cookies han sido la forma tradicional de guardar los datos en el cliente, la llegada de HTML5 nuevas alternativas, como lo es el Local Storage y el Session Storage, de los cuales no hablaremos en esta ocasión, pero las menciono por si quieres investigar un poco más al respecto.

The post Cookie params con @CookieParam appeared first on Oscar Blancarte - Software Architecture.

Los header son utilizados en REST para enviar metadatos asociados a la petición o la respuesta, los cuales van desde el formato y tamaño del payload, nombre del servidor del servidor de aplicaciones, fecha de invocación, caducidad de un recurso, versión y nombre del sistema operativo, tipo de navegador, dispositivo, lenguaje y hasta headers para la seguridad.

NOTA: Este artículo es parte de un tutorial completo para crear API REST con JAX-RS, si quieres ver el índice completo entra aquí.

Los headers es una sección adicional al payload de una solicitud, la cual no puede ser vista a simple vista, si no que requiere de un analizador HTTP para poderlos ver, sin embargo, todas las solicitudes llevan por default una serie de headers, incluso si nosotros no las establecemos. Los headers enviados por default varían de cliente a cliente y de servidor a servidor, por lo que en este artículo aprenderemos a analizar los headers.

Uno de los principales usos de los header es para enviar los tokens de
autenticación, como es el caso de JSON Web Token (JWT), el cual lo establecemos en el header Authorization, dicho lo anterior, veremos como recuperar este header mediante el API JAX-RS de Java.

package api.services;

import javax.ws.rs.*;
import javax.ws.rs.core.*;

@Path("security")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class Security {
	
	@GET
	public Response authenticate(@HeaderParam("authorization") String token) {
		return Response.ok("token="+token).build();
	}
}

Los header pueden ser recuperados anotando los parámetros con @HaderParam, por lo que vamos a requerir un parámetro en Java por cada header que esperamos recibir en el API.

Si ejecutamos el ejemplo anterior, podemos ver el siguiente resultado:

En la parte superior podemos ver los header que definimos en el request y en la parte de abajo los header que nos retorno el servidor; en la respuesta podemos ver el token que le hemos enviado.

Otra de las formas de recuperar los header es por medio de la clase HttpHeaders, la cual podemos inyectar a nuestro método mediante la anotación @Context. La ventaja evidente de esté método es que podemos recuperar cualquier header, sin importar si lo esperábamos o no y nos evita tener que definir una grán cantidad de parámetros si esperamos muchos headers. Veamos un nuevo ejemplo con este método:

package api.services;

import java.util.Map;

import javax.ws.rs.*;
import javax.ws.rs.core.*;

@Path("security")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.TEXT_PLAIN)
public class Security {
	
	@GET
	public Response authenticate (@Context HttpHeaders headers) {
		String result = "";
		for(Map.Entry entry: headers.getRequestHeaders().entrySet() ) {
			result += entry.getKey() + "=" + entry.getValue() + ", ";
		}
		
		return Response.ok(result).build();
	}
}

Ahora veamos una ejecución de prueba:

En este caso, podemos observar que hemos recibido muchos más parámetros de los que enviamos, y esto se debe a lo que mencionamos al inicio, y es que cada cliente agrega una serie de headers para identificarlo.

Agregar headres en la respuesta

Ademas de recibir headers, también podemos enviar headers a los clientes del API; los headers los podemos agregar directamente al objeto Response, mediante una serie de claves-valor, veamos un ejemplo:

package api.services;

import java.util.Map;
import javax.ws.rs.*;
import javax.ws.rs.core.*;

@Path("security")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.TEXT_PLAIN)
public class Security {
		
	@GET
	public Response authenticate (@Context HttpHeaders headers) {
		String result = "";
		for(Map.Entry entry: headers.getRequestHeaders().entrySet() ) {
			result += entry.getKey() + "=" + entry.getValue() + ", ";
		}
		
		Response.ResponseBuilder response = Response.ok(result);
		response.header("my-header1", "value 1");
		response.header("my-header2", "value 2");
		
		return response.build();
	}
}

Conclusiones

No debemos de confundirnos al momento de utilizar los headers, pues no se deben de utilizar como una forma de enviar parámetros a nuestro API, si no como metadatos que complementen el request y que ayuden al servidor/cliente como tratar la solocitud/respuesta.

The post Header params con @HeaderParam appeared first on Oscar Blancarte - Software Architecture.

Como programador seguramente has trabajado con una infinidad de colecciones, seguramente te ha tocado recorrerlas, ordenarlas, dividirlas, filtrarlas, eliminar o agregar nuevos elementos en la colección. Y cada vez que hacías esto estabas casi forzado a realizar un foreach sobre la colección, incluso, tenías que hacer un foreach anidado para poder realizar operaciones más complejas; prueba de ello es que el nombre ConcurrentModificationException  te recuerda a algo (¿o no?).

Pues bien, los Streams no permite crear atajos a la hora de procesar colecciones, creando flujos de datos que permite el procesamiento de una forma declarativa, es decir, que nos centramos en lo que queremos resolver, y no en cómo debemos hacerlo, como pasa en la programación imperativa.

Sígueme en mi canal de Youtube

Pero dejémonos de palabrerías (que me sobran) y vallamos a un escenario concreto donde se puede aplicar para entender mejor. Veamos el caso más simple al utilizar una colección, imprimamos todos los valores de una lista ¿Simple no?

public static void printForeach(){
  List<String> names = getStringArray();
  for (String name : names) {
     System.out.println(name);
  }
}

Este código que está viendo, es un escenario normal que utilizarías para imprimir todos los elementos de una lista (apuesto que sí), ¿verdad que no tiene nada de extraño? La verdad es que no, porque ya estamos acostumbrados a hacerlo así, pero te apuesto que tu punto de vista acerca de este código cambiaría si ti dijera que puedo hacer el foreach en una solo línea de código. ¿no me crees? Pues tómala!!

public static void printStream(){
    List<String> names = getStringArray();
    names.stream().forEach(System.out::println);
}

Probablemente te estés preguntado ¿qué clase de brujería es eso?, pero la realidad es que no hay tal brujería, simplemente estamos utilizando los Streams. Notemos que estamos utilizando el método stream() para obtener el Stream, seguido, solo utilizamos el método forEach() en el cual definimos mediante lo que vamos a hacer para cada elemento de la colección. En este caso estamos imprimiendo cada empleado utilizando Referencia a métodos.

Para comprender mejor que es un stream (espero no herir los sentimientos de algunos) lo voy a explicar de una forma simple fácil de digerir y que pueda que no cuadre con la definición perfecta, pero seguro me entenderás. Imagina que los streams son una forma de iterar todos los elementos de la colección de una forma simple, y que además mientras los iteras puedes realizar operaciones sobre la colección de forma declarativa. Es decir, vamos a realizar operaciones pero centrándonos en el objetivo que buscamos, no en cómo implementar el algoritmo para que funcione. Veamos otro ejemplo más complejo.

Imaginemos que tenemos una lista de Empleados, cada empleado tiene un ID que lo identifica como único, tiene un nombre y el departamento el que pertenece. La lista de empleados es la siguiente:

Ahora bien, sobre esta lista queremos filtrar todos los Empleados que pertenecen al departamento de sistemas, luego vamos a ordenas todos los empleados de forma ascendente por su nombre, luego vamos a filtrar los elementos repetidos mediante su ID, finalmente, imprimiremos el nombre de todos los empleados que cumplieron con todas las reglas. Pfff!! ¿Imaginas hacer esto con una colección? A mí ya me empezó a doler la cabeza 🙁 . Por suerte, el enfoque declarativo de los Streams nos permite enfocarnos solamente en el que y no en el cómo. Veamos cómo quedaría la solución usando Streams.

public static void printOrderedSystemEmployees(){
    List<Employee> employess = getEmployeeArray();
    employess.stream()
            .filter(x -> x.getDepartment().equals("Systems"))
            .sorted((x,y) -> x.getName().compareToIgnoreCase(y.getName()))
            .distinct()
            .forEach(System.out::println);
}

Ves lo fácil que es hacer todo esto con los Streams, solo nos preocupamos por lo que queremos hacer pero no por el cómo. Veamos los métodos del Stream utilizados, filter, nos permite filtrar elementos de la lista, para lo cual solo deberemos crear una expresión que regrese un boolean, si regresa true, entonces es agregado al Stream de resultados. Luego tenemos el método sorted() en el cual definimos cual es mayor mediante la comparación de los nombres. Seguido, utilizamos el método distinct() para filtrar los Empleados repetidos, para esto hemos sobreescrito el método equals para comprar por el ID en lugar del Hashcode. Finalmente un foreach para imprimir los resultados:

• Fernanda Martinez
• Liliana Castro
• Oscar Blancarte
• Rebeca Perez

¡Realmente sorprendente verdad!!, al menos para mí si… Pues bien, así como vimos algunos métodos interesantes de los Streams, debes de saber que la interface Stream proporciona varios métodos interesantes que te pueden ayudar muchísimo, sin embargo la intención de este artículo es introducirte en el concepto de los Stream y que logres entender que son y cómo se utilizan, por lo que si quieres aprender todavía más, poder ver este link, donde explican a profundidad la interface Stream y todos los métodos que expone. Me gustaría explicarte a detalle cada uno de los métodos disponibles, pero en realidad creo que sería reinventar la rueda, pues en el link se explica mucho mejor de lo que yo mismo podría hacerlo.

El resultado se puede apreciar mejor con la siguiente imagen:

En fin, creo que si lograste entender que son los Streams yo me doy por bien servidor, pero si por algún motivo tienes alguna duda, puedes escribirme en la sección de comentarios y con gusto te contestaré.

The post Java 8 – Streams appeared first on Oscar Blancarte - Software Architecture.

Básicamente Java ofrece dos interfaces que serán claves para realizar un ordenamiento simple, las cuales son Comparator  y Comparable, estas dos interfaces atienden contextos diferentes en el ordenamiento de las listas, pues existen dos escenarios concretos (Si ya conoces la teoría puedes brincarte a la última sección):

Objetos preparados para ser Ordenados

El escenario más simple para ordenar un Lista, es cuando sus elementos están preparados para ser ordenados, esto implica que los elementos de la lista implementan la interface Comparable. Al implementar esta interface, las clases deberá implementar el método public interface Comparable<T>, el cual sirve para comprar un objeto contra otro, este método recibe como parámetro otro objeto, el cual utilizaremos para comprarlo contra el actual para responder con un entero, el cual deberá ser:

• < 0 (Menor que cero): cuando el objeto actual es menor que el otro
• = 0 (Igual a cero): cuando los objetos son iguales
• > 0 (Mayor que cero): cuando el otro objeto es mayor.

Cuando una clase implementa Comparable entonces podemos decir que está preparada para ser Ordenada y ordenarla será tan simple como hacer lo siguiente:

Collections.sort(lstSortEmployees);

Asumiendo que la variable lstSortEmployees es una lista de objetos que implementan Comparable.

Objetos que no están preparados para ser Ordenados

Por otra parte, las clases que no implementan Comparable no podrán ser ordenadas de forma natural, por lo que tendremos que recurrir a la interface Comparator, la cual sirve para crear una clase externa que ayude al ordenamiento de los Objetos sin modificar la estructura de las clases existentes. Para lo cual será necesario crear una nueva clase que implementa la interface Comparator y con ello el método int compare(T o1, T o2), el cual funciona exactamente igual que el de la interface Comparable, solo que este recibe como parámetros los dos objetos que será comparados.

Ahora bien, si queremos ordenar una lista mediante este método podríamos hacerlo de la siguiente manera:

Collections.sort(lstEmployees, new EmployeeComparator());

Donde lstEmployees es la lista de objetos a ordenar y EmployeeComparator es una clase que implementa Comparator. Aunque también podríamos ahorrarnos la creación de una nueva clase y crear una clase anónima, como podemos ver a continuación:

Collections.sort(lstEmployees, new Comparator<Employee>(){

    @Override
    public int compare(Employee o1, Employee o2) {
        return o1.getName().compareToIgnoreCase(o2.getName());
    }
});

Veamos que este último ejemplo instanciamos la interface Comparator al vuelo y definimos el método compare para determinar cuál empleado es mayor que cual.

Finalmente, Java 8 ofrece una forma muchos más simple de ordenar los objetos utilizado Lamba Expresión, por lo cual en lugar de crear un Comparator, solo definimos la estrategia para comparar los objetos, veamos cómo quedaría:

Collections.sort(lstEmployees, (x, y) -> x.getName().compareToIgnoreCase(y.getName()));

Mediante lamba expresión definimos solamente como los objetos deberán ser comparados.

Un ejemplo práctico:

Muy bonita la explicación, pero pasemos mejor a un ejemplo práctico. Vamos a ver un ejemplo rápido para realizar los 3 tipos de ordenamientos que vimos anteriormente. Todo el código fuente lo puedes encontrar el GiHub: https://github.com/oscarjb1/SortList.git

package com.osb.sortlist;

import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

/**
 * @author Oscar Blancarte <oscarblancarte3@gmail.com>
 */
public class SortMain {

    private static final String[] NAMES = new String[]{
        "Oscar Blancarte",
        "Juan Perez",
        "Gabriel German",
        "Liliana Castro",
        "Alfredo Alvarado",
        "Rebeca Hernandez",
        "Sofia Galindo",
        "Samuel Alvarez",
        "Manuel Orozco"
    };

    public static void main(String[] args) {

        //Ordenar empleados que estan preparados para ser ordenados
        List<SortEmployee> lstSortEmployees = getSorteableEmployeeList();
        Collections.sort(lstSortEmployees);
        printList("lstSortEmployess ==>", lstSortEmployees);

        //Ordenar empleados que no estan preparados para ser ordenados
        List<Employee> lstEmployees = getEmployeeList();
        Collections.sort(lstEmployees, new Comparator<Employee>(){
            @Override
            public int compare(Employee o1, Employee o2) {
                return o1.getName().compareToIgnoreCase(o2.getName());
            }
        });
        printList("lstEmployees ==>", lstEmployees);

        //Ordenas Empleados con Lambda Expresion
        Collections.sort(lstEmployees, (x, y) -> x.getName().compareToIgnoreCase(y.getName()));
        printList("lstEmployees Lambda ==>", lstEmployees);
    }

    private static void printList(String title, List list) {
        System.out.println(title);
        list.forEach(x -> System.out.println("\t" + x.toString()));
        System.out.println("");
    }

    private static List<Employee> getEmployeeList() {
        List<Employee> employees = new ArrayList<>();
        for (String name : NAMES) {
            employees.add(new Employee(name));
        }
        return employees;
    }

    private static List<SortEmployee> getSorteableEmployeeList() {
        List<SortEmployee> employees = new ArrayList<>();
        for (String name : NAMES) {
            employees.add(new SortEmployee(name));
        }
        return employees;
    }
}

La siguiente clase representa un empleado que no está preparado para ser ordenado:

package com.osb.sortlist;

/**
 * @author Oscar Blancarte <oscarblancarte3@gmail.com>
 */
public class Employee {
    private String name;
    
    public Employee(){
    }

    public Employee(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    @Override
    public String toString() {
        return name;
    }
}

Este otro empleado si está preparado para ser ordenado:

package com.osb.sortlist;

/**
 * @author Oscar Blancarte <oscarblancarte3@gmail.com>
 */
public class SortEmployee implements Comparable<SortEmployee> {
    
    private String name;

    public SortEmployee( String name) {
        this.name = name;
    }

    @Override
    public int compareTo(SortEmployee employee1) {
        return this.name.compareToIgnoreCase(employee1.name);
    }

    @Override
    public String toString() {
        return name;
    }
}

El resultado de la ejecución del proyecto nos da el siguiente resultado:

lstSortEmployess ==>
    Alfredo Alvarado
    Gabriel German
    Juan Perez
    Liliana Castro
    Manuel Orozco
    Oscar Blancarte
    Rebeca Hernandez
    Samuel Alvarez
    Sofia Galindo

lstEmployees ==>
    Alfredo Alvarado
    Gabriel German
    Juan Perez
    Liliana Castro
    Manuel Orozco
    Oscar Blancarte
    Rebeca Hernandez
    Samuel Alvarez
    Sofia Galindo

lstEmployees Lambda ==>
    Alfredo Alvarado
    Gabriel German
    Juan Perez
    Liliana Castro
    Manuel Orozco
    Oscar Blancarte
    Rebeca Hernandez
    Samuel Alvarez
    Sofia Galindo

Como puedes ver, estamos realizando tres ordenamientos, el primero es con una lista de SortEmployee, el segundo ordenamiento es con una lista de Employee, y la tercera es utilizando lamba expresión.

Espero que esta explicación sea lo suficientemente clara como para aclarar cualquier duda que tuvieras, pero si no es así, recuerda que puedes escribirme en los comentarios y con gusto te responderé.

The post Ordenar Listas en Java appeared first on Oscar Blancarte - Software Architecture.

La siguiente imagen muestra más claro cómo funciona la referencia a métodos:

En la imagen podemos ver una interface funcional, la cual define un método abstracto, por otro lado, tenemos una clase Custom, la cual define un método implementado, este método tiene un cuerpo y una funcionalidad previamente implementada. Sabemos que el método abstracto de la interface funcional no tiene implementada una funcionalidad, pues es una interface, y queremos que el método abstracto haga referencia al método de la clase Custom, por lo cual “asignamos” o referenciamos el método de la clase custom por medio del método de la interface funcional. Para que un método pueda ser referenciado debe de coincidir los parámetros y el retorno de la interface funcional con el del método que queremos referenciar, por lo tanto, el nombre del método no importaría.
¿Pero cómo funciona esto?
Cuando referenciamos un método, lo que pasa es que la funcionalidad del método original es implementada con una referencia al método referenciado, esto quieres decir que cuando ejecutemos el método de la interface funcional, en realidad lo que pasara es que se ejecutara el método de la otra clase.

Tipos de métodos referenciados:

• Referencia a un método estático
• Referencia a un método de un objeto
• Referencia a un método de un objeto arbitrario
• Referencia a un constructor

Antes de explicarlos, me gustaría que vieras el código, trates de familiarizarte con las clases para después entrar en la explicación. El código completo lo puedes encontrar GitHub: https://github.com/oscarjb1/MethodReferences.git

La siguiente clase es un Interface Funcional debidamente anotada con @FunctionalInterface , Esta interface la cual utilizaremos como base para referenciar los métodos.

package com.osb.referencedmethod;

/**
* @author Oscar Blancarte <oscarblancarte3@gmail.com>
*/
@FunctionalInterface
public interface IHello {
public void sayHello();
}

La siguiente clase será utilizada para referencias a su constructor.

package com.osb.referencedmethod;

/**
* @author Oscar Blancarte <oscarblancarte3@gmail.com>
*/
public class Hello implements IHello {

private String helloMessage;

public Hello() {
System.out.println("Hey!!! i'am a constructor");
}

public void createHello(String helloMessage) {
this.helloMessage = helloMessage;
}

@Override
public void sayHello() {
System.out.println(this.helloMessage);
}
}

La siguiente clase tiene el contenido más importante de este artículo, en ella veremos los 4 tipos de referencias a métodos.

package com.osb.referencedmethod;

import com.osb.referencedmethod.IHello;
import java.util.Arrays;

/**
* @author Oscar Blancarte <oscarblancarte3@gmail.com>
*/
public class Methods {
public static void sayStaticHello() {
System.out.println("Hey!!! i'am a static hello!");
}

public void sayInstanceHello() {
System.out.println("Hey!!! i'am a instance hello");
}

public static void main(String[] args) {
//Referencia a un método estatico
IHello staticRef = Methods::sayStaticHello;
staticRef.sayHello();

//Referencia a un método de un objeto
Methods methods = new Methods();
IHello instanceRef = methods::sayInstanceHello;
instanceRef.sayHello();

//Referencia a un método de un objeto arbitrario
String[] names = new String[]{"Oscar", "Alex", "Maria", "Samuel", "Perla", "Fausto"};
Arrays.sort(names, String::compareToIgnoreCase);
System.out.println("Hey!!! i'am a ordered array " + Arrays.toString(names));

//Referencia a un constructor
IHello hello = Hello::new;
hello.sayHello();
}
}

Una vez, analizadas las clases pasaremos explicar, pero antes, me gustaría que vieras el resultado de la ejecución del proyecto:

Hey!!! i'am a static hello!
Hey!!! i'am a instance hello
Hey!!! i'am a ordered array [Alex, Fausto, Maria, Oscar, Perla, Samuel]
Hey!!! i'am a constructor

¡Impresionante no!!!, ¿esperabas este resultado? Si es así, entonces quieres decir que ya estas más familiarizado con Java 8 y las expresiones lambda, pero si no es así, no importa, porque a continuación explicaremos lo que está pasando. Para hacer esta explicación más simple, asumiremos que ya conocemos que son las interfaces funcionales, si no es así, aquí explico cómo. Pues bien, iniciaremos con las referencias a los métodos estáticos, para lo cual regresaremos a las líneas 20-21, observemos que estamos creando la variable staticRef, la cual es de tipo IHello (Recordemos que IHello es una interface funcional), pero al asignarle valor a la variable, no lo hacemos con un new, si no que indicamos que la interface funcional se debe implementar con el método sayStaticHello el cual está definido en la clase Methods, para hacer la referencia al método sayStaticHello de la clase Methods. Para hacer la referencia se utiliza :: (Cuadro puntos o dos dobles punto). Al ejecutar el método en la línea 21, vemos que se imprime “Hey!!! i’am a static hello!”.
La otra forma de implementar las referencias es por medio de los métodos a un objeto en particular como en las líneas 24-26, en la cual vemos que primero instanciamos la clase Methods, luego volvemos a utilizar :: para hacer referencia al método sayInstanceHello, observa que esta vez utilizamos el objeto en lugar de la clase, ya que este método no es static. Al ejecutar el método se imprimirá “Hey!!! i’am a instance hello”.
Otra de las formas de implementar la referencia a métodos es por medio de un objeto arbitrario. Se dice arbitrario, porque en realidad no sabes sobre que objeto vamos hacer la referencia, pero si sabes el tipo de datos, por lo tanto, podemos asumir los métodos que tiene para referenciarlos. Un ejemplo de esto está en las líneas 29-31. Veamos lo que vamos a hacer, tenemos un Array de Strings el cual tiene una serie de nombre que queremos ordenar, para lo cual vamos a utilizar la clase Arrays, esta clase nos permite ordenar Objetos que implementen la interface Comparator, esta interface es una interface funcional debido a que solo tiene el método public int compareTo(T o), por lo que podríamos mandar una referencia a un método que pueda implementarla, en este caso veamos que al método sort le mandamos el array de nombre y una referencia al método compareToIgnoreCase el cual tiene la siguiente definición public int compareToIgnoreCase(String str), veamos que tanto compareTo y compareToIgnoreCase reciben el String a comprar y los dos regresan un int, por lo tanto la referencia a métodos es compatible. Lo que pasa entonces en la línea 30, es que la lista será iterada, y por cada String, llamará a su método compareToIgnoreCase, notemos algo muy importante…. La instrucción String::compareToIgnoreCase, no es una referencia a un método estático como podríamos creer, en su lugar, como sabemos que es una lista de String, le estamos diciendo que de cada String que está en la lista, use su método compareToIgnoreCase para comprar el siguiente elemento de la lista. Es por eso que se llama referencia a métodos de objetos arbitrario, porque conocemos el tipo de datos, pero no el objeto concreto. Al imprimir la lista, veremos una lista correctamente ordenada: “Hey!!! i’am a ordered array [Alex, Fausto, Maria, Oscar, Perla, Samuel]”

Finalmente, tenemos la referencia a constructores, la cual nos permitirá asignar la referencia de un constructor a el método de la interface funcional, de tal forma que cuando ejecutemos el método, este en realidad llamará al constructor de la clase referenciada. Como vemos en las líneas 34-35, estamos haciendo referencia al constructor mediante los :: (cuatro puntos) seguido del operador new, así de fácil. Finalmente cuando ejecutemos el método sayHello, este en realidad llamará al constructor de la clase Hello y se imprimirá en pantalla: “Hey!!! i’am a constructor”. Recordemos que las clases pueden tener más de un constructor, ¿entonces como sabe Java a que constructor llamar?, pues es fácil, llamará al que tenga compatibilidad con los parámetros de la interface funcional. Como en este caso, el método sayHello, no recibe parámetros, entonces se llama al constructor sin parámetros de la clase Hello. Por otra parte, si el método recibiera un String, entonces llamaría al constructor que recibe un solo parámetro. ¡Así de fácil!

Conclusiones:

Desde mi punto de vista, los métodos y constructores referenciados fueron de las cosas más extrañas que me parecieron del Java 8, pues al inicio no lograba entender cómo funcionaba a la perfección, sobre todo la referencia a métodos de un objeto arbitrario, pero la verdad es que es solo práctica, tenemos que descargar el código y probar, modificar las clases y probar de nuevo. Si no experimentamos se nos hará muy difícil entenderlas, pero más a un recordarlas cuando las necesitemos.
Como verás esta fue una guía rápida de los métodos referenciados, pero si tienes dudas, déjamelas en los comentarios y con gusto las resolveré. Recuerda que puedes descargar el código y a practicar.

Si estas interesado en seguir aprendiendo más de las mejoras de Java 8 te dejo este Enlace donde están todos los artículos que he escrito sobre Java 8

The post Java 8 – Métodos referenciados appeared first on Oscar Blancarte - Software Architecture.

Como el título de este articulo lo dice, hablaremos de cómo implementar los WebSocket utilizado Java como BackEnd, pero cabe mencionar que todos los lenguajes de programación deberían de tener sus propias API’s para soportar conexiones del lado del servidor.  Los WebSocket fueron agregados a apartar de la versión Java EE 7 bajo la especificación JSR 356, es por ello que todos los Application Server certificados para Java EE 7 deberán de tener una implementación estándar de dicha especificación. Basta de charla y pasemos a cómo implementar un WebSocket con Java.

Implementando un WebSocket con Java

Para explicar cómo funcionan los WebSocket vamos a implementar un ejemplo muy simple, crearemos una barra de progreso la cual se cargará del valor 0 al 100 simulando que un proceso se está ejecutando en el BackEnd. En el formulario tendremos un botón que iniciara el proceso, cuando el usuario presione el botón, enviaremos un mensaje al BackEnd por medio del WebSocket, en ese momento, el BackEnd iniciara con un proceso de notificaciones el cual enviará por medio del WebSocket un mensaje con las actualizaciones de la barra de progreso. Este ejemplo está desarrollado con Java 8 y Wildfly 9.0.

Este ejemplo está compuesto de 4 archivos:

• html: página principal del proyecto, sobre la que mostraremos la barra de progreso.
• js: Archivo de JavaScript en donde está programado el WebSocket y el procesamiento de los mensajes de envío y recepción.
• css: archivo de clases de estilo (opcional).
• java: Clase donde implementamos el WebSocket Server con Java, esta se ejecuta del lado del servidor.

Todo el código del proyecto lo puedes descargar de GitHub: https://github.com/oscarjb1/ProgressWebSocket.git

Index.html

Primero que nada, veremos el documento index.html para entender como esta armada la pantalla:

<!DOCTYPE html>
<html>
    <head>
        <title>WebSocket Progress</title>
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <script type="text/javascript"src="websocket.js"/></script>
        <link rel="stylesheet" type="text/css" href="styles.css">
</head>
<body>
    <section  class="container">
        <h1>WebSocket Progress</h1>
        <div>
            <div class="progress-container">
                <form id="form">
                    <input id="btnSubmit" type="button" value="start" onclick="formSubmit();"/>
                    <progress id="progress" value="0" max="100"></progress>
                    <label for="progress" id="lblProgress"></label>
                </form>
            </div>
        </div>
    </section>
</body>
</html>

Lo primero que hacemos en el Header es importar al archivo styles.css del cual no hay mucho que decir, salvo que es utilizado para darle una apariencia más agradable a la página, y el archivo websocket.js del cual hablaremos más adelante.

El siguiente punto importante es el formulario, en el definimos un botón que al presionarlo ejecutara la función formSubmit() que está definido en el archivo websocket.js, que iniciara con el proceso de carga del progress bar.

También tenemos un progress, el cual será actualizado a medida que el WebSocket reciba las notificaciones del BackEnd, para lo cual utilizaremos el ID (progress) para identificarlo más adelante. Finalmente, debajo del progress tenemos un label el cual será actualizado con el progreso del progress bar.

Tanto el progress como el label son actualizados por Javascript a medida que el servidor manda los datos por medio del WebSocket.

Websocket.js

Por su nombre, podríamos pensar que se trata de una librería o algún script ya desarrollado, pero la realidad es que es un Script totalmente custom y desarrollado a la medida para esta solución.

var socket = new WebSocket("ws://localhost:8080/ProgressWebSocket-1.0-SNAPSHOT/progress");
socket.onmessage = onMessage;

function onMessage(event) {
    var btnSubmit = document.getElementById("btnSubmit");
    btnSubmit.disabled = true;
    
    var progress = document.getElementById("progress");
    var data = JSON.parse(event.data);
    progress.value = data.value;
    
    var lblProgress = document.getElementById("lblProgress");
    if(data.value < 100){
        lblProgress.innerHTML = 'Progress: ' + data.value + '%';
    }else{
        btnSubmit.disabled = false;
        lblProgress.innerHTML = "Finish";
    }
    
}

function formSubmit() {
    socket.send("{\"start\":\"true\"}");
}

La primera línea es la más importante, pues en esta se establece la conexión con el servidor, la clase WebSocket es una clase estándar que nos permitirá comunicarnos con el Servidor de una forma simple, esta clase tiene como parámetro la URL sobre la cual escucha el BackEnd, más adelante veremos cómo está formada esta URL, por lo pronto asumamos que existe un WebSocket Server que está escuchando.

En la línea 2 definimos la función que procesara los mensajes entrantes, es decir, cuando el BackEnd envíe un mensaje al navegador, este lo atenderá por medio del método definido, en este caso, establecemos el método onMessage para procesar los mensajes entrantes.

En la línea 4 definimos el método onMessage el cual implementa toda la lógica de procesamiento de los mensajes entrantes, el parámetro event corresponde al evento recibido y mediante event.data es posible recuperar el mensaje que envió el Servidor. Veamos qué es lo que hace. Primero que nada, en las líneas 5-6 obtenemos la referencia el botón y lo deshabilitamos para impedir que se presione mientras esta en procesamiento. En la línea 8 convertimos el mensaje enviado por el Server en un Json para poderlo procesar. En las líneas 10-11 obtenemos una referencia al progress y actualizamos el valor de la barra de progreso, para lo cual establecemos la propiedad value por el valor enviado por el Servidor. En las líneas 13-19 establecemos el valor del label, indicando el progreso recibido por el servidor, en caso de finalizar (100%), la etiqueta cambia a Finish y el botón se habilitado nuevamente.

Finalmente, en las últimas líneas, tenemos el método formSubmit, el cual es ejecutado por el botón cuando es presionado, este método manda un mensaje dummy al servidor mediante el método send del WebSocket.

ServerDashboardWebSocket.java

Esta es la parte principal para implementar un WebSocket con Java, ya que desde aquí es de donde se aceptan las conexiones del navegador y se procesan los mensajes de envío y recepción.

package com.osb.progresswebsocket.socket;

import java.util.HashSet;
import java.util.Set;
import javax.enterprise.context.ApplicationScoped;
import javax.websocket.OnClose;
import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

/**
 * @author Oscar Blancarte <oscarblancarte3@gmail.com>
 */
@ApplicationScoped
@ServerEndpoint("/progress")
public class ServerDashboardWebSocket {

    private Set<Session> sessions = new HashSet<>();

    @OnOpen
    public void open(Session session) {
        System.out.println("Session opened ==>");
        sessions.add(session);
    }

    @OnMessage
    public void handleMessage(String message, Session session) {
        System.out.println("new message ==> " + message);
        try {
            for (int c = 0; c < 100; c++) {
                for (Session s : sessions) {
                    s.getBasicRemote().sendText("{\"value\" : \"" + (c + 1) + "\"}");
                }
                Thread.sleep(100);
            }
        } catch (Exception e) {
            System.out.println(e.getMessage());
            e.printStackTrace();
        }
    }

    @OnClose
    public void close(Session session) {
        System.out.println("Session closed ==>");
        sessions.remove(session);
    }

    @OnError
    public void onError(Throwable e) {
        System.out.println(e.getMessage());
        e.printStackTrace();
    }
}

Primero que nada, observemos que esta es una clase común y corriente, no extiende ni implementa ninguna clase, sin embargo, esta anotada con @ApplicationScope y @ServerEndpoint. Si ya has trabajado con JavaEE es muy probable que conozcas la primera, la cual no pertenece al API de WebSocket, pero es utilizada para crear un Bean disponible durante toda la vida de la aplicación. La segunda, @ServerEndpoint es en la que debemos de poner atención, con tan solo marcar una clase con ella, le estamos diciendo al Application Server que esta se trata de un WebSocket Server el cual estará escuchando en la URL http://<HOST>:<PORT>/<APPLICATION>/progress, la última parte de la url (/progress) es la que definimos en la anotación @ServerEndpoint por lo que tenemos que tener cuidado de que coincida con la URL que definimos en el archivo websocket.js.

También podemos ver que tenemos una Set de Session. Las Session son objetos que representan las conexiones de los navegadores, por lo que tendremos un Set para no perder la referencia a todas las conexiones.

A continuación, veremos una serie de métodos anotados, estas anotaciones le dicen a Application Server que método debe de ejecutar ante cualquier evento. Veamos los diferentes métodos.

Método open, está marcado con la anotación @OnOpen y se ejecutara cada vez que una nueva conexión se establezca con el servidor, el parámetro Session representa la conexión y la almacenamos en el Set de sesiones.

Método close, esta anotado con @OnClose y se ejecutara cada vez que una sesión se desconecte. Recibe el objeto Session que se desconectó para poder identificarla.

Método onError, esta anotado con @OnError, y se ejecutara ante cualquier error, el error es enviado como parámetro.

Método handleMessage, anotado con @OnMessage, será ejecutado cada vez que llegue un nuevo mensaje de alguno de los navegadores. Este recibe como parámetro el mensaje enviado y el objeto Session que mando el mensaje. Este es el método más importante en nuestro ejemplo, porque una vez recibido un mensaje, iniciara una serie de envíos de mensajes al navegador. Observemos que haremos un ciclo del 1 al 100 y en cada interación enviaremos al Navegador un mensaje con el progreso, al finalizar cada interación, dormiremos el hilo 100 milisegundos para apreciar mejor como se llena la barra. Utilizamos el método getBasicRemote() para que nos regrese una implementación de envío asíncrono y seguido ejecutamos el método sendText, el cual se utiliza para mandar un mensaje de texto al navegador.

Resumen:

Repasemos como funciona todo, cuando entramos a la página, esta carga el archivo websocket.js y establece conexión inmediata con el Servidor, en este momento el método open de la clase ServerDashboardWebSocket.java es ejecutado para recibir la nueva sesión. Seguido, el usuario presiona el botón start y envía mediante el función websocket.send un mensaje al Servidor, el Servidor recibe el mensaje mediante el método handleMessage de la clase ServerDashboardWebSocket.java, el cual envía una serie de mensaje como respuesta al navegador, por su parte, el navegador procesa los mensajes entrantes mediante la función onMessage de JavaScript, en esta función se actualiza la barra de progreso.

The post WebSocket con Java appeared first on Oscar Blancarte - Software Architecture.

Primero que nada, tenemos que saber que el Persistence Context se crea mediante un Persistence Unit y el Entity Manager se crea a partir de un Persistence Context, veamos la siguiente imagen para entender mejor:

Veamos que todo parte del archivo persistence.xml del cual ya hablamos anteriormente, en este archivo se definen los Persistence Unit, y mediante estos es creado el Persistence Context, el Persistence Context tiene la finalidad de delimitar el alcance de las transacciones, pero también está delimitado a administrar las Entidades definidas por el Persistence Unit con el que fue creado.  Adicionalmente, el Entity Manager hace referencia a un Persistence Context el cual será utilizado para administrar las entidades y las transacciones.

Una de las ventajas de tener varios Persistence Unit, es que nos permite definir diferentes configuraciones para cada uno, de esta manera podemos delimitar las entidades de cada módulo e incluso una configuración de base de datos diferentes para cada uno.

Container-Managed Entity Manager

Básicamente existen dos formas de trabajar con JPA, la más simple es cuando lo utilizamos en aplicaciones SE o de escritorio y la segunda forma que es la que estudiaremos en esta sección, es cuando lo utilizamos en ambientes de Java EE con EJB.

La principal característica de utilizar Entity Manager administrado por el contenedor, es que es el mismo Container el que se encarga de abrir y cerrar las transacciones, por lo que el programador solo se preocupa por implementar la lógica de negocio despreocupándose en la totalidad de las transacciones.

En ambientes Java EE se suele utilizar la anotación @PersistenceContext  para crear el EntityManager, como veremos en el siguiente EJB.

package com.obb.jpa.jpaturorial.entitymanager;

import javax.ejb.*;
import javax.persistence.*;

/**
 * @author Oscar Blancarte
 */
@EJB
@Stateless
public class EmployeeDAO implements IEmployeeDAO{

    @PersistenceContext(unitName = "JPA_PU")
    private EntityManager manager;
}

Cuando utilizamos la anotación @PersistenceContext  el contenedor inyecta de forma automática una referencia válida del EntityManager creado a partir de la Persistence Unit JPA_PU, de esta forma, el programador podrá utilizar el EntityManager en cualquier método que defina, y las transacciones será administradas de forma automática.

Ahora bien, existen dos variantes de los Container-Managed, Transaction-Scope y Extended, los cuales son utilizados en circunstancias diferentes. Para utilizar una variante o la otra, es necesario definirlo en la anotación @PersistenceContext  mediante la propiedad type. Los valores posibles son TRANSACTION  y EXTENDED  como veremos a continuación:

@PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.TRANSACTION)
@PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.EXTENDED)

En caso de no definir la propiedad type, el valor por default será TRANSACTION, lo cual está bien, porque es por lejos la variante más utilizada.

Transaction-Scope

La variante Transaction-Scope es la variante utiliza por default, por lo que no es necesario definir la propiedad type para utilizarla. Esta variante tiene la particularidad de que el contexto de persistencia solo será válido durante le ejecución de la operación de negocio, una vez que la operación termine el contexto de persistencia se destruye y todas las entidades relacionadas con el Entity Manager será descartadas.

Este tipo de estrategias se utiliza para EJB sin estado como los @Stateless, pues cada invocación a una operación de negocio se espera que realice una acción, persista y retorne un resultado, y cada ejecución tendrá un contexto de persistencia diferente, garantizando de esta forma que el servicio siempre arroje el mismo resultado para la misma entrada.

Veamos un ejemplo de un servicio de creación de empleados:

package com.obb.jpa.jpaturorial.entitymanager;
import com.obb.jpa.jpaturorial.entity.Employee; 
import javax.ejb.*; 
import javax.persistence.*; 
/** 
* @author Oscar Blancarte 
*/ 
@EJB 
@Stateless 
public class EmployeeDAO implements IEmployeeDAO{ 
@PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.TRANSACTION) 
private EntityManager manager; 

@TransactionAttribute(TransactionAttributeType.NEVER) 
public Employee getEmployeeById(Long empId){ 
//Se consulta el empleado mediante el ID 
return manager.find(Employee.class, empId); 
} 

@TransactionAttribute(TransactionAttributeType.SUPPORTS) 
public void updateEmployeeName(Long empId, String newName){ 
//El empleado es nuevamente consultado de la base de datos 
//debido a que cada invocación es un nuevo contexto de persistencia 
Employee emp = manager.find(Employee.class, empId); 
emp.setName(newName); 
//Al termina el método, el contenedor realiza un Commit automático. 
} 
}

Imaginemos el siguiente escenario, tenemos una aplicación que carga el empleado en pantalla utilizando el método getEmployeeById, esta consulta al empleado mediante el ID y lo retorna, la aplicación utiliza el empleado consultado para mostrarlo en pantalla, luego, modificamos el nombre del empleado y guardamos los cambios mediante el método updateEmployeeName.

Lo primero que hace la aplicación es consultar el empleado, hasta aquí todo bien, pero cuando actualizamos el nombre del empleado, vemos que realizamos un find mediante el ID del empleado, podríamos pensar que como ya lo hemos consultado anteriormente mediante el método getEmployeeById este solo lo retomará del cache sin realizar una nueva consulta a la base de datos, sin embargo, Transaction-Scope garantiza que cada ejecución crea un nuevo PersistenceContext en blanco, por lo que el empleado que anteriormente ya habíamos consultado será nuevamente consultado, debido que en la segunda llamada al método updateemployeeName el Persistence Context está en blanco.

No te preocupes por las anotaciones @TransactionAttribute, más adelante las explicaremos por ahora pasémoslas por alto.

Extended

La segunda variante es Extended, que como su nombre nos lo indica, se trata de un Contexto de Persistencia Extendido, donde el contexto persistirá durante todo el tiempo de vida de la sesión, sin importar el número de operaciones o transacciones que se realicen.

A diferencia de Transaction-Scope, en esta variante todos los cambios realizados en el Persistence Context seguirán vigentes, por lo que cada ejecución que realicemos se favorecerá de las ejecuciones pasadas.

Este tipo de variante es utilizada cuando trabajamos con EJB con sesión como el @Stateful, veamos el mismo ejemplo anterior pero esta vez utilizando un EJB con sesión y la variante Extended.

package com.obb.jpa.jpaturorial.entitymanager;

import com.obb.jpa.jpaturorial.entity.Employee;
import javax.ejb.*;
import javax.persistence.*;

/**
 * @author Oscar Blancarte
 */
@EJB
@Stateful
public class EmployeeExtendedDAO implements IEmployeeDAO{
    
    @PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.EXTENDED)
    private EntityManager manager;
    
    @TransactionAttribute(TransactionAttributeType.NEVER)
    public Employee getEmployeeById(Long empId){
        //Se consulta el empleado mediante el ID
        return manager.find(Employee.class, empId);
    }
    
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    public void updateEmployeeName(Long empId, String newName){
        //El empleado no es consultado, debido a que ya fue consultado previamente
        Employee emp = manager.find(Employee.class, empId);
        emp.setName(newName);
        //Al termina el método, el contenedor realiza un Commit automático.
        //Los camibios realizados seguiran estando disponibles
    }
}

En este caso las cosas son un poco diferentes. Primero que nada, se realiza la consulta del empleado mediante el método getEmployeeById y el empleado es retornado, cuando la ejecución del método termina, el Persistence Context continúa existiendo, por lo que cuando se realiza la actualización del nombre del empleado y se realiza la consulta del empleado, el Entity Manager ya no consulta al empleado, pues este ya fue consultado en el método anterior. Finalmente, el nombre es actualizado y al terminar el método se hace un commit de la transacción. Al finalizar el método el Contexto de persistencia continua activo hasta que la sesión finaliza.

Application-Managed Entity Manager

La segunda forma de trabajar con JPA es delegar al programador la responsabilidad de administrar las transacciones, este escenario se da con mucha más frecuencia en aplicaciones de escritorio, aunque existen escenarios donde es utilizado en entornos de Java EE.

Básicamente el programador tiene que crear el EntityManager a través del EntityManagerFactory y tiene que abrir y cerrar las transacciones cada vez que requiera.

Veamos cómo quedaría el escenario anteriormente planteado utilizando application-managed:

package com.obb.jpa.jpaturorial.entitymanager;

import com.obb.jpa.jpaturorial.entity.Employee;
import javax.ejb.*;
import javax.persistence.*;

/**
* @author Oscar Blancarte
*/
public class EmployeeApplicationDAO {

private EntityManager manager;

public EmployeeApplicationDAO() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA_PU");
manager = emf.createEntityManager();
}

public Employee getEmployeeById(Long empId) {
return manager.find(Employee.class, empId);
}

public void updateEmployeeName(Long empId, String newName) {
//Se abre la transacción manualmente
manager.getTransaction().begin();
Employee emp = manager.find(Employee.class, empId);
emp.setName(newName);
//Se cierra la transacción manulamente
manager.getTransaction().commit();
}
}

Podemos apreciar que el constructor de la clase estamos creando manualmente el EntityManager en lugar de simplemente inyectarlo como el Container-Managed, la otra diferencia es en el método updateEmployeeName, ya que para poder persistir los cabios tenemos que abrir y cerrar la transacción con los métodos beign y commit.

The post Entity Manager & Persistence Context appeared first on Oscar Blancarte - Software Architecture.