2.middleware

Curso 5007437

Conceptos y estándares de arquitecturas orientadas a servicios Web

Curso 2006/2007

Capítulo 2: MiddlewarePedro Álvarez [email protected] José Ángel Bañares [email protected]

http://diis.unizar.es/PostWeb/Departamento de Informática e Ingeniería de Sistemas

mailto:[email protected]












http://diis.unizar.es/PostWeb/








Índice - Capítulo 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Þ 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 WebDepartamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)

2

El papel de un Middleware

Þ Middleware como abstracción de programación

Þ Middleware como infraestructura


3

Abstracciones de programación

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 el portabilidad coste de

desarrollo y mantenimiento de las aplicaciones, facilitando la

o Un Middleware es en esencia un conjunto de abstracciones de programación que facilitan el desarrollo de sistemas distribuidos complejosÞ 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,Þ El modelo de programación subyacente determinará como evolucionará

la plataforma cuando las nuevas tecnologías evolucionen.


4

La genealogía de los MiddlewareApplication

servers

TP-MonitorsObject brokers

Message brokers

Transactional RPC

Object oriented RPC (RMI)

Asynchronous RPC

Formas especializadas de RPC, suelen tener funcionalidad adicional

Remote Procedure CallRemote Procedure Call: oculta detalles de comunicación detrás de llamadas a procedimiento, y ayuda a a cruzar plataformas heterogéneas

sockets:Interface a nivel de sistema operativo sobre los protocolos de comunicación

TCP, UDP:

sockets

TCP, UDP User Datagram Protocol (UDP) transporta paquetes de datos sin garantíasTransmission Control Protocol (TCP) verifica la entrega correcta de los datos

Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios WebDepartamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza) 5

Internet Protocol (IP) Internet Protocol (IP):Mueve un paquete de datos de un nodo a otro

Middleware como infraestructuraDCE

entorno de desarrollo

IDLcódigo cliente Código servidor

proceso cliente proceso servidor

fuentes IDL

Compilador IDL

específica del lenguaje

Stub del cliente

Llamada al interface

Stub del servidor

Llamada al interfaceespecífica del lenguaje

RPC API RPC API

interfaceheaders

RPC run timelibreria servicios

RPC run timelibrería servicios

Protocolos RPC

Servicio de seguridad

Servicios de celdaServicio de

distribución de ficheros

Servicio procesos


6

DCE runtime environment

Infraestructurao Según vamos contando con abstracciones de programación de

más alto nivel, éstas deben estar soportadas por una infraestructura 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 monitorización más fácil y menos costosaÞ RPC => transaccional RPC => recuperación, modelos

de transacción avanzados, etc.Þ La infraestructura debe tener en cuenta los aspectos 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

Entendiendo el papel del middlewareLos middleware cumplen un doble papel: como infraestructura y como abstracciones de programación

INFRAESTRUCTURAABSTRACCIONES DE PROGRAMACIÓN

o Pretenden ocultar los detalles de bajo

o Recoge todo lo necesario paradesarrollar y ejecutar sistemas

nivel del hardware, redes y distribucióno La evolución es hacia primitivas más

potentes que se basan en el concepto básico de RPC, añadiendo propiedades adicionales o permitiendo un uso más flexible del concepto

distribuidos complejoso La tendencia es hacia arquitecturas

orientadas a servicios a una escala global y a la estandarización de interfaces

o Otra tendencia importante es hacia una única infraestructura para minimizar la complejidad y las interacciones

o La evolución es hacia la integración de plataformas y la flexibilidad en la configuración

o Su “aspecto” viene dictado por laevolución de los lenguajes deprogramación (RPC y C, CORBA yC++, RMI y Java, SOAP-XML yServicios Web)


8

Abstracciones

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.e., una buena implementación, y un sistema subyacente que la soporte)

o Las abstracciones de programación, aparecen con frecuencia como reacción a cambios en el hardware o la naturaleza de los sistemas que están siendo desarrollados


9

Java como abstracción

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 (no es lo mismo que movilidad de código)Þ 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

Servicios como abstracción

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 queremos “saber” si el servicio está programado en Java, Lisp, C, C+

+, Fortran, etc…Þ No quiero saber si tengo que invocar un procedimiento, método,

