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.

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.

Paso 1: Crear una proyecto SOA.

Entraremos a JDeveloper y daremos click en File/New/SOA Project y nos saldrá la pantalla siguiente, Solo cambiamos el nombre del proyecto a “Calculadora” y damos Next en las dos pantallas.

En este punto ya habrás creado una SOA Project y te abrirá la pantalla del Composite, de no ser a podemos abrirlo desde el archivo composite.xml que se genera en la estructura del proyecto:

Paso 3: Crear los tipos de datos en un Schema

El siguiente paso es clave ya que es indispensable definir los tipos de datos que recibirá y responderá nuestro servicio para lo cual crearemos un Schema de la siguiente manera File/New/XML Schema asegurándonos que la pestaña All Technologies este seleccionada.

 En la siguiente pantalla solo cambiamos el nombre del archivo a “Calculadora.xsd” y continuamos.

Continuaremos con crear los tipos de tal forma que nuestro Schema quede de la siguiente manera:

NOTA: En la siguiente entrada explico mas a detalle como crear un Schema

Paso 3: Crear un BPEL

 Con el Schema creado ya podemos crear un BPEL que reciba SumaRequestType y que tenga como resultado un SumaResponseType

Abriremos el archivo composite.xml que se crea con el proyecto en el cual daremos click derecho en la sección del medio “Components” y seleccionamos Insert/BPEL Process como se muestra en la siguiente figura.

 Nos deberá aparecer una pantalla como la siguiente y pondremos los datos como aparecen:

Seleccionamos la opción de BPEL 2.0, Cambiamos el nombre a CalculadoraProcess, En NameSpace podemos poner lo que mas nos agrade no es necesario dejarlo igual, En Temple seleccionamos Synchronous BPEL Process para que sea un servicio con entrada y respuesta y finalmente en Input y Output seleccionamos los tipos que definimos en el Schema del paso 2. Seleccionar los correctamente los Input y Output es un paso clave ya que definen los tipos que se utilizaran como parámetro de entrada y salida de nuestro servicio. Finalmente presionamos OK y tendremos creado en BPEL que se mirara a sí:

En el centro tenemos el BPEL(Azul) el cual lo creamos en el paso anterior, Del lado izquierdo tenemos expuesto un WebService que para los parámetros
al BPEL y de igual forma regresara al consumidor el resultado del BPEL, Entre medio de los dos tenemos una linea que indica que el WebService y el BPEL están conectados por lo que la información fluirá entre los dos.

Ya con el BPEL creaso solo faltara programar el BPEL para que realice el calculo de la suma para lo cual daremos doble click sobre el BPEL para abrir el editor y nos dirigirá a la siguiente pantalla:

La imagen anterior nos muestra la forma mas simple del BPEL el cual solo tiene dos actividades receiveInput que solo recibe los parámetros de entrada en la variable llamada “InputVariable” y la actividad replyOutput las cual regresa el resultado del BPEL en la variable “OutputVariable”. Ambas variables son creadas de forma automática y corresponden con los tipos definidos en el Schema (SumaRequestType y SumaResponseType).

El siguiente paso consiste en sumar los dos valores y ponerlos en la variable OutputVariable para que BPEL regrese el resultado al terminar. Para esto tendremos que crear una actividad llamada Assign la cual se encuentra en la paleta de componentes del lado  Derecho:

Presionamos sobre “Assign” y sin soltar arrastramos hasta colocarlo en medio de las dos actividades existentes y le ponemos el nombre de SumaAssign quedando como se muestra en la figura anterior.

La actividad Assign sirve para asignar valores a cualquier variable que tengamos en el BPEL por lo cual daremos doble click sobre la actividad Assign:

Veremos la pantalla anterior la cual esta dividida en tres secciones:

• Izquierda: De esta parte tomaremos los valores para hacer las asignaciones
• Derecho: En esta sección ponemos los valores asignados mediante la sección de la izquierda.
• Abajo: Aquí solo se en listan las asignaciones que vamos haciendo.

Para sumar los dos valores necesitaremos mas de un campo por lo que tendremos que hacer una formula arrastrando la calculadora hasta el nodo llamado result:

En la pantalla siguiente solo seleccionamos el nodo num1 para que se coloque arriba agregamos el operador “+” y hacemos lo mismo para el num2, Con esto ya tenemos lista la formula y damos ok.

Finalmente tendremos la asignación en la parte de abajo y presionamos OK para finalizar la asignación.

Guardamos los cambios del proyecto y nuestro BPEL esta listo para deployarse

Paso 4: Deploy

Para hacer el deploy tendremos que tener corriendo una instancia de WebLogic con la SOA Suite instalada y seguir los siguientes pasos.

