Arquitectura orientada a servicios

(1)

SERVICIOS WEB

(2)

Arquitectura orientada a servicios

Deﬁnición de SOA ... ...

SOA is an evolu/on of past pla3orms, preserving successful characteris/cs of tradi/onal architectures, and bringing with it dis/nct principles that foster service-‐orienta/on in support of a service-‐oriented enterprise.

...

(3)

¿ Cuál es el problema? Integración

•  Reto teconológico: Integración de sistemas soBware distribuidos

–  Combinar disDntos módulos para la realización de un proceso de negocio

–  Aseguradora ofrece a sus clientes un servicio de cálculo y comparación de presupuestos

•  Hay otras compañías o partes de la compñía especializadas en ell

•  La aseguradora quiere complementar su aplicación con la de otros, y no desarrollar from scratch (desde cero)

•  Integración entre empresas

–  B2B-‐commerce, colaboración (c,...) –  Aproximaciones: EAI, MOM

•  Integración dentro de la empresa

–  OpDmización de procesos de negocio a través de la integración –  Aproximaciones: middleware (CORBA, RMI, MOM), EAI

•  Necesario un acuerdo para usar un middleware especíﬁco

•  El middleware debe estar “centralizado”

–  Inapropiado para integración entre empresas

»  Soluciones punto a punto

•  Quién controla las colas de mensajes en un MOM?

–  Problemas con ﬁrewalls

(4)

¿ Por qué es la integración de

aplicaciones distribuidas es tan di\cil?

•  Dependencia de la plataforma

–  Diferentes sistemas operaDvos, modelos de programación, sistemas que no fueron diseñados para interaccionar con otros, ...

•  Dependencia del formato de datos

–  Diferentes formatos y modelos de datos

–  Modelos de objetos incompaDbles (java, .net)

•  Fuerte dependencia

–  Las aplicaciones son parte del proceso de negocio; la

alteración de una aplicación alterará el proceso de negocio

➔ Complejidad

➔ Falta de interoperabilidad.

(5)

Orientación a servicios Nuevo enfoque

•  Construir las aplicaciones en base a servicios

– Describir los recursos de computación disponibles como servicios que pueden ser solicitados a través de una interfaz conocide

– UDlizar protocolos estándar basados en Internet ...

•  Surge la Orientación a servicios

(6)

Evolución (I)

Arquitectura Cliente / Servidor

Servicios Web y Arquitecturas REST Arquitectura Cliente/Servidor

máster online en

Arquitectura Cliente/Servidor

online en Dirección e Ingeniería

Servicios de Presentación

de Sitios Web

ese tac ó Lógica de Aplicación

Lógica de Aplicación Petición

Respuesta Software de

comunicaciones

Software de comunicaciones Respuesta

Interacción de protocolos Sistema

Operativo Plataforma

Sistema Operativo Plataforma de protocolos

Plataforma Hardware

CLIENTE SERVIDOR

Coordinador: Dr. Javier Parra Fuente

(7)

Servicios Web y Arquitecturas REST

Arquitectura Cliente/Servidor/Componente

Servicios de Presentación

Petición Petición

Lógica de Aplicación S f

Lógica de Aplicación

S f d

Petición Respuesta

Lógica de Aplicación Software de S f

comunicaciones Sistema

Software de comunicaciones

Sistema

HTTP Protocolo

Propietario

Software de comunicaciones

Sistema Sistema

Operativo Plataforma

H d

Sistema Operativo Plataforma

H d

Sistema Operativo Plataforma

Hardware Hardware

CLIENTE WEB SERVIDOR WEB

Hardware COMPONENTE

Evolución (II)

Arquitectura Cliente/Servidor/

Componente

(8)

Evolución (III)

Arquitectura Java EE Distribuida

Servicios Web y Arquitecturas REST Arquitectura JavaEE Distribuida

Arquitectura JavaEE Distribuida

online en Dirección e Ingeniería de Sitios

Petición ^JNDI Petición Web

Servlet

JDBC

S

e S Respuesta

HTTP

