1. MIDDLEWARE
&
CORBA
Por:
• Reyes Gabriel Carlos Ignacio
• Ruiz Quiroz Oscar Heberto
L.S.C.A. 601

2. ¿Qué es?
O Software intermediario entre los componentes de
un sistema distribuido.
O Servicios proporcionados:
O Representación común de la información
O Lenguaje para especificar tipos
O Implementación (codificación) de cada tipo
O Herramientas de “conversión”
O Invocación remota
O Localización
O Etc. (nombrado, seguridad...)

3. Un poco de Historia
O El origen de la palabra Middleware se
remonta al año 1968, en donde la palabra
es usada durante la 1968 NATO Software
Engineering Conference, siendo una idea
de cómo conectar el nuevo software con
sistemas más antiguos.

4. Mejor explicado
O Imagina que en un cyber y mandas a
imprimir desde tu computadora, entre la
comgputadora y la impresora debe haber
un intermediario (middleware) que es el
controlador de la impresora, el cual da el
servicio al cliente. De esta manera el
cliente (computadora) puede hacer uso de
la impresora, por que hay en medio quien
le ayude.

5. Ejemplos de Middleware
• ONC RPC (Sun)
• DCE (Open Software Foundation)
• CORBA (Object Management
Group)
• Java (Sun)
• SOAP, XML-RPC, ...

6. Taxonomía de los software
middleware

7. Common Object Request
Broker Arquitecture (CORBA)
Permite invocar métodos de objetos remotos
sin que importe el lenguaje en el que estén
escritos el llamador y el llamado, ni las
plataformas (s.o. y hw.) y redes de
comunicación intermedias
Incluye un buen número de servicios
O Nombres
O Seguridad
O Transacciones
O Persistencia
O Notificaciones

8. Common Object Request
Broker Arquitecture (CORBA)
Está estandarizado por el OMG (Object
Management Group)
O Sólo emite especificaciones (no existe
implementación de referencia)
O Las especificaciones se desarrollan por
consenso y son públicas y gratuitas
O Existen muchos fabricantes que implementan
las especificaciones más importantes para las
plataformas más usuales
O También estandariza UML (Unified Modeling
Language)

9. ¿Quién es omg?
O Obj Management Group
O Creado en 1989. Actualmente conformado
por alrededor de 800 compañías de
software, hardware y telecomunicaciones
(Sum, IBM, 3com, American airlines, Hewlett-
packard, Microsoft, Philips, Canon, etc.)
O El OMG no desarrolla software, si no que se
limita a definir y publicar estándares. El
desarrollo del software se realiza en cada
compañía independiente.

10. Arquitectura corba
O CORBA esta fundamentado en dos modelos: Un modelo de
Objetos, el cual agrega todas las características de
Orientación por Objetos como Tipos de
Datos, Abstracción, Polimorfismo y Herencia y un modelo
de referencia o arquitectura conocida como OMA (Object
Management Architecture).
O CORBA define una arquitectura para los objetos
distribuidos. El paradigma básico de CORBA es el de un
pedido de servicios de un objeto distribuido. Todo definido
por el OMG está en términos de este paradigma básico.
O Los servicios que un objeto proporciona son dados por su
interfaz . Los interfaces se definen en la lengua de la
definición de interfaz de OMG (IDL). Los objetos
distribuidos son identificados por las referencias del
objeto, que son mecanografiadas por los interfaces de IDL.

11. Ventajas
1) Disponibilidad y Versatilidad
O Muchas arquitecturas y sistemas operativos
cuentan con una implementación de CORBA, lo
que hace suponer que se puede usar CORBA
virtualmente en cualquier proyecto de sistemas
distribuidos.
O 2) Las especificaciones se adoptan por consenso.
O 3) Buena infraestructura para construir
aplicaciones distribuidas.
O 4) Permite integrar aplicaciones heterogéneas.

12. Ventajas
5) Adaptación a Lenguajes de
programación
O Además, es posible emplear los servicios
de CORBA desde cualquier lenguaje de
programación, desde C++, C ó
Java, hasta COBOL ó Ada.

13. Desventajas
1) Incompatibilidad entre implementaciones
Cuestiones como la colocación de librerías o las
diferentes formas de implementar la gestión de la
concurrencia, hacen difícil la portabilidad del código y
obligan al programador a reciclarse cuando quiere
cambiar de ORB. Además, donde el estándar no
concreta, las implementaciones pueden variar entre
sí, lo que da lugar a molestas incompatibilidades que
complican la vida al usuario.
2) Las especificaciones tardan en desarrollarse, y en
consecuencia las implementaciones tardan en salir al
mercado