SOAP vs REST es una comparación que muchos programadores o incluso arquitectos de software suelen preguntarse a la hora de desarrollar las API para sus sistemas, pero cual es realmente la diferencia que existe entre ellas, ¿Será que una es superior a la otra? ¿Será que REST llego para remplazar a SOAP? Pues bien, en este artículo trataremos de resolver esta gran duda.

Primero que nada, me gustaría aclarar un error muy común que puede hacer que distorsione por completo tu entendimiento con respecto a los Web Services y es que SOA no es igual que SOAP y tener Web Services no significa que tenemos SOA. Hace un tiempo publique un artículo donde hablaba acerca de la Arquitectura SOA por si quieres darle una repasada al tema.
Pues bien, ya con este punto aclaro, debemos entender que SOA (Service-Oriented Architecture) es un tipo de Arquitectura de Software y no una tecnología o producto. SOA es una arquitectura que se base en la integración de aplicaciones mediante Servicios, los servicios representan la medida más granular de la arquitectura, sobre la que se construyen otros artefactos como: composiciones, proxys, fachadas, BPM e incluso API completas. Ahora bien, si SOA tiene como médula espinal los servicios, ¿no son SOAP y REST servicios? ¡Revelador no!!
Entonces si REST y SOAP son en realidad servicios, entonces que diferencia existe entre las dos, cual es el propósito de que existan dos tecnologías que aparentemente hacen lo mismo. Primero entendamos que SOAP y REST siguen la misma Arquitectura (SOA), por lo que las dos deberían de apegarse a los mismos principios.

En este punto nos debe de quedar claro que tanto SOAP como REST son tecnologías que implementan la arquitectura SOA.

Que es SOAP:

Los servicios SOAP o mejor conocimos simplemente como Web Services, son servicios que basan su comunicación bajo el protocolo SOAP (Simple Object Access Protocol) el cual este definido por Wikipedia como “protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML”. Por lo tanto, queda claro que la comunicación se realiza mediante XML, lo cual nos debe de quedar muy claro, pues es en este aspecto donde radican las principales diferencias contra REST. Los servicios SOAP funcionan por lo general por el protocolo HTTP que es lo más común cuando invocamos un Web Services, sin embargo, SOAP no está limitado a este protocolo, si no que puede ser enviado por FTP, POP3, TCP, Colas de mensajería (JMS, MQ, etc). Pero como comentaba, HTTP es el protocolo principal.

Si bien, me gustaría poner una sección de ventajas y desventajas, la realidad es que estas pueden ser lo contrario dependiendo del punto de vista y la situación concreta del problema a resolver por lo que me gustaría dejar un breve análisis de cuando utilizar SOAP. A mi parecer SOAP sigue siendo el mejor protocolo para la comunicación de Server to Server o Partner to Partner pues es un protocolo mucho más robusto, tiene un tipiado mucho más fuerte, permite agregar metadatos mediante los atributos (cosa que JSON no tiene), permite definir espacios de nombre, evitando la ambigüedad. Por lo mismo, SOAP es un formato más pesado, tanto en tamaño como en procesamiento, pues los XML tiene que ser parseado a un árbol DOM, resolver espacios de nombre (namespaces) antes de poder empezar a procesar el documento. Los XML además tienen métodos de validación muy potentes y ampliamente utilizados, a diferencia de JSON, el cual, si tiene forma de validar, pero no son tan potente y su utilización es pobremente utilizada (no significa que en el futuro no se estandarice su uso).

Nótese que, SOAP solo soporta formato XML, por lo que cuando lo que necesitamos es flexibilidad y un performance superior, podemos optar por REST. Tengo otro artículo donde hablo de XML vs JSON por si quieres profundizar en el tema.

Que es REST

Por otra parte, tenemos REST, el chico nuevo de la cuadra. REST ya tiene unos años, pero en realidad tiene poco que se le empezó a dar la importancia que hoy tiene. REST es una tecnología mucho más flexible que transporta datos por medio del protocolo HTTP, pero este permite utilizar los diversos métodos que proporciona HTTP para comunicarse, como lo son GET, POST, PUT, DELETE, PATCH y a la vez, utiliza los códigos de respuesta nativos de HTTP (404,200,204,409). REST es tan flexible que permite transmitir prácticamente cualquier tipo de datos, ya que el tipo de datos está definido por el Header Content-Type, lo que nos permite mandar, XML, JSON, Binarios (imágenes, documentos), Text, etc. que contrasta con SOAP que solo permite la transmisión de datos en formato XML. A pesar de la gran variedad de tipos de datos que podemos mandar con REST, la gran mayoría transmite en JSON por un motivo muy importante, JSON es interpretado de forma natural por JavaScript, lo que ha hecho que frameworks como Angular y React se aprovechen al máximo, pues pueden enviar peticiones directas al servidor por medio de AJAX y obtener los datos de una forma nativa. Los formularios de HTML pueden ser apuntados a los servicios REST sin ningún problema (por ejemplo).

