Consumir Web Service SOAP Con JavaScript.

Consumir Web Service SOAP Con JavaScript.

Como vimos en el post Anterior consumimos un web service REST, en este vamos a consumir un web service SOAP, Esto lo realice durante el mismo proyecto en donde revisamos diferentes tecnologías para consumir los webs services en la parte Front End.

Es una función muy práctica y básica, pero por lo menos a mí me ayudo a entender cómo funciona por eso quiero mostrárselo.

Lo que inicialmente siempre hago para tener una referencia de la estructura del web service es cargar el archivo WDSL en un SOAP UI, de esta forma podemos ver que funciona, la estructura de datos que nos devuelve. Para los que no lo conocen es una herramienta muy práctica para consumir web service y no solo SOAP, si no también REST, les dejo el link por si les interesa.

https://www.soapui.org/ “Es gratis!”.

Iniciemos, para esto debemos tener un web service SOAP publicado en algún servidor y accesible.

Tenemos nuestro documento HTML y vamos a incrustar una porción de código JavaScript.

Para esto utilizamos: la etiqueta <script> dentro de nuestro HTML, de esta forma:

Luego de esto vamos a construir la función que va a consumir el web service SOAP.

En la función que llamamos soap creamos un objeto XMLHttpRequest por el abriremos la conexión con nuestro servicio.

Este objeto que llamamos xmlhttp usando uno de sus métodos “open”, le daremos el método, la dirección y indicaremos si es asíncrono.

open(method, url, async)

xmlhttp.open('POST', 'http://10.92.48.177:8081/StreamFyApp/SongWS?wsdl', true);

Aquí pusimos método = POST, la dirección de nuestro web service, y true para Async.

Luego de eso crearemos una variable para construir nuestro Request o petición para el Servicio SOAP, esto debe ser con la estructura que ya probamos en SOAP UI.

Posterior a esto vamos a utilizar la función “onreadystatechange”, la cual se ejecutara cuando haya un cambio en el estado.

El evento onreadystatechange, tiene la propiedad readyState la cual mantiene el estado del XMLHttpRequest.

El evento onreadystatechange se dispara cada vez que cambia el readyState.

Durante una solicitud del servidor, el readyState cambia de 0 a 4:

0: solicitud no inicializada.

1: conexión del servidor estableció.

2: solicitud recibida.

3: Solicitud de procesamiento.

4: solicitar acabado y la respuesta está listo.

En el código vemos que si el estado es 4 pasa a la validar el Status.

Estatus tiene dos estados 200  y 400.

200 = ok

400 = Page no found ( Muy conocido en la web)

 

Ya casi terminamos, solo nos falta enviar el POST Request para esto hacemos lo siguiente:

Aquí básicamente seteamos lo header para el request y enviamos el string Request que cargamos anteriormente en la variable “sr”.

Ya tenemos nuestra función ahora debemos llamarla, en este caso lo vamos hacer con un botón, pero se puede poner en el load de la página o en cualquier evento.

Aquí ya estamos consumiendo el web service, y tenemos lista la información para trabajar con ella.

Nos vemos.

Jhonny

Streaming

Streaming

 Cuando pensamos en un proyecto para el curso de sistemas distribuidos, se nos ocurrió la reproducción multimedia exactamente de audio e inmediatamente se viene a la cabeza Streaming ya que es la tecnología más conocida actual que se utiliza para optimizar la descarga y reproducción de archivos de audios y video.

Para esto fue necesario investigar como lo podíamos hacer teniendo en cuenta las características que se debían cumplir en el proyecto por ejemplo web service en SOAP, REST y, por otro lado, también las limitaciones, como lo es el poco tiempo de desarrollo, presupuesto…

Bueno finalmente les comentare el resultado de la investigación sobre el streaming, en que consiste su arquitectura entre otras cosas.

