TECNOLOGIAS PARA LA INTEGRACION DE … · Arquitectura Orientada a Servicios (SOA) COMPONENTES ......

Facultad de Estadística e Informática

TECNOLOGIAS PARA LA INTEGRACION DE SOLUCIONES


Clase 25

▪ Repaso segundo parcial.Tema 3: Tecnologías de Servicios Web

Tema 4: Servicios Web RESTful


Clase 25

▪ Repaso segundo parcial.Tema 3: Tecnologías de Servicios Web


Tema 3: Tecnologías de Servicios Web

Servicio Web es una función bien definida, auto-contenida y no depende del contexto o estado de otros servicios.

Ejemplo: API de Google Maps(https://developers.google.com/maps/web-services/overview?hl=es-419)

https://developers.google.com/maps/web-services/overview?hl=es-419


Arquitectura Orientada a Servicios (SOA)COMPONENTES

Servicios✓ Componente reutilizable de software.

Servicios

Contrato

Implementación

Interfaz

Lógica

Datos


Figura. Conceptos básicos de Servicios Web

Proveedor de

servicio

Consumidor

de servicio

Directorio

Usa UDDI

Mensajes SOAP

Solicitud de servicio XML basado en WSDL

Respuesta de servicio XML basado en WSDL

Consultas a Directorio

1

2

3

4

5


Proveedor de servicio

Consumidor de servicio

Directorio

Solicitud de servicio XML basado en WSDL

Respuesta de servicio XML basado en WSDL

<element name=“ClienteInfoSolicitud”>…..<element name=“cuenta” tipo=“string”/>…..

</element><element name=“ClienteInfoRespuesta”>

<element name=“nombre” tipo=“string”/><element name=“telefono” tipo=“string”/>…

</element>

<m:ObtenerClienteInfo…><cuenta>1823</cuenta>

</m:ObtenerClienteInfo>

<m:ObtenerClienteInfoResp…><nombre>Universidad Veracruzana</nombre><telefono>228-8-42-17-00</telefono>…

</m: ObtenerClienteInfoResp >

SOAP (Simple Object Access Protocol)

• SOAP (Simple Object Access Protocol) es un protocolo basado en XML, que permite la interacción entre varios dispositivos y que tiene la capacidad de transmitir información compleja

• Los datos pueden ser transmitidos a través de HTTP, SMTP, etc. SOAP especifica el formato de los mensajes

Además de XML se requiere un protocolo para enviar y recibir peticiones

Simple Object Access Protocol. Esta especificación SOAP define:◦ El formato del mensaje

◦ Como deben ser codificados los datos

◦ Como enviar los mensajes

◦ Como manejar las respuesta a estos mensajes

Tecnologías de Servicios Web

SOAP (Simple Object Access Protocol)

El mensaje SOAP está compuesto por un envelope (sobre), cuya estructura está formada por los siguientes elementos: header(cabecera) y body (cuerpo)

SOAP Envelope

Header

Body

WSDL

XML u otro formato

HTTP u otro protocolo


WSDL (Web Services DescriptionLanguage). Es un formato para describir una interfaz de Servicios Web.

WSDL (Lenguaje de Descripción de Servicios Web)

rquitecturas Orientadas a Servicios y WCF

•WSDL (Lenguaje de Descripción de Servicios Web), permite que un servicio y un cliente establezcan un acuerdo en lo que se refiere a los detalles de transporte de mensajes y su contenido, a través de un documento procesable por dispositivos

•WSDL representa una especie de contrato entre el proveedor y el que solicita. WSDL especifica la sintaxis y los mecanismos de intercambio de mensajes

◦ Mediante un documento Web Services DescriptionLanguage (WSDL) un servicio Web puede conocer los mensajes que un cliente puede enviar y la respuesta que recibirá.

Introducción a Windows Communication Foundation



WSDL Tiene tres partes:

Definiciones

Operaciones

Enlace de servicios

Expresadas en XML e incluyen definiciones de tipos de datos y definiciones de mensajes

Describen acciones para los mensajes soportados


Tecnologías de Servicios Web Definiciones Operaciones Enlaces de servicios

Definiciones de tipos de datos

Definiciones de mensajes





Operación

Operación

Operación

Tipo de puerto

Enlaces Puerto yDirecciones de red



UDDI (Universal Description,

Discovery and Integration). Provee la definición de un conjunto de servicios, soportando la descripción y descubrimiento de:



1) Negocios, organizaciones y otros proveedores de Servicios Web.

2) Los servicios Web disponibles.

3) Las interfaces técnicas que pueden ser usadas para acceder a los servicios.