Respuesta RMI

JSP JDBC

JMS

e

M HTTP

RMI

COMPONENTE

4

(9)

Orientación a servicios ¿Qué es un servicio?

•  Conceptos de la vida coDdiana

–  Gas, agua, luz, teléfono

–  Tarjeta de crédito, banco, transporte, ...

–  Paquetes de funcionalidad que funcionan con un contrato y que son publicitados

•  CaracterísDcas comunes a estos servicios

–  Se pueden componer

–  Se pueden descubrir (metadatos)

–  Su uso, frecuentemente, se basa en contratos (coste, condiciones de uso, calidad de servicio, ...)

–  Su uso requiere poco o ningún conocimiento de cómo se implementa el servicio.

(10)

Orientación a servicios ¿Qué es un servicio?

•  Diferentes “deﬁniciones”

–  Conjunto discreto de funcionalidad conDgua y autónoma

–  Unidad de trabajo realizada por un proveedor del servicio para conseguir los resultados deseados por un consumidor del servicio –  Los servicios representan los procesos y acDvidades necesarios para

gesDonar los bienes de una organización en sus diferentes estados –  Módulo so?ware auto-‐descripBvo y autocontenido, disponible vía

red que realiza tareas en nombre de un usuario o aplicación

•  Usar un servicio exige un conocimiento previo del mismo: descripción del servicio (nombre del servicio y los datos necesarios y devueltos por él)

•  Para comunicarse, se envían mensajes (Unidades independientes de comunicación)

(11)

Orientación a servicios ¿Qué es un servicio?

•  Un caso parDcular son los servicios web

–  Sistema soBware diseñado para soportar la

interacción aplicación-‐a-‐aplicación sobre una red

independientemente de la plataforma de las mismas (interoperable), Dene una interfaz descrita en un

formato procesable por una máquina

–  Son intermediarios basados en estándares abiertos.

–  Para la integración de componentes soBware Servicios Web heterogéneos dentro de una organización y entre organizaciones.

(12)

Deﬁnición de Servicio Web

•  Un Servicio Web es una interfaz modular y auto-‐describible que puede publicarse,

localizarse e invocarse a través de la red, mediante el intercambio de mensajes XML estandarizados.

(13)

Ejemplos de Servicios Web

Servicios Web y Arquitecturas REST Ejemplos de Servicio Web

Ejemplos de Servicio Web

S id A li i

Servicio Web Tiempo

Servidor Aplicaciones

Servicio Web Televisión

Servicio Televisión

Web Teléfonos

CLIENTE

(14)

Origen de los Servicios Web

•  Inicio:Computación de máquinas sin comunic.

•  LAN Ethernet-‐Muchos protocolos propietarios

•  Arquitecturasdistribuidas-‐Independientes de Arquitectura, SO, etc.

– CORBA, DCOM, J2EE, …

•  UsodeFirewalls-‐Puerto80

– Protocolos IIOP (CORBA), DCE (DCOM), RMI o RMI/IIOP (J2EE), ...

(15)

Origen de los Servicios Web

•  Aspectos a tener en cuenta:

– Plataformas

– Sistema OperaDvo

– Representación de los datos – Subsistema de Red

– Paradigma de programación

•  Comunicación de Sistemas Heterogéneos

(16)

Origen de los Servicios Web

•  El modelo de arquitectura orientada a

servicios permite el envío de servicios a través de Internet empleando tecnologías estándar como XML, uDlizando componentes de

cualquier aplicación, cualquier plataforma,

cualquier disposiDvo y cualquier localización.

(17)

CaracterísDcas de los Servicios Web

•  CaracterísDcas:

– Basado en XML

– Débilmente Acoplado – Síncrono o Asíncrono

– Llamadas a Procedimientos Remotos – Integración de Aplicaciones con una

infraestructura ligera

– Interoperabilidad entre aplicaciones heterogéneas

(18)

Orientación a servicios -‐ Principios

1) Los servicios son reuDlizables

•  Haya o no posibilidades inmediatas de reuDlización, los servicios deben diseñarse con la reuDlización en mente.

