Curso Capítulo 2: Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007

Transcripción

1 Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Curs 2006/2007 Capítul 2: Middleware Pedr Álvarez alvaper@unizar.es Jsé Ángel Bañares banares@unizar.es Departament de Infrmática e Ingeniería de Sistemas

2 Índice - Capítul 2 Entendiend el papel de un middleware Þ Middleware cm abstracción de prgramación Þ Middleware cm infraestructura Una rápida revisión de las platafrmas middleware cnvencinales Þ RPC Þ TP Mnitrs Þ Object brkers Þ Middleware Orientads a Mensajes Cnvergencia Middleware Þ La evlución hacia ls servicis Web Þ Ls Middleware hy, y la cnvergencia hacia el Ideal Þ Mits alrededr de ls servicis Web Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 2

3 El papel de un Middleware Þ Middleware cm abstracción de prgramación Þ Middleware cm infraestructura Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 3

4 Abstraccines de prgramación Ls lenguajes de prgramación (cualquier frma de sistema sftware), evlucina siempre hacia mayres niveles de abstracción: Þ Ocultand detalles de la platafrma y del hardware Þ Primitivas más ptentes Þ Ayudand/autmatizand en las tareas más pesadas (cmpiladres, ptimizadres, balance de la carga, etc.) Þ Reduciend el númer de errres de prgramación Þ Rd Reduciend d el prtabilidad d cste de desarrll y mantenimient i t de las aplicacines, facilitand la Un Middleware es en esencia un cnjunt de abstraccines de prgramación que facilitan el desarrll de sistemas distribuids cmplejs Þ Para cmprender una platafrma middleware sól se precisa cncer su mdel de prgramación Þ A partir del mdel de prgramación se puede determinar cual serán las limitacines del middleware, Þ El mdel de prgramación subyacente determinará cm evlucinará la platafrma cuand las nuevas tecnlgías evlucinen. Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 4

5 La genealgía de ls Middleware Applicatin servers TP-Mnitrs Object brkers Message brkers Transactinal RPC Object riented RPC (RMI) Asynchrnus RPC Frmas especializadas de RPC, suelen tener funcinalidad adicinal Remte Prcedure Call sckets Remte Prcedure Call: culta detalles de cmunicación detrás de llamadas a prcedimient, y ayuda a a cruzar platafrmas hetergéneas sckets: Interface a nivel de sistema perativ sbre ls prtcls de cmunicación TCP, UDP Internet Prtcl (IP) Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) TCP, UDP: User Datagram Prtcl (UDP) transprta paquetes de dats sin garantías Transmissin Cntrl Prtcl (TCP) verifica la entrega crrecta de ls dats Internet Prtcl (IP): Mueve un paquete de dats de un nd a tr 5

6 Middleware cm infraestructura códig cliente prces cliente DCE entrn de desarrll IDL prces servidr Códig servidr Llamada al interface específica del lenguaje Stub del cliente fuentes IDL Cmpiladr IDL Llamada al interface específica del lenguaje Stub del servidr RPC API RPC run time libreria servicis interface headers RPC API RPC run time librería servicis Prtcls RPC Servici de seguridad Servicis de celda Servici de distribución de fichers Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) Servici prcess DCE runtime envirnment 6

7 Infraestructura Según vams cntand cn abstraccines de prgramación de más alt nivel, ét éstas db deben estar sprtadas td pr una if infraestructura t que permita su implementación Þ La funcinalidad adicinal se cnsigue casi siempre a través de capas adicinales Þ Las capas sftware adicinal incrementan la cmplejidad y el tamañ de la infraestructura necesaria La infraestructura debe también sprtar funcinalidad adicinal que (abstraccines adicinales) permita el desarrll, el mantenimient y la mnitrizaciónmás fácil y mens scstsasa Þ RPC => transaccinal RPC => recuperación, mdels de transacción avanzads, etc. Þ La infraestructura debe tener en cuenta ls aspects n funcinales que n cntemplan ls mdels de dats y ls lenguajes de prgramación: prestacines, recuperación, mantenimient, gestión de recurss, etc. Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 7

