Middleware heredado by tfs31371

VIEWS: 0 PAGES: 28

									  1.264 Tema 16


Middleware heredado
              ¿Qué es el middleware heredado?


      Cliente (interf. de      Cliente (interf. de
      usuario, aplic. local)   usuario, aplic. local)

                                            Red

  ¿Cómo conectamos                            Pre-web, pero
                          Middleware
clientes y servidores?                       post-Internet


        Servidor (b. datos,      Servidor (b. datos,
         aplicación, etc.)        aplicación, etc.)
                ¿Por qué middleware?

•   Desarrollo de Internet
    – Redes de área extensa con alto ancho de banda, muchos
      usuarios conectados
•   PC potentes y baratos
    – Muchos más usuarios en empresas y en Internet
•   Las redes y la informática conducen los negocios en la red
    – Compras, transacciones, cadena de suministro, diseño
       colaborativo, gestión de proyectos, …
    – Millones de servidores pre-web conectados con altos anchos
    de banda
    – Aplicaciones pre-web con miles de millones de transacciones
    distribuidas
•   El diseño tradicional cliente-servidor no es adaptable
    – Cliente-servidor implica la existencia de un servidor
    – Válido para aplicación de departamentos en una red de área
    local (LAN)
    – Necesidad de varios servidores para gestionar aplicaciones
    – Necesidad de middleware cliente-servidor
               Por qué middleware, (cont.)

•   Las aplicaciones no se adaptan bien
    –   Excel: de 4 MB a 32 MB de RAM entre 1990 y 2000
    –   Lotus 1-2-3: de 0,5 MB a 11 MB entre 1982 y 1997
    –   Ditto para Word, PowerPoint, Access. Y sigue creciendo
    –   Muchas funciones comunes: gráficos, tablas, formato,
        fusión de correo, etc.
• Los componentes aceptan código compartido entre
aplicaciones (middleware de aplicación)
    – Limitación y costes elevados para desarrolladores de software
    – Reducción del desarrollo a medida que aumenta la envergadura
•   El middleware heredado tampoco se adapta muy bien
    – Mismos conceptos de middleware para compartir código en
      aplicaciones y en redes entre clientes y servidores
    – Las aplicaciones deben comunicarse entre sí para ofrecer
      algunas de las funciones compartidas necesarias, ya sea en
      el mismo equipo o en otro
                         ¿Por qué no SQL?
 • SQL sólo gestiona datos, no procesos
     – Válido para devolver listas de transporte en un estado
     – No válido para devolver rutas mejoradas de camiones de
     entregas
 • El rendimiento de SQL en las redes no es bueno
     – Las secuencias de sentencias SQL y de consultas
       tienen grandes retrasos
     – Es más rápido almacenar procedimientos en bases de
       datos del servidor e invocar llamadas de función para
       ejecutar y devolver resultados

            Cliente                            Cliente
 Ejecut.              Dev.         Insertar,
                                                         Actualizar
procedim.             resultados    borrar
            Serv.                              Serv.
          Proced.
        almacenado      BD                                 BD
                      Objetos distribuidos

•   ¿Cómo encontrar todas las partes de una aplicación si no se
    pueden tener en el PC o en la estación de trabajo?
•   Objetos distribuidos = componentes
    – Objeto: parte de aplicación en una aplicación sencilla (datos,
      métodos)
    – Componente: parte de aplicación que interactúa en sistemas
      operativos, redes, lenguajes, aplicaciones, herramientas,
      hardware
•   Distintas normas:
    – Llamada a procedimiento remoto (RPC): síncrono
        •   Arquitectura de agente de petición de objeto común (CORBA): consorcio
        •   ActiveX (COM, DCOM, OLE): Microsoft
        •   Lenguaje de marcado extensible (XML): consorcio
        •   Protocolo simple de aplicación de objetos (SOAP): basado en XML
    – Middleware orientado a objetos (MOM); asíncrono
        • XML, BizTalk (Microsoft prefiere MOM y no RPC: es más simple)
    – Supervisión de procesado de transacciones (superv. TP)
        • Propio, para bases de datos heterogéneas de grandes volúmenes
Middleware de llamada a procedimiento remoto

 • Dos normas RPC heredadas
   – CORBA
   – ActiveX/COM/DCOM
 • Los componentes se alojan en buses de objetos
 distribuidos (ActiveX/COM o CORBA)
   – Los buses de objetos ofrecen compatibilidad de
     sistemas: los servicios que heredan los componentes
     en tiempo de creación o de ejecución colaboran con
     el resto de los componentes
   – La arquitectura de los componentes se diseña
     para funcionar con otros componentes desde
     el principio
           Componentes (heredados y WSDL)