•  ReuDlizables en diferentes senDdos

–  Interoperabilidad entre aplicaciones

•  En principio, los WS son reuDlizables porque se basan en estándares (HTTP, XML, ...)

•  Pero, será necesario que la lógica también sea reusable

–  Composición

–  UDlity services (seguridad, auditoría, ...)

•  Con la uDlización de estándares de diseño

–  IdenDﬁca al servicio y su relación con otros –  Contrato diseño

–  Contrato implementación –  Implementa

•  Ejemplos

–  Correos, sobre (envelope), SOAP

–  Un servicio de acceso a un recurso no comparDble que no tenga previsto el uso comparDdo del mismo

–  El mejor hotel del Himalaya –  ¿ Otros?

(19)

Orientación a servicios -‐ Principios

2) Los servicios comparten un contrato formal

– El contrato describe el servicio y los términos del intercambio de información

– De manera formal, Dene que especiﬁcar

•  El punto en el que se proporciona el servicio Información que necesita y que produce

•  Reglas y caracterísDcas del servicio y de sus operaciones

– ¿ Similitudes? ¿ Diferencias?

(20)

Orientación a servicios -‐ Principios

3) Los servicios están débilmente acoplados

–  El acoplamiento débil es una condición bajo la que un servicio adquiere el conocimiento de otro manteniendo su independencia del mismo

•  Se consigue uDlizando contratos de servicio que permite a los servicios interactuar dentro de unos parámetros predeﬁnidos

–  Ejemplo: DisDntas representaciones internas de datos en disDntas máquinas.

•  Necesidad real: Necesito transmiDr info

•  Necesidad ArDﬁcial: Necesito transmiDr la info de forma disDnta o bien transmiDr info de en qué arquitectura me encuentro.

–  Ejemplo. Cliente y servicio comparten un conocimiento común acerca de la representación en memoria del objeto y la forma de acceder a él.

¿Qué ocurre si cambiamos el interfaz y añadimos un método getTitle()?

interface Library{

Book borrowBook(in string ISBN); } interface Book {

string getISBN();

string getAuthor();

string getTitle();}

(21)

Orientación a servicios -‐ Principios

4) Los servicios abstraen la lógica subyacente

–  Lo único visible de un servicio para el “mundo exterior” es lo que está expuesto en su contrato de servicio

•  Funcionamiento de “caja negra”

•  No hay acuerdos tácitos

–  Granularidad de las operaciones (REST versus SOAP)

5) Los servicios se pueden componer

–  Los servicios pueden representar cualquier Dpo de lógica, incluyendo otros servicios

•  Una extensión común que subraya la composición de servicios es el concepto de orquestación

–  La composición es otra forma de reuDlización

•  La lógica se puede representar a diferentes niveles de granularidad, creando capas de abstracción

(22)

Orientación a servicios -‐ Principios

7) Los servicios no Denen estado

–  Los servicios deberían minimizar la canDdad de información de estado que manejan y el Dempo durante el cual la manDenen

•  Cuando un servicio está procesando una peDción Dene, temporalmente, estado

•  La información de estado es especíﬁca de una acDvidad en curso

–  Cada mensaje que un cliente envía a un servicio debe contener toda la info necesaria para su procesamiento

•  ¿ Qué pasaría si, en el caso anterior, el S1 enviase, previamente al

token, el nombre del almacén de información del que debe recuperar la info?

–  Uso de mensajes-‐documento

•  Cuanta más “inteligencia” tengan los mensajes, más independientes y autosuﬁcientes serán los servicios

–  + reuDlización –  + escalable –  + ﬁable

(23)

Orientación a servicios -‐ Principios

8) Los servicios se pueden descubrir

– Los servicios deberían permiDr que sus

descripciones fueran descubiertas y comprendidas por humanos y solicitantes de servicios

– El descubrimiento evita la creación accidental de servicios redundantes o servicios que implementan lógica redundante

•  La meta-‐información asociada a cada servicio debería ser suﬁciente para describir toda su funcionalidad

