Está en la página 1de 52

Curso 5007437

Conceptos y estndares de arquitecturas orientadas a servicios Web Curso 2006/2007

Captulo 2: Middleware
Pedro lvarez alvaper@unizar.es Jos ngel Baares banares@unizar.es

http://diis.unizar.es/PostWeb/ Departamento de Informtica e Ingeniera de Sistemas

ndice - Captulo 2
o

Entendiendo el papel de un middleware Middleware como abstraccin de programacin Middleware como infraestructura Una rpida revisin de las plataformas middleware convencionales RPC TP Monitors Object brokers Middleware Orientados a Mensajes Convergencia Middleware La evolucin hacia los servicios Web Los Middleware hoy, y la convergencia hacia el Ideal Mitos alrededor de los servicios Web

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

El papel de un Middleware
Middleware como abstraccin de programacin Middleware como infraestructura

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Abstracciones de programacin
o

Los lenguajes de programacin (cualquier forma de sistema software), evoluciona siempre hacia mayores niveles de abstraccin: Ocultando detalles de la plataforma y del hardware Primitivas ms potentes Ayudando/automatizando en las tareas ms pesadas (compiladores, optimizadores, balanceo de la carga, etc.) Reduciendo el nmero de errores de programacin Reduciendo el portabilidad coste de desarrollo y mantenimiento de las aplicaciones, facilitando la Un Middleware es en esencia un conjunto de abstracciones de programacin que facilitan el desarrollo de sistemas distribuidos complejos Para comprender una plataforma middleware slo se precisa conocer su modelo de programacin A partir del modelo de programacin se puede determinar cual sern las limitaciones del middleware, El modelo de programacin subyacente determinar como evolucionar la plataforma cuando las nuevas tecnologas evolucionen.

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

La genealoga de los Middleware


Application servers TP-Monitors Object brokers Message brokers

Transactional RPC

Object oriented RPC (RMI)

Asynchronous RPC

Formas especializadas de RPC, suelen tener funcionalidad adicional

Remote Procedure Call

Remote Procedure Call: oculta detalles de comunicacin detrs de llamadas a procedimiento, y ayuda a a cruzar plataformas heterogneas sockets: Interface a nivel de sistema operativo sobre los protocolos de comunicacin TCP , UDP: User Datagram Protocol (UDP) transporta paquetes de datos sin garantas Transmission Control Protocol (TCP) verifica la entrega correcta de los datos Internet Protocol (IP): Mueve un paquete orientadas a servicios Web de datos de un nodo a otro 5

sockets

TCP , UDP

Internet Protocol (IP)


Curso 5007437 Conceptos y estndares de arquitecturas
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Middleware como infraestructura


proceso cliente cdigo cliente

DCE entorno de desarrollo IDL

proceso servidor Cdigo servidor

Llamada al interface especfica del lenguaje


Stub del cliente

fuentes IDL

Llamada al interface especfica del lenguaje


Stub del servidor

Compilador IDL

RPC API RPC run time libreria servicios interface headers

RPC API RPC run time librera servicios

Protocolos RPC

Servicio de seguridad

Servicios de celda

Servicio de distribucin de ficheros

Servicio procesos

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

DCE runtime environment 6

Infraestructura
o

Segn vamos contando con abstracciones de programacin de ms alto nivel, stas deben estar soportadas por una infraestructura que permita su implementacin La funcionalidad adicional se consigue casi siempre a travs de capas adicionales Las capas software adicional incrementan la complejidad y el tamao de la infraestructura necesaria La infraestructura debe tambin soportar funcionalidad adicional que (abstracciones adicionales) permita el desarrollo, el mantenimiento y la monitorizacin ms fcil y menos costosa RPC => transaccional RPC => recuperacin, modelos de transaccin avanzados, etc. La infraestructura debe tener en cuenta los aspectos no funcionales que no contemplan los modelos de datos y los lenguajes de programacin: prestaciones, recuperacin, mantenimiento, gestin de recursos, etc.
7

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Entendiendo el papel del middleware


Los middleware cumplen un doble papel: como infraestructura y como abstracciones de programacin
ABSTRACCIONES DE PROGRAMACIN
o
o o

INFRAESTRUCTURA

