PDF de programación - Tema 16 Middleware heredado

1.264 Tema 16

Middleware heredado

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

¿Por qué middleware?

– Redes de área extensa con alto ancho de banda, muchos

• Desarrollo de Internet

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

Dev.
resultados

Insertar,
borrar

Serv.
Proced.

almacenado BD

Serv.

Actualizar

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
fabric. ActiveX

Interf. ActiveX
Comp. químico
ActiveX

Comprar

Conexión ADO

Conexión ADO

BD
prod.
quím.

Oracle

BD

pedidos

Sybase

Crear

Interf. ActiveX

Comp. entrada
ActiveX

Comprar,
configurar

B. datos en
servidores
de red
corporativa

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

• En curso: servicio de sucesos, transacciones, relaciones,

de los objetos del bus

consultas, licencias...

– Ejemplo: reserva de carga de mercancías

• Muestra transportistas, vuelos, espacio disponible, de reserva, pago

ORB de CORBA

Cliente

Implem.
de objetos

Invo