Sobre el proyecto hacemos click derecho y precionamos /Deploy/Composite… y nos saldrá una pantalla nueva. Seleccionamos Deploy to Aplicaction server/Next en la pantalla siguiente Next sin hacer ningún cambio, en la siguiente pantalla seleccionamos el servidor al que queremos hacer deploy o damos de alta uno nuevo en caso de no tener ninguno registrado, En la siguiente pantalla solo seleccionamos next, y finish.

Con estos pasos tendremos la composicion SOA y el BPEL deployados y ya solo faltara hacer una prueba con algún cliente de WebServices como soapUI o la consola de Weblogic.

Paso 5: Prueba

Para obtener la URL del webservice nos vamos al portal EnterpriceManager el cual esta en la url

http://localhost:7001/em en caso de no estar instalado el weblogic en la misma maquina cambiar localhost por la IP.

Una vez autenticados del lado izquierdo entramos a la ruta /SOA/soa-infra/default/Calculadora

nos abrirá un dashboard solo de la composición y en ella veremos un icono con un mondo y una pieza de rompecabeza, damos click y aparecera una url que termina en ?wsdl esa la copiamos y la usamos en cualquier cliente para consumir webservices.

NOTA: Mas adelante publicare como instalar JDeveloper, WebLogic, SOA Suite y OSB.. 

The post Oracle SOA Suite – Como crear un BPEL appeared first on Oscar Blancarte - Software Architecture.

Hoy en día los sistemas de información generan una gran cantidad de información mediante la operación del día a día. Estos sistemas generalmente están comunicados con otros sistemas o módulos para compartir o extraer información.  Esta comunicación entre sistemas es llamado “Integraciones” y son muy importantes ya que de no existir los sistemas no se podrían comunicar y se generaría un caos.

Un ejemplo claro de integración:

Imagínate un sistema de punto de venta en donde se capturan las ventas diarias, se cobra y se consulta inventario. El punto de venta cada vez que realiza una venta tiene que descontar del almacén las unidades vendidas las cuales el Sistema de Almacén resta y lleva la cuenta para hacer los pedidos cuando la existencia esta bajando. Por otra parte las vendedoras consultan el inventario para saber si algún producto lo aun lo tiene en existencia y poder dar cotizaciones a los clientes.

Al finalizar el día todas las ventas se van al sistema de contabilidad para hacer las pólizas contables.

Si nos damos cuenta el sistema de ventas necesita una “Integración” constante con el sistema de Almacén ya que desde allí consulta la existencia pero también la modifica cuando venden.

Al final del día el sistema se tiene que “Integrar” con el sistema de contabilidad para realizar las pólizas.

Hora imaginemos que estas integraciones no existieran!!, Te imaginas como se pudiera operar si esta comunicación con los sistemas no se pudiera dar o no fuera eficiente?

SOA Composite

Bien un composite es donde diseñamos a un alto nivel la integración o Integraciones las cuales serán expuestas como servicios para que los sistemas los consuman y logren la integración.

Una composición SOA se divide en tres secciones:

• Exposed Services: En esta sección describimos la forma en que expondremos los servicios ante los consumidores(Aplicaciones), esta sección podemos exponer WebServices, EJB, Servicios HTTP, Sockets los cuales sirven para que los clientes puedan iniciar la integración bajo demanda, pero también existen métodos que hacen que muestra integración se ejecutaba bajo algún evento en especial como por ejemplo, Colas de mensaje(Queue) JMS, Base de datos(Poolling), B2B. En resumen esta sección representa la entrada de la integración y el inicio de su ejecución.
• External References: En esta sección ponemos los servicios externos que requeriremos para que nuestra integración se pueda realizar. Aquí podemos poner WebServices, Base de datos, HTTP, Colas de mensaje, B2B,etc.
• Components: Aquí es donde se programa las acciones a seguir para que nuestra integración realice lo que esperamos, A qui podemos poner BPEL, Human Task, Business Rules,BPM las cuales son componentes diseñados para atacar diferentes problemáticas.

Un composite para la integración del sistema de punto de ventas y almacén se vería algo a sí

Fig.1: Composite para integrar Punto de venta con Almacén.

En la figura anterior podemos ver que tenemos dos servicios del lado izquierdo los cuales representa los servicios que estamos exponiendo para ser consumidos por el Punto de venta.

En medio vemos dos BPEL(En Azul) los cuales se encargan de Orquestar las acciones necesarias para realizar la operación deseada.

Y del lado derecho tenemos el WebService que expone el almacén, el cual tiene las operaciones consultaExistencia y actualizarExistencia necesarias para realizar la integración.

Por ultimo les dejo esta liga donde donde podrán encontrar mucha mas información de lo que es un Composite

http://docs.oracle.com/cd/E14571_01/integration.1111/e10223/arch_02.htm

The post Oracle SOA Suite – Que es un Composite 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.