Inicialmente se descargaban archivos y luego se reproducen lo que se busca es entregan varios paquetes en tiempo real, que se descargan y al mismo tiempo que se reproducen.

Como funciona, veámoslo de una manera práctica:

1.     Se conecta al servidor: Un cliente reproductor se conecta al servidor remoto y el servidor envía el archivo.

2.     Almacena el Buffer: El cliente empieza a recibir el archivo y construye un buffer, es decir, una memoria en cache que es donde empieza a guardarlo.

3.     Empieza la reproducción: Cuando esta memoria en cache buffer empieza a llenarse con una porción del archivo el reproductor empieza a reproducir mientras en segundo plano continúa recibiendo y descargando el archivo.

Ahora que conocemos el funcionamiento a nivel general, podríamos entender porque cuando vemos un video en youtube y la velocidad de internet baja o se cae la conexión porque el video sigue reproduciendo y luego se detiene y esto ocurre porque se acaba la información que hay descargada en el buffer.

Hay dos tipos de Streaming, descarga progresiva y transmisión por secuencias.

La descarga progresiva se reproduce en servidores web que disponen de apache, IIS, el archivo que se quiere reproducir solicitado por el cliente es enviado al servidor como cualquier otro archivo utilizando el protocolo HTTP. Si dicho archivo está diseñado para streaming al ser leído por el reproductor cliente, se iniciará en streaming en cuanto se llene el bufer.

En la trasmisión por secuencias: Se reproduce en en servidores web o servidores multimedia que disponen de un software diseñados para esto, de esta forma hay una mejor gestión del streaming, como pueden ser Windows media server, la utilización de este tipo de tecnologías frente a la de descarga progresiva ofrece mejoras significativas como, por ejemplo mayor rapidez en la visualización de la descarga lo que normalmente llamamos carga, Posibilidad de transmisiones en directo algo como lo que permite Facebook últimamente, mejor gestión del ancho de banda y registro de clientes: autenticación, filtrado por ip.

Esto se utiliza en Spotity, youtube, Skype y es lo que pretendemos hacer en nuestro proyecto para el curso de sistemas distribuidos.

¿Finalmente logramos reproducir las canciones en nuestra web?, ¿cómo lo hicimos?

Utilizamos tecnología web service, uno para agregar canciones a nuestro servidor y otro web service que entregaba la información de las canciones por medio de un archivo JSON, ambos web service desarrollados en JAVA (jsp) con el estilo de arquitectura REST.

Tenemos nuestro cliente en la web donde incluimos tecnología JavaScript, apoyándonos en la librería JPlayer.

En donde en nuestro HTML, cargamos los Javascript, donde se consume el web service que nos entrega todas las canciones, en formato JSON.

Este formato JSON lo interpretamos y ponemos a reproducir la canción.

Para que quede un poco más claro mostrare parte del código básico para el funcionamiento.

Nuestro Index.html

-         Importar JavaScript

-         Estructura HTML, CSS donde cargara la lista de canciones.

-         El JavaScript donde consume el Web Service.

Y listo este es el resultado.

Les dejo el link de JPlayer para que vean su documentación y puedan hacer esto. 

http://www.jplayer.org/latest/developer-guide/

Nos vemos. 
Jhonny.

Arquitectura de objetos Distribuidos.

Arquitectura de objetos Distribuidos.

Normalmente trabajamos con arquitecturas Cliente, servidor es por eso que quiero hablar de arquitectura de objetos distribuidos, los objetos se distribuyen a través de varias computadoras en una red y se comunican a través de middleware que proporciona un conjunto de servicios que permiten la comunicación entre objetos y para que estos puedan ser añadidos o eliminados del sistema.  Veamos algunas características del modelo cliente servidor y modelo de objetos distribuidos, además de sus ventajas.

-          En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son diferentes.

-          Los clientes reciben servicios de los servidores y no de otros clientes; los servidores pueden actuar como clientes recibiendo servicios de otros servidores, pero sin solicitar servicios de clientes.

-          Los clientes deben conocer los servidores que ofrece cada uno de los servidores y deben conocer como contactar con cada uno de ellos.

-          El modelo Cliente – Servidor funciona bien para muchos tipo de aplicaciones.

-          Sin embargo, limita la flexibilidad del diseñador, que debe decidir donde se proporciona cada servicio.

-          Tambien debe planificar la escalabilidad y proporcionar algún medio para distribuir la carga sobre los servidores, cuando mas clientes se añadan al sistema.

-          Una opción superdora es eliminar la distinción entre cliente y servidor y diseñar una arquitectura de objetos distribuidos.

-          Aquí, los componentes del sistema con objetos que proporcionand y requieren un conjunto de servicios.

-          Otros objetos relizan llamadas a estos servicios sin hacer ninguna lógica entre el receptor de un servicio y el proveedor de un servicio.

-          Los objetos pueden distribuirse a través de varias computadoras en una red y comunicarse a través de middleware.

-          A este middleware se lo denomina intermediario de peticiones de objetos.

-          Su misión es proporcionar una interfaz transparente entre los objetos.

-          Proporciona un conjunto de servicios que permiten la comunicación entre los objetos y que estos sean añadidos y eliminados del sistema.

Ventajas del modelo de objetos distribuidos.

-          Permitir al diseñador retrasar decisiones sobre dónde y cómo deberían proporcionarse los servicios.

-          Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier nodo de la red.

-          Es una arquitectura abierta: permite añadir nuevos recursos si es necesario.

El sistema es flexible y escalable. 

REST / SOAP

REST / SOAP

En los ultimos dos POST le he hablado:

 1. Streaming consumiendo un web service en REST.

2. consumir desde JavaScript SOAP.

ambos desde Front end, entonces me gustaría explicarles de forma muy práctica y resumido como funciona cada uno, que también fue me dejo este proyecto desarrollado durante mi curso de Sistemas Distribuidos.

SOAP.

Iniciemos por SOAP, Simple Object Access Protocol es un protocolo de mensajería basado en XML utilizado por los servicios web.

La ventaja principal del SOAP es que proporciona un mecanismo de descripción del web services hacía el Cliente por medio del WSDL que es basado en el lenguaje XML para describir los servicios web y cómo acceder a ellos, que es lo que vemos en el primer gráfico.

SOAP se basa en el intercambio de mensajes y se pueden ejecutar en SMTP, HTTP, FTP entre otros y devolver mensajes de datos basados ​​en XML.

Los SOAP Sender en la aplicación es el que tiene los datos a enviar un mensaje SOAP. Vemoas en que se compone un mensaje SOAP.

Un mensaje SOAP se compone de un elemento envoltura que contiene header opcional y un elemento del cuerpo mandatorio.

REST, transferencia de estado representación.

REST ha ganado aceptación a través de la web como una alternativa sencilla al WSDL.

REST tiene una completa comunicación por medio de HTPP y no requiere mensajes XML o WDSL, API definiciones.

REST Tampoco necesita midleware solo HTTP, tiene los métodos, get, put, post, delete.

REST puede retornar XML, texto plano, JSON (JavaScript notación de objetos), HTML entre otro.

REST es mucho más fácil de implementar utilizando casi cualquier herramienta que permita una banda inferior y con curva de aprendizaje corta, sin embargo, los clientes tienen que saber que envían y lo que esperan que les envíen.

En general cuando vamos a publicar una API para el mundo exterior compleja normalmente se utiliza SOAP aun que REST es generalmente la mejor opción si su aplicación necesita un nivel garantizado de fiabilidad y seguridad, por lo que ofrece estándares adicionales para asegurar que este tipo de operación REST maneja stateless y es mejor para la leer actualizar y borrar las operaciones si desea transferir XML JSON el texto etc.

Nos vemos. 

Jhonny