8 Entendiend d el papel del middleware Ls middleware cumplen un dble papel: p cm infraestructura ycm abstraccines de prgramación ABSTRACCIONES DE PROGRAMACIÓN Pretenden cultar ls detalles de baj nivel del hardware, redes y distribución La evlución es hacia primitivas más ptentes que se basan en el cncept básic de RPC, añadiend ñdi d prpiedades idd adicinales permitiend un us más flexible del cncept Su aspect viene dictad pr la evlución de ls lenguajes de prgramación (RPC y C, CORBA y C++, RMI y Java, SOAP-XML y Servicis Web) INFRAESTRUCTURA Recge td l necesari para desarrllar y ejecutar sistemas distribuids cmplejs La tendencia es hacia arquitecturas rientadas a servicis a una escala glbal y a la estandarización de interfaces Otra tendencia imprtante es hacia una única infraestructura para minimizar la cmplejidad y las interaccines La evlución es hacia la integración de platafrmas y la flexibilidad en la cnfiguración Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 8

9 Abstraccines Las abstraccines de prgramación sn un element clave de ls middleware, per n el únic: Þ Una abstracción de prgramación sin una infraestructura que la sprte n ayuda (p.e., una buena implementación, y un sistema subyacente que la sprte) Las abstraccines de prgramación, aparecen cn frecuencia cm reacción a cambis en el hardware la naturaleza de ls sistemas que están siend desarrllads Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 9

10 Java cm abstracción Java es un lenguaje de prgramación que abstrae el hardware subyacente:ls prgramadres sl ven la máquina virtual Java (infraestructura), sin precuparse del cmputadr sbre el que se ejecuta Þ Prtabilidad de códig (n es l mism que mvilidad de códig) Þ El primer pas hacia la estandarización de las abstraccines de un middleware (puest que ahra se pueden apyar sbre un platafrma virtual sbre la que tds están de acuerd) Þ Per es una platafrma cncret cn un mdel/paradigma de prgramación cncret. NO TODOS LA COMPARTEN! Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 10

11 Servicis i cm abstracción La cmputación Orientada a Servici se fundamenta en una cmunicación que se abstraiga del mdel de cmunicación prpi del lenguaje de cmunicación y de la platafrma de ejecución Þ N querems saber si el servici está prgramad en Java, Lisp, C, C++, Frtran, etc Þ N quier saber si teng que invcar un prcedimient, métd, función, Þ N quier saber nada de estructuras de dats en Java, Lisp, C, C++ Þ N quier saber nada de UNIX, Windws, Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 11

12 Cmunicación en Servicis (Web) Services are defined d as exchange f messages between participants. i t This separatin f participants in a exchange is a key t decupling applicatins. Service-riented systems hide the internal abstractins that prvides the service such as classes, bjects, methds, r remte prcedures. By aviding ad gany knwledge f the internal structure, it is pssible t incrprate any sftware cmpnent r applicatin that can be "wrapped" in message handling cde that allws it t adhere t the frmal service definitin WbS Web Services Architecture t W3C Wrking Grup Nte 11 February Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 12

13 Midleware cm infraestructura Java (EJB, RMI, CORBA, etc.),.net, sn infraestructuras t middleware. Capa sftware ejecutable que me permite abstraerns de aspects ctidians en la prgramación de sistemas distribuids Þ Primitivas i i de cmunicación i basada en RPC, RMI, Þ Sprte a transaccines Þ Gestión del cicl de vida de ls bjets/prcess Þ Ns facilitan la definición de la lógica de negció Þ Sn platafrmas ltf ejecutables tbl cn un mdel dl de prgramación cncret! t! Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 13