Otra de las grandes ventajas que presenta JSON sobre SOAP es el performance, ya que los JSON son considerablemente más livianos en peso y mucho más rápido en su procesamiento. Pero como ya vimos, el performance tiene un costo, y es la robustez del mensaje como tal.

Ahora bien, desde mi punto de vista REST debería ser utilizado para obtener datos en aplicaciones WEB que funcionan principalmente con el Modelo MVC del lado del cliente, es decir, que todos los procesamientos se realizan desde el navegador y que solo va al backend para obtener o actualiza la base de datos. Otra de las situaciones es cuando tenemos aplicaciones donde los recursos de procesamiento son bajos y con ancho de banda limitado, como sería el caso de las aplicaciones móviles o robótica.

Te invito a que vas mi articulo “Construir un API REST con NodeJS“, en el cual hablo desde cero como implementar un API REST de la forma más simple y clara, utilizando NodeJS y Express. O puedes puedes ver la guia completa de cómo implementar un API REST con Java desde cero.

Te puede interesar mi video de Youtube”Qué es API REST? – 🚀Y por que es importante aprenderlo 🚀“

SOAP vs REST Conclusiones

Como vimos en este análisis, no hay un claro ganador, pues tanto SOAP como REST siguen siendo muy útiles en condiciones diferentes, incluso existen aplicaciones que ya exponente todas sus API’s en SOAP y REST para asegurar que la integración con ellas sea lo más natural posible sin importar la aplicación con la que se estén integrado.

Cabe mencionar que REST ha estado tomando fuerza a una velocidad impresionante y más con la llegada de NodeJS y las bases de datos NoSQL como MongoDB. Sin embargo, el hecho de que REST tome fuerza, no significa que le esté quitando protagonismo a SOAP, pues recordemos que con la llegada del Internet de las cosas (IOT) cada vez se conectan más dispositivos a internet que necesitan ser integrados (una gran oportunidad para REST) y es donde REST está tomando la delantera.

La verdad es que el futuro no se ve claro, pero lo que, si es que a pesar de que REST siga tomando fuerza, SOAP sigue siendo una tecnología muy robusta y extremadamente utilizada por lo que una cosa si es segura, a SOAP todavía le queda un largo camino.

A pesar de todo este análisis, lo importante es tu qué opinas, ¿cuál crees que sea el futuro?, ¿crees que REST poco a poco matara a SOAP? O ¿simplemente SOAP seguirá funcionando a la par con REST?.

The post SOAP vs REST ¿cual es mejor? appeared first on Oscar Blancarte - Software Architecture.

Crear Web Services con Java es mucho más fácil de lo que pudiéramos creer, pues ya que tan solo es necesario anotar una clase, para que esta sea expuesta automáticamente como tal por medio del servidor de aplicaciones. Para demostrar esto, desarrollaremos un Servicio para consultar y crear Empleados.

Lo primero que tenemos que hacer, es crear una clase que queremos exponer como WebService, luego la tenemos que anotar con @WebService :

@WebService(serviceName = "EmployeeService", targetNamespace = "http://xmlns.oscarblancarte.com/services/v1/EmployeeService")
public class EmployeeServiceImpl

Las propiedades utilizadas son las siguientes:

• serviceName: Nombre del servicio, que será utilizado para crear la URL del endpoint.
• targetNamespace: Define el Namespace del servicio.

Basta decir que las propiedades serviceName  y targetNamespace  son opcionales, ya que, de no colocarlas, serán asignadas de forma automática, tomando el nombre de la clase y el paquete en que se encuentra respectivamente.

En segundo lugar, es necesario crear los métodos que serán expuestos como las operaciones del WebService, estos métodos, deben de ser anotados con @WebMethod , veamos cómo quedaría una clase WebService terminada:

