2 Middleware

Curso 5007437
Conceptos y estándares de arquitecturas

orientadas a servicios Web
Curso 2006/2007
Capítulo 2:
Middleware
Pedro Álvarez
alvaper@unizar.es
José Ángel Bañares
banares@unizar.es
http://diis.unizar.es/PostWeb/
Departamento de Informática e Ingeniería de Sistemas
Í di - Capítulo
Índice C ít l 2
o Entendiendo el papel de un middleware
Þ Middleware como abstracción de programación
Þ Middleware como infraestructura
o Una rápida revisión de las plataformas middleware
convencionales
Þ RPC
Þ TP Monitors
M it
Þ Object brokers
Þ Middleware Orientados a Mensajes
o Convergencia Middleware
Þ La evolución hacia los servicios Web
Þ Los Middleware hoy, y la convergencia hacia el “Ideal”
Þ Mitos alrededor de los servicios Web
Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Departamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)
2
El papel de unn Middleware
Middle are
Þ Middleware como abstracción de
programación
Þ Middleware como infraestructura

3
Ab t
Abstracciones
i de
d programación
ió
o Los lenguajes de programación (cualquier forma de sistema software), evoluciona
siempre hacia mayores niveles de abstracción:
Þ Ocultando detalles de la plataforma y del hardware
Þ Primitivas más potentes
Þ Ayudando/automatizando en las tareas más pesadas
(compiladores, optimizadores, balanceo de la carga, etc.)
Þ Reduciendo el número de errores de programación
Þ Reduciendo
R d i d ell portabilidad
t bilid d coste
t de
d desarrollo
d ll y mantenimiento
t i i t ded las
l
aplicaciones, facilitando la
o Un Middleware es en esencia un conjunto de abstracciones de programación que
facilitan el desarrollo de sistemas distribuidos complejos
p j
Þ Para comprender una plataforma middleware sólo se precisa conocer su
modelo de programación
Þ A partir del modelo de programación se puede determinar cual serán las
limitaciones del middleware,
middle are
Þ El modelo de programación subyacente determinará como evolucionará la
plataforma cuando las nuevas tecnologías evolucionen.

4
La genealogía de los Middleware
Application
servers
Object Message
TP-Monitors brokers brokers
Transactional Object oriented Asynchronous Formas especializadas de RPC, suelen tener

RPC RPC (RMI) RPC funcionalidad adicional
Remote Procedure Call: oculta detalles de

Remote Procedure Call
comunicación detrás de llamadas a procedimiento, y
ayuda a a cruzar plataformas heterogéneas
sockets:
sockets Interface a nivel de sistema operativo sobre los
protocolos de comunicación
TCP, UDP:
TCP
TCP, UDP User Datagram Protocol (UDP) transporta paquetes de
datos sin garantías
Transmission Control Protocol (TCP) verifica la
entrega correcta de los datos
Internet Protocol (IP) Internet Protocol (IP):
Curso 5007437 Conceptos y estándares de arquitecturas Mueve
orientadas un paquete
a servicios Web de datos de un nodo a otro
5
Middleware como infraestructura
proceso cliente DCE proceso servidor
entorno de
desarrollo
código cliente IDL Código servidor
fuentes
IDL
Llamada al interface Llamada al interface
específica del lenguaje específica del lenguaje
Stub del cliente Compilador IDL Stub del servidor
RPC API RPC API
RPC run titime interface RPC run time

ti
libreria servicios headers librería servicios
Servicio de
Protocolos Servicio Servicio
Servicios de celda distribución de
RPC de seguridad
g procesos
p
fi h
ficheros

DCE runtime environment
6
Infraestructura
o Según vamos contando con abstracciones de programación de más
alto
lt nivel,
i l éstas
é t deben
d b estart soportadas
t d por una infraestructura
i f t t que
permita su implementación
Þ La funcionalidad adicional se consigue casi siempre a través de
capas adicionales
Þ Las capas software adicional incrementan la complejidad y el
tamaño de la infraestructura necesaria
o La infraestructura debe también soportar funcionalidad adicional que

(abstracciones adicionales) permita el desarrollo, el mantenimiento y la
o o ac ó más
monitorización ás fácil
ác y menos
e os cos
costosa
osa
Þ RPC => transaccional RPC => recuperación, modelos de
transacción avanzados, etc.
Þ La infraestructura debe tener en cuenta los aspectos
p no funcionales
que no contemplan los modelos de datos y los lenguajes de
programación: prestaciones, recuperación, mantenimiento, gestión
de recursos, etc.