14 Servicis Web cm infraestructuras ras Ls Servicis i Web (un cas particular de cmputación rientada a servicis) i es un tip diferente de infraestructura. NO ES UNA INFRAESTRUCTURA EJECUTABLE. ES INDEPENDIENTE de la platafrma de ejecución Ls servicis Web n sn una tecnlgía cmplementaria que n reemplaza tras tecnlgías Þ N es un nuev lenguaje de prgramación Þ N es una nueva tecnlgía middleware en el sentid de J2EE, CORBA.NET. QUEREMOS MANTENER LAS ABSTRACCIONES sbre una infraestructura COMÚN independiente di de la platafrma de ejecución (JAVA,.NET) Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 14

15 Ideas clave a entender Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 15

16 Rápida revisión Tecnlgías Middleware Þ RPC Þ TP Mnitrs Þ Object brkers Þ Middleware Orientad a Mensajes Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 16

17 Middleware básic: RPC El prgramadr n debe implementar tda la infraestructura para cada sistema distribuid. Se puede utilizar RPC (nuestr primer ejempl de middleware de baj nivel) Qué ns permite un sistema RPC? Þ Ocultar la distribución detrás de llamadas a prcedimients Þ Ofrecer un lenguaje de definición de interfaces (IDL) para describir ls servicis Þ Generar el códig necesari para realizar las llamadas remtas y tratar cn tds ls aspects de cmunicación ió Þ Suministrar un binder si se cuenta cn un directri de servicis y nmbres CLIENTE Llamada prcedimient remt stub CLIENTE Bind Marshalling 1 Send stub SERVER Unmarshalling Return Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) Prcedimient remt 1 Marshalling: Organizar ls dats en un frmat antes de enviarls Serializatin: Transfrmar el mensaje en una cadena de bytes SERVIDOR Prces cliente Cmmunicatin mdule Cmmunicatin mdule Dispatcher (seleccina stub) Prces servidr 17

18 Binding en RPC cliente client prcess servidr Prces servidr Llamada prcedimient Stub cliente bind marshal serialize send Módul cmunicación ió prcedure Stub servidr unmarshal deserialize receive dispatcher (seleccina stub) Módul cmunicación ió Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 18

19 Dynamic Binding cliente Llamada prcedimient client stub bind marshal serialize 2. find 5. send Prces cliente Módul cmunicación servidr prcedimient server stub 0. register unmarshal deserialize 7. receive Prces servidr dispatcher (seleccina stub) Módul Cmunicación 3. Preguta pr servidr que implemente el prcedimient 6. Invca prcedimient 1. Registra servidr y 4. Dirección del servidr prcedimient Servici i de nmbres y directri i (binder) Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 19

20 Qué puede ir mal? CLIENTE DEL CONTROL INVENTARIO busca_prduct cmprueba inventari IF prvisines_baj THEN realiza_rden actualiza inventari... RPC es un prtcl punt a punt, en el cmprueba_inventari sentid de que sprta la interacción de ds entidades (el cliente y el servidr) Cuand hay más de ds entidades interactuand t (un cliente cn ds actualiza_inventari servidres, un cliente cn un servidr y el servidrcnlabasededats),rpctrata las llamadas de frma independiente. Sin embarg las llamadas n sn independientes La recuperación de falls parciales es muy cmpleja. Pr ejempl, se envió la rden, per el inventari n ha sid actualizad, se ha hech el pag per n se ha registrad Evitar ests prblemas utilizand sól sistemas RPC es muy csts Servidr2 (prducts) Nuev_prduct busca_prduct Brra_prduct Actualiza_prduct BdD prducts Servidr 3 (inventari) Realiza_rden Cancela_rden actualiza_inventariinventari cmprueba_inventari BdD Inventari y rdenes Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 20

21 RPC Transaccinal La slución es realizar llamadas transaccinales Qué es un TRPC? Þ L mism que un RPC más Þ cnstruccines del lenguajes adicinales que sprtan manejar varias llamadas RPC cm una unidad Þ cn frecuencia, incluyen también interfaces a bases de dats para realizar transaccines utilizand el estándar XA (2 Phase Cmmit) Þ y más csas que puedan ser útiles Simplificand las csas, se puede decir que TP-Mnitrs (Transactin Prcessing Mnitrs) sn sistemas basads en RPC. Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 21

