E. Servicios Web PDF

Arquitectura y Servicios de Internet – Servicios web
Unidad E. Servicios Web
1
Universidad de Burgos - Francisco J. Rodríguez <fjrdiaz@ubu.es>
Tabla de contenidos
 Introducción
 Protocolos
 Conceptos
 Arquitecturas de servicios web
 Localización y seguridad
 Orquestación y coreografía
 Plataformas actuales
 Calidad
2
Introducción
 Internet ha favorecido a la necesidad de
integración de sistemas muy heterógeneos:
 Software
 Hardware
 Las empresas han buscado tecnologías que

tuviesen la capacidad de integrar sistemas.
PROBLEMA: Cada vez más sistemas y fue

imposible
3
Introducción
 Solución es buscar un lenguaje común de
intercambio de información aprovechando los
estándares que existen.
 Así es como nacen los SERVICIOS WEB
basados en XML.
 Un servicio web es una colección de
protocolos y estándares que sirven para
intercambiar datos entre aplicaciones.
 El concepto de intercambio → interoperabilidad se
adopta mediante estándares abiertos.
4
Introducción
 Los servicios proporcionan mecanismos de
comunicación estándares entre diferentes
aplicaciones.
 Existe una interactuación entre aplicación del

cliente-servidor para presentar la información
al usuario final.
5
Protocolos: Precedentes
 SMTP/MIME
 correo electrónico es todavía uno de los
sistemas dominantes
 FTP, NNTP
 HTTP/HTTPS y el lenguaje HTML
 protocolos que dan popularidad a Internet
La mayoría facilitan la interacción entre personas a

través de internet / intranet
6
Protocolos: Precedentes
 DCE de OSF – basado en RPC, procedural
 ORB – orientado a objetos, mayoritariamente síncrono
 CORBA, COM/DCOM/COM+/.NET de Microsoft, Java RMI/EJBs
 MOM – orientada a mensaje, comunicación síncrona así
como asíncrona
 Muchas implementaciones propietarias
 JMS como ejemplo de Java API estándar
La mayoría facilitan interacción aplicación a aplicación (app2app) dentro

de una intranet de confianza y sin consideraciones de interoperabilidad
entre diferentes plataformas
7
Conceptos
 Varios conceptos clave sobre los servicios

web:
 Independiente del lenguaje.
 A través de internet utilizando protocolos
establecidos.
 Poco acoplados basado en mensajes.
 Interoperable porque está basado en estándares.
8
Conceptos
 Características
 Usados en entornos con necesidad de comunicación entre
plataformas heterogéneas
 Usar servicios desde clientes esparcidos por la web
Cliente Servicio Web
Cliente RED Servicio Web

(Web – HTTP)
Cliente Servicio Web
 Con la habilidad de atravesar firewalls
9
Conceptos
 Características
intercambio de
mensajes
aplicación aplicación
protocolo para registro y
descubrimiento de descubrimiento de localización UDDI
servicios servicios
descripción de servicios descripción de servicios

protocolo para descripción WSDL
mensajería mensajería
comunicación entre procesos incluyendo
empaquetado / desempaquetado de datos XML,SOAP
transporte transporte
envío de mensajes TCP,HTTP
protocolo de red para la
red red transmisión física y IP
encaminamiento de paquetes
Big web services

10
Conceptos
 En realidad, existen tantas definiciones de los

Servicios Web como compañías los desarrollan,
pero hay algo en común: LOS ASPECTOS
TÉCNICOS:
 SOAP: Protocolo web estándar.

 WSDL: Método para describir interfaces con suficiente
detalle para permitir a un usuario construir una aplicación
cliente para comunicarse con ellos. La descripción se
realiza en un documento XML.
 UDDI: Registro de los servicios web para que los
usuarios puedan encontrarlos.
11
Conceptos
 El éxito reside en el uso de estándares muy

conocidos como XML.
 Se logra: INTEROPERABILIDAD e
