1.264 Tema 16. Middleware heredado

Transcripción

1 1.264 Tema 16 Middleware heredado

2 Qué es el middleware heredado? Cliente (interf. de usuario, aplic. local) Cliente (interf. de usuario, aplic. local) Cómo conectamos clientes y servidores? Middleware Red Pre-web, pero post-internet Servidor (b. datos, aplicación, etc.) Servidor (b. datos, aplicación, etc.)

3 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

4 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

5 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 Ejecut. procedim. 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 Serv. Dev. resultados Insertar, borrar Cliente Serv. Actualizar Proced. almacenado BD BD

6 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

7 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

8 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

9 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

10 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

11 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

12 Aplicación basada en componentes ActiveX/COM Componente de fabric. ActiveX Crear Interf. ActiveX Interf. ActiveX Comprar Comp. químico ActiveX Comp. entrada ActiveX Comprar, configurar Conexión ADO BD prod. quím. Oracle Conexión ADO BD pedidos Sybase B. datos en servidores de red corporativa

13 Objetos de datos de ActiveX Servidor BD Servidor web Navegador

14 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

15 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

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

17 ORB de CORBA Cliente Implem. de objetos Invoc. dinámica Mod. IDL cliente Interf ORB Estruc. estática Invoc. estruct. dinámica Adapt. objetos Núcleo del agente de petición de objetos Almacén implementación Almacén implementación

18 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

19 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

20 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

21 Comunicación inter-orb IIOP es el protocolo inter-orb de Internet

22 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

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

24 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

25 Ejemplo de uso típico de CORBA Almacenamiento principal: pedidos, disponibilidad del producto No admitido No Y2K Sólo interfaz del programa Sistema UNIX: recepción y procesado de pedidos Distintas consultas SQL para cada campo del formulario

26 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

27 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

28 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