•   Requisitos básicos:
    –   Comercializable
    –   No es una aplicación integral
    –   Utilizable en combinaciones impredecibles (similar a base de datos)
    –   Interfaz bien especificada
    –   Interactúa entre lenguajes, redes, sistemas operativos…
•   Funciones deseadas:
    – Seguridad: autoprotección, autoautenticación a clientes,
    seguimiento de auditorías
    – Licencias, versiones, metadatos: ofrece datos de sí mismo
    – Notificación de sucesos: notifica a las partes interesadas
      cuando ocurre algo
    – Gestión de configuración y propiedades, comandos
    – Compatibilidad para herramientas abiertas
                                 COM

•   Modelo de componentes más utilizado
    – Arquitectura ascendente: sin arquitectura global, las
      funciones se van añadiendo según las versiones
•   Modelo de objeto fundamental: base de ActiveX
    – COM permite que un objeto muestre su funcionalidad al
      resto de componentes y aplicaciones del host.
    – COM define la propia exposición del objeto y cómo ésta
      funciona en los procesos y en las redes.
    – COM también define el ciclo de vida del objeto.
•   Ejemplos:
    – Los controles ActiveX pueden comunicarse entre sí y con
      formularios de Visual Basic
        • Todos cumplen las normas de interfaz de ActiveX
    – Los controles personalizados suelen construirse según las
    normas de ActiveX
        • Visio, Quicken, Oracle, etc., ofrecen controles
                        Conceptos de COM

• Interfaces: mecanismo por el que un objeto muestra su
  funcionalidad.
    • Tabla de (punteros) funciones implementadas por el objeto.
    • Reemplazado por UDDI, WSDL y XML en middleware de Internet
• Discovery : interfaz básica en la que se basa el resto.
    • Interf. consulta: método para consultar un objeto en una interfaz
      concreta. O devuelve una función o notifica al cliente.
    • Recuento de refs.: técnica por la que un objeto (o, estrictamente, una
      interfaz) decide cuándo ya no se utiliza y, en consecuencia, puede
      eliminarse. Cuenta el número de referencias de clientes. Se libera si es 0.
    • J2EE y ASP.NET admiten esto en middleware de Internet
• Marshaling: mecanismo que permite que los objetos se puedan usar
  en hilos, procesos y redes, con independencia de la ubicación.
    • COM ofrece código para empaquetar parámetros del método en formato
      transferible (y en redes con procesos ejecutables en otros equipos) y
      para desempaquetarlos en el servidor.
    • SOAP (XML) hace esto en Internet
– Agregación: permite que un objeto utilice otro
    • No implementado en Internet
                        Interfaces COM
•   Las interfaces COM tienen un ID global único (GUID)
    – Número de 128 bits, generado para evitar colisiones
•   COM no depende del lenguaje
    – Ignora la implementación del componente (objeto)
      subyacente
    – Sólo se muestra a norma de interfaz y de marshalling COM
        • La clave reside en la reutilización. Si se muestran los terminales,
          pueden crear problemas en caso de modificarse
•   Transparencia local/remota. El objeto COM puede:
        • Estar dentro del mismo proceso (.EXE)
        • Estar en otro equipo
        • Estar en un equipo remoto
•   Usar el registro de MS para ubicar los componentes en la red
    – Instalar una entrada de cada componente en todos los equipos:
      adaptabilidad, seguridad, fiabilidad, problemas de rendimiento
•   COM está desfasado pero sigue siendo muy utilizado
  Aplicación basada en componentes ActiveX/COM


                     Componente de                Crear
                     fabric. ActiveX
          Interf. ActiveX                   Interf. ActiveX

           Comp. químico                                        Comprar,
Comprar                                Comp. entrada
           ActiveX                     ActiveX                configurar

     Conexión ADO             Conexión ADO
                                                           B. datos en
                                                          servidores
                   BD
                                               BD         de red
                  prod.
                                            pedidos       corporativa
                  quím.

                Oracle                       Sybase
        Objetos de datos de ActiveX
Servidor BD   Servidor web     Navegador
               Aplicación ActiveX, (cont.)

•   Todos los componentes pueden estar en uno o
    en varios equipos
    – Arquitectura de uno, dos o tres niveles
    – Componentes del catálogo de productos químicos y
      componentes de pedidos: pueden tener interfaz de usuario
      en el PC cliente.
    – Como alternativa, pueden ser componentes de servidor y su
      proveedor puede ofrecer componentes de UI distintos en el
      PC cliente.
        • Recordar: problemas de rendimiento en SQL cliente-servidor.
        • Posibilidad de configurar formularios y navegación.