INTEGRACIÓN.
 Permiten compartir servicios software, socios,
proveedores, etc.
 Esto implica:
 ESCALABILIDAD
 REDUCCIÓN DE COSTES
 OPTIMIZACIÓN DEL MANTENIMIENTO
 ACELERAR LA TOMA DE DECICIONES
12
Conceptos
 Ventajas:
 Interoperabilidad entre aplicaciones independientemente

de propiedades o plataformas.
 Se fomentan los estándares y protocolos basados en
texto
 Se pueden apoyar en cortafuegos ya que dependen de
HTTP
 Permiten servicios y software de diferentes compañías
ubicados en diferentes lugares geográficos
 Aportan independencia entre aplicación y servicio
13
Conceptos
 Inconvenientes:
 En relación a las transacciones, no se puede comparar el

grado de desarrollo con la computación distribuida como
CORBA.
 Rendimiento bajo con respecto a RMI, CORBA o DCOM.
 Al apoyarse en HTTP se pueden saltar reglas de
seguridad del cortafuegos
 Poca información de servicios web para algunos
lenguajes de programación
14
Arquitectura de Servicios Web

 Diseño de servicios web
 cómo se procesan las peticiones en el servidor
 cómo se invocan y usan los servicios
Servicio web Orientado a RPC Orientado a Orientado a
documento - SOAP recurso - REST
Modelo de RPC Mensaje (o RPC Operaciones
interacción con attachment
XML)
Modelo de proceso Centrado en Centrado en Centrado en
objetos (de documento recurso
negocio)
Tipo de interacción Normalmente Normalmente Normalmente
síncrono asíncrono (pero síncrono (pero
puede ser puede ser
síncrono) asíncrono)
Nota: en rojo soluciones en desuso

 Ejemplos:
 Centrado en Invocación a Método Remoto
 Ej: autorización de tarjeta de crédito:
1. se recibe los datos de la tarjeta como argumentos al método, se recibe la petición por el WS
2. se mapea a un EJB de Sesión
3. se responde
 Viene a ser reemplazado por servicios web REST
 Centrado en Documento
 el servicio recibe un documento XML, y el documento contiene sólo datos y no
vinculaciones explícitas a la lógica de negocio a aplicar
 no son invocados método específicos en el servicio.
 el servicio web aplica la lógica de negocio al documento XML, y el contenido del
documento determina el flujo de trabajo.
 Ej: servicio web de agencia de viajes.
1. se recibe una petición: documento XML con los datos
2. se procesa
3. se responde de acuerdo al contenido del documento
16

 RPC
 Interfaz de llamada a procedimientos y funciones distribuidas
 ¡No débilmente acoplados!
 Primera generación de servicios web
 Muy próxima al modelo de RPC o RMI
 Criticado en la actualidad → “deprecated” ;)
 Centrado en mensajes
 Débilmente acoplados
 Centrados en el “contrato” (proporcionado por el documento WSDL)
 REST (REpresentational State Transfer)

 Emular al protocolo HTTP
 restricción de interfaz limitada de a un conjunto conocido de operaciones (Ej: GET, PUT,
DELETE, POST, OPTIONS, HEAD, etc.)
 Centrado en interactuar con recursos
 no con mensajes ni operaciones.
 Intentando resolver los problemas previos con RPC y mensajes (big web services)
17
 Operación estilo RPC

 Nomenclatura
 Invocación a método  mensaje entrada (input message)
 Argumentos de entrada  parte (part)
 Tipo de retorno  mensaje salida (output message)
Local name: concatenar Mensaje de entrada XML

Namespace: http://www.sd.com/ope
<foo:concatenar xmlns:foo="http://www.sd.com/ope"
Input message: xmlns:xsd="http://www.w3.org/2001/XMLSchema"
Part 1: xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance">
Name: s1 <s1 xsd:type="xsd:string">texto1</s1>
Type: … <s2 xsd:type="xsd:string">texto2</s2>
Part 2: </foo:concatenar>
Name: s2
Type: …
Output message:
Part 1:
<foo:output xmlns:foo="http://www.sd.com/ope">
Name: … texto1texto2
Type: … </foo:ouptut>
Mensaje de respuesta XML
18
 Aplicación web actual no es suficiente:

 No facilita la integración de las apliaciones de