Pretenden ocultar los detalles de bajo nivel del hardware, redes y distribucin La evolucin es hacia primitivas ms potentes que se basan en el concepto bsico de RPC, aadiendo propiedades adicionales o permitiendo un uso ms flexible del concepto Su aspecto viene dictado por la evolucin de los lenguajes de programacin (RPC y C, CORBA y C++, RMI y Java, SOAP-XML y Servicios Web)

Recoge todo lo necesario para desarrollar y ejecutar sistemas distribuidos complejos La tendencia es hacia arquitecturas orientadas a servicios a una escala global y a la estandarizacin de interfaces Otra tendencia importante es hacia una nica infraestructura para minimizar la complejidad y las interacciones La evolucin es hacia la integracin de plataformas y la flexibilidad en la configuracin

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Abstracciones
o

Las abstracciones de programacin son un elemento clave de los middleware, pero no el nico: Una abstraccin de programacin sin una infraestructura que la soporte no ayuda (p.e., una buena implementacin, y un sistema subyacente que la soporte) Las abstracciones de programacin, aparecen con frecuencia como reaccin a cambios en el hardware o la naturaleza de los sistemas que estn siendo desarrollados

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Java como abstraccin


o

Java es un lenguaje de programacin que abstrae el hardware subyacente: los programadores solo ven la mquina virtual Java (infraestructura), sin preocuparse del computador sobre el que se ejecuta Portabilidad de cdigo (no es lo mismo que movilidad de cdigo) El primer paso hacia la estandarizacin de las abstracciones de un middleware (puesto que ahora se pueden apoyar sobre un plataforma virtual sobre la que todos estn de acuerdo) Pero es una plataforma concreto con un modelo/paradigma de programacin concreto. NO TODOS LA COMPARTEN!

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

10

Servicios como abstraccin


o

La computacin Orientada a Servicio se fundamenta en una comunicacin que se abstraiga del modelo de comunicacin propio del lenguaje de comunicacin y de la plataforma de ejecucin No queremos saber si el servicio est programado en Java, Lisp, C, C++, Fortran, etc No quiero saber si tengo que invocar un procedimiento, mtodo, funcin, No quiero saber nada de estructuras de datos en Java, Lisp, C, C++ No quiero saber nada de UNIX, Windows,

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

11

Comunicacin en Servicios (Web)


Services are defined as exchange of messages between participants. This separation of participants in a exchange is a key to decoupling applications.

Service-oriented systems hide the internal abstractions that provides the service such as classes, objects, methods, or remote procedures.
By avoiding any knowledge of the internal structure, it is possible to incorporate any software component or application that can be "wrapped" in message handling code that allows it to adhere to the formal service definition

Web Services Architecture W3C Working Group Note 11 February 2004 http://www.w3.org/TR/ws-arch/wsa.pdf

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

12

Midleware como infraestructura


o

Java (EJB, RMI, CORBA, etc.), .NET, son infraestructuras middleware. Capa software ejecutable que me permite abstraernos de aspectos cotidianos en la programacin de sistemas distribuidos Primitivas de comunicacin basada en RPC, RMI, Soporte a transacciones Gestin del ciclo de vida de los objetos/Procesos Nos facilitan la definicin de la lgica de negoci Son plataformas ejecutables con un modelo de programacin concreto!

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

13

Servicios Web como infraestructuras


o

Los Servicios Web (un caso particular de computacin orientada a servicios) es un tipo diferente de infraestructura. NO ES UNA INFRAESTRUCTURA EJECUTABLE. ES INDEPENDIENTE de la plataforma de ejecucin

Los servicios Web no son una tecnologa complementaria que no reemplaza otras tecnologas No es un nuevo lenguaje de programacin No es una nueva tecnologa middleware en el sentido de J2EE, CORBA o .NET.
QUEREMOS MANTENER LAS ABSTRACCIONES sobre una infraestructura COMN independiente de la plataforma de ejecucin (JAVA, .NET)

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

14

Ideas clave a entender

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

15

Rpida revisin Tecnologas Middleware


RPC TP Monitors Object brokers Middleware Orientado a Mensajes

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

16

Middleware bsico: RPC


o

El programador no debe implementar toda la infraestructura para cada sistema distribuido. Se puede utilizar RPC (nuestro primer ejemplo de middleware de bajo nivel) Qu nos permite un sistema RPC? Ocultar la distribucin detrs de llamadas a procedimientos Ofrecer un lenguaje de definicin de interfaces (IDL) para describir los servicios Generar el cdigo necesario para realizar las llamadas remotas y tratar con todos los aspectos de comunicacin Suministrar un binder si se cuenta con un directorio de servicios y nombres

