Tema 3 3

Servicios Web

Programación de Red.
Ingeniería en Informática

Servicios Web
Objetivos:
 Conocer el concepto de Servicios Web y toda
la tecnología asociada
 Conocer los protocolos más importantes
asociados a Servicios Web
 Estudiar SOAP, WSDL y UDDI (WSIL)
 Dar un visión general sobre orquestación de
Servicios Web
 Conocer algunos aspectos de seguridad en
Servicios Web 2

Servicios Web

 Concepto de Servicio Web.
 SOAP.
 WSDL.
 UDDI (WSIL).
 Orquestación de Servicios Web.
 Seguridad

3

Orquestación de Servicios Web

 Tipos de Integración.
 Sistemas de Gestión de Flujos.
 Introducción a Sistemas EAI.
 Arquitectura de Sistemas EAI.

4

Tipos de Integración
 Tipos de Integración
 Integración de Plataforma
 Comunicación de aplicaciones en diferentes máquinas
 Independencia de localización, hardware, SO y lenguaje de
programación
 Los Servicios Web constituyen una buena solución para este
problema
 Integración de Datos
 Independencia de arquitectura de almacenamiento
 Independencia de heterogeneidades de formato
 Independencia de heterogeneidades de esquema
 Independencia de combinación de datos
 Sistemas EII ⇒ Enterprise Information Integration 5

 Tipos de Integración
 Integración de Aplicaciones/Procesos (en intranets)
 Creación rápida de aplicaciones basadas en otras
aplicaciones existentes
 Procesos de negocio modelados como flujos ⇒ Sistemas de
gestión de flujos
 Integración B2B (Business to Business) ⇒ Integración de
aplicaciones en Internet
 Independencia de en qué organización (empresa) se
encuentran las aplicaciones que se comunican
 Pregunta: ¿Qué debemos considerar cuando las aplicaciones
que se comunican pertenecen a organizaciones diferentes?
⇒ seguridad (↑), acoplamiento (↓), estándares propios o
sectoriales, etc. 6

 Integración de Aplicaciones ⇒ Sistemas EAI
 Sistemas EAI ⇒ Enterprise Application Integration
 Lógica de control inter-aplicación
 Soporte para envío/recepción de mensajes síncronos y
asíncronos
 Transacciones multi-aplicación
 Soporte para la creación sencilla de wrappers (adaptadores)
para las aplicaciones existentes
 Las soluciones deben basarse en estándares ⇒ Los
Servicios Web juegan un papel crucial mediante los
estándares emergentes para la orquestación (WS-BPEL) y la
coreografía (WSCI) de Servicios Web
 En intranets son una realidad y deben de evolucionar para
dar mayor soporte a comunicaciones B2B (Internet) 7



8

Sistemas de Gestión de Flujos
 Procesos de Negocio
 Los procesos básicos de una organización involucran la
interacción entre múltiples aplicaciones preexistentes
 Estos procesos pueden modelarse como flujos (workflows)
que especifican cómo deben colaborar entre sí las distintas
entidades (aplicaciones/personas) para llevar a cabo el
proceso
 Un flujo (workflow) debe especificar aspectos tales como:
 La secuencia de acciones a realizar por cada entidad
 Los datos intercambiados entre las entidades y la manera en
que deben ser transformados
 Reglas para la toma de decisiones
 Restricciones a satisfacer 9

 Sistemas de Gestión de Flujos
 Casi todos los procesos de negocio pueden modelarse
como flujos ⇒ Escribiendo un wrapper (envoltorio o
adaptador) para cada aplicación
 Se define una interfaz remota estándar (por ejemplo un Web
Service) para el wrapper (adaptador), que permita acceder a
las funcionalidades soportadas por aplicación
 El wrapper (adaptador) debe ser genérico y válido para
soportar las necesidades de todos los procesos que
pretendan interactuar con la aplicación
 La información de entrada y salida a cada aplicación se
deberá modelar de acuerdo a algún formato de intercambio
estándar (por ejemplo XML)
10

 Sistemas de Gestión de Flujos
 Ventajas
 Crear un nuevo proceso de negocio “no” implica programar
 El soporte para el intercambio de mensajes, las transacciones