Tecnologías de Servicios Web El sistema de registro de Negocio UDDI contiene tres directorios:

Páginas Blancas UDDI

Páginas Amarillas UDDI

Páginas Verdes UDDI

4 principios de la orientación a serviciosPara diseñar e implementar SOA, se deben conocer los 4 principios de la orientación a servicios (The Four Tenets of Service Orientation)

Arquitecturas Orientadas a Servicios y WCF


SOAInstitute.org

4 principios de la orientación a servicios

Para diseñar e implementar SOA, se deben conocer los 4 principios de la orientación a servicios (The Four Tenets of Service Orientation):

1. Los límites son explícitos. No se deben hacer suposiciones de como un servicio o cliente procesarán las peticiones. Todo debe ser explicito.

2. Los servicios son autónomos. No se tiene control sobre los servicios consumidos. Pueden ser desconectados o modificados.





3. Los servicios comparten esquema y contrato. Los Servicios publican sus operaciones y la estructura de sus datos mediante interfaces.

Si se desea modificar el servicio, estas interfaces deben actualizarse añadiendo nuevos contratos y esquemas pero continuanfuncionando los existentes para los clientes actuales.





4. La compatibilidad del servicio se basa en políticas. El servicio y el cliente deben conocer las políticas de requerimientos del servicio de antemano.



Alternativas a Windows CommunicationFoundation

JAX-WS (Java API for XML Web Services)

Es una interfaz de programación de aplicaciones (API) de Java en Extensible Markup Language (XML) para la creación de servicios web (WS). Es parte de la plataforma Java EE de Oracle

JAX-WS se desarrolla como un proyecto de código abierto y forma parte del proyecto GlassFish

Alternativas a WCF

Clase 15. Tecnologías de Servicios Web

PHP Web Services NuSOAPEs un kit de herramientas (ToolKit) para desarrollar Web Services bajo el lenguaje PHP.

Está compuesto por una serie de clases que pueden hacer mucho más fácil el desarrollo de Web Services.

Provee soporte para el desarrollo de clientes y de servidores. NuSOAP está basado en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1

Alternativas a WCF


Clase 25

▪ Repaso segundo parcial.Tema 4: Servicios Web RESTful

¿Qué es REST?

➢REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas distribuidos en la Web.

➢Se refiere a una interfaz, que consiste en una red de recursos Web relacionada por links y operaciones como GET, DELETE (transiciones de estado).

➢El término fue introducido en la tesis doctoral de Roy Rielding en 2000, quien es uno de los principales autores de la especificación HTTP.

¿Qué es REST?

➢REST no es un estándar, es un estilo de arquitectura y el término se refiere estrictamente a una colección de principios para el diseño de arquitecturas de red.

➢Estos principios resumen cómo los recursos son definidos y diseccionados.

➢Frecuentemente se utiliza para describir a cualquier interfaz que transmite datos específicos de un dominio sobre HTTP sin una capa adicional como la hace SOAP.

¿Qué es REST?

•Aunque REST no es un estándar, esta basado en estándares:•HTTP•URL•Representación de recursos: XML/HTML/JSON• Tipos de contenido MIME: text/xml, text/html,

text/json

¿Qué es REST?

Internet

Servicio Web

Servicio Web

Servicio Web

• Intenta usar todas las características de la Web para el intercambio de mensajes entre computadoras distribuidas.

• Las URIs identifican los recursos, los cuales son objetos conceptuales. La representación de tales objetos se distribuye por medio de mensajes a través de la Web.

URI

XML/JSON

Principios de REST

➢Escalabilidad de la interacción con los componentes.La Web ha crecido exponencialmente sin degradar su rendimiento.

➢Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial.

Principios de REST

➢Compatibilidad con componentes intermedios. La compatibilidad con intermediarios (Proxys, Firewall, Cachés) nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

Elementos participantes en REST

Debido a que la Web evidentemente es un ejemplo clave de diseño basado en REST; consiste del protocolo HTTP con una interfaz uniforme para acceso a los recursos, el cuál consiste de:

URIs

Códigos de estado

Verbos HTTP

Cabeceras

Contenido guiado

por MIME

URIs

Un identificador de recursos uniforme o URI —del inglés UniformResource Identifier— es una cadena de caracteres que identifica los recursos de una red de forma unívoca.

Las “cosas” identificadas por URIs son “recursos”. Aunque es más apropiado decir que los Recursos son identificados mediante URIs.

Operación URI

Listado https://www.myserver.com/api/películas/

Detalle https://www.myserver.com/api/películas/3

Verbos HTTP

❖Los verbos más importantes en HTTP son PUT, GET, POST, DELETE.