Internet con resto de software de las empresas.
 Para extraer la máxima cantidad de información, los
sitios deben evolucionar. Por eso surgen los WS.
 Funcionalidad de los protocolos empleados:
 XML un WS es una APP creada en XML.
 WSDL describe el servicio cuando está publicado.
Es el lenguaje XML que los proveedores
proporcionan para describir sus servicios web.
 SOAP permite la comunicación entre programa.
 UDDI permite la publicación y localización de los
servicios, es decir, son como una guía de teléfonos.
19
 SOAP
 Protocolo de comunicación para los servicios web
XML.
 Incluye aspectos como invocación a objetos o
servicio de nombres, pero no los especifica.
 Define el formato XML para los mensajes, es decir,
un fragmento XML correctamente definido e incluido
en un par de elementos SOAP es un mensaje SOAP.
 Se puede especificar la representación de datos.
 Permite utilizar SOAP para realizar llamadas a
procedimientos remotos, es decir, se puede utilizar
para implementar aplicaciones de tipo RPC con un
mensaje SOAP que contiene una función invocable.
 Normalmente emplea HTTP pero NO es necesario.
20
 SOAP
 Accesible a través de una URL
Servidor web en http://www.sd.com
 Ej: http://www.sd.com/
 Nombre del servicio (endpoint)
Servicio web en la ruta /Servicio
 Ej: http://www.sd.com/Servicio
Operación
 Habilitando operaciones
Nombre: Concat
 Ej: concatenar
 Único nombre global para las
operaciones (namespace) Operación
 No son url a recursos reales Nombre: ...
 Globalmente únicos
 Ej: http://www.sd.com/ope
Internet
21
 Operación estilo centrado en documento SOAP

 Mensaje de entrada sólo contiene una parte
 Definido en un esquema (XML schema)
Local name: concatenar <xsd:schema targetNamespace=http://www.sd.com/ope

Namespace: http://www.sd.com/ope xmlns:xsd=http://www.w3.org/2001/XMLSchema>
Input message:
<xsd:element name="concatenarRequest">
Part 1:
Name: concatenarRequest
<xsd:complexType>
Element: <xsd:sequence>
Output message: <xsd:element name="s1" type="xsd:string"/>
Part 1: <xsd:element name="s2" type="xsd:string"/>
Name: concantenarResponse </xsd:sequence>
Type: …
</xsd:complexType>
</xsd:element>
</xsd:schema>
Definición del elemento
22
 Operación centrada en documento SOAP

<xsd:schema targetNamespace=http://www.sd.com/ope
xmlns:xsd=http://www.w3.org/2001/XMLSchema> <foo:concatenarRequest
<xsd:element name="concatenarRequest"> xmlns:foo="http://www.sd.com/ope">
<xsd:complexType> <s1>texto1</s1>
<xsd:sequence> <s2>texto2</s2>
<xsd:element name="s1" type="xsd:string"/> </foo:concatenarRequest>
<xsd:element name="s2" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
Mensaje de entrada XML
</xsd:element>
Se puede validar contra un
</xsd:schema> esquema
<foo:concatenarResponse
Mensaje de respuesta XML xmlns:foo="http://www.sd.com/ope"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"
xsi:type="xsd:string">
texto1texto2
</foo:concatenarResponse>
23

Simple Object Access Protocol (SOAP)
 Protocolo basado en XML para Estructura del mensajes
intercambiar información
SOAP1.1 Recubrimiento
 Reglas de codificación para instancias de SOAP
tipos de datos
 Convención para representar
invocaciones RPC Bloque de
 Diseñado para computación Cabecera