y otros mecanismos genéricos de diseño es proporcionado
para todos los procesos de negocio por la plataforma de
gestión de flujos
 La respuesta a cambios es más rápida
 Todos los procesos de negocio son gestionados de la misma
forma y desde un único punto ⇒ Facilita la administración,
autenticación, seguridad, etc.
 Algunas herramientas ya traen implementados adaptadores
(wrappers) típicos, al igual que flujos típicos (incidencias,
pedidos, etc.) 11



12

Introducción a Sistemas EAI
 Sistemas EAI (Enterprise Application Integration)
 Lógica de control inter-aplicación
 Soporte para envío/recepción de mensajes síncronos y
asíncronos
 Transacciones multi-aplicación
 Soporte para la creación sencilla de wrappers
(adaptadores) para las aplicaciones existentes
 Las soluciones deben basarse en estándares ⇒ Los
Servicios Web juegan un papel crucial mediante los
estándares emergentes para la orquestación (WS-BPEL) y
la coreografía (WSCI) de Servicios Web
 En intranets son una realidad y deben de evolucionar para
dar mayor soporte a comunicaciones B2B (Internet) 13

 Sistemas EAI ⇒ Evolución
 1ª Generación: WMS (Workflow Management Systems)
 Orientado a que las entidades involucradas en los procesos
de negocio sean personas ⇒ Las acciones a realizar dentro
de un flujo consisten fundamentalmente en el rellenado o la
interpretación de formularios por parte de los usuarios
(personas)
 Dificultades de integración con aplicaciones existentes
 Falta de funcionalidad ⇒ Sin soporte para transacciones y
poca escalabilidad
 Visión de muy alto nivel ⇒ No se ocupa de peculiaridades
técnicas de las aplicaciones involucradas y en la práctica,
involucra gran cantidad de “trabajo manual” de integración
por parte de las personas 14

 2ª Generación: Sistemas EAI (Enterprise Application Integration)
 Centrados en coordinar aplicaciones, en lugar de personas
 Wrappers (conectores o adaptadores) pre-construidos para
tecnologías habituales. Por ejemplo JCA → J2EE Connector
Architecture
 XML como lenguaje de comunicación inter-aplicación
 Reglas de transformación de documentos XML para definir
traducciones entre los lenguajes de cada aplicación
 Soporte transaccional
 Escalabilidad y tolerancia a fallos ⇒ Basados en
arquitecturas distribuidas
 Centrado fundamentalmente en intranets (perspectiva intra-
organización)
15
 Lenguajes propietarios

 3ª Generación: Orquestación de Servicios Web → Salto a
B2B (Internet)
 Perspectiva inter-organización
 Aumentan las preocupaciones de seguridad
 Aumentan los requisitos de autonomía y asincronismo de
las aplicaciones
 Surgen nuevas posibilidades ⇒ Por ejemplo el
descubrimiento de nuevos servicios relevantes disponible
en Internet (UDDI)
 WS-BPEL ⇒ Web Service Business Process Execution
Language
16



17

Arquitectura de Sistemas EAI
 Sistemas EAI
 Cada aplicación tiene asociado un adaptador (o conector, o
“wrapper”) específico:
 Hacen que todas las aplicaciones se ajusten a un modelo común.
 Se ocupan de la comunicación inter-aplicación (Corba, RMI,
Servicios Web, etc.)
 Traducen mensajes del lenguaje del sistema EAI al lenguaje de la
aplicación y las respuestas de la aplicación al lenguaje EAI.
 Un “Concentrador” (“Hub”) central:
 Controla las interacciones entre las aplicaciones para ejecutar un
flujo.
 Funcionalidades de conversión de datos (“Data Mapping”).
 Autorización → seguridad, usuarios, permisos, etc.
 Notificaciones.
18
 Trazabilidad.

 Sistemas Hub @ Spoke

19

 Adaptadores
 Aplicaciones no hablan directamente entre sí sino a través
del hub.
 La mayoría de sistemas EAI incluyen adaptadores pre-
construidos fácilmente configurables para algunos casos:
 Servicios Web, Corba, etc.
 Aplicaciones de fabricantes populares: ERPs, CRMs, Gestores de
contenidos, etc.
 Para el resto de aplicaciones (normalmente un elevado porcentaje),