CLIENTE
Llamada procedimiento remoto

Proceso cliente

stub CLIENTE
Bind Marshalling1 Send
Communication module

stub SERVER Unmarshalling Return

Communication module

Dispatcher
SERVIDOR
(selecciona stub)

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web 1Marshalling: Organizar los datos en un formato antes de enviarlos
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza) Serialization: Transformar el mensaje en una cadena de bytes

Procedimiento remoto

Proceso servidor

17

Binding en RPC
cliente Llamada procedimiento Stub cliente bind marshal serialize send client process

servidor
procedure Stub servidor

Proceso servidor

dispatcher (selecciona stub)


Mdulo comunicacin

Mdulo comunicacin

unmarshal deserialize receive

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

18

Dynamic Binding
cliente Llamada procedimiento client stub bind marshal serialize 2. find 5. send Proceso cliente servidor procedimiento server stub 0. register unmarshal deserialize 7. receive dispatcher (selecciona stub) Mdulo Comunicacin Proceso servidor

Mdulo comunicacin

3. Preguta por servidor que implemente el procedimiento

6. Invoca procedimiento 4. Direccin del servidor

1.

Registra servidor y procedimient

Servicio de nombres y directorio (binder)


Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

19

Qu puede ir mal?
o

RPC es un protocolo punto a punto, en el sentido de que soporta la interaccin de dos entidades (el cliente y el servidor) Cuando hay ms de dos entidades interactuando (un cliente con dos servidores, un cliente con un servidor y el servidor con la base de datos), RPC trata las llamadas de forma independiente. Sin embargo las llamadas no son independientes La recuperacin de fallos parciales es muy compleja. Por ejemplo, se envi la orden, pero el inventario no ha sido actualizado, o se ha hecho el pago pero no se ha registrado Evitar estos problemas utilizando slo sistemas RPC es muy costoso

CLIENTE DEL CONTROL INVENTARIO busca_producto comprueba_inventario IF provisiones_bajo THEN realiza_orden actualiza_inventario ...

Servidor2 (productos) Nuevo_producto busca_producto Borra_producto Actualiza_producto

Servidor 3 (inventario) Realiza_orden Cancela_orden actualiza_inventario comprueba_inventario

BdD productos

BdD Inventario y ordenes

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

20

RPC Transaccional
o
o

La solucin es realizar llamadas transaccionales Qu es un TRPC? Lo mismo que un RPC ms construcciones del lenguajes adicionales que soportan manejar varias llamadas RPC como una unidad con frecuencia, incluyen tambin interfaces a bases de datos para realizar transacciones utilizando el estndar XA (2 Phase Commit) y ms cosas que puedan ser tiles

Simplificando las cosas, se puede decir que TP-Monitors (Transaction Processing Monitors) son sistemas basados en RPC.

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

21

TP-Monitors
o

El ciclo de diseo un TP-Monitor es muy similar a RPC: se definen los servicios a implementar y se especifican en IDL se especifica que servicios son transacciones Se usa un compilador de IDL para generar los stubs del cliente y del servidor La ejecucin requiere un mayor control : los servicios transaccionales mantienen el contexto de la informacin y registran las llamadas para garantizar la atomicidad los stubs necesitan soportar ms informacin como el id de la transaccin y el contexto de la llamada Llamadas jerrquicas complejas se suelen implementar con TP-Monitors y no con RPC plano
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

CLIENTE DEL CONTROL INVENTARIO busca_producto comprueba_inventario IF provisiones_bajo THEN BOT realiza_orden actualiza_inventario EOT..

Servidor2 (productos) Nuevo_producto busca_producto Borra_producto Actualiza_producto

Servidor 3 (inventario) Realiza_orden Cancela_orden actualiza_inventario comprueba_inventario

BdD productos

BdD Inventario y ordenes

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

22

TP-Light y TP-Heavy = 2 niveles y 3 niveles


o

Un TP-heavy monitor ofrece: Un entorno de desarrollo completo (herramientas de programacin, servicios, libreras, etc.), servicios adicionales (colas persistentes, herramientas de comunicacin, servicios transaccionales, planificacin, etc.), soporte para la autentificacin (de usuarios y derechos de acceso a diferentes servicios), soluciones propias de comunicacin, replicacin, balance de carga, gestin de almacenamiento ... (similar a un sistema operativo). Su propsito es ofrecer un entorno de ejecucin para gestores de recursos (aplicaciones), con una garanta razonable en las prestaciones Ejemplos: CICS, Encina, Tuxedo.