distribuida poco acoplada

 Sin referencias remotas Cabecera
 Usado con XML Schema
 Independiente del transporte
Cuerpo SOAP
 SOAP con Attachments permite
datos arbitrarios a ser
empaquetados.
Elemento de
Fallo
 SOAP:
 No es lo mismo la especificación SOAP que las
múltiples implementaciones de dicha especificación.
 A día de hoy nadie escribe mensajes SOAP
directamente sino que se utilizan software de apoyo:
Microsoft SOAP Toolkit o Apache Tookit. El primero
traduce llamadas de funciones de COM a SOAP,
mientras el segundo de JAVA a SOAP, es decir, son
implementaciones concretas.
 Implementado en diferentes hardware y software, es
decir, multiplataforma.
 UBICUIDAD de HTTP y la simplicidad de CORBA los
hacen ideales para usar en WS.
25
 WSDL
 Documento XML que describe un conjunto de mensajes
SOAP y cómo se realiza el intercambio de mensajes.
 Al ser XML es legible y editable.
 Especifica contenido de un mensaje de petición y el
aspecto del mensaje de respuesta en una notación
inequívoca.
 Se basa en el estándar XML Schema y es
INDEPENDIENTE del lenguaje de programación, es
decir, es clave para describir interfaces pues se basa en
estándares.
 También indica dónde está el servicio y el protocolo de
comunicación.
 Entre las herramientas más usadas están en .NET
26

Web Services Description Language (WSDL)
 Un documento WSDL describe: Estructura de Documento

 Qué hace el servicio WSDL1.1
 Dónde reside Documento
 Cómo invocarlo WSDL
[Tipos]
 WSDL es similar a IDL
 más flexible y extensible {Mensajes}
 Define enlace con SOAP1.1, HTTP

{Tipos de puertos}
GET/POST y MIME
{Bindings}
 Descripciones WSDL disponibles
desde un registro UDDI
{Servicios}

Web Services Description Language (WSDL)
 Tipo de puerto (Port type)

 Agrupación de operaciones
 Tip: similar a una clase en Java y sus métodos
 Varios tipos de puerto en un servicio web
 Binding
 Se puede acceder a un tipo de puerto usando diferentes formatos
 Ej: SOAP
 Un tipo de puerto indica el tipo de transporte

 Ej: HTTP POST request o email
 Cada combinación es un "binding"
28
 Estructura
Web Services Description Language. (2013, October 31). In Wikipedia, The Free Encyclopedia.
http://en.wikipedia.org/w/index.php?title=Web_Services_Description_Language&oldid=579589757 29

 Desarrollo
 Top-down
 Dirigido por el WSDL
 Generando interfaces y códigos (esqueletos/proxies) para
los clientes y servidores
 Independiente del lenguaje de programación
 Ej: en Java con JAX-WS, herramienta wsimport
 Bottom-up
 Dirigido por el componente servidor
 Ligado a la implementación del componente inicial
 Generando WSDL y códigos adicionales (clientes, etc.)
 Ej: en Java con JAX-WS, herramienta wsgen
30

 Tipos de datos
 Basado en tipos de datos de esquemas XML
Tipo SOAP (xsi:type)
Integer xsd:int
Boolean xsd:boolean
String xsd:string
Float xsd:float
Double xsd:double
Date xsd:date
Array / Hash /Object xsd:struct
Mixed xsd:anytype

 REST
 Pautas de diseño
 Identificar recursos – entidades conceptuales - que serán URIs
 Ej: producto, listado de empleados
 Invocación utilizando URI (o URL) a recursos
 Ej: GET o POST

 http://example.com/maps/Main%20Street
 Formato de intercambio Mejor nombre de

recurso que
 XML verbos
 JSON (JavaScript Object Notation)
 Texto plano... etc.
 Operaciones
 CRUD (Create, Read, Update, Delete → PUT, GET, POST,
DELETE → etc.)
 Códigos de estado (HTTP) a devolver