función, …Þ No quiero saber nada de estructuras de datos en Java, Lisp, C, C++Þ No quiero saber nada de UNIX, Windows,…


11

Comunicación en Servicios (Web)

Services aredefined as separation of participants

Service-oriented

exchange of messages between participants. Thisin a exchange is

systems provides

a key to decoupling applications.

hide the internalabstractions that the service such asclasses, 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 ArchitectureW3C Working Group Note 11 February 2004http://www.w3.org/TR/ws-arch/wsa.pdf


12

http://www.w3.org/TR/ws-arch/wsa.pdf

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 programación de sistemas distribuidosÞ Primitivas de comunicación basada en RPC, RMI, …Þ Soporte a transaccionesÞ Gestión del ciclo de vida de los objetos/Procesos Þ Nos facilitan la definición de la lógica de negoció Þ…

o ¡Son plataformas ejecutables con un modelo de programación concreto!


13

Servicios Web como infraestructuras

o Los Servicios Web (un caso particular de computación orientada a servicios) 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 independiente de la plataforma de ejecución (JAVA, .NET)


14

Ideas clave a entender …


15

Rápida revisión Tecnologías Middleware

Þ RPCÞ TP MonitorsÞ Object brokersÞ Middleware Orientado a Mensajes


16

Middleware básico: RPC

Send

Communication module

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)

o ¿Qué nos permite un sistema RPC?Þ Ocultar la distribución detrás

de llamadas a procedimientosÞ Ofrecer un lenguaje de definición

de interfaces (IDL) para describir los servicios

Þ Generar el código necesario para realizar las llamadas remotas y tratar con todos los aspectos de comunicación

Þ Suministrar un “binder“ si se cuenta con un directorio de servicios y nombres

CLIENTELlamada procedimiento remoto

Proceso cliente

stub CLIENTE Bind Marshalling1

Communication module

stub SERVER Unmarshalling

Dispatcher (selecciona

stub)

Return


17

SERVIDOR1Marshalling: Organizar los datos en un formato antes de enviarlos Serialization: Transformar el mensaje en una cadena de bytes

Procedimiento remoto Proceso servidor

Binding en RPC

cliente

client process

servidor

Proceso servidor

Llamada procedimiento

Stub cliente

procedure

Stub servidor

dispatcher (selecciona

Módulo comunicación

bindmarshal serialize


unmarshaldeserialize

stub)

send

receive


18

Dynamic Binding

clienteLlamada procedimiento

Proceso cliente

servidor

procedimiento

Proceso servidor

client stubbind marshal

server stub0. register unmarshal deserialize7. receive

dispatcher

(selecciona stub)


serialize2. find5. send

Módulo Comunicación

3. Preguta por servidorque implemente el procedimiento

6. Invoca procedimiento

1. Registraservidor y procedimient

4. Dirección del servidor

Servicio de nombres y directorio (binder)


19

CLIENTE DEL CONTROL INVENTARIObusca_producto comprueba_inventario IF provisiones_bajo THEN

realiza_orden actualiza_inventario

...

¿Qué puede ir mal?

o RPC es un protocolo punto a punto, en el sentido de que soporta la interacción de dos entidades (el cliente y el servidor)

o Cuando hay más de dos