❖ Suelen ser comparados con las operaciones asociadas a la tecnología de base de datos: CRUD: CREATE, READ, UPDATE, DELETE.

❖Otras analogías pueden también ser hechas como con el concepto de copiar-y-pegar (Copy&Paste).

Acción HTTP SQL UNIX Shell

Create PUT INSERT >

Read GET SELECT <

Update POST UPDATE >>

Delete DELETE DELETE Del/Rm

Verbos HTTP

❖Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición. Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación.

Códigos de estado

❖HTTP especifica un conjunto de códigos de estado para cadallamada.

❖Es decir, al solicitar un recurso mediante un URI, el servidor regresará un código de estado de la respuesta, por ejemplo: Éxito, Error o No encontrado.

Códigos de estado

Código de estado

Significado

200 Éxito. La respuesta incluirá información pertinente sobre el recurso

201 Recurso creado. La respuesta incluirá la URI del recurso creado.

301 El recurso se ha movido. Debe incluir la URI de la nueva ubicación.

400 Petición errónea. El cliente debe reformular la petición.

401 Sin autorización. Credenciales erróneas para acceder al recurso.

403Acceso denegado. Se ha autentificado al usuario, pero no tiene permiso de acceder al recuso.

404 Recurso no encontrado.

500Error de servidor. Algo malo pasó en el servidor. Se debe incluir algún tipo de información.

Cabeceras

❖Las Cabeceras HTTP son los parámetros que se envían en una petición o respuesta HTTP, al cliente o al servidor para proporcionar información esencial sobre la transacción en curso.

❖Estas cabeceras proporcionan información mediante la sintaxis 'Cabecera: Valor' y son enviadas automáticamente por el navegador o el servidor Web.

Cabeceras

Cabecera de petición

Ejemplo

Accept Accept: text/plain

Accept-Charset Accept-Charset: utf-8

Accept-Language Accept-Language: en-US

Cabecera de respuesta

Ejemplo

Status Status: 200 OK

Content-TypeContent-Type: text/html;

charset=utf-8

Content-Language Content-Language: en

Contenido guiado por MIME

Se refiere a los encabezados MIME media typeó content type.

Es un identificador del formato del archivo y el contenido que se transmite en Internet.

Esto permite conocer el visor apropiado para el tipo de datos del encabezado enviado.

Se compone de un tipo y un subtipo: tipo/subtipo.

MIME Type

application/javascript

application/json

application/xml

application/zip

text/css

text/html

image/jpeg

Ejemplos REST con XMLPor ejemplo la siguiente petición puede ser enviada a un servidor:

GET /api/peliculas/1234 HTTP/1.1

La respuesta del servicio:

HTTP/1.1 200 OK

Content-Type: application/xml

<Pelicula Id="1234" Status="Active" DateCreated="2017-08-19" Owner=“Erika“ Category=“Acción">

<link rel="self" href="/api/peliculas/1234" method="GET" />

<link rel=“actores" href="/api/peliculas/1234/actores" method="GET" />

<link rel=“delete" href="/api/peliculas/1234" method="DELETE" />

<link rel="update" href="/api/peliculas/1234" method="PUT" />

</Pelicula>

Ejemplos REST con XMLPor ejemplo para crear una nueva película:

POST /api/peliculas HTTP/1.1


<Pelicula Status="Active" DateCreated="2017-08-15" Owner=“Erika“ Category=“Drama">

La respuesta del servicio asumiendo que se creó exitosamente:

HTTP/1.1 201 Created

Location: /api/peliculas/6789


<Pelicula Id="6789" Status="Active" DateCreated="2017-08-15" Owner=“Erika" Category=“Drama">

<link rel="self" href="/api/tasks/6789" method="GET" />

<link rel="owner" href="/api/tasks/6789/owner" method="GET" />

<link rel=“delete" href="/api/tasks/6789" method="DELETE" />

<link rel="update" href="/api/tasks/6789" method="PUT" />

</Task>

¿REST vs los servicios Web estudiados anteriormente

Esta pregunta es un tanto errónea, aunque es bastante típica en los foros de discusión.

REST es un estilo, mientras que los servicios Web son sistemas software. Por tanto, no es posible la comparación de ambos conceptos.

Por otra parte, popularmente se generaliza el concepto de servicio Web con el de servicio Web basado en SOAP. Como hemos visto en apartados anteriores, es posible diseñar servicios Web basados en REST, es decir tomando REST como estilo de diseño.

Por tanto, REST no es una alternativa a los servicios Web, más bien, un servicio Web puede ser implementado mediante SOAP o basado en el estilo REST.

¿REST Vs SOAP?