32
 ¿Cuándo son apropiados los serviciso REST?

 Apropiados cuando:
 Servicios web sin estado
 Mejora de rendimiento con datos "cacheados" por el servidor (servidor
web)
 Limitado a las peticiones GET
 Cliente y servidor tienen un mutuo acuerdo del formato de mensaje a

transmitir
 No hay método formal de describir la interfaz como con los "big
services"
 Se suelen distribuir con "toolkits" que describen las interfaces en los
lenguajes de programación más populares

 Ancho de banda o recursos limitados
 Especialmente con dispositivos PDA o móviles
 SOAP carga demasiado...
33

 Servicios web RESTful (Representational State Transfer)
 Características:
 Identificación de recursos con URIs
 Independientemente del tipo de recurso (Ej: base de datos, fichero de texto,
etc.)
 Mensajes autodescriptivos
 Sin estado – es necesario el mantenimiento del estado a ambos lados
 Viable utilizar cachés en las operaciones
 Como en HTTP. Ej: GET es “cacheable”, POST no
 Comunicación síncrona con ancho de banda limitado
 Aunque en la actualidad se puede hacer en asíncrono
 Protocolos e interfaces estandarizados (HTTP, XML, JSON)
 Mejor integración con protocolo "bien conocido" como HTTP
 Basados en estándares (y lenguajes) bien conocidos:
 HTTP, XML, URI y MIME
 Sin SOAP ni definición con WSDL
 Infraestructura más ligera que los "big web services" (SOAP + WS*)
 Pero con dificultades para QoS (transacciones, seguridad, etc.)
34
 Resumen:
 Estilo de integración de aplicaciones
 [Pautasso et al., 2008]
Shared database Message Bus

File transfer
Remote
Procedure Call
SOAP
REST WS*
35
Localización
Universal Description, Discovery and Integration (UDDI)
 Servicios de Descripción y Descubrimiento

 Encontrar implementaciones de servicios
 Determinar la seguridad y protocolo de transporte
 Búsqueda de servicios basada en claves
 información del servicio y sus proveedores
 Etc.
 Proporciona
 Soporte para taxonomías de entidades UDDI
 APIs estándar para acceder al registro
 Soporte I18n (internacionalización)
 Modelo de seguridad
Seguridad
 WS-Security
 Protocolos de seguridad para servicios web
 Garantías de integridad y seguridad
 A nivel de aplicación sobre el mensaje SOAP
 Autenticación: cómo transferir token de seguridad
 Integridad (XML Signature)
 Confidencialidad (XML Encription)
 Alternativa
 Trabajar con TLS con HTTPS
 Encriptación punto a punto
37
Orquestación y coordinación
 Orquestación
 Servicios web gestionados por un único punto
central (otro WS)
 Componiendo un proceso de negocio
 Coreografía
 Cada WS sabe en qué momento tiene que
actuar
 Descentralizada
 Basada en la colaboración y el intercambio de
mensajes en procesos públicos
 Scripts que modelan flujos de trabajos de

procesos de negocio
 Multitud de lenguajes
 WSCL, XLALNG, WSFL, BPMN, WSCI, BPML y
BPEL4WS
 BPEL4WS (Business Process Execution
Language for Web Services) como
estándar de facto
38
Plataformas actuales
 .NET
 WebLogic
 WebSphere
 Axis y Jakarta Tomcat
 Java Servicios Web Development Pack
 ColdFusion
 JOnAS
 Novell exteNd
 Zope
 VERASTREAM
39
Calidad
 No se puede definir CALIDAD para un WebService.
 A pesar de tener herramientas para medir la calidad

se debería estandarizar QUÉ medir.
 Un WS deberá ser de gran calidad:

 Bajo precio
 Resultados obtenidos similares a los esperados.
 Integración con respecto a las espectativas del usuario.
 Escalabilidad mediante modularidad y flexibilidad
 Calidad y fiabilidad de los servicios.