Un TP-Light es una extensin en la bases de datos: implementada como hilos, en lugar de procesos, se basa en procedimientos almacenados (mtodos" almacenados en la bases de datos que realizan operaciones) y demonios (triggers), No es un entorno de desarrollo. Los monitores ligeros aparecen segn se van haciendo ms sofisticadas las bases de datos, integrando parte de la funcionalidad de los TP-Monitor en la base de datos. En lugar de escribir preguntas complejas, la pregunta es implementada y almacenada como un procedimiento. El cliente invoca el procedimiento almacenado, en lugar de invocar una pregunta. Ejemplos: Transact-SQL de Sybase, PL/SQL de Oracle.
23

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Bases de datos y el modelo de 2 niveles


o o

Las bases de datos se utilizan tradicionalmente para gestionar datos. Pero la simple gestin de los datos no es un fin en si mismo. Se gestionan datos porque se tiene alguna lgica de aplicacin en mente. Esto se olvida con frecuencia al considerar las bases de datos. Si la lgica de la aplicacin es lo importante, Por qu no mover la lgica de la aplicacin a la base de datos? Esto es lo que proponen muchos vendedores, proponiendo modelos de 2 niveles, incorporando la base de datos herramientas para implementar la lgica de la aplicacin. Estas herramientas incluyen triggers, replicacin, procedimientos almacenados, interfaces de acceso estndar (ODBC, JDBC), etc.

cliente

Sistema de gestin de base de datos


Entorno de Desarrollo BdD aplicacin

Aplicacin externa

database
Gestor recursos
Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

24

CORBA
o

Cliente (objeto CORBA) stub cliente (proxy) librera CORBA

Servidor (objeto CORBA) stub Interfaz servidor Llamadas remotas (skeleton) CORBA Basic Object Adaptor

CORBA (Common Object Request Broker Architecture) es parte de la arquitectura de gestin de objetos estndar (Object Management Architecture, OMA), una arquitectura de referencia para el desarrollo basado en componentes Las partes clave de CORBA son: El ORB (Object Request Broker): se encarga de la interaccin entre componentes Los servicios CORBA: Servicios estndar soportados Un lenguaje IDL estndar para la publicacin de interfaces Protocolos que permiten a los ORB dialogar entre s CORBA es un intento de actualizar los RPC integrndolo con el modelo de objetos y desarrollando un estndar

Marshalling1 serialization2

Object Request Broker (ORB)

servicios CORBA

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web 1 Marshalling: es empaquetar datos en un formato de mensaje antes de transmitir el mensaje por el canal de Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza) comunicacin 25 2 Serializaction: Transforma el mensaje en cadenas de bytes antes de enviar el mensaje por el canal de comunicacin

Un sistema en capas (Distintos esfuerzos de estandarizacin)


CORBA facilities
Servicios bsicos verticales:
finanzas telecomunicaciones

Servicios bsicos horizontales: Objetos definidos por el usuario


Documentos distribuidos Gestin informacin Gestin sistemas Gestin tareas

Object Request Broker

naming trader

transactions concurrency

events query

lifecycle security

properties collection

relationships externalization

time startup

licensing persistence

CORBAservices
Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

26

CORBA sigue el modelo RPC


o

CORBA comparte el mismo modelo que RPC : Intentan resolver el mismo problema CORBA se implementa con frecuencia sobre RPC A diferencia de RPC, CORBA propone una arquitectura completa e identifica partes del sistema en mucho ms detalle que RPC (RPC es un mecanismo de comunicacin, mientras que CORBA es una arquitectura de referencia que incluye un mecanismo de comunicacin) CORBA propone una arquitectura estndar basada en componentes, pero las ideas no son nuevas

El desarrollo es similar a RPC: se definen servicios ofrecidos por el servidor utilizando IDL (define el objeto servidor) Se compila la definicin utilizando un compilador IDL. . El resultado es el stub del cliente (proxy, server proxy, proxy object) y el stub del servidor (skeleton). Las signaturas del mtodo (servicios que pueden ser invocados) se almacenan en el repositorio de interfaces. Se programa el cliente y se enlaza con el stub Se programa el servidor y se enlaza con el stub A diferencia de RPC, los stubs hacen que el cliente y el servidor sean independientes del sistema operativo y del lenguaje
27

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Desarrollo con CORBA (Modelo RPC)