package com.osb.jax.ws.services.interfaces;

import com.osb.jax.ws.services.types.Employee;
import java.util.*;
import javax.jws.*;

/**
 * @author Oscar Blancarte
 */
@WebService(serviceName = "EmployeeService", targetNamespace = "http://xmlns.oscarblancarte.com/services/v1/EmployeeService")
public class EmployeeServiceImpl {
    
    private static final List<Employee> EMPLOYEES = new ArrayList<>();
    
    @WebMethod
    @WebResult(name = "employee")
    public List<Employee> getEmployeeList(){
        return EMPLOYEES;
    }
    
    @WebMethod
    public boolean createEmployee(@WebParam(name = "employee") Employee employee){
        EMPLOYEES.add(employee);
        return true;
    }
}

La anotación @WebParam  es utilizado para personalizar el nombre del parámetro en el WSDL.

La definición de la clase Employee es la siguiente:

package com.osb.jax.ws.services.types;


/**
 * @author Oscar Blancarte
 */
public class Employee {
    
    private Long id;
    private String name;

    public Employee() {
    }
    
    public Employee(Long id, String name) {
        this.id = id;
        this.name = name;
    }
    
    public Long getId() {
        return id;
    }

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

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
    
    
}

Finalmente, solo serán necesario deployar en el servidor de aplicaciones nuestro proyecto, en este caso, estamos utilizando Wildfly 9, pero podrías utilizar cualquier servidor que sea de tu preferencia. Una vez deployado, podrás ver el servicio en la URL: http://localhost:8080/JAX-WS-1.0-SNAPSHOT/EmployeeService?wsdl.

Podemos probar el servicio con SOAP-UI para ver el servicio y las dos operaciones:

Observemos que tenemos dos operaciones:

• createEmployee: nos permite crear un nuevo Empleado
• getEmployeeList: obtener un listado de todos los Empleados registrados.

Primeo ejecutaremos el método createEmployee:

Con este paso, ya habremos creado un nuevo Empleado llamado Oscar Blancarte.

El segundo paso, será consultar los empleados con el método getEmployeeList:

Como vemos, crear Servicios Web es tan simple como anotar una simple clase y desplegarla en nuestro servidor de aplicaciones.

The post Web Services con Java (JAX-WS) appeared first on Oscar Blancarte - Software Architecture.

Antes del debut de SOA teníamos la Arquitectura de ManFrame y Cliente-Servidor las cuales no quiero decir que sean obsoletas o pasadas de moda ya que cada un ofrece ventajas y desventajas que pueden ser decisivas según nuestro escenario de negocio.

Mainframe

Bien, ManFrame es una arquitectura que su enfoque central radica en un servidor super potente capas de hacer miles de transacciones por si sola y administrar miles de usuarios concurrentes desde una única ubicación. Esto desde luego es una gran ventaja pero tenia el gran inconveniente que todo es centralizado.

Cliente-Servidor

A diferencia de Mainframe el cliente servidor es una arquitectura mas fácil de encontrar ya que muchos de los aplicativos que usamos en muestra computadora la utilizan, Este tipo de arquitectura se caracteriza en que una parte del programa se encuentra instalada en nuestra computadora y esta otra parte llamada Servidor la cual es otro software que atiende las peticiones le cliente por medio de un protocolo como TCP/IP. Esta arquitectura ayuda en que parte del procesamiento se realiza por parte del cliente pero para almacenar o realizar consultas en tiempo real se comunicaba con el servidor.

Service-oriented architecture (SOA)

Como observamos en las arquitecturas anteriores estas se enfocan únicamente en si mismas sin importarles mucho la forma en la cual nos comunicamos con otras aplicaciones, ya que cada una tenia un protocolo único de comunicación  y era difícil interactuar con otros sistemas.

Sin embargo SOA es diferente ya que esta diseñado no solo para complacer al sistema al cual estamos diseñando si no también ve un poco mas y esto es por que se preocupa por la forma en que este sistema se deberá comunicar con los demas, ya sea consumiendo servicios de proveedores externos e internos o simplemente exponiendo servicios para que otras aplicaciones se puedan comunicarse con el.

La principal ventaja que ofrece SOA es que su activo principal no son las aplicaciones o sistemas si no los Contratos que expone y es que con una definición correcta de un contrato podríamos incluso cambiar el aplicativo por otro y nadie se diera cuenta. Un contrato define la forma en que se realizara la comunicación, establece el formato de entrada del servicio y de salida lo que ayuda a que cualquier cliente pueda interpretarlos sin ningún problema.