es necesario programar de forma manual todo o parte del
adaptador implementando alguna interfaz.
 Se pretende que el programador de adaptadores tenga que
ocuparse sólo de proporcionar el “camino de acceso” a la
aplicación, sin lógica ni post-procesamiento complejo. No siempre
es posible. 20

 Servicio de mensajes
 Un sistema EAI requiere de funcionalidades de creación,
envío y recepción de mensajes:
 Garantía de entrega, de orden de mensajes...
 Garantía de integridad y privacidad de mensajes.
 Notificaciones de error.
 Diferentes semánticas de envío (“once and only once”, “at least
once”, etc.)
 Mensajes multicast.
 Mensajes síncronos y/o asíncronos.
 Mensajes punto a punto: Colas de mensajes.
 Mecanismos de subscripción: jerarquías de temas.
 Muchos sistemas utilizan implementaciones de JMS (Java Message
Service).
21



22

 Interacción entre servicios

23

 Estándares WS para SOA (Systems Oriented Arquitecture)

24

 Estándares WS para SOA (Systems Oriented Arquitecture)

25

 Orquestación de servicios Web
 Conectar servicios web entre sí para crear procesos de
negocio de alto nivel.
 Se trata de subsumir la funcionalidad básica del EAI dentro
de un marco válido también para aplicaciones Business to
Business (B2B).
 La orquestación de servicios Web se basa en un modelo
centralizado en el cual las interacciones no se realizan
directamente entre los servicios Web sino que existe una
entidad encargada de definir la lógica de interacción.
 Normas propuestas ⇒ XLANG, WSFL (Web Services Flow
Language), WS-BPEL (Business Process Execution Language for
Web Services), WSCI (Web Service Choreography Interface), BPML
26
(Business Process Modeling Language), etc.

 BPML ⇒ Propuesta por SUN, CSC, Intalio y otros (incluye
WSCI).
 Similar a WS-BPEL en la construcción de flujos que definen el
comportamiento de un Servicio Web. Más completo en algunos
aspectos.
 Utiliza WSCI para definir los intercambios entre los Servicios
Web que forman parte del proceso.
 WSCI ⇒ Propuesta por SUN, SAP, BEA e Intalio.
 WSCI no define un flujo de tareas ejecutable ⇒ En su lugar,
define un proceso mediante los intercambios de mensajes entre
Servicios Web que participan en la realización del mismo.
 Cada Servicio Web es visto como una caja negra y no se pueden
definir declarativamente las operaciones que suceden en su
interior. 27

 No existe un Servicio Web “rector”.

 WS-BPEL ⇒ Business Process Execution Language for Web
Services.
 Esta especificación modela el comportamiento de los diversos
WS que puedan participar en la interacción de un proceso de
negocio.
 Tiene una sintaxis en XML para la descripción de la lógica de
control necesaria para coordinar los WS que participen en un
flujo de proceso. Esta gramática es ejecutada por un motor de
orquestación que coordina todas las actividades y compensa el
proceso global cuando ocurre algún error.

28

 Orquestación de servicios Web
 El W3C ha lanzado un grupo de trabajo dedicado a la
orquestación de servicios Web. Considera WSCI, pero no WS-
BPEL (no ha sido enviado como propuesta y sus costes de
licencia, en principio, no son gratuitos). Utiliza WSCI para definir
los intercambios entre los servicios Web que forman parte del
proceso.
 Los que proponen WS-BPEL tienen un peso enorme en la
industria y parece imponerse como norma “de facto”.
 WS-BPEL está estandarizado por OASIS desde la versión 2.0.
⇒ http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
 WS-BPEL nace de la necesidad de manejar lenguajes distintos
entre la programación a gran escala y la programación detallada,
ya que en su esencia, ambos tipos de desarrollo requieren de
distintos grados de comunicación con otros servicios. 29

 Orquestación vs. Coreografía
 Un modelo de orquestación provee un ámbito específicamente
enfocado en la vista de un participante en particular.
 En cambio, un modelo coreográfico abarca todos los
participantes y sus interacciones asociadas, dando una vista
global del sistema.
 La coreografía de servicios Web (WS-Choreography) es una
especificación de W3C que define procesos de modelo de
negocio basados en XML, los cuales describen protocolos de
colaboración entre participantes de un servicio Web.
 La orquestación describe un control central del comportamiento