40
Calidad con respecto a otras tecnologías
 Permite a diferentes programas escritos en diferentes

lenguajes sobre diferentes plataformas comunicarse
entre sí de un modo basado en estándares.
 Antes se podía hacer con CORBA y DCE, pero ahora

se puede hacer de una forma más sencilla con SOAP
y la forma de acceso es muy fácil.
 La mayoría de compañías tienen implementaciones

SOAP para sus productos.
41
Calidad con respecto a otras tecnologías
 Trabajan con protocolos web estándares

como HTTP, TCP/IP.
 La mayoría de compañías tienen una

infraestructura Web y personal con
conocimiento y experiencia en su
mantenimiento, y por ello, el acceso a
servicios web XML es más sencillo que a
otras tecnologías.
42
Bibliografía
 Liu, M. L (2004) Computación Distribuida. Addison-Wesley
 Capítulo 11. Aplicaciones de Internet – Parte 2
 Tong Ka Iok, Kent (2006) Developing Web Services with Apache
Axis TipTec Development ISBN 1-4116-7032-9
 Pautasso, C., Zimmermann, O. And Leymann, F. (2008) RESTful
Web Services vs. "Big" Web Services: Making the Right
Architectural Decision. IW3C2 2008.
43

E. Servicios Web PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

E. Servicios Web PDF

Cargado por

Copyright:

Formatos disponibles

Arquitectura y Servicios de Internet – Servicios web

Unidad E. Servicios Web

 Las empresas han buscado tecnologías que

PROBLEMA: Cada vez más sistemas y fue

 Existe una interactuación entre aplicación del

La mayoría facilitan la interacción entre personas a

La mayoría facilitan interacción aplicación a aplicación (app2app) dentro

 Varios conceptos clave sobre los servicios

Cliente Servicio Web

Cliente RED Servicio Web

 Con la habilidad de atravesar firewalls

descripción de servicios descripción de servicios

Big web services

 En realidad, existen tantas definiciones de los

 SOAP: Protocolo web estándar.

 El éxito reside en el uso de estándares muy

 Interoperabilidad entre aplicaciones independientemente

 En relación a las transacciones, no se puede comparar el

Arquitectura de Servicios Web

Arquitectura de Servicios Web

 Viene a ser reemplazado por servicios web REST

Arquitectura de Servicios Web

 REST (REpresentational State Transfer)

Arquitectura de Servicios Web

 Operación estilo RPC

Local name: concatenar Mensaje de entrada XML

Mensaje de respuesta XML

Arquitectura de Servicios Web

 Aplicación web actual no es suficiente:

Arquitectura de Servicios Web

Arquitectura de Servicios Web

 No son url a recursos reales Nombre: ...

Arquitectura de Servicios Web

 Operación estilo centrado en documento SOAP

Local name: concatenar <xsd:schema targetNamespace=http://www.sd.com/ope

Definición del elemento

Arquitectura de Servicios Web

 Operación centrada en documento SOAP

Arquitectura de Servicios Web

distribuida poco acoplada

Arquitectura de Servicios Web

Arquitectura de Servicios Web

Arquitectura de Servicios Web

 Un documento WSDL describe: Estructura de Documento

 Define enlace con SOAP1.1, HTTP

Arquitectura de Servicios Web

 Tipo de puerto (Port type)

 Varios tipos de puerto en un servicio web

 Un tipo de puerto indica el tipo de transporte

 Cada combinación es un "binding"

Arquitectura de Servicios Web

Arquitectura de Servicios Web

Arquitectura de Servicios Web

Arquitectura de Servicios Web

 Invocación utilizando URI (o URL) a recursos

 Ej: GET o POST

 Formato de intercambio Mejor nombre de

 JSON (JavaScript Object Notation)

 Texto plano... etc.

Arquitectura de Servicios Web

 ¿Cuándo son apropiados los serviciso REST?

 Cliente y servidor tienen un mutuo acuerdo del formato de mensaje a

lenguajes de programación más populares