7
E t di d ell papell del
Entendiendo d l middleware
iddl
Los middleware cumplen
p un doble papel:
p p como infraestructura y como
abstracciones de programación
ABSTRACCIONES DE INFRAESTRUCTURA
PROGRAMACIÓN
o Recoge todo lo necesario para
desarrollar y ejecutar sistemas
o Pretenden ocultar los detalles de bajo distribuidos complejos
nivel del hardware, redes y distribución o La tendencia es hacia arquitecturas
o La evolución es hacia primitivas más orientadas a servicios a una escala
potentes que se basan en el concepto global y a la estandarización de
bá i de
básico d RPC,
RPC añadiendo
ñ di d propiedades
i d d interfaces
adicionales o permitiendo un uso más o Otra tendencia importante es hacia
flexible del concepto una única infraestructura para
minimizar la complejidad y las
o Su “aspecto” viene dictado por la interacciones
evolución de los lenguajes de o La evolución es hacia la integración
programación (RPC y C, CORBA y de plataformas y la flexibilidad en la
C++, RMI y Java, SOAP-XML y configuración
Servicios Web))

8
Ab t
Abstracciones
i
o Las abstracciones de programación son un elemento clave de los
middleware, pero no el único:
Þ Una abstracción de programación sin una infraestructura que la
soporte no ayuda (p
(p.e.,
e una buena implementación
implementación, y un sistema
subyacente que la soporte)
o Las abstracciones de programación, aparecen con frecuencia como
reacción
ió a cambios
bi en ell hardware
h d o la
l naturaleza
t l de
d los
l sistemas
it que
están siendo desarrollados

9
J
Java como abstracción
bt ió
o Java es un lenguaje de programación que abstrae el hardware subyacente: los
programadores solo ven la máquina virtual Java (infraestructura), sin
preocuparse del computador sobre el que se ejecuta
Þ Portabilidad de código
g ((no es lo mismo que
q movilidad de código) g )
Þ El primer paso hacia la estandarización de las abstracciones de un
middleware (puesto que ahora se pueden apoyar sobre un plataforma virtual
sobre la que “todos” están de acuerdo)
Þ Pero es una plataforma concreto con un modelo/paradigma de programación
concreto. ¡NO TODOS LA COMPARTEN!

10
S i i como abstracción
Servicios bt ió
o La computación Orientada a Servicio se fundamenta en una comunicación que
se abstraiga del modelo de comunicación propio del lenguaje de comunicación y
de la plataforma de ejecución
Þ No qqueremos “saber” si el servicio está programado
p g en Java,, Lisp,
p, C,, C++,,
Fortran, etc…
Þ No quiero saber si tengo que invocar un procedimiento, método, función, …
Þ No qquiero saber nada de estructuras de datos en Java,, Lisp,
p, C,, C++
Þ No quiero saber nada de UNIX, Windows,…

11
Com nicación en Servicios
Comunicación Ser icios (Web)
Services
S i are defined
d fi d as exchange
h off messages between
b t participants.
ti i t Thi
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.
Byy a
avoiding
od g a any
y knowledge
o edge o of tthe
e internal
te a ststructure,
uctu e, itt iss poss
possible
b e to incorporate
co po ate
any software component or application that can be "wrapped" in message handling
code that allows it to adhere to the formal service definition
Web
W bSServices
i A
Architecture
hit t
W3C Working Group Note 11 February 2004
http://www.w3.org/TR/ws-arch/wsa.pdf

12
Midle are como infraestructura
Midleware infraestr ct ra
o JJava (EJB
(EJB, RMI,
RMI CORBA,
CORBA etc.),
t ) .NET,
NET son infraestructuras
i f t t middleware.
iddl
Capa software ejecutable que me permite abstraernos de aspectos
cotidianos en la programación de sistemas distribuidos
Þ Primitivas
i ii de
d comunicación
i i basada
b d en RPC, RMI, …
Þ Soporte a transacciones
Þ Gestión del ciclo de vida de los objetos/Procesos
j
Þ Nos facilitan la definición de la lógica de negoció
Þ …
o ¡Son
S plataformas
l t f ejecutables
j t bl con un modelo d l de
d programación
ió concreto!
t !

13
Ser icios Web como infraestructuras
Servicios infraestr ct ras
o Los Servicios
L S i i Web W b (un
( caso particular
ti l de
d computación
t ió orientada
i t d a servicios)
i i ) es
un tipo diferente de infraestructura. NO ES UNA INFRAESTRUCTURA
EJECUTABLE. ES INDEPENDIENTE de la plataforma de ejecución
o Los servicios Web no son una tecnología complementaria que no
reemplaza otras tecnologías
Þ No es un nuevo lenguaje de programación
Þ No es una “nueva tecnología middleware” en el sentido de J2EE,
CORBA o .NET.
o QUEREMOS MANTENER LAS ABSTRACCIONES sobre una infraestructura
COMÚN iindependiente
d di dde lla plataforma
l f dde ejecución
j ió (JAVA
(JAVA, .NET)
NET)

14
Ideas clave
cla e a entender …

15
Rápida revisión
re isión Tecnologías Middleware
Middle are
Þ RPC
Þ TP Monitors
Þ Object brokers
Þ Middleware Orientado a Mensajes

16
Middl
Middleware básico:
bá i RPC
CLIENTE Proceso cliente
o El programador no debe implementar Llamada procedimiento remoto
toda la infraestructura para cada sistema
distribuido. Se puede utilizar RPC
(nuestro primer ejemplo de middleware
de bajo nivel) stub CLIENTE
o ¿Qué nos permite un sistema RPC? Bind
Þ Ocultar la distribución detrás de Marshalling1
llamadas a procedimientos Send Communication
Þ Ofrecer un lenguaje de definición module
de interfaces (IDL) para describir
los servicios
Þ Generar el código necesario para
realizar las llamadas remotas y Communication
tratar con todos los aspectos de stub SERVER module
comunicación
i ió Unmarshalling
Þ Suministrar un “binder“ si se cuenta Return
con un directorio de servicios y Dispatcher
nombres (selecciona
stub)
Curso 5007437
1Marshalling: Conceptos
Organizar y estándares
los datos de arquitecturas
en un formato
SERVIDOR
orientadas a servicios Web
antes de enviarlos Procedimiento remoto
Serialization: Transformar el mensaje en una cadena de bytes Proceso servidor 17
Binding en RPC
cliente client Proceso

process servidor servidor
Llamada
procedure
procedimiento
dispatcher
(selecciona
Stub cliente Stub servidor
stub)
bind
marshal unmarshal
serialize Módulo deserialize Módulo
send comunicación
i ió receive comunicación
i ió

18
D namic Binding
Dynamic
Proceso Proceso
cliente cliente servidor servidor
Llamada
procedimiento
p procedimiento
dispatcher
client stub (selecciona
server stub
bind stub)
0 register
0.
marshal
h l
serialize unmarshal
2. find Módulo deserialize Módulo
5. send comunicación 7. receive Comunicación
3. Preguta por servidor

6. Invoca procedimiento 1. Registra
que implemente
el procedimiento servidor y
4. Dirección del servidor procedimiento
S
Servicio
i i dde nombres
b y directorio
di t i (bi
(binder)
d )
19
¿Qué puede ir mal? CLIENTE DEL
CONTROL
INVENTARIO
busca_producto
o RPC es un protocolo punto a punto,punto en el comprueba inventario
comprueba_inventario
sentido de que soporta la interacción de dos IF provisiones_bajo
entidades (el cliente y el servidor) THEN
o Cuando hay más de dos entidades realiza_orden
i t
interactuando
t d (
(un cliente
li t con dos
d actualiza inventario
actualiza_inventario
servidores, un cliente con un servidor y el ...
servidor con la base de datos), RPC trata
las llamadas de forma independiente. Sin
embargo
b l
las ll
llamadas
d no son Servidor2 (productos) Servidor 3 (inventario)
independientes
Nuevo_producto Realiza_orden
o La recuperación de fallos parciales es muy busca_producto Cancela_orden
p j Por ejemplo,
compleja. j p , se envió la orden,, Borra producto
Borra_producto actualiza inventario
pero el inventario no ha sido actualizado, o Actualiza_producto comprueba_inventario
se ha hecho el pago pero no se ha
registrado …
o Evitar estos problemas utilizando sólo
sistemas RPC es muy costoso BdD
BdD Inventario
productos y ordenes

20
RPC T
Transaccional
i l
o La solución es realizar llamadas o Simplificando las cosas, se puede decir
transaccionales
i l que TP-Monitors
TP M i (T
(Transaction
i
o ¿Qué es un TRPC? Processing Monitors) son sistemas
Þ Lo mismo que un RPC más … basados en RPC.
Þ construcciones del lenguajes
adicionales que soportan manejar
varias llamadas RPC como una
unidad
Þ con frecuencia, incluyen también
interfaces a bases de datos para
realizar transacciones utilizando el
estándar XA (2 Phase Commit)
Þ y más cosas que puedan ser útiles
…

21
CLIENTE DEL
CONTROL
TP M it
TP-Monitors INVENTARIO
busca_producto
comprueba_inventario
o El cciclo
c o de diseño
d se o un
u TP-Monitor
o to es IF provisiones
provisiones_bajo
bajo
muy similar a RPC: THEN
Þ se definen los servicios a BOT
implementar y se especifican en realiza_orden
IDL actualiza inventario
Þ se especifica que servicios son EOT..
transacciones
Þ Se usa un compilador de IDL para
ggenerar los stubs del cliente y del Servidor2 (productos) Servidor 3 (inventario)
servidor
o La ejecución requiere un mayor control : Nuevo_producto Realiza_orden
Þ los servicios transaccionales busca_producto Cancela_orden
mantienen el contexto de la Borra producto
Borra_producto actualiza inventario
información y registran las llamadas Actualiza_producto comprueba_inventario
para garantizar la atomicidad
Þ los stubs necesitan soportar más
información como el id de la
transacción y el contexto de la
llamada BdD
BdD Inventario
o Llamadas jerárquicas complejas se y ordenes
suelen implementar con TP-Monitors y productos
no con RPC plano l
22
TP Light y TP-Heavy
TP-Light TP Heavy = 2 niveles y 3 niveles
o Un TP-heavy monitor ofrece: o Un TP-Light es una extensión en la
Þ Un entorno de desarrollo completo b
bases d datos:
de d
(herramientas de programación, Þ implementada como hilos, en lugar
servicios, librerías, etc.), de procesos,
Þ servicios adicionales (colas Þ se basa en procedimientos
persistentes, herramientas de almacenados (“métodos"
comunicación, servicios almacenados en la bases de datos
transaccionales, planificación, que realizan operaciones) y
etc.), demonios (triggers),
Þ soporte t para la
l autentificación
t tifi ió (de (d Þ No
N es un entorno
t d desarrollo.
de d ll
usuarios y derechos de acceso a o Los monitores ligeros aparecen según
diferentes servicios), se van haciendo más sofisticadas las
Þ soluciones propias de bases de datos, integrando parte de la
comunicación replicación
comunicación, replicación, balance funcionalidad de los TP-Monitor
TP Monitor en la
de carga, gestión de base de datos.
almacenamiento ... (similar a un o En lugar de escribir preguntas
sistema operativo). complejas, la pregunta es implementada
o Su propósito es ofrecer un entorno de y almacenada como un procedimiento.
procedimiento
ejecución para gestores de recursos El cliente invoca el procedimiento
(aplicaciones), con una garantía almacenado, en lugar de invocar una
razonable en las prestaciones pregunta.
o Ejemplos: CICS,
CICS Encina,
Encina Tuxedo.
Tuxedo o Ejemplos: Transact
Transact-SQL
SQL de Sybase,
Sybase
PL/SQL de Oracle.
23
B
Bases de
d datos
d t y ell modelo
d l de
d 2 niveles
i l
o Las bases de datos se utilizan cliente
tradicionalmente para gestionar datos.
o Pero la simple gestión de los datos no es
un fin en si mismo. Se gestionan datos
pporque
q se tiene alguna
g lógica
g de aplicación
p Sistema de gestión
en mente. Esto se olvida con frecuencia al de base de datos
considerar las bases de datos.
o Si la lógica de la aplicación es lo
importante, ¿Por qué no mover la lógica de Entorno de
la aplicación a la base de datos? Esto es lo Desarrollo
que proponen muchos vendedores, BdD
proponiendo modelos de 2 niveles,
incorporando la base de datos herramientas Lógica de la
para implementar la lógica de la aplicación
li ió
aplicación.
o Estas herramientas incluyen triggers,
replicación, procedimientos almacenados,
interfaces de acceso estándar (ODBC,(ODBC
JDBC), etc.
Aplicación
externa
database
Gestor recursos
24
CORBA Cliente
(objeto
Servidor
(objeto
CORBA) CORBA)
o CORBA (Common Object Request
Broker Architecture) es parte de la
arquitectura de gestión de objetos stub stub
estándar (Object Management Interfaz
Architecture, OMA), una arquitectura de cliente servidor
(
(proxy) ) Llamadas remotas ((skeleton)
k l )
referencia para el desarrollo basado en
componentes
o Las partes clave de CORBA son:
Þ El ORB (Object Request Broker): librería CORBA
1
se encarga de la interacción entre Marshalling
M h lli B i
Basic
CORBA Object
componentes serialization2
Þ Los servicios CORBA: Servicios Adaptor
estándar soportados
p
Þ Un lenguaje IDL estándar para la
publicación de interfaces
Þ Protocolos que permiten a los ORB Object Request Broker (ORB)
dialogar entre sí
o CORBA es un intento de actualizar los
RPC integrándolo con el modelo de
objetos y desarrollando un estándar servicios
CORBA
1Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web
Marshalling: es empaquetar datos en un formato de mensaje antes de transmitir el mensaje por el canal de
comunicación 25
2
Serializaction: Transforma el mensaje en cadenas de bytes antes de enviar el mensaje por el canal de comunicación
Un sistema en capas
(Distintos esfuerzos de estandarización)
CORBA facilities
Servicios básicos verticales:
finanzas telecomunicaciones …
Servicios básicos horizontales:

Documentos Gestión Gestión Gestión
Objetos definidos distribuidos información sistemas tareas
por el usuario
Object Request Broker
naming transactions events lifecycle properties relationships time licensing
trader concurrency query security collection externalization startup persistence
CORBAservices
26
CORBA sigue el modelo RPC
o CORBA comparte el mismo modelo que o El desarrollo es similar a RPC:
RPC : Þ se definen servicios ofrecidos por el
Þ Intentan resolver el mismo problema servidor utilizando IDL (define el
Þ CORBA se implementa con objeto servidor)
frecuencia sobre RPC Þ Se compila la definición utilizando
o A diferencia de RPC, CORBA propone un compilador IDL. . El resultado es
una arquitectura completa e identifica el stub del cliente (proxy, server
partes del sistema en mucho más detalle proxy,
p y pproxyy object)
j ) y el stub del
que RPC (RPC es un mecanismo de servidor (skeleton). Las signaturas
comunicación, mientras que CORBA es del método (servicios que pueden ser
una arquitectura de referencia que incluye invocados) se almacenan en el
un mecanismo de comunicación) p
repositorio de interfaces.
o CORBA propone una arquitectura Þ Se programa el cliente y se enlaza
estándar basada en componentes, pero las con el stub
ideas no son nuevas Þ Se programa el servidor y se enlaza
con ell stub
t b
o A diferencia de RPC, los stubs hacen que
el cliente y el servidor sean
independientes del sistema operativo y
del lenguaje
27
Desarrollo con CORBA (Modelo RPC)
1 Crea tus
D fi i i i
Defininiciones IDL
2
Precompilador
Skeletons
3
Añade Implementación Servidor
4
Compila
5
Client IDL Server IDL
Interface Stubs Implementación
Skeletons
R
Repository
it Objetos
Cliente
Servidor

28
Objetos por todos los lados: IIOP y GIOP
o Para qque los ORBs sean realmente una Cliente Servidor
arquitectura de componentes universal, ( bj t
(objeto ( bj t
(objeto
los ORBs deben comunicar entre sí (no CORBA) CORBA)
se puede tener todos los componentes
del “mundo
“m ndo mundial”
m ndial” interactuando
interact ando en
un único ORB) ORB 1 ORB 2
o Con este fin, CORBA ofrece un
protocolo general; EL General Inter
Inter-
ORB Protocol (GIOP), que especifica GIOP GIOP
como pasar llamadas entre ORBs
o El Internet Inter-ORB Protocol
especifica como pasar mensajes GIOP
sobre TCP/IP IIOP IIOP
o Hay protocolos adicionales que permiten
comunicar ORBs con otros sistemas
o La idea sonaba bien, pero surgió
demasiado tarde y ha sido superada por Internet (TCP/IP)
los servicios
ser icios Web … o NO!
29
L mejor
Lo j ded los
l dos
d mundos:
d Object
Obj t Monitors
M it
Las tecnologías Middleware se deben interpretar como las diferentes etapas
de evolución hacia un sistema ideal. Los sistemas actuales no compiten
entre sí, más bien se complementan. La competencia surge cuando las
infraestructuras que las soportan convergen hacia una única plataforma:
o OBJECT REQUEST BROKERS (ORBs): Reutilización y distribución de

componentes mediante un interface orientado a objetos estándar y servicios
que añaden
ñ d semántica
á i a la
l interacción
i ió entre componentes.
o 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?

Obj M
Object Monitor
i = ORB + TP
TP-Monitor
M i

30
Middle are Orientada a Mensajes
Middleware
o RPC soportan comunicaciones síncronas,
síncronas pero se requieren formas más
dinámicas y formas de interacción asíncrona
o La interoperabilidad basada en Mensaje no es nada revolucionario
Þ Ya existen implementaciones de RPC que ofrecen comunicación asíncrona
Þ Muchos sistemas TP-Monitors tenían colas de mensajes
o La interoperabilidad basada en mensajes es un paradigma donde clientes y
servidores se comunican intercambiando mensajes
o 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
}
31
Ejemplos mensajes
o Cliente y Servidor deben acordar el tipo
p de mensajesj que
q intercambian
o No existe distinción entre cliente y servidor (es conceptual)
Message : pedirPresupuesto { Message: presupuesto {

NumeroReferenciaPresupuesto: 325 NumeroReferenciaPresupuesto: 325
Cliente: Acme,INC FechaEntregraPrevista: Mar 12, 2003
Producto:#115 (bilgrafo, blue) Precio:1200€
Cantidad: 1200 }
FechaEntrega: Marzo 16,2003
DireccionEntrega: Palo Alto,
Alto CA
}
Herramienta
Herramienta aplicación cliente
aplicación
p cliente p
presupuestos
p
presupuestos
Middleware Orientado a Mensajes (MOM) Middleware Orientado a Mensajes (MOM)
Un cliente envía un La aplicación de

mensaje a la aplicación de presupuestos envía un
presupuestos mensajej all cliente
li
32
Colas de mensajes
Middleware Orientado a
Mensajes (MOM)
o Un MOM no aporta ningún
Herramienta
H i t beneficio significativo, pero
aplicación cliente
presupuestos
son la base de desarrollo de
conceptos y características
Mensajes
útiles.
Cola encolados
entrante
o La abstracción más
importante son las colas de
mensajes
Nú l MOM
Núcleo
Herramienta
Herramienta Presupuestos
2
o Beneficios de las colas de mensajes: Presupuestos Herramienta
1 Presupuestos
- Los destinatarios controlan cuando 3
procesar el mensaje
- No tienen que estar continuamente a
la espera de mensajes, ni tienen Cola entrante
porque existir
i ti cuando
d se envía
í ell compartida
mensaje
-Las colas pueden ser compartidas, se Núcleo MOM
les ppuede asignar
g pprioridades a los
mensajes, etc., etc.
33
Con ergencia Middleware
Convergencia Middle are
Þ La evolución
e ol ción hacia los ser
servicios
icios Web
Þ Los Middleware hoy, y la convergencia hacia el
“Ideal”
Þ Servicios Web como MetaMiddleware,
MetaMiddleware o Middleware
para Middlewares
Þ Mitos alrededor de los servicios Web

34
Res men Evolución
Resumen E ol ción
o El funcionamiento del Web esta basado en el paradigma
cliente/servidor
Þ La evolución de la Web ha pasado de ser un medio de
publicar y emitir documentos electrónicos a soportar
aplicaciones cliente/servidor más interactivas.
Hipertexto Web interactivo Objetos en la Web
Función
Transacciones
seguras: Java Objetos
•SSL •Componentes distribuidos
•S-HTTP
S HTTP móviles •Documentos
F
•Tablas •Firewalls •Applets compuestos

•imágenes •ActiveXs
•sonido •CORBA
•Web con texto,
•vídeo
gráficos, y enlaces
•CGI
1994 1995 Tiempo 1996 1997
35
CORBA Y JAVA (Plataforma ubicua)
bic a)
I
Invoca
3 servicio 2 Servidor
HTTP
Descarga HTML + Stub+ Applet+ Orblet
HTML Stub Applet Orblet
4 Invoca servicio Servidor

CORBA
5 ORB
CORBA
Muestra
Resultados
Objeto
j
servidor
Cliente Web 1 Instala HTML
• cliente.html Servidor Web
• Applet CliApplet.class
• Stub y Orblet
36
Middle are + Java
Middleware Ja a + Internet
o Modelo Cliente/servidor en tres capas
Documentos HTML
HTPP HTPP
CGI
Internet
TCP/ IP
Aplicaciones
CORBA
CORBA IIOP CORBA
IIOP
Objetos
Servidor
Cliente Web Tradicional
Servidor Web
37
¿Q é puede
¿Qué p ede ir mal? (1)
o Los protocolos de los middleware no pueden atravesar firewall,
firewall
salvo...
Entorno
Internet servidor
Applet
Firewall
Entorno
li t
cliente Visible
Vi ibl all applet
l t
Invisible al applet Entorno de
otros servidores

38
SOAP (RPC sobre HTTP + XML)
Servicios
Web
Documentos HTML
SOAP
HTPP HTPP
CGI
HTPP
Internet
TCP/ IP
Aplicaciones
CORBA
CORBA IIOP CORBA
IIOP
Objetos Servidor
Cliente Web ad c o a
Tradicional
Servidor Web
39
¿Q é puede
¿Qué p ede ir mal? (2)
Convergencia de los middleware
o En la práctica, siempre se precisa más de un tipo de middleware. Hay
que ver que ofrece cada producto.
o Existen implementaciones de una gran variedad de funcionalidades que
se solapan:
l Lo
L que en CORBA se denominan
d i Servicios
S i i CORBA
runtime App.
pp wrappers
pp
engine platform
support
pp
N
Name
RPC services repository
o Existen muchas posibles combinaciones. Algunas funcionan, y otras no.

40
Funcionalidad Intercambiable
runntime Appp. wrappeers
rrepositoryy
platform
support
enngine
servicces
Namme
RPC
o Que haya combinaciones posibles, no quiere decir que todas tengan sentido
o En un entorno integrado, la funcionalidad integrada no debería llevarse a cabo incorporando
p
componentes externos,, sino diseñándolo de forma coherente desde el principio.
p p Esto no
siempre es posible hoy en día.
41
Sistema “Ideal”
gestión gestión
transacciones objetos
j
gestión
procesos
gestión gestión
mensajes datos
INFRAESTRUCTURA COMÚN

42
¿Qué
Q é iinfraestructura
f t t mínima
í i se precisa?(1)
i ?(1)
o Primitivas
P i iti de
d comunicación
i ió (al( l estilo
til RPC,
RPC CORBA,
CORBA RMI o un simplei l
intercambio de documentos)
Þ Queremos aplicaciones desacopladas
• Primitiva de comunicación asíncrona
Þ Una forma de intercambiar mensajes independiente de la plataforma
y qque atraviese cortafuegos
g
• Protocolos de Internet: HTTP, STMP
• Representación de los mensajes en XML: SOAP.
Þ Descripciones
D i i de
d los
l interfaces
i t f en XML a partir
ti de
d primitivas
i iti de
d
comunicación asíncrona de envío/recepción: WSDL
o Registro de Servicios: UDDI.
Þ Único
Ú servicio centralizado compartido

43
Q é puede
Qué p ede¿ir mal? (3)
Motivación desde el B2B/EAI
o En iinteracciones
E t i entre
t organizaciones
i i no hhay un llugar obvio
b i donde
d d
colocar el middleware
Þ Los middleware tradicionales se sitúan entre las aplicaciones a
i
integrar. Las aplicaciones
li i están distribuidas,
di ib id pero ell middleware
iddl se
centraliza y controla por una compañía.
Þ La adopción de la misma solución supone que el cliente, el
proveedor y el mayorista acuerdan utilizar una determinada
plataforma middleware

44
Limitaciones de los Middleware
con encionales en el B2B
convencionales
o La solución
L l ió presentada
t d podría
d í ser posible
ibl sii hay
h pocas compañías
ñí
involucradas
o Si hay varias compañías, hay que tener en cuenta que
Þ Las compañías quieren preservar su autonomía y confidencialidad
o Una alternativa sería la comunicación punto-a-punto

Þ Esto
E t quiere
i decir,
d i que cuando d dos
d compañías
ñí quieren
i comunicar,
i
acuerdan utilizar cierta infraestructura middleware.
Þ Por ejemplo, ambos utilizan sus respectivos broker de mensajes para
i t
intercambiar
bi mensajes j (D
(Dos o mas aplicaciones
li i utilizando
tili d broker
b k de d
mensajes distintos, pero homogéneos pueden interaccionar).

45
¿Qué
Q é iinfraestructura
f t t mínima
í i se precisa?(2)
i ?(2)
o Las transacciones
L t i o cualquier
l i otro
t aspecto t que antes
t se hacia
h i mediante
di t
un middleware centralizado, ahora hay que llevarlo a cabo mediante
protocolos (conversaciones entre los servicios involucrados).

46
T
Tecnología
l í middleware
iddl en ell presente
t
o RPC y el modelo RPC son el núcleo de cualquier plataforma
middleware,
iddl i l
incluso cuando
d utilizan
tili i t
interacción
ió asíncrona.
í
o RPC, ha pasado a ser la infraestructura de bajo nivel, y su uso directo es

infrecuente por parte delos desarrolladores
o TP-Monitors son tan importantes como en décadas pasadas, pero se han

convertido en componentes de sistemas mayores y están ocultas detrás
de capas
p adicionales qque tienen ppor objeto
j la integración
g de aplicaciones
p
y servicios
i i Web. b Como los l RPC, lal funcionalidad
f i lid d de d los
l TP-Monitors
i
va migrando hacia los niveles más bajos de la infraestructura y resultan
invisibles para el desarrollador.
o CORBA está siendo reemplazado (más bien incoporando en...) por

otras plataformas, a pesar de que sus ideas son todavía usadas y copiadas
por los nuevos sistemas. CORBA ha sufrido tres desarrollos que han
cambiado el panorama: la rápida adopción de Java y la máquina virtual
Java Internet y el Web,
Java, Web y la aparición de J2EE y tecnologías
relacionadas que se constituyen como el estándar de facto para el
middleware (y de esto que dicen los del microsoft...)

47
Ser icios Web
Servicios Web, MetaMiddleware
MetaMiddle are
o Metamiddleware
M t iddl como INFRAESTRUCTURA común ú para otros
t
middlewares:
• VENTAJAS
u Representación de datos no propietaria (XML)
u Interfaces definidos en XML
u USO de protocolos de Internet

48
Vamos a ver
er unn ejemplo ya!
a!
http://webservices.amazon.com/onca/xml?Service=A
h // b i / / l?S i
WSECommerceService&AWSAccessKeyId=1JFWX63WKHTWX3
4G4KG2&Operation=ItemSearch&Keywords=Aragon&Sear
chInde Books
chIndex=Books
LIBROS EN AMAZON QUE TRATAN DE ARAGON
ESTILO REST de invocación de servicios WEB

No hay SOAP
SOAP, NI UDDI
UDDI, NI WSDL!!!
¡¡¡SOLO HTTP y XML!!!

49
50
Conceptos de partida
Arq itect ra de servicios

Arquitectura ser icios web
eb
¿Cuál es el origen de la
arquitectura de servicios Web?
¿Evolución o revolución?
¿Cuál es el estilo arquitectural de
los servicios Web?
¿Dó d encajan
¿Dónde j aquíí los
l
middleware, las EAI?
¿Es la “arquitectura definitiva” para la
construcción de sistemas distribuidos?
51
¡Ojo con los SW!
o El correo electrónico utiliza
tili a STMP,
STMP sin embargo podemos mirar en sus
contenido para evitar spam
Þ PODEMOS MIRAR los mensajes SOAP para que no lleguen a su
destino PODEMOS PONER BARRERAS
destino.
Þ SOAP sigue el estilo RPC. Esto implica tener miles de interfaces
(APIS) distintos con modelos de datos subyacentes que pueden dar
problemas ppara su uso como Servicio.
p
• HTTP como protocolo de aplicación incluye las siguientes
OPCIONES, GET (recupera documento), POST (adjunta información al
recurso), PUT (almacena información), DELETE (borra el recurso
indicado) Es un interfaz universal.
indicado). 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 intereacción RMI, IORB, JMS. ¡WSDL contempla estos protocolos de
transporte!

52

2 Middleware

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

2 Middleware

Cargado por

Copyright:

Formatos disponibles

Curso 5007437

Conceptos y estándares de arquitecturas

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Transactional Object oriented Asynchronous Formas especializadas de RPC, suelen tener

Remote Procedure Call: oculta detalles de

RPC API RPC API

RPC run titime interface RPC run time

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

o La infraestructura debe también soportar funcionalidad adicional que

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

cliente client Proceso

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

3. Preguta por servidor

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Servicios básicos horizontales:

Object Request Broker

naming transactions events lifecycle properties relationships time licensing

trader concurrency query security collection externalization startup persistence

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

o OBJECT REQUEST BROKERS (ORBs): Reutilización y distribución de

y… Object Transaction Monitors?

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Message : pedirPresupuesto { Message: presupuesto {

Middleware Orientado a Mensajes (MOM) Middleware Orientado a Mensajes (MOM)

Un cliente envía un La aplicación de

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

•Tablas •Firewalls •Applets compuestos

HTML Stub Applet Orblet

4 Invoca servicio Servidor

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

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

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

runntime Appp. wrappeers

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

o Una alternativa sería la comunicación punto-a-punto

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

o RPC, ha pasado a ser la infraestructura de bajo nivel, y su uso directo es

o TP-Monitors son tan importantes como en décadas pasadas, pero se han

o CORBA está siendo reemplazado (más bien incoporando en...) por

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

u Interfaces definidos en XML

u USO de protocolos de Internet

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

LIBROS EN AMAZON QUE TRATAN DE ARAGON

ESTILO REST de invocación de servicios WEB

¡¡¡SOLO HTTP y XML!!!

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web

Arq itect ra de servicios