como un director de orquesta, mientras que la coreografía trata
sobre el control distribuido del comportamiento donde
participantes individuales realizan procesos basados en eventos
externos. 30

 Orquestación vs. Coreografía

31

 WS-BPEL (Introducción)
 (Web Services) Business Process Execution Language, WS-
BPEL (Lenguaje de Ejecución de Procesos de Negocio con
Servicios Web) ⇒ Es un lenguaje estandarizado por OASIS para
la composición de servicios Web
 WS-BPEL está desarrollado a partir de WSFL y XLANG, ambos
lenguajes orientados a la descripción de servicios Web ⇒ Antes
de su estandarización se denominaba BPEL4WS.
 WS-BPEL consiste en un lenguaje basado en XML diseñado
para el control centralizado de la invocación de diferentes
servicios Web, con cierta lógica de negocio añadida que ayuda a
la programación en gran escala (desarrollo de software de gran
tamaño que involucra grandes procesos de desarrollo, evolución
y mantenimiento).
 WS-BPEL concebido por Oracle, IBM, SAP, Microsoft, etc. 32

 WS-BPEL ⇒ Es el encargado de orquestar todo el proceso
ordenando qué servicio Web ejecutar y en qué momento.
 WS-BPEL ⇒ Proporciona métodos de definición y soporte para
flujos de trabajo y procesos de negocio.
 WS-BPEL ⇒ Depende del uso de WSDL para describir los
mensajes entrantes y salientes → Mensaje = invocación de
operación (modelo de interacción orientado al mensaje).
 WS-BPEL ⇒ Modelo de lenguaje extensible de componentes para
permitir escribir expresiones y consultas en múltiples lenguajes
(soporta Xpath).
 WS-BPEL ⇒ Permite construcciones de programación estructurada
incluyendo "if-then-elseif-else", "while", "sequence“, flow, etc.
 WS-BPEL ⇒ Permite el encapsulamiento de lógica con variables
locales, manejadores de fallo, manejadores de compensación y 33
manejadores de eventos.

 WS-BPEL (Introducción) ⇒ Objetivos de Diseño
 Definir procesos de negocio que interactúan con entidades
externas mediante operaciones de un servicio Web definidas
usando WSDL y que se manifiestan a sí mismas como WS.
 Definir procesos de negocio utilizando un lenguaje basado en
XML.
 Definir una serie de conceptos de orquestación de servicios Web
que pretenden ser usados por vistas internas o externas de un
proceso de negocio.
 Proveer sistemas de control jerárquicos y de estilo gráfico, que
permitan que su uso sea lo más fusionado posible.
 Soportar un método de identificación de instancias de procesos
que permita la definición de identificadores de instancias a nivel
de mensajes de aplicaciones.
34

 WS-BPEL (Introducción) ⇒ Objetivos de Diseño
 Proporcionar funciones de manipulación simple de datos,
requeridas para definir datos de procesos y flujos de control.
 Ofrecer la posibilidad de la creación y terminación implícitas de
instancias de procesos, como un mecanismo básico de ciclo de
vida.
 Definir un modelo de transacción de largo plazo que se base en
técnicas probadas tales como acciones de compensación y
ámbito, de tal manera que permita la recuperación de fallos para
partes de procesos de negocios a largo plazo.
 Usar servicios Web como modelo para la descomposición y
ensamblado de procesos.
 Construir sobre estándares de servicios Web (aprobados y
propuestos) tanto como sea posible, de manera modular y
35
extensible.

 La versión actual es la 2.0, aunque algunas implementaciones
aún soportan sólo la 1.1.
 Estandarizado por Oasis (http://www.oasis-
open.org/home/index.php) ⇒ http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wsbpel
 Se utiliza para:
 Procesos abstractos ⇒ Definir conversaciones y protocolos para el
uso de un servicio Web o de la forma de colaborar de varios
servicios Web.
 Procesos ejecutables ⇒ Flujos donde cada entidad involucrada es
un servicio Web y que, a su vez, ofrecen al exterior una interfaz de
servicio Web.
 Patrocinado por grandes empresas de informática ⇒ IBM,
Microsoft, SAP, Siebel y BEA. 36

 La mayoría de sistemas EAI actuales están empezando a