22 TP-Mnitrs El cicl ccdedse diseñ un TP-Mnitr es muy similar a RPC: Þ se definen ls servicis a implementar y se especifican en IDL Þ se especifica que servicis sn transaccines Þ Se usa un cmpiladr de IDL para generar ls stubs del cliente ydel servidr La ejecución requiere un mayr cntrl : Þ ls servicis transaccinales mantienen el cntext de la infrmación y registran las llamadas para garantizar la atmicidad Þ ls stubs necesitan sprtar más infrmación cm el id de la transacción y el cntext de la llamada Llamadas jerárquicas cmplejas se suelen implementar cn TP-Mnitrs y n cn RPC plan Servidr2 (prducts) Nuev_prduct busca_prduct Brra_prduct Actualiza_prduct CLIENTE DEL CONTROL INVENTARIO busca_prduct cmprueba_inventari IF prvisines_baj THEN BOT realiza_rden actualiza_inventariinventari EOT.. BdD prducts Servidr 3 (inventari) Realiza_rden Cancela_rden actualiza_inventariinventari cmprueba_inventari BdD Inventari y rdenes Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 22

23 TP-Light y TP-Heavy = 2 niveles y 3 niveles Un TP-heavy mnitr frece: Un TP-Light es una extensión en la Þ Un entrn de desarrll cmplet bases de dats: (herramientas de prgramación, Þ implementada cm hils, en lugar servicis, librerías, etc.), de prcess, Þ servicis adicinales (clas Þ se basa en prcedimients persistentes, herramientas de almacenads ( métds" cmunicación, servicis almacenads en la bases de dats transaccinales, planificación, que realizan peracines) y etc.), demnis (triggers), Þ sprte para la autentificación tifi ió (de usuaris y derechs de acces a diferentes servicis), Þ slucines prpias de cmunicación, replicación, balance de carga, gestión de almacenamient... (similar a un sistema perativ). Þ Nesunentrn de desarrll. Ls mnitres ligers aparecen según se van haciend más sfisticadas las bases de dats, integrand parte de la funcinalidad de ls TP-Mnitr en la base de dats. En lugar de escribir preguntas cmplejas, la pregunta es implementada Su prpósit es frecer un entrn de y almacenada cm un prcedimient. ejecución para gestres de recurss El cliente invca el prcedimient (aplicacines), cn una garantía almacenad, en lugar de invcar una raznable en las prestacines pregunta. Ejempls: CICS, Encina, Tuxed. Ejempls: Transact-SQL de Sybase, PL/SQL de Oracle. Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 23

24 Bases de dats y el mdel de 2 niveles Las bases de dats se utilizan cliente tradicinalmente para gestinar dats. Per la simple gestión de ls dats n es un fin en si mism. Se gestinan dats prque se tiene alguna lógica deaplicación Sistema de gestión en mente. Est se lvida cn frecuencia al de base de dats cnsiderar las bases de dats. Si la lógica de la aplicación es l imprtante, Pr qué n mver la lógica de Entrn de la aplicación a la base de dats? Est es l Desarrll que prpnen muchs vendedres, BdD prpniend mdels de 2 niveles, incrprand la base de dats herramientas para implementar la lógica de la aplicación. Estas herramientas incluyen triggers, replicación, prcedimients almacenads, interfaces de acces estándar (ODBC, JDBC), etc. Lógica de la aplicación ió database Aplicación externa Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) Gestr recurss 24

25 CORBA CORBA (Cmmn Object Request Brker Architecture) es parte de la arquitectura de gestión de bjets estándar (Object Management Architecture, OMA), una arquitectura de referencia para el desarrll basad en cmpnentes Las partes clave de CORBA sn: Þ El ORB (Object Request Brker): se encarga de la interacción entre cmpnentes Þ Ls servicis CORBA: Servicis estándar sprtads Þ Un lenguaje IDL estándar para la publicación de interfaces Þ Prtcls que permiten a ls ORB dialgar entre sí CORBA es un intent de actualizar ls RPC integrándl cn el mdel de bjets y desarrlland un estándar Cliente (bjet CORBA) stub cliente (prxy) librería CORBA Interfaz Llamadas remtas Marshalling 1 serializatin 2 Object Request Brker (ORB) servicis CORBA Servidr (bjet CORBA) stub servidr (kl (skeletn) CORBA Basic Object Adaptr 1 Curs Marshalling: es Cncepts empaquetar y estándares dats en de un arquitecturas frmat de mensaje rientadas antes a servicis de transmitir Web el mensaje pr el canal de Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) cmunicación 25 2 Serializactin: Transfrma el mensaje en cadenas de bytes antes de enviar el mensaje pr el canal de cmunicación

26 Un sistema en capas (Distints esfuerzs de estandarización) CORBA facilities Servicis básics verticales: finanzas telecmunicacines Servicis básics hrizntales: Objets definids pr el usuari Dcuments distribuids Gestión infrmación Gestión sistemas Gestión tareas Object Request Brker naming transactins events lifecycle prperties relatinships time licensing trader cncurrency query security cllectin externalizatin startup persistence CORBAservices Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 26

27 CORBA sigue el mdel RPC CORBA cmparte el mism mdel que El desarrll es similar a RPC: RPC : Þ se definen servicis frecids pr el Þ Intentan reslver el mism prblema servidr utilizand IDL (define el Þ CORBA se implementa cn bjet servidr) frecuencia sbre RPC Þ Se cmpila la definición utilizand A diferencia de RPC, CORBA prpne un cmpiladr IDL.. El resultad es una arquitectura cmpleta e identifica el stub del cliente (prxy, server partes del sistema en much más detalle prxy, prxy bject) yel stub del que RPC (RPC es un mecanism de servidr (skeletn). Las signaturas cmunicación, mientras que CORBA es del métd (servicis que pueden ser una arquitectura de referencia que incluye invcads) se almacenan en el un mecanism de cmunicación) repsitri de interfaces. CORBA prpne una arquitectura Þ Se prgrama el cliente y se enlaza estándar basada en cmpnentes, per las cn el stub ideas n sn nuevas Þ Se prgrama el servidr y se enlaza cn el stub A diferencia de RPC, ls stubs hacen que el cliente y el servidr sean independientes del sistema perativ y del lenguaje Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 27

28 Desarrll cn CORBA (Mdel RPC) 1 Crea tus Defininicines i i i IDL 2 Precmpiladr Skeletns 3 Añade Implementación Servidr 4 Cmpila 5 Interface Repsitry Client IDL Stubs Server IDL Skeletns Implementación Objets Cliente Servidr Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 28

29 Objets pr tds ls lads: IIOP y GIOP Para que ls ORBs sean realmente una arquitectura de cmpnentes universal, ls ORBs deben cmunicar entre sí (n se puede tener tds ls cmpnentes del mund mundial interactuandand en un únic ORB) Cn este fin, CORBA frece un prtcl general; EL General Inter- ORB Prtcl (GIOP), que especifica cm pasar llamadas entre ORBs El Internet Inter-ORB Prtcl especifica cm pasar mensajes GIOP sbre TCP/IP Hay prtcls adicinales que permiten cmunicar ORBs cn trs sistemas La idea snaba bien, per surgió demasiad tarde y ha sid superada pr ls servicis Web NO! Cliente (bjet Servidr (bjet CORBA) CORBA) ORB 1 ORB 2 GIOP GIOP IIOP IIOP Internet (TCP/IP) Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 29

30 L mejr de ls ds munds: Object Mnitrs Las tecnlgías Middleware se deben interpretar cm las diferentes etapas de evlución hacia un sistema ideal. Ls sistemas actuales n cmpiten entre sí, más bien se cmplementan. La cmpetencia surge cuand las infraestructuras que las sprtan cnvergen hacia una única platafrma: OBJECT REQUEST BROKERS (ORBs): Reutilización y distribución de cmpnentes mediante un interface rientad a bjets estándar y servicis que añaden ñd semántica a la interacción ió entre cmpnentes. TRANSACTION PROCESSING MONITORS: Un entrn de desarrll de cmpnentes capaces de interactuar transaccinalmente y herramientas necesarias para mantener las cnsistencia transaccinal y Object Transactin Mnitrs? Object Mnitr = ORB + TP-Mnitr Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 30

31 Middleware Orientada a Mensajes RPC sprtan cmunicacines síncrnas, per se requieren frmas más dinámicas y frmas de interacción asíncrna La interperabilidad basada en Mensaje n es nada revlucinari Þ Ya existen implementacines de RPC que frecen cmunicación asíncrna Þ Muchs sistemas TP-Mnitrs tenían clas de mensajes La interperabilidad basada en mensajes es un paradigma dnde clientes y servidres se cmunican intercambiand mensajes Un mensaje se caracteriza pr un TIPO (p.e. tips XML) y un cnjunt de pares atribut-valr <NOMBRE, VALOR> Message PedirPresupuest { NumerReferenciaPresupuest:Integer Cliente: String Prduct: String Cantidad: Integer FechaEntrega: Timestamp DireccinEntrega: String } Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 31

32 Ejempls mensajes Cliente y Servidr deben acrdar el tip de mensajes que intercambian N existe distinción entre cliente y servidr (es cnceptual) Message : pedirpresupuest { NumerReferenciaPresupuest: 325 Cliente: Acme,INC Prduct:#115 (bilgraf, blue) Cantidad: 1200 FechaEntrega: Marz 16,2003 DireccinEntrega: Pal Alt, CA } Message: presupuest { NumerReferenciaPresupuest: 325 FechaEntregraPrevista: Mar 12, 2003 Preci:1200 } aplicación cliente Herramienta presupuests aplicación cliente Herramienta presupuests p Middleware Orientad a Mensajes (MOM) Middleware Orientad a Mensajes (MOM) Un cliente envía un mensaje a la aplicación de presupuests La aplicación de presupuests envía un mensaje al cliente Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 32

33 Clas de mensajes aplicación cliente Cla entrante Middleware Orientad a Mensajes (MOM) Núcle MOM Herramienta presupuests Mensajes enclads Un MOM n aprta ningún benefici significativ, per sn la base de desarrll de cncepts y características útiles. La abstracción más imprtante sn las clas de mensajes Herramienta Presupuests 1 Cla entrante Herramienta Presupuests 2 Beneficis de las clas de mensajes: - Ls destinataris cntrlan cuand 3 prcesar el mensaje - N tienen que estar cntinuamente a la espera de mensajes, ni tienen prque existir iti cuand se envía el mensaje -Las clas pueden ser cmpartidas, se les puede asignar priridades a ls mensajes, etc., etc. cmpartida Núcle MOM Herramienta Presupuests 3 Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 33

34 Cnvergencia Middleware Þ La evlución hacia ls servicis Web Þ Ls Middleware hy, y la cnvergencia hacia el Ideal Þ Servicis Web cm MetaMiddleware, Middleware para Middlewares Þ Mits alrededr de ls servicis Web Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 34

35 Resumen Evlución El funcinamient del Web esta basad en el paradigma cliente/servidr Þ La evlución de la Web ha pasad de ser un medi de publicar y emitir dcuments electrónics a sprtar aplicacines cliente/servidr más interactivas. Hipertext Web interactiv Objets en la Web Función Web cn text, gráfics, y enlaces Tablas imágenes snid víde CGI Transaccines seguras: SSL Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) Java Cmpnentes móviles Objets distribuids Dcuments S-HTTP Firewalls Applets cmpuests ActiveXs CORBA Tiemp

36 CORBA Y JAVA (Platafrma ubicua) 3 Invca servici 2 Descarga HTML + Stub+ Applet+ Orblet Servidr HTTP HTML Stub Applet Orblet 4 Invca servici Servidr CORBA 5 Muestra Resultads ORB Objet servidr CORBA Cliente Web 1 Instala HTML cliente.html Applet CliApplet.class Stub y Orblet Servidr Web Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 36

37 Middleware + Java a + Internet Mdel Cliente/servidr en tres capas Dcuments HTML HTPP CORBA IIOP Internet TCP/ IP HTPP CORBA IIOP CGI Aplicacines CORBA Objets Cliente Web Servidr Web Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) Servidr Tradicinal 37