Otra de las ventajas que ofrece SOA es que utiliza protocolos de comunicación Estándar como WebServices lo cual le permite comunicarse con cualquier aplicación sin importar en que lenguaje este desarrollada.

Cada servicio que se desarrolla en SOA se realiza bajo la premisa de que sera reutilizado al máximo y que sera de utilidad para otros sistemas por lo cual cada servicio deberá ser planeado con cuidado para que sea lo mas simple posible y a si aumentar el grado de re-utilización que tendrá.

A continuación les dejo un esquema muy simple de como la arquitectura SOA nos puede ayudar en las integraciones de los diferentes sistemas que se encuentran en una empresa.

Del lado derecho tenemos las aplicaciones a las cuales necesitamos comunicarnos para realizar un proceso de integración y cada una tiene expuesto un conjunto de servicios, En el medio tenemos la capa de orquestación donde creamos servicios de integración a partir de otros servicios existentes. y del lado izquierdo tenemos las aplicaciones las cuales requieren una integración con algún sistema interno o externo.

En resumen SOA es una arquitectura diseñada para la integración de todos los distintos aplicativos que conforman la infraestructura del cliente, pero también busca la integración con aplicativos externos como de proveedores.

Si quieres conocer mas de SOA y de Integraciones con BPEL aquí te dejo algunos links de otros de mis Post.

Que es una composición SOA

Que es la virtualizacion de servicios

Como crear un BPEL

The post Que es Service-oriented architecture (SOA) appeared first on Oscar Blancarte - Software Architecture.

Para empezar virtualizar viene de la palabra virtual como cuando hablamos de maquinas virtuales, pues esto es algo parecido pues un servicio virtual no es mas que una mascara que lo único que hace es exponer un WebService que por dentro hace la llamada a otro u otros WebServices para dar una funcionalidad nuevo o extendida.

Imaginemos que estamos desarrollando una aplicación móvil para una empresa la cual dentro de sus sistemas ya tiene un conjunto de webservices desarrollados para las principales tareas que realiza, sin embargo hasta el momento no tiene ningún desarrollo para móviles y le preocupa la seguridad ya que al exponer sus webservices tema que alguna persona mal intencionada pueda entrar y hacer algún mal.

Por lo que desarrollo un WebService para que el usuario se Autentifique cuando entre a la aplicación, sin embargo eso no es todo, también requiere que cuando el usuario realice alguna acción se validen sus privilegios para denegar cualquier acción no permita para ese usuario.

Otro punto importante es que el cliente quiere que cuando una persona intente hacer una acción no autorizada o falle en el Login se registre tal acción para poder auditar y detectar situaciones sospechosas.

El cliente nos brinda los siguientes WebServices con los que debemos diseñar nuestra aplicación:

SecurityService  //WebServices que expone el sistema de seguridad centralizado.

• login(usuario, password) : boolean: Operación que autentifica al usuario y nos dice indica si el login fue exitoso o no.
• autorization(usuario,password, accion ):boolean: Operación que nos indica si un usuario tiene privilegios para realizar una acción determinada, El parámetro acción representa el ID de la operación a ejecutar.

AuditService //WebService que expone el sistema de Auditoria Informática

• intentoAccion(usuario, accion, DateTime, autorizationResult): void: Operación que registra cuando una acción es solicitada

ClienteService //WebService para consultar los datos del cliente

• consultaDatosPersonales(idCliente): Cliente: Operación que regresa los datos básicos del cliente como nombre,apellido, sexo, CURP, etc.
•  consultaSaldo(idCliente): double: Operación que regresa el saldo del cliente

Desarrollando la solución

Imaginemos que la aplicación lo único que hace es consultar los datos del cliente y su saldo sin embargo no todos los usuarios pueden saber el saldo de un cliente por lo que el servicio se separa y se consulta de forma independiente.

Lo primero que se nos ocurre es hacer una pantalla de login y autenticarnos con el servicio de login pasandole el nombre de usuario y password. Si el login se realiza correctamente entramos a la aplicación, sin embargo el cliente quiere que cuando un login falle o se de correctamente notifiquemos el evento al departamento de Auditoria mediante la operación de intentoAccion y pesarla el ID de la operación Login y la fecha y hora del intento.