soportar WS-BPEL.
 Los servicios Web son sólo uno de los formatos de interfaz que
utilizan.
 WS-BPEL tiene el potencial para convertirse en un estándar
para este tipo de sistemas.
 WS-BPEL tiene algunas carencias
 Es necesario formas más sencillas para manipular datos.
 XML no es un lenguaje cómodo para escribir código “a mano” y en
los entornos actuales es difícil evitarlo.
 Algunos defienden el poder incrustar código Java en los flujos
BPEL. Otros ven esto como contrario a la filosofía básica de los
sistemas de Workflow.
37

 Principales elementos de WS-BPEL
 Socios (“PartnerLinks”) ⇒ Entidades que participan en el flujo.
 Variables.
 Actividades.
 Manejadores:
 Manejadores de eventos.
 Manejadores de fallos (excepciones).
 Manejadores de compensación (operaciones deshacer).
 Conjuntos de correlación.
 Un Flujo WS-BPEL ofrece a su vez una interfaz de servicio Web
hacia el exterior.
 Normalmente un proceso WS-BPEL se compone de:
 Un archivo con el proceso a ejecutar (.BPEL).
38
 Una serie de archivos WSDL de apoyo (definiciones).

 WS-BPEL (Socios)
 Los socios representan a los servicios Web invocados por el
proceso. Se basan en dos elementos:
 Tipo de Enlace del Socio (Partner Link Type):
 Define un enlace genérico para una categoría de servicios
web.
 Similar a la definición de una interfaz en lenguajes OO.
 Ejemplo: obtención de cartelera, búsqueda de libros, compra
de libros.
 Enlace del Socio (Partner Link):
 Define el servicio web que realmente se invocará.
 Similar a una implementación de una interfaz en lenguajes
OO.
39

 WS-BPEL (Socios)
 Tipos de enlaces entre socios
 “PartnerLinkTypes” ⇒ Define una colección de roles.
 En lugar de definir la relación entre dos servicios Web en términos
de “proceso” y “servicio externo” (que adopta el punto de vista del
servicio “proceso”), se define de forma neutra.
 Cada rol indica una lista de tipos de puerto (portTypes). Un servicio
Web puede jugar ese rol si implementa esos tipos de puerto.
 Un enlace de socio (PartnerLink) se especifica dándole un nombre,
indicando un “partner link type” y especificando el rol jugado por el
partner en ese “partner link type”.
 Definición de un PartnerLinkType ⇒ Se definen en archivos WSDL
utilizados por el proceso BPEL, y no directamente en el proceso
BPEL.

40

 WS-BPEL (Enlaces entre Socios)
 Definición de enlaces (PartnerLinks → instancias del tipo de
enlace) en el proceso BPEL:
<partnerLinks>
<partnerLink name="bookSearcher"
partnerLinkType="lns:bookSearchLinkType"
partnerRole="bookSearchEngine"/>
</partnerLinks>

 El alias debe apuntar a la URI del fichero WSDL conteniendo
lns
la definición del tipo de enlace bookSearchLinkType.
 Se define una instancia del tipo de enlace bookSearchLinkType:
 Se especifica el nombre de la instancia (bookSearcher).
 Se utilizan los atributos partnerRole y/o myRole para indicar quién
juega cada rol del tipo de enlace (el proceso o el socio).
 No se especifica el “binding” (deployment time).
41

 WS-BPEL (Variables)
 Las variables se utilizan para guardar los datos utilizados dentro
del proceso.
 Variables pueden ser:
 Mensajes completos definidos en una especificación WSDL.
 Un valor de un tipo XML simple (enteros, flotantes, etc.) o
compuesto (XML Schema).
 Elementos XML.
 El tipo de las variables se define en la especificación WSDL del
servicio (o en otros WSDL externos).
 Ejemplos:
<variable name=“searchRequest"
messageType=“searchdef:bookSearchMessage"/>
<variable name=“searchResponse"
messageType=“searchdef:bookSearchReturn"/> 42
<variable name=“numResults“ type=“xsd:int"/>

 WS-BPEL (Actividades primitivas)
 Actividades primitivas:
 Invoke ⇒ Invocar una operación en un servicio web.
 Receive ⇒ Esperar a la recepción de una invocación sobre una