• Las bases de datos y componentes deben estar en la red
corporativa
    – No válido para Internet: rendimiento, seguridad, protocolos
                              CORBA
•   CORBA es un middleware estándar abierto que
    establece relaciones entre objetos
     – El cliente puede invocar claramente el método en el objeto
       del servidor de la red
     – El objeto aparece como local en la aplicación cliente
•   Agente de petición de objetos (ORB): objeto clave de CORBA
     –   Intercepta llamadas del cliente al servidor
     –   Responsable de encontrar el objeto que implemente la petición
     –   Transmite los parámetros
     –   Invoca el método
     –   Devuelve resultados al cliente
•   El cliente ignora la ubicación del objeto, su lenguaje de
    programación o el sistema operativo
     – CORBA ofrece interoperabilidad en entornos heterogéneos
     – COM es, en esencia, sólo de Microsoft, aunque hay extensiones
                                 CORBA
•   Definido por el Grupo de gestión de objetos (OMG), fundado en 1989
      como consorcio de proveedores de objetos (actualmente con
      800 miembros).
       – Sitio web: www.omg.org
       – Versión actual: CORBA 2.x en uso; especific. CORBA 3.0 publicada
       – Agente de petición de objetos (ORB)
           • Permite a clientes invocar métodos en objetos remotos
           • Si el objeto remoto tiene interfaz de componentes, el objeto llamado
             se vincula a un módulo para llamar a sus métodos
           • Si no, consulta el almacén de la interfaz para buscarlos
           • Comunicación entre ORB a través de núcleo tcp/ip (Internet)
       – El bus de objetos cuenta con servicios de objeto
           • Normas para la creación, almacenamiento, definición y nomenclatura
             de los objetos del bus
           • En curso: servicio de sucesos, transacciones, relaciones,
             consultas, licencias...
       – Ejemplo: reserva de carga de mercancías
           • Muestra transportistas, vuelos, espacio disponible, de reserva, pago
                           ORB de CORBA

                                               Implem.
                 Cliente
                                             de objetos



                 Mod.                          Invoc.
    Invoc.                 Interf      Estruc.              Adapt.
                  IDL                          estruct.
                           ORB        estática
    dinámica     cliente                       dinámica     objetos

                 Núcleo del agente de petición de objetos

  Almacén                                                    Almacén
implementación                                               implementación
             Componentes del ORB cliente
•   Módulos IDL del cliente: (vinculación estática)
    – Los módulos invocan servicios residentes en los servidores
    – Sin embargo, desde el punto de vista del cliente, el objeto del
      servidor parece local
    – Los módulos actúan como proxy para el objeto remoto
    – Los archivos de encabezados (nombres de funciones y
      argumentos) para invocar métodos localmente de los
      lenguajes de programación se convierten en locales
    – Los módulos envían mensajes (marshalling): parámetros de
      codificación y descodificación hacia y desde el servidor
•   Interfaz de invocación dinámica: (vinculación dinámica)
    – Interfaz estándar para los metadatos del almacén de
      interfaces que definen todos los objetos del servidor
    – Siempre busca generación de parámetros y muestra las
      peticiones remotas, así como sus resultados
•   Almacén de interfaces
    – Contiene información sobre las clases (componentes) admitidas
            Componentes ORB del servidor

•   Módulos IDL del servidor o estructuras:
    – Igual que los módulos IDL del cliente
    – El objeto del servidor realmente no se llama localmente en el
      cliente: es su estructura la que hace que así parezca
•   Interfaz de estructura dinámica:
    – Igual que la interfaz de invocación dinámica del cliente
    – El mensaje tiene un formato más genérico y se procesa de
    forma distinta
•   Adaptador de objetos (gestor):
    – No es necesario en el cliente: tiene menos objetos y procesos
    – Acepta peticiones a objetos del servidor, asigna ID de
      objetos, registra clases admitidas en el servidor (muy
      distinto a ActiveX)
•   Almacén de implementación
    – Similar al almacén de interfaces del cliente que ofrece
      información en tiempo de ejecución sobre las clases
      admitidas y los objetos instanciados en el servidor