Esto desde luego nos implicaría dos llamadas a Webservices, uno para Login y otro para Auditoria:

 Fig.1: Muestra la comunicación con los dos webservices de forma separada.

Para la pantalla de datos del cliente tendríamos que implementar nuevamente un sistema de llamadas donde primero verificaríamos si tenemos privilegios para leer los datos del cliente con el webservices de autorizacion, de darse los privilegios entonces se consulta el Webservices de consultaDatosPerosnales, seguido de consultar los privilegios para autorizar al usuario para leer el saldo del cliente y consultar el servicio de  consultaSaldo. Nuevamente si alguna autorización falla es requerido notificar al departamento de Auditoria mediante el Webservices intentoAccion. Este esquema quedaría algo a sí.

 Fig.2: Fugura que muestra el número de acción a realizar solo para completar la consulta de los datos del cliente y saldo.

Un esquema con Virtualización:

Una vez que examinamos como tendríamos que desarrollar una aplicación sin virtualización podemos empezar a examinar el esquema con virtualización.

La primera acción que deberíamos hacer es crear un proxy que cumpla casi exactamente con el contrato(WSDL) que sirve como punto de entrada a nuestra aplicación pero que ademas de esto le estaríamos pasando los datos de autenticación y autorización en el Header del mensaje SOAP de tal forma que el proxy tomara el header lo enviara al servicio de autorization en caso de autorización continuara con la llamada al servicio de consultaDatosPerosnales y regresara el resultado.Pero en caso de haber fallado la autorización llamaría al servicio de Auditoria y regresaría un Throw para indicar que el servicio ha fallado por seguridad.

La aplicación se viera de esta manera para el escenario de consulta de datos del suscriptor:

Fig.3: Escenario con virtualización

Si nos damos cuenta en este escenario ya solo tenemos una invocación a un único servicio el cual se encarga de realizar las operaciones previas a la consulta de los datos del cliente y también notificar al departamento de Auditoria en caso de haber fallado la autorización.

Este enfoque tiene las siguientes ventajas:

• Se reduce el numero de llamadas al servidor
• Aumentan los tiempos de respuesta
• Las operaciones se realizan desde la misma infraestructura del cliente por lo que la seguridad es mucho mejor.
• El implementar un Enterprice Service Bus nos da la cualidad de poder medir el performance (KPI o Key Performance Indicator).
• Definir los acuerdos de nivel de servicio o SLA.

The post Que es la Virtualización de Servicios appeared first on Oscar Blancarte - Software Architecture.

Se le llama Orquestar por que BPEL es el encargado de consumir varios servicios en un orden especificado y realizar una función muy concreta.

Escenario practico.

Agencia de viaje: Imagínate que entras a un pagina de agencia de viaje en la cual puedes comprar un paquete que incluye boletos de avión y hotel. Lo único que tenemos que hacer nosotros es decir a donde queremos con la fecha y la agencia de viaje nos arrojara los paquetes con un precio y solo tenemos que pagar con nuestra tarjeta de crédito para que nuestra reservación quede lista.

Una vez que confirmamos nuestra compra la agencia de viaje tendrá que hacer algunas operaciones que no dependen de ella como seria reservar el boleto de avión con la aerolínea, reservar los día del cuarto directamente con el Hotel, Hacer un cargo por el porcentaje que gana la agencia por realizar la venta y por ultimo guardar en el sistema de la agencia el registro de la venta.

Fig.1: Muestra el proceso a realizar para completar una reservación.

Si nos damos cuenta los pasos 2,3,4 no depende de la agencia de viaje si no de servicios que exponen los proveedores como webservices.

Como encaja BPEL en este escenario.

Con BPEL podemos crear un solo servicio que reciba todos los parámetros necesarios para realizar la operación como los datos de la reservación y los datos de la tarjeta de crédito, con estos primero realizaremos la reservación del avión, luego reservaremos el hotel, cargaremos nuestra utilidad al cliente, Guardaremos el registro de la reservación y finalmente regresaremos al cliente la confirmación al cliente. A este proceso se le conoce como orquestar ya que toma el flujo de la ejecución y realiza las tareas de forma automática y en un orden especificado.

Si bien esto te puede parecer algo que cualquier lenguaje pueda realizar la realidad es que BPEL esta diseñador para estos escenarios lo que permite una programación mucho mas rápida.

The post Que es BPEL appeared first on Oscar Blancarte - Software Architecture.