operación del sitio web.
 Reply ⇒ Generar la respuesta de una operación entrada/salida.
 Wait ⇒ Esperar un tiempo.
 Assign ⇒ Asignar valores a variables.
 Throw ⇒ Lanzar excepciones.
 Rethrow ⇒ Relanzar excepciones desde dentro de manejadores de
error.
 Exit ⇒ Terminar la instancia.
 Empty ⇒ No hacer nada.
 ExtensionActivity ⇒ Para añadir extensiones propietarias.
 Validate ⇒ Permite validar el esquema de variables XML. 43

 WS-BPEL (Actividades estructuradas)
 Las actividades primitivas pueden ser combinadas utilizando las
siguientes estructuras de control:
 Sequence ⇒ Secuencia de actividades.
 Flow ⇒ Ejecutar actividades en paralelo. Las restricciones de
orden pueden especificarse mediante “links” (enlaces).
 If ⇒ Estructura condicional para escoger entre un conjunto de
actividades.
 While, Repeat, ForEach ⇒ Creación de bucles.
 Pick ⇒ Ejecutar uno de varios caminos alternativos, en función de
que se produzca un evento u otro.
 Scope ⇒ Define un bloque de actividades (utilizado en
transacciones).
 Compensate ⇒ Define las actividades de un bloque de
compensación. 44

 WS-BPEL (Manejadores)
 Manejadores de fallos (Fault Handlers). Se ejecutan cuando se
lanza una excepción ⇒ Similar al manejo de excepciones en LP.
 Manejadores de compensación (Compensation Handlers). Se
ejecutan para deshacer una operación ⇒ Relacionados con el
tratamiento de transacciones.
 Manejadores de eventos. Se ejecutan cuando se recibe un
mensaje particular o se produce una determinada alerta.
 Los manejadores deben asociarse a un ámbito (“scope”),
concepto muy similar al de “bloque de código” en los LP
 Si salta una excepción dentro de un scope determinado, se invoca
el correspondiente manejador de fallo.
 Los manejadores de eventos están activos mientras el flujo de
control permanece dentro del bloque. Se ejecutan si llega un
determinado mensaje o se da una cierta condición. 45

 WS-BPEL (Conjuntos de correlación)
 BPEL especifica procesos abstractos (por ejemplo, procesar una
orden de compra o el tratamiento de una incidencia).
 Surge el problema de cómo puede identificar cada instancia los
mensajes concretos que se refieren a ella (por ejemplo, los
mensajes involucrados en el procesamiento de una orden de
compra concreta).
 La idea básica es asignar un nombre a una parte del mensaje
útil para identificar una instancia concreta (por ejemplo, número
de orden de compra). Entonces, el sistema asignará a cada
instancia el mensaje que tenga el valor asociado a ella (por
ejemplo asignará los mensajes asociados a un número de orden
de compra a la instancia encargada de procesar dicha orden).
 Los conjuntos de correlación son un concepto discutido en
BPEL, ya que es un concepto lioso de demasiado bajo nivel 46

 WS-BPEL (Conclusiones)
 BPEL sigue las ideas básicas de los sistemas de gestión de
flujos, y las aplica para la orquestación de servicios Web.
 BPEL está pensado para que los procesos sean creados
gráficamente ya que crearlos directamente en XML no es factible
para procesos complejos.
 Algunas direcciones Web interesantes:
 http://soa.netbeans.org/soa/
 http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=int
roduccion-BPEL-openesb
 http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=int
roduccion-BPEL-openesb2
 http://www.bajaryoutube.com/videos/bpel-tutorial-teil-1-bytid-
lqiYIFPd1Wc.html
47

 Orquestación de servicios Web (Microsoft Biztalk Server)
 http://msdn.microsoft.com/es-es/library/aa561986(v=BTS.10).aspx
 http://msdn.microsoft.com/es-es/library/aa559238(v=bts.10).aspx

48

 Windows Workflow Foundation (WF)
 http://msdn.microsoft.com/es-es/library/bb628617(v=VS.90).aspx
 http://msdn.microsoft.com/es-es/netframework/aa663328

49

Tema 3 3

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Tema 3 3

Similar a Tema 3 3 (20)

Más de avalver2

Más de avalver2 (7)

Último

Último (20)

Tema 3 3