1
Crea tus Defininiciones IDL

Precompilador Skeletons

3
Aade Implementacin Servidor

Compila

5
Interface Repository

Client IDL Stubs

Server IDL Skeletons

Implementacin Objetos

Cliente

Servidor

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

28

Objetos por todos los lados: IIOP y GIOP


o

o o

Para que los ORBs sean realmente una arquitectura de componentes universal, los ORBs deben comunicar entre s (no se puede tener todos los componentes del mundo mundial interactuando en un nico ORB) Con este fin, CORBA ofrece un protocolo general; EL General InterORB Protocol (GIOP), que especifica como pasar llamadas entre ORBs El Internet Inter-ORB Protocol especifica como pasar mensajes GIOP sobre TCP/IP Hay protocolos adicionales que permiten comunicar ORBs con otros sistemas La idea sonaba bien, pero surgi demasiado tarde y ha sido superada por los servicios Web o NO!
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Cliente (objeto CORBA)

Servidor (objeto CORBA)

ORB 1

ORB 2

GIOP

GIOP

IIOP

IIOP

Internet (TCP/IP)

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

29

Lo mejor de los dos mundos: Object Monitors


Las tecnologas Middleware se deben interpretar como las diferentes etapas de evolucin hacia un sistema ideal. Los sistemas actuales no compiten entre s, ms bien se complementan. La competencia surge cuando las infraestructuras que las soportan convergen hacia una nica plataforma:
o

OBJECT REQUEST BROKERS (ORBs): Reutilizacin y distribucin de componentes mediante un interface orientado a objetos estndar y servicios que aaden semntica a la interaccin entre componentes. TRANSACTION PROCESSING MONITORS: Un entorno de desarrollo de componentes capaces de interactuar transaccionalmente y herramientas necesarias para mantener las consistencia transaccional y Object Transaction Monitors?

Object Monitor = ORB + TP-Monitor

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

30

Middleware Orientada a Mensajes


o o

o o

RPC soportan comunicaciones sncronas, pero se requieren formas ms dinmicas y formas de interaccin asncrona La interoperabilidad basada en Mensaje no es nada revolucionario Ya existen implementaciones de RPC que ofrecen comunicacin asncrona Muchos sistemas TP-Monitors tenan colas de mensajes La interoperabilidad basada en mensajes es un paradigma donde clientes y servidores se comunican intercambiando mensajes Un mensaje se caracteriza por un TIPO (p.e. tipos XML) y un conjunto de pares atributo-valor <NOMBRE, VALOR>
Message PedirPresupuesto { NumeroReferenciaPresupuesto:Integer Cliente: String Producto: String Cantidad: Integer FechaEntrega: Timestamp DireccionEntrega: String }
Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

31

Ejemplos mensajes
o o