entidades (un cliente con dos

interactuandoservidores, 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

o La recuperación 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 …

o Evitar estos problemas utilizando sólo sistemas RPC es muy costoso

Nuevo_producto busca_producto Borra_producto

Realiza_orden Cancela_orden

actualiza_inventario

Servidor 3 (inventario)Servidor2 (productos)

Actualiza_producto comprueba_inventario

BdD productos

BdD Inventario y ordenes


20

RPC Transaccionalo La solución es realizar llamadas

transaccionaleso ¿Qué es un TRPC?

Þ Lo mismo que un RPC más …Þ 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…

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


21

CLIENTE DEL CONTROL INVENTARIObusca_producto comprueba_inventario IF provisiones_bajo THEN

BOTrealiza_orden

actualiza_inventario EOT..

TP-Monitorso El ciclo de diseño 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 paragenerar los stubs del cliente y del servidor

o La ejecución requiere un mayor control :Þ los servicios transaccionales

mantienen el contexto de la información y registran las llamadas para garantizar la atomicidad

Þ los stubs necesitan soportar más información como el id de la transacción y el contexto de la

Nuevo_producto busca_producto Borra_producto

Realiza_orden Cancela_orden

actualiza_inventario

Servidor 3 (inventario)Servidor2 (productos)

Actualiza_producto comprueba_inventario

llamadao Llamadas jerárquicas complejas se

suelen implementar con TP-Monitors y no con RPC plano

BdD productos

BdD Inventario y ordenes


22

TP-Light y TP-Heavy = 2 niveles y 3 niveleso Un TP-heavy monitor ofrece:

Þ Un entorno de desarrollo completo (herramientas de programación, servicios, librerías, etc.),

Þ servicios adicionales (colas persistentes, herramientas de comunicación, servicios transaccionales, planificación, etc.),

Þ soporte para la autentificación (de usuarios y derechos de acceso a diferentes servicios),

Þ soluciones propias de comunicación, replicación, balance de carga, gestión de almacenamiento ... (similar a un sistema operativo).

o Su propósito es ofrecer un entorno de ejecución para gestores de recursos (aplicaciones), con una garantía razonable en las prestaciones

o Ejemplos: CICS, Encina, Tuxedo.


23

o Un TP-Light es una extensión en la bases de datos:

Þ implementada como hilos, en lugar de procesos,

Þ se basa en procedimientos almacenados (“métodos" almacenados en la bases de datos que realizan operaciones) y demonios (triggers),

Þ No es un entorno de desarrollo.

o Los monitores ligeros aparecen según se van haciendo más sofisticadas las bases de datos, integrando parte de la funcionalidad de los TP-Monitor en la base de datos.

o 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.

o Ejemplos: Transact-SQL de Sybase, PL/SQL de Oracle.

Bases de datos y el modelo de 2 niveleso Las bases de datos se utilizan

tradicionalmente para gestionar datos.o Pero la simple gestión de los datos no

es un fin en si mismo. Se gestionan datos porque se tiene alguna lógica de aplicación en mente. Esto se olvida con frecuencia al 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 la aplicación 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 lógica de la aplicación.

o Estas herramientas incluyen triggers, replicación, procedimientos almacenados, interfaces de acceso estándar (ODBC, JDBC), etc.

cliente

Sistema de gestión de base de datos

Entorno de Desarrollo

BdD

aplicación

database

Aplicación externa

Gestor recursos


CORBA Cliente (objeto CORBA)

Servidor (objeto

CORBA)o CORBA (Common Object Request

Broker Architecture) es parte de laarquitectura de gestión de objetosestándar (Object ManagementArchitecture, OMA), una arquitectura de referencia para el desarrollo basado en componentes

o Las partes clave de CORBA son:

stub cliente (proxy)

stub servidor

(skeleton)

Interfaz Llamadas remotas

Þ El ORB (Object Request Broker): se encarga de la interacción entre

librería CORBABasic

componentesÞ Los servicios CORBA:

Servicios estándar soportadosÞ Un lenguaje IDL estándar para la

publicación de interfacesÞ Protocolos que permiten a los ORB

dialogar entre sí

CORBA Object Adaptor

Marshalling1

serialization2

Object Request Broker (ORB)

o CORBA es un intento de actualizar los RPC integrándolo con el modelo de objetos y desarrollando un estándar servicios

CORBA


25

1 Marshalling: es empaquetar datos en un formato de mensaje antes de transmitir el mensaje por el canal de

2 Serializaction: Transforma el mensaje en cadenas de bytes antes de enviar el mensaje por el canal de comunicación

comunicación

Un sistema en capas(Distintos esfuerzos de estandarización)

CORBA facilities

Servicios básicos verticales:

finanzas

telecomunicaciones

…

Objetos definidos por el usuario

Documentos distribuidos

Gestión información

Gestión sistemas

Gestión tareas

Servicios básicos horizontales:

Object Request Broker

naming

transactions

events

lifecycle

properties

relationships

time

licensing

concurrency

collection

security

trader

externalization

query

startup

persistence

CORBAservices


26

CORBA sigue el modelo RPCo CORBA comparte el mismo modelo que o El desarrollo es similar a RPC:

RPC :Þ Intentan resolver el mismo problemaÞ CORBA se implementa con

frecuencia sobre RPC

Þ se definen servicios ofrecidos por el servidor utilizando IDL (define el objeto servidor)

o A diferencia de RPC, CORBA propone una arquitectura completa e identifica partes del sistema en mucho más detalle

Þ Se compila la definición utilizandoun compilador IDL. . El resultado es el stub del cliente (proxy, server proxy, proxy object) y el stub del

que RPC (RPC es un mecanismo decomunicación, mientras que CORBA esuna arquitectura de referencia que incluye un mecanismo de comunicación)

o CORBA propone una arquitectura estándar basada en componentes, pero las ideas no son nuevas

servidor (skeleton). Las signaturas del método (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

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)Crea tus

Defininiciones IDL

1

Precompilador2

Skeletons

3

Compila

Añade Implementación Servidor

4

5

Interface Repository

Client IDL Stubs

Server IDL Skeletons

Implementación Objetos

ServidorCliente


28

Objetos por todos los lados: IIOP y GIOPo Para que los ORBs sean realmente una

Cliente (objeto

Servidor (objetoarquitectura de componentes

universal, los ORBs deben comunicar entre sí (no se puede tener todos los componentes del “mundo mundial” interactuando en

CORBA) CORBA)

un único ORB)o Con este fin, CORBA ofrece un

protocolo general; EL General Inter-

ORB 1 ORB 2

ORB Protocol (GIOP), queespecificacomo pasar llamadas entre ORBs

o El Internet Inter-ORB Protocol especifica como pasar mensajes GIOP sobre TCP/IP

o Hay protocolos adicionales que permiten comunicar ORBs con otros sistemas

GIOP GIOP

IIOP IIOP

o La idea sonaba bien, pero surgió demasiado tarde y ha sido superada por los servicios Web … o NO!


29

Internet (TCP/IP)

Lo mejor de los dos mundos: Object Monitors

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 semántica a la interacción 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?

Object Monitor = ORB + TP-Monitor


30

Middleware Orientada a Mensajes

o RPC soportan comunicaciones 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:Integ

er Cliente: String

Producto: String

Cantidad: Integer

FechaEntrega: Timestamp

DireccionEntrega: String

}Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios WebDepartamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)