Lenguaje de definición de interfaz CORBA (IDL)

 •   Las interfaces a los objetos son la clave
      –   Definida mediante el lenguaje de definición de interfaz (IDL)
      –   IDL se compila en todas las secciones de la página
      –   (Similar a la tabla COM de funciones
      –   Java en la actualidad genera IDL automáticamente


     C++       Java     Cobol            C++      Java    Cobol

     IDL       IDL      IDL               IDL      IDL      IDL
              Cliente                              Servidor

                                 ORB
      Comunicación inter-ORB




IIOP es el protocolo inter-ORB de Internet
                    Problemas con ORB
•   Los ORB comerciales siguen siendo lentos e ineficaces
     – Sin balance de cargas, tolerancia a errores y con millones de
     transacciones
     – El descubrimiento de objetos en ORB a gran escala no es claro:
         • ¿Directorios de emisiones, base de datos central…?
•   El código del servidor no es muy portátil; el del cliente, sí
     – Las especificaciones tardan en llegar al lado del servidor
•   Sucesos, transacciones, etc., siguen sin estar disponibles
•   Problemas de interoperabilidad entre ORB existentes
     – Visigenic (Inprise) e Iona son las implementaciones líder
• CORBA tiene diseño descendente: buena arquitectura, servicios
limitados
     – ActiveX/COM es ascendente: arquitectura limitada, muchos servicios
     Aplicación basada en componentes CORBA

                 ORB
                          Aplic. componentes      Crear
                             fabricación
                      IIOP                 IIOP
    ORB                            ORB
        Comp. aplicación               Comp. aplicación    Crear,
Comprar
            produc. quím.                entrada pedido configurar
                                                      B. datos en
               IIOP                       IIOP        servidores red
                                                      corporativa
           ORB                         ORB
                 BD
                  quím                       BD
                                             pedidos

                 Oracle                        Sybase
               Aplicación CORBA (cont.)

•   Todos los componentes pueden estar en un
    equipo o en distintos equipos
    – Arquitectura de uno, dos o tres niveles
    – Mismas opciones, con más flexibilidad que COM/ActiveX
    – Un ORB por equipo.
        • Si algunos componentes están en el mismo servidor, sólo habrá un
        ORB en dicho servidor
• Las bases de datos y los componentes deben estar en la red
corporativa
    – Esto no funciona en Internet: rendimiento, seguridad, protocolos
    – Java y CORBA, sin embargo, sí funcionan en la red.
      Requieren el modelo de seguridad de Java
•   Más difícil desarrollar CORBA que ActiveX
    – Herramientas más caras, pero más adaptables con servidores UNIX
                Ejemplo de uso típico de CORBA

Almacenamiento
 principal: pedidos,                        No admitido
 disponibilidad del                         No Y2K
 producto                                   Sólo interfaz del
                                             programa


 Sistema UNIX:
  recepción y
  procesado de
  pedidos




Distintas
consultas SQL
para cada
campo del
formulario
Uso típico de CORBA, (cont.)



                       Sustituye EZBridge con
                       ORB de CORBA
                        Solo necesita 6 objetos




                         Usa ORB de
                         CORBA entre
                         UNIX y los PC de
                         Windows
                  ActiveX/COM y CORBA

•   ActiveX:
    – Separa la interfaz de objetos de la implementación, igual que CORBA
    – Tiene IDL, no igual que el IDL de CORBA y no interactúa
    – Los objetos ActiveX no son objetos reales: tienen métodos
       pero no atributos
    – Los objetos ActiveX se presentan como grupo de funciones
    relacionadas
        • Los clientes cuentan con punteros para acceder a las funciones
        • Al volver a conectarse, los atributos de la sesión anterior no se
        conservan
    – Las bibliotecas de tipo COM son prácticamente como el almacén de
    interfaces de CORBA
        • Los clientes consultan la biblioteca de tipo COM para encontrar
          interfaces y parámetros
    – El registro COM es similar al almacén de implementación de CORBA
                           Resumen

•   ActiveX/COM
    – Prevalece en aplicaciones de escritorio y basadas en PC
    – Algunas restricciones técnicas (atributos, descubrimiento)
    – Componentes en el mercado para PC: gráficos, datos,
    visualización, etc.
    – Enfoque ascendente: mejoras graduales en interfaces entre
       las interfaces de escritorio
•   CORBA
    – Usado en UNIX y en el campo de los servidores
        • IIOP incorporado en Netscape
    – Componentes en el mercado para grandes sistemas:
    facturación, finanzas, etc.
    – Enfoque descendente: arquitectura general orientada a
       servicios concretos
•   Ambos reemplazados ya por SOAP, UDDI, WSDL y ebXML

								
To top