Cliente y Servidor deben acordar el tipo de mensajes que intercambian No existe distincin entre cliente y servidor (es conceptual)
Message : pedirPresupuesto { NumeroReferenciaPresupuesto: 325 Cliente: Acme,INC Producto:#115 (bilgrafo, blue) Cantidad: 1200 FechaEntrega: Marzo 16,2003 DireccionEntrega: Palo Alto, CA } Message: presupuesto { NumeroReferenciaPresupuesto: 325 FechaEntregraPrevista: Mar 12, 2003 Precio:1200 }

aplicacin cliente

Herramienta presupuestos

aplicacin cliente

Herramienta presupuestos

Middleware Orientado a Mensajes (MOM)

Middleware Orientado a Mensajes (MOM)

Un cliente enva un mensaje a la aplicacin de presupuestos


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

La aplicacin de presupuestos enva un mensaje al cliente 32

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Colas de mensajes
aplicacin cliente

Middleware Orientado a Mensajes (MOM)


Herramienta presupuestos
Mensajes

Cola entrante

encolados

Un MOM no aporta ningn beneficio significativo, pero son la base de desarrollo de conceptos y caractersticas tiles. La abstraccin ms importante son las colas de mensajes
Herramienta Presupuestos 2

Ncleo MOM

Beneficios de las colas de mensajes: - Los destinatarios controlan cuando procesar el mensaje - No tienen que estar continuamente a la espera de mensajes, ni tienen porque existir cuando se enva el mensaje -Las colas pueden ser compartidas, se les puede asignar prioridades a los mensajes, etc., etc.

Herramienta Presupuestos 1

Herramienta Presupuestos 3

Cola entrante
compartida

Ncleo MOM

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

33

Convergencia Middleware
La evolucin hacia los servicios Web Los Middleware hoy, y la convergencia hacia el Ideal Servicios Web como MetaMiddleware, o Middleware para Middlewares Mitos alrededor de los servicios Web

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

34

Resumen Evolucin
o

El funcionamiento del Web esta basado en el paradigma cliente/servidor La evolucin de la Web ha pasado de ser un medio de publicar y emitir documentos electrnicos a soportar aplicaciones cliente/servidor ms interactivas.
Hipertexto Web interactivo Objetos en la Web

Funcin

Web con texto, grficos, y enlaces

Tablas imgenes sonido vdeo CGI

Transacciones seguras: SSL S-HTTP Firewalls

Java Componentes mviles Applets

Objetos distribuidos Documentos compuestos ActiveXs CORBA

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

1994

1995

Tiempo

1996

1997
35

CORBA Y JAVA (Plataforma ubicua)


3 Invoca servicio 2
Descarga HTML + Stub+ Applet+ Orblet

Servidor HTTP

HTML

Stub

Applet Orblet

4 5
Muestra Resultados

Invoca servicio

Servidor CORBA
CORBA Objeto servidor

ORB

Cliente Web

1 Instala HTML

cliente.html Servidor Web Applet CliApplet.class Stub y Orblet 36

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Middleware + Java + Internet


o

Modelo Cliente/servidor en tres capas


Documentos HTML

HTPP

HTPP Internet TCP/ IP

CGI

Aplicaciones

CORBA IIOP

CORBA IIOP
Objetos

CORBA

Cliente Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Servidor Web

Servidor Tradicional
37

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Qu puede ir mal? (1)


o

Los protocolos de los middleware no pueden atravesar firewall, salvo...

Internet
Applet Firewall Entorno cliente Visible al applet Invisible al applet

Entorno servidor

Entorno de otros servidores

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

38

SOAP (RPC sobre HTTP + XML)


Servicios Web

Documentos HTML

SOAP HTPP HTPP CGI HTPP Internet TCP/ IP


Aplicaciones

CORBA IIOP

CORBA IIOP
Objetos

CORBA

Cliente Web Servidor Web


Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

Servidor Tradicional
39

Qu puede ir mal? (2) Convergencia de los middleware


o o

En la prctica, siempre se precisa ms de un tipo de middleware. Hay que ver que ofrece cada producto. Existen implementaciones de una gran variedad de funcionalidades que se solapan: Lo que en CORBA se denominan Servicios CORBA

RPC

runtime App. wrappers engine platform support Name repository services

Existen muchas posibles combinaciones. Algunas funcionan, y otras no.

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

40

Funcionalidad Intercambiable
runtime App. wrappers engine platform support Name repository services
o o

Que haya combinaciones posibles, no quiere decir que todas tengan sentido En un entorno integrado, la funcionalidad integrada no debera llevarse a cabo incorporando componentes externos, sino disendolo de forma coherente desde el principio. Esto no siempre es posible hoy en da.
41

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

RPC

Sistema Ideal
gestin gestin transacciones objetos gestin procesos
gestin mensajes gestin datos

INFRAESTRUCTURA COMN

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

42

Qu infraestructura mnima se precisa?(1)


o

Primitivas de comunicacin (al estilo RPC, CORBA, RMI o un simple intercambio de documentos) Queremos aplicaciones desacopladas Primitiva de comunicacin asncrona Una forma de intercambiar mensajes independiente de la plataforma y que atraviese cortafuegos Protocolos de Internet: HTTP, STMP Representacin de los mensajes en XML: SOAP. Descripciones de los interfaces en XML a partir de primitivas de comunicacin asncrona de envo/recepcin: WSDL Registro de Servicios: UDDI. nico servicio centralizado compartido

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

43

Qu puedeir mal? (3) Motivacin desde el B2B/EAI


o

En interacciones entre organizaciones no hay un lugar obvio donde colocar el middleware Los middleware tradicionales se sitan entre las aplicaciones a integrar. Las aplicaciones estn distribuidas, pero el middleware se centraliza y controla por una compaa. La adopcin de la misma solucin supone que el cliente, el proveedor y el mayorista acuerdan utilizar una determinada plataforma middleware

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

44

Limitaciones de los Middleware convencionales en el B2B


o o

La solucin presentada podra ser posible si hay pocas compaas involucradas Si hay varias compaas, hay que tener en cuenta que Las compaas quieren preservar su autonoma y confidencialidad

Una alternativa sera la comunicacin punto-a-punto Esto quiere decir, que cuando dos compaas quieren comunicar, acuerdan utilizar cierta infraestructura middleware. Por ejemplo, ambos utilizan sus respectivos broker de mensajes para intercambiar mensajes (Dos o mas aplicaciones utilizando broker de mensajes distintos, pero homogneos pueden interaccionar).

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

45

Qu infraestructura mnima se precisa?(2)


o

Las transacciones o cualquier otro aspecto que antes se hacia mediante un middleware centralizado, ahora hay que llevarlo a cabo mediante protocolos (conversaciones entre los servicios involucrados).

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

46

Tecnologa middleware en el presente


o

RPC y el modelo RPC son el ncleo de cualquier plataforma middleware, incluso cuando utilizan interaccin asncrona. RPC, ha pasado a ser la infraestructura de bajo nivel, y su uso directo es infrecuente por parte delos desarrolladores TP-Monitors son tan importantes como en dcadas pasadas, pero se han convertido en componentes de sistemas mayores y estn ocultas detrs de capas adicionales que tienen por objeto la integracin de aplicaciones y servicios Web. Como los RPC, la funcionalidad de los TP-Monitors va migrando hacia los niveles ms bajos de la infraestructura y resultan invisibles para el desarrollador.

CORBA est siendo reemplazado (ms bien incoporando en...) por otras plataformas, a pesar de que sus ideas son todava usadas y copiadas por los nuevos sistemas. CORBA ha sufrido tres desarrollos que han cambiado el panorama: la rpida adopcin de Java y la mquina virtual Java, Internet y el Web, y la aparicin de J2EE y tecnologas relacionadas que se constituyen como el estndar de facto para el middleware (y de esto que dicen los del microsoft...)

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

47

Servicios Web, MetaMiddleware


o

Metamiddleware como INFRAESTRUCTURA comn para otros middlewares: VENTAJAS u Representacin de datos no propietaria (XML) u Interfaces definidos en XML u USO de protocolos de Internet

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

48

Vamos a ver un ejemplo ya!


http://webservices.amazon.com/onca/xml?Service=A WSECommerceService&AWSAccessKeyId=1JFWX63WKHTWX3 4G4KG2&Operation=ItemSearch&Keywords=Aragon&Sear chIndex=Books LIBROS EN AMAZON QUE TRATAN DE ARAGON ESTILO REST de invocacin de servicios WEB , , SOLO HTTP y XML!!!

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

49

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

50

Conceptos de partida

Arquitectura de servicios web

Cul es el origen de la
arquitectura de servicios Web? Evolucin o revolucin? Cul es el estilo arquitectural de los servicios Web? Dnde encajan aqu los middleware, las EAI? Es la arquitectura definitiva para la construccin de sistemas distribuidos?
Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web
Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

51

Ojo con los SW!


o

El correo electrnico utiliza STMP, sin embargo podemos mirar en su contenido para evitar spam PODEMOS MIRAR los mensajes SOAP para que no lleguen a su destino. PODEMOS PONER BARRERAS SOAP sigue el estilo RPC. Esto implica tener miles de interfaces (APIS) distintos con modelos de datos subyacentes que pueden dar problemas para su uso como Servicio. HTTP como protocolo de aplicacin incluye las siguientes
OPCIONES, GET (recupera documento), POST (adjunta informacin al recurso), PUT (almacena informacin), DELETE (borra el recurso indicado). Es un interfaz universal. El servidor ya interpretar que hacer mirando el documento XML. Se puede hacer el nfasis en SERVICIOS, o en WEB (protocolo HTTP). Se est haciendo el nfasis en SERVICIOS. PORQUE no utilizar otros estilos de intereaccin RMI, IORB, JMS. WSDL contempla estos protocolos de transporte!

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web


Departamento de Informtica e Ingeniera de Sistemas (Univ. Zaragoza)

52