31

Ejemplos mensajeso Cliente y Servidor deben acordar el tipo de mensajes que intercambiano No existe distinción entre cliente y servidor (es conceptual)

Message : pedirPresupuesto { NumeroReferenciaPresupuesto: 325

Message: presupuesto { NumeroReferenciaPresupuesto: 325FechaEntregraPrevista: Mar 12, 2003 Precio:1200€

}

aplicación cliente

Cliente: Acme,INC Producto:#115 (bilgrafo, blue) Cantidad: 1200FechaEntrega: Marzo 16,2003 DireccionEntrega: Palo Alto, CA

Herramienta presupuestos

}

aplicación cliente


Middleware Orientado a Mensajes (MOM)

Middleware Orientado a Mensajes (MOM)

Un cliente envía un mensaje a la aplicación de presupuestos


32

La aplicación de presupuestos envía un mensaje al cliente

Colas de mensajesMiddleware Orientado aMensajes (MOM) o Un MOM no aporta ningún

beneficio significativo, pero son la base de desarrollo de conceptos y características útiles.

aplicación cliente


MensajesCola

entrant

e

encolados o La abstracción más

importante son las colas de mensajes

Núcleo MOM

Herramienta

Presupuestos 1

Herramienta

Presupuestos 2 Herramient

a Presupuesto

s 3

o Beneficios de las colas de mensajes:- Los destinatarios controlan cuando

Cola entrante

procesar el mensaje- No tienen que estar continuamente a la espera de mensajes, ni tienen porque existir cuando se envía el

Núcleo MOM

compartidamensaje

-Las colas pueden ser compartidas, seles puede asignar prioridades a los


3

mensajes, etc., etc.

Convergencia Middleware

Þ La evolución 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


34

Resumen Evolució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

Transacciones seguras:•SSL•S-HTTP

Java•Componentes móviles

Objetos distribuidos•Documentos compuestosF

un

ció

n

•Web con texto, gráficos, y enlaces

•ActiveXs•CORBA

•Tablas•imágenes•sonido•vídeo•CGI

•Firewalls •Applets

TiempoCurso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios WebDepartamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)

35

1994 1995 1996 1997

CORBA Y JAVA (Plataforma ubicua)

ServidorHT

TP

2

Descarga HTML + Stub+ Applet+ Orblet

3 Invoca servicio

HTML Stub Applet Orblet

Servidor CORBA

Invoca servicio4

ORBCORBA

Objeto servidor

Muestra Resultados

5

Cliente WebServidor Web

Instala HTML• cliente.html••


36

Applet CliApplet.class Stub y Orblet

1

o Modelo Cliente/servidor en tres capas

Middleware + Java + Internet

Documentos HTML

HTPP HTPP

Internet TCP/ IP

CGI

CORBA

Aplicaciones

CORBA IIOP

CORBA IIOP

ObjetosServidor Tradicional


37

Cliente WebServidor Web

¿Qué puede ir mal? (1)

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

InternetEntorno servidor

Applet

FirewallEntorno cliente

Entorno de otros servidores

Visible al applet Invisible al applet


38

SOAP (RPC sobre HTTP + XML)Servicios

Web

Documentos HTML

HTPP HTPP

SOAP

Internet TCP/ IP

CGIHTPP

CORBA

Aplicaciones

CORBA IIOP

CORBA IIOP

Objetos

Cliente WebServidor TradicionalServidor Web


39

¿Qué puede 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: Lo que en CORBA se denominan Servicios CORBA

App. wrappersruntime

platform support

engine

RPCName

services repository

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


40

Funcionalidad Intercambiable

App

. wra

pper

s

plat

form

su

ppor

t

repo

sito

ryN

ame

serv

ices

runt

ime

engi

ne

RP

C

o Que haya combinaciones posibles, no quiere decir que todas tengan sentidoo En un entorno integrado, la funcionalidad integrada no debería llevarse a cabo incorporando

componentes externos, sino diseñándolo de forma coherente desde el principio. Esto no siempre es posible hoy en día.


41

Sistema “Ideal”

gestiónobjetos

gestióntransacciones

gestión procesos

gestióndatos

gestiónmensajes

INFRAESTRUCTURA COMÚN


42

¿Qué infraestructura mínima se precisa?(1)

o Primitivas de comunicación (al estilo RPC, CORBA, RMI o un simple intercambio de documentos)Þ Queremos aplicaciones desacopladas

• Primitiva de comunicación asíncronaÞ Una forma de intercambiar mensajes independiente de la plataforma

y que atraviese cortafuegos• Protocolos de Internet: HTTP, STMP• Representación de los mensajes en XML: SOAP.

Þ Descripciones de los interfaces en XML a partir de primitivas de comunicación asíncrona de envío/recepción: WSDL

o Registro de Servicios: UDDI.Þ Único servicio centralizado compartido


43

Qué puede¿ir mal? (3)Motivación desde el B2B/EAI

o En interacciones entre organizaciones no hay un lugar obvio donde colocar el middlewareÞ Los middleware tradicionales se sitúan entre las aplicaciones a

integrar. Las aplicaciones están distribuidas, pero el middleware 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 Middlewareconvencionales en el B2B

o La solución presentada podría ser posible si hay 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 quiere decir, que cuando dos compañías 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 homogéneos pueden interaccionar).


45

¿Qué infraestructura mínima 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).


46

Tecnología middleware en el presenteo RPC y el modelo RPC son el núcleo de cualquier

plataforma middleware, incluso cuando utilizan interacción 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 adicionales que tienen por objeto la integración de aplicaciones y servicios Web. Como los RPC, la funcionalidad de los TP-Monitorsva migrando hacia los niveles más bajos de la infraestructura y resultaninvisibles 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

copiadaspor 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, 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

Servicios Web, MetaMiddleware

o Metamiddleware como INFRAESTRUCTURA común para otros middlewares:

• VENTAJASu Representación de datos no propietaria (XML)u Interfaces definidos en XMLu USO de protocolos de Internet


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 invocación de servicios WEB, ,

¡¡¡SOLO HTTP y XML!!!


49

http://webservices.amazon.com/onca/xml?Service=A


5

0

Conceptos de partida

Arquitectura de servicios web

¿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ónde encajan aquí losmiddleware, las EAI?

¿Es la “arquitectura definitiva” para la construcción de sistemas distribuidos?Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios

WebDepartamento de Informática e Ingeniería de Sistemas (Univ. Zaragoza)

51

¡Ojo con los SW!

o El correo electrónico 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 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. 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

Documents