2 Middleware

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

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.

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

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

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

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

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!

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,

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

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!

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)

14
Ideas clave a entender

15
Rpida revisin Tecnologas Middleware

RPC TP Monitors Object brokers Middleware Orientado a Mensajes

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

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)

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

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.

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

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

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

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!
Cliente (objeto CORBA)
Servidor (objeto CORBA)
ORB 1
ORB 2
GIOP
GIOP
IIOP
IIOP
Internet (TCP/IP)
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

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 }
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
Middleware Orientado a Mensajes (MOM)
Un cliente enva un mensaje a la aplicacin de presupuestos

La aplicacin de presupuestos enva un mensaje al cliente 32
Colas de mensajes
aplicacin cliente

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.
Cola entrante
compartida
Ncleo MOM

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

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

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

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
Servidor Web
Servidor Tradicional
37
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

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

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.

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

RPC
Sistema Ideal
gestin gestin transacciones objetos gestin procesos
gestin mensajes gestin datos
INFRAESTRUCTURA COMN

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

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

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

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

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

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

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!!!

49

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?
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!

52

2 Middleware

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 Middleware

Uploaded by

Copyright:

Available Formats

Curso 5007437

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

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

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

La genealoga de los Middleware

Object oriented RPC (RMI)

Formas especializadas de RPC, suelen tener funcionalidad adicional

Remote Procedure Call

Internet Protocol (IP)

Middleware como infraestructura

DCE entorno de desarrollo IDL

proceso servidor Cdigo servidor

Llamada al interface especfica del lenguaje

Llamada al interface especfica del lenguaje

RPC API RPC run time libreria servicios interface headers

RPC API RPC run time librera servicios

Servicio de distribucin de ficheros

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

DCE runtime environment 6

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Entendiendo el papel del middleware

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Java como abstraccin

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Servicios como abstraccin

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Comunicacin en Servicios (Web)

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Midleware como infraestructura

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Servicios Web como infraestructuras

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Ideas clave a entender

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Rpida revisin Tecnologas Middleware

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Middleware bsico: RPC

stub SERVER Unmarshalling Return

dispatcher (selecciona stub)

unmarshal deserialize receive

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

3. Preguta por servidor que implemente el procedimiento

6. Invoca procedimiento 4. Direccin del servidor

Registra servidor y procedimient

Servicio de nombres y directorio (binder)

Servidor2 (productos) Nuevo_producto busca_producto Borra_producto Actualiza_producto

Servidor 3 (inventario) Realiza_orden Cancela_orden actualiza_inventario comprueba_inventario

BdD Inventario y ordenes

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Servidor2 (productos) Nuevo_producto busca_producto Borra_producto Actualiza_producto

Servidor 3 (inventario) Realiza_orden Cancela_orden actualiza_inventario comprueba_inventario

BdD Inventario y ordenes

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

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

Curso 5007437 Conceptos y estndares de arquitecturas orientadas a servicios Web

Bases de datos y el modelo de 2 niveles

Sistema de gestin de base de datos

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

Object Request Broker (ORB)