38 Qué puede ir mal? (1) Ls prtcls de ls middleware n pueden atravesar firewall, salv... Applet Internet Entrn servidr Firewall Entrn cliente Visible ibl al applet Invisible al applet Entrn de trs servidres Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 38

39 SOAP (RPC sbre HTTP + XML) Servicis Web HTPP CORBA IIOP SOAP Internet TCP/ IP HTPP HTPP CORBA IIOP Dcuments HTML CGI Aplicacines CORBA Objets Cliente Web Servidr Web Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) Servidr Tradicinal a 39

40 Qué puede ir mal? (2) Cnvergencia de ls middleware En la práctica, siempre se precisa más de un tip de middleware. Hay que ver que frece cada prduct. Existen implementacines de una gran variedad de funcinalidades que se slapan: L que en CORBA se denminan Servicis i CORBA RPC runtime engine Name services App. wrappers platfrm supprt repsitry Existen muchas psibles cmbinacines. Algunas funcinan, y tras n. Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 40

41 Funcinalidad Intercambiable RPC run ntime en ngine Nam servic me ces r Ap pp. wrappe ers platfrm supprt repsitry Que haya cmbinacines psibles, n quiere decir que tdas tengan sentid En un entrn integrad, la funcinalidad integrada n debería llevarse a cab incrprand cmpnentes externs, sin diseñándl de frma cherente desde el principi. p Est n siempre es psible hy en día. Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 41

