SlideShare una empresa de Scribd logo
4
Lo más leído
9
Lo más leído
10
Lo más leído
MIDDLEWARE
       &
     CORBA
             Por:
• Reyes Gabriel Carlos Ignacio
 • Ruiz Quiroz Oscar Heberto

                         L.S.C.A. 601
¿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...)
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.
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.
Ejemplos de Middleware
• ONC RPC (Sun)
• DCE (Open Software Foundation)
• CORBA (Object Management
  Group)
• Java (Sun)
• SOAP, XML-RPC, ...
Taxonomía de los software
      middleware
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
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)
¿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.
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.
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.
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.
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
Middleware & Corba

Más contenido relacionado

PPTX
CISCO 1 - Introduccion a las redes
PDF
Ingenieria software ejemplo
PPTX
Microsoft azure presentacion
PPTX
Ingenieria de software - Unidad 3 arquitecturas de software
PDF
Historias de usuario
PPTX
Algoritmo de servidor centralizado
PDF
IEEE 730 1989: Plan de aseguramiento de la calidad del software
PPT
Del análisis al diseño. diagramas de secuencia y contratos
CISCO 1 - Introduccion a las redes
Ingenieria software ejemplo
Microsoft azure presentacion
Ingenieria de software - Unidad 3 arquitecturas de software
Historias de usuario
Algoritmo de servidor centralizado
IEEE 730 1989: Plan de aseguramiento de la calidad del software
Del análisis al diseño. diagramas de secuencia y contratos

La actualidad más candente (20)

PPTX
Desarrollo de software basado en componentes
PPTX
TRANSACCIONES
PPTX
3. conceptos de calidad del software
PPTX
Diseño de Software
PPTX
Arquitectura de los sistemas operativos
PDF
Requisitos funcionales
PPT
Arquitectura de sistemas distribuidos
DOCX
Caso de uso de biblioteca
PPTX
Algoritmo ricart y Agrawala
DOCX
Plan de Pruebas
PPT
Metricas Tecnicas Del Software
PPTX
PPT
Unidad 4 Mad Modelado Analisis Casos De Uso
PDF
Alta disponibilidad-con-heartbeat
PPTX
Amazon Web Services
PDF
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
DOCX
Middleware en los sistemas distribuidos
POT
3.1.6 espacio para objetos
PPTX
Aseguramiento de la Calidad del Software II
PPT
Atributos de calidad en el desarrollo de software
Desarrollo de software basado en componentes
TRANSACCIONES
3. conceptos de calidad del software
Diseño de Software
Arquitectura de los sistemas operativos
Requisitos funcionales
Arquitectura de sistemas distribuidos
Caso de uso de biblioteca
Algoritmo ricart y Agrawala
Plan de Pruebas
Metricas Tecnicas Del Software
Unidad 4 Mad Modelado Analisis Casos De Uso
Alta disponibilidad-con-heartbeat
Amazon Web Services
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
Middleware en los sistemas distribuidos
3.1.6 espacio para objetos
Aseguramiento de la Calidad del Software II
Atributos de calidad en el desarrollo de software
Publicidad

Destacado (16)

PPTX
Middleware
DOCX
Aplicaciones Middleware
PPT
Middleware
PPT
07 middleware
DOCX
PPT
RPC - LLAMADAS REMOTAS
PPTX
PDF
Areas donde implementamos los sistemas distribuidos
PPSX
Sistemas distribuidos
PDF
Arquitectura cliente servidor
PPTX
Sistemas Operativos Distribuidos
PPT
Sistemas Distribuidos
DOCX
Antecedentes de los sistemas distribuidos.
DOCX
Tipos de sistemas distribuidos.
PPTX
PPTX
Semana 13 sistemas distribuidos
Middleware
Aplicaciones Middleware
Middleware
07 middleware
RPC - LLAMADAS REMOTAS
Areas donde implementamos los sistemas distribuidos
Sistemas distribuidos
Arquitectura cliente servidor
Sistemas Operativos Distribuidos
Sistemas Distribuidos
Antecedentes de los sistemas distribuidos.
Tipos de sistemas distribuidos.
Semana 13 sistemas distribuidos
Publicidad

Similar a Middleware & Corba (20)

PDF
Arquitectura Corba
PDF
Tecnologías de Desarrollo de Sistemas Distribuidos basados en Objetos
PPT
P3 Componentes
PPTX
Ug chica
PPTX
PPTX
Ug mvillao
PPT
PPTX
Ug chaguay
PPTX
Merchan y mocha
PPTX
Ug zuñiga
PPTX
Net remoting
PPTX
.Net Remoting
PPTX
R_QuintoNevarez
PPTX
Ut jsilvareyes
PPSX
Jacomefarino
PPSX
Jacomefarino
PDF
odmg - corba
PDF
DOCX
Trabajo grupal 1 taller-prog-distribuida
PPTX
189 206
Arquitectura Corba
Tecnologías de Desarrollo de Sistemas Distribuidos basados en Objetos
P3 Componentes
Ug chica
Ug mvillao
Ug chaguay
Merchan y mocha
Ug zuñiga
Net remoting
.Net Remoting
R_QuintoNevarez
Ut jsilvareyes
Jacomefarino
Jacomefarino
odmg - corba
Trabajo grupal 1 taller-prog-distribuida
189 206

Middleware & Corba

  • 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