(24)

Arquitectura Aplicación con Servicios Web

Servicios Web y Arquitecturas REST

Arquitectura Aplicación con Servicios Web

online en Dirección e Ingeniería de Sitios

Petición ^JNDI Petición Web

Servlet

JDBC ServicioServicio Respuesta Web

HTTP

Respuesta HTTP

JSP JDBC

JMS

Web

HTTP

COMPONENTE

(25)

ParDcipantes de un Servicio

•  Tresroles:

– Solicitante del Servicio – Proveedor del Servicio – Anunciante del Servicio

Servicios Web y Arquitecturas REST Participantes en un Servicio Web

Participantes en un Servicio Web

• Tres roles:

online en Dirección e Ingeniería – Solicitante del Servicio

– Proveedor del Servicio

– Anunciante del Servicio

Anunciante Anunciante

registrar localizar

tili

1 2

3

Solicitante utilizar Proveedor

(26)

Solicitante del Servicio

•  Cliente del Servicio Web que generalmente trabajará con los anunciantes para localizar Servicios Web con los que trabajar.

•  Criterios de decisión de Servicio:

– Coste – calidad

– disponibilidad

– seguridad que ofrece el Servicio Web

(27)

Solicitante del Servicio

•  Pasos que dará un cliente para trabajar con un servicio serán:

1.  Ponerse en contacto con algún anunciante para localizar un servicio concreto

2.  Realizar un enlace al Servicio Web para obtener el modo de ponerlo en

funcionamiento.

3.  UDlizar el Servicio Web.

(28)

Proveedor del Servicio

•  Proporciona el servicio.

•  Ofrece una descripción XML del servicio y la implementación del mismo.

•  Diseñar e Implementar servicios teniendo en cuenta

–  Alta disponibilidad del servicio –  Entorno de transacciones seguro –  Servicio de calidad

–  Prevención de ataques de hackers

(29)

Proveedor del Servicio

•  Los paso que deberá seguir el proveedor para ofrecer su servicio a los solicitantes serán:

1.  Implementar el Servicio Web

2.  Desarrollar la información de descripción del servicio.

3.  Desplegar el servicio en un Servidor

4.  Publicar el servicio para que sea localizable por los anunciantes

(30)

Anunciante del Servicio

•  Proporciona el modo de descubrir Dpos y

semánDcas de Servicios Web y proporciona el enlace a dicho servicio.

(31)

Estándares en Servicios Web

•  XML(eXtensible Markup Language)

•  SOAP(Simple Object Access Protocol)

•  WSDL(Web Services DeﬁniDon Language)

•  UDDI(Universal DescripDon, Discovery and IntegraDon)

•  ebXML(Electronic Business XML)

(32)

Estándares en Servicios Web

•  WS-‐*

– WS-‐Security – WS-‐Bpel

– WS-‐Interoperability

– WS-‐Adressing y WS-‐RouDng – WS-‐Policy y WS-‐EvenDng

– WS-‐Choreography y WS-‐CoordinaDon – WS-‐Resource y WS-‐Discovery

– WS-‐SecureConversaDon y WS-‐NoDﬁcaDon – WS-‐Trust y WS-‐FederaDon

– WS-‐ReliableMessaging y WS-‐Reliability

– WS-‐AtomicTransacDon y WS-‐BuisnessAcDvity

(33)

SOA

Modelo de diseño que se adhiere a estos principios

18

Orientación a servicios

SOA

 Modelo de diseño que se adhiere a estos principios

Service

+ operacion5(...) +operacion2()

Interface B + operacion1(...) +operacion2()

Interface A

Contrato del servicio

Lógica de

negocio Datos Implementación del servicio

(34)

Servicios Web Públicos

• hxp://www.xmethods.com

• hxp://www.searchwebservices.com

• hxp://www.salcentral.com

• hxp://www.bindingpoint.com

• hxp://www.ionicsoB.com/demo/index.jsp

• hxp://www.wsindex.org

Arquitectura orientada a servicios

SERVICIOS WEB