42 Sistema Ideal gestión transaccines gestión prcess gestión mensajes gestión bjets gestión dats INFRAESTRUCTURA COMÚN Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 42

43 Qué infraestructura t mínima se precisa?(1) Primitivas iti de cmunicación ió (al estil RPC, CORBA, RMI un simple intercambi de dcuments) Þ Querems aplicacines desacpladas Primitiva de cmunicación asíncrna Þ Una frma de intercambiar mensajes independiente de la platafrma yque atraviese crtafuegs Prtcls de Internet: HTTP, STMP Representación de ls mensajes en XML: SOAP. Þ Descripcines i de ls interfaces en XML a partir de primitivas iti de cmunicación asíncrna de enví/recepción: WSDL Registr de Servicis: UDDI. Þ Únic servici centralizad cmpartid Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 43

44 Qué puede ir mal? (3) Mtivación desde el B2B/EAI En interaccines i entre rganizacines i n hay un lugar bvi dnde d clcar el middleware Þ Ls middleware tradicinales se sitúan entre las aplicacines a integrar. Las aplicacines i están distribuidas, ib id per el middleware se centraliza y cntrla pr una cmpañía. Þ La adpción de la misma slución supne que el cliente, el prveedr y el mayrista acuerdan utilizar una determinada platafrma middleware Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 44

45 Limitacines de ls Middleware cnvencinales en el B2B La slución presentada pdría ser psible si hay pcas cmpañías invlucradas Si hay varias cmpañías, hay que tener en cuenta que Þ Las cmpañías quieren preservar su autnmía y cnfidencialidad Una alternativa sería la cmunicación punt-a-punt Þ Et Est quiere decir, que cuand ds cmpañías quieren cmunicar, acuerdan utilizar cierta infraestructura middleware. Þ Pr ejempl, ambs utilizan sus respectivs brker de mensajes para intercambiar mensajes (Ds mas aplicacines i utilizand brker de mensajes distints, per hmgénes pueden interaccinar). Curs Cncepts y estándares de arquitecturas rientadas a servicis Web Departament de Infrmática e Ingeniería de Sistemas (Univ. Zaragza) 45