❖SOAP puede ser demasiado complicado para mostrar cantidades de datos masivos.

❖Este es el caso de grandes empresas como eBay y Google.

❖El problema principal surge del propósito inicial de SOAP, pues fue originalmente pensada para ser una versión, sobre Internet, de DCOM o CORBA, modelos RPC (RemoteProcedure Call) .

¿REST Vs SOAP?

❖Son más adecuadas para entornos aislados, es decir, entornos perfectamente conocidos.

❖Pero cuando el número de usuarios es muy grande es necesario emplear una estrategia diferente. Protocolos basados en RPC no son adecuados para este tipo de sistemas, ya que cambiar su interfaz resulta complicado.

❖Por esta razón, se intenta tomar como modelo a la Web.

¿REST Vs SOAP?REST SOAP

Características Las operaciones se definen en los mensajes. Una dirección única para cada instancia del proceso. Cada objeto soporta las operaciones estándares definidas. Componentes débilmente acoplados.

Las operaciones son definidas como puertos WSDL. Dirección única para todas las operaciones. Múltiple instancias del proceso comparten la misma operación. Componentes fuertemente acoplados.

Ventajas Bajo consumo de recursos. Las instancias del proceso son creadas explícitamente. El cliente no necesita información de enrutamiento a partir de la URI inicial. Los clientes pueden tener una interfaz “listener” (escuchadora) genérica para las notificaciones. Generalmente fácil de construir y adoptar.

Fácil (generalmente) de utilizar. La depuración es posible. Las operaciones complejas pueden ser escondidas detrás de una fachada. Envolver APIs existentes es sencillo.Incrementa la privacidad. Herramientas de desarrollo.


Desventajas Gran número de objetos. Manejar el espacio de nombres (URIs) puede ser engorroso. La descripción sintáctica/semántica muy informal (orientada al usuario). Pocas herramientas de desarrollo.

Los clientes necesitan saber las operaciones y su semántica antes del uso. Los clientes necesitan puertos dedicados para diferentes tipos de notificaciones.Las instancias del proceso son creadas Implícitamente.

Punto de vista La Web es el universo de la información accesible globalmente.

La Web es el transporte universal de Mensajes.

Tecnología Interacción dirigida por el usuario por medio de formularios. Pocas operaciones con muchos recursos.Mecanismo consistente de nombrado de recursos (URI). Se centra en la escalabilidad y rendimiento a gran escala para sistemas distribuidos hipermedia.

Flujo de eventos orquestados. Muchas operaciones con pocos recursos. Falta de un mecanismo de nombrado. Se centra en el diseño de aplicaciones distribuidas.


Protocolo HTTPXML autodescriptivo. HTTP. HTTP es un protocolo de aplicación. Síncrono.

SOAPTipado fuerte, XML Schema. Independiente del transporte.HTTP es un protocolo de transporte. Síncrono y Asíncrono.

Descripción del servicio

Confía en documentos orientados al usuario que define las direcciones de petición y las respuestas. Interactuar con el servicio supone horas de testeado y depuración de URIs. No es necesario el tipado fuerte, si ambos lados están de acuerdo con el contenido.

WSDL. Se pueden construir automáticamente stubs (clientes) por medio del WSDL. Tipado fuerte.

Gestión del estado

El servidor no tiene estado (stateless). Los recursos contienen datos y enlaces representando transiciones a estados válidos.Los clientes mantienen el estado siguiendo los enlaces.

El servidor puede mantener el estado de la conversación. Los mensajes solo contienen datos.Los clientes mantienen el estado suponiendo el estado del servicio.

¿REST Vs SOAP?

REST SOAP

Seguridad HTTPS. Implementado desde hace muchos años. Comunicación punto a punto segura.

WS-Security. Las implementaciones están comenzando a aparecer ahora. Comunicación origen a destino segura.

Metodología de diseño

Identificar recursos a ser expuestos como servicios. Definir URLs para direccionarlos. Distinguir los recursos de solo lectura (GET) de los modificables (POST,PUT,DELETE).Implementar e implantar el servidor Web.

Listar las operaciones del servicio en el documento WSDL. Definir un modelo de datos para el contenido de los mensajes. Elegir un protocolo de transporte apropiado y definir las correspondientes políticas de calidad del servicio, de seguridad y transaccional.Implementar e implantar el contenedor del servicio Web.

¿Cómo diseñar un Servicio Web basado en REST?

1. Identificar todas las entidades conceptuales que se desean exponer como servicio.

2. Crear una URL para cada recurso. Los recursos deberían ser nombres, no verbos (acciones).

Por ejemplo no utilizar esto:

http://www.service.com/entities/getEntity?id=001

Como podemos observar, getEntity es un verbo.

Mejor utilizar el estilo REST, un nombre: http://www.service.com/entities/001


1. Categorizar los recursos de acuerdo con si los clientes pueden obtener un representación del recurso o si pueden modificarlo. Para el primero, debemos hacer los recursos accesibles utilizando un HTTP GET. Para el último, debemos hacer los recursos accesibles mediante HTTP POST, PUT y/o DELETE.

2. Todos los recursos accesibles mediante GET no deberían tener efectos secundarios. Es decir, los recursos deberían devolver la representación del recurso.


3. Ninguna representación debería estar aislada. Es decir, es recomendable poner hipervínculos dentro de la representación de un recurso para permitir a los clientes obtener más información.

4. Describir como nuestro servicio ha de ser invocado, mediante un documento HTML.

Microsoft ASP.NET Web APIIMPLEMENTANDO REST

¿Qué es ASP.NET Web API?

❖HTTP no es solo para servir páginas Web.

❖También es una plataforma para construir APIs que exponen servicios y datos.

❖Casi cualquier plataforma tiene una biblioteca HTTP, por lo que servicios HTTP pueden alcanzar un gran rango de clientes, incluidos navegadores, dispositivos móviles y aplicaciones de escritorio tradicionales.

ASP.NET Web API es una Framework que facilita la creación de servicios RESTful que son capaces de proveer servicios

completamente orientados a recursos.

Alternativas de otras compañías

RESTful Web Services in Javahttps://jersey.java.net/

https://jersey.java.net/

Alternativas de otras compañías

Slim es un micro framework de PHP paradesarrollar aplicaciones Web y APIs.

ASP .NET WEB API UTILIZA MVC PARA IMPLEMENTAR SERVICIOS WEB

¿Qué es MVC?

◦ Patrón de arquitectura de software que separa el modelo, la interfaz de usuario y el control de la lógica de una aplicación en tres distintos componentes.

◦ Presentado por Trygve Reenskaug en 1979 para el Framework Smaltalk(utilizada para crear las interfaces de Apple Lisa y Macintosh).

Modelo

VistaControlador

Patrón de MVC

◦MVC propone la construcción de tres distintos componentes:

1. Modelo

2. Vista

3. Controlador

Modelo

VistaControlador

ACTUALIZA MANIPULA

MUESTRA UTILIZA

Patrón de MVC

El modelo

Representación de los datosLógica del negocioObtiene y almacena datos en un almacenamiento persistente(Base de Datos)

La vista

Interfaz de usuario a partir del modeloElementos de interacción(HTML, XML)

El controlador

Maneja la interacción con el usuario e invoca cambios al Modelo y Vistas.Intermediario entre el Modelo y la Vista.

Jerarquía de dependencia en MVC

El modelo

El Modelo solo conoce sobre el mismo.Esto quiere decir, que el código fuente del Modelo no hace referencias ni a la Vista o al Controlador.

La vista

La Vista si conoce al Modelo. Preguntará al Modelo sobre su estado para saber que mostrar.De esta manera, la Vista puede desplegar algo que esta basado en lo que el Modelo ha hecho.La Vista no sabe nada del Controlador.

El controlador

Conoce al Modelo y a la Vista.Si el usuario realiza una acción, el Controlador sabe que función en el Modelo llamar y también sabe que Vista mostrar al usuario.

Beneficios de MVC➢Fácil de manejar la complejidad

➢Desarrollo de aplicaciones más rápido

➢Reusabilidad del código

➢Desarrollo en paralelo

➢Facilita la presentación de información de diferentes maneras donde el código de la aplicación no se ve afectado

➢Ideal para sistemas grandes y distribuidos

➢Gran control sobre el comportamiento de la aplicación

Flujo de MVC

1. El usuario realiza una acción en la interfaz (ej. presiona un botón)

2. El Controlador toma el evento o acción de entrada

3. El Controlador notifica la acción al Modelo, la cuál pudiera involucrar un cambio en el Modelo (ej. edición de datos).

4. Esto genera una nueva Vista que se envía al usuario. La Vista toma los datos del Modelo (ej. lista de usuarios).

5. La interfaz de usuario espera por otra interacción de usuario, lo que inicia un nuevo ciclo.

Gracias por su atención

TECNOLOGIAS PARA LA INTEGRACION DE … · Arquitectura Orientada a Servicios (SOA) COMPONENTES ......

Documents

Transcript of TECNOLOGIAS PARA LA INTEGRACION DE … · Arquitectura Orientada a Servicios (SOA) COMPONENTES ......