Conclusión

Ya se han visto varios conceptos sobre objetos distribuidos y componentes, espero que haya quedado claro como trabaja este modelo y la importancia que posee para aquellos que quieran especializarse en el mundo distribuido y la relevancia que tiene y tendrá a futuro. Para finalizar se les dejará un video con un resumen de todo lo tratado en este blog. Cualquier duda, consulta, sugerencia hacerla llegar a nuestro blog, para construir conjuntamente una mejor información para el usuario.

Parte 1.

Parte 2

Presentacion (PPTS) Objetos distribuidos por Fabián Millán .

Revisión de CORBA

La especificación CORBA detalla las interfaces y características del componente ORB de la OMA. La última actualización hasta el momento es CORBA 2.2. En la Figura 2, se muestra la arquitectura CORBA y como se relacionan sus distintos componentes:

                                                        Figura 2. Arquitectura CORBA

La arquitectura CORBA está orientada a objetos. Los objetos CORBA presentan muchas características de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. Lo que hace a CORBA más interesante es que proporciona estas capacidades, incluso cuando es utilizado en lenguajes no orientados a objeto como C o COBOL, aunque CORBA trabaja particularmente bien con los lenguajes orientados a objeto como C++ y Java.

Dentro de las nuevas técnicas y lenguajes de modelado de objetos, cabe destacar la notación estándar UML (Unified Modeling Language), cuya última actualización es UML 1.2 a mediados de 1998. UML es una evolución de las metodologías orientadas a objeto anteriores, como Booch, OMT, y OOSE, tratando de unificar lo mejor de cada una de ellas. UML ha dado lugar un potente lenguaje visual, para expresar diseños orientados a objetos, consistente en palabras, textos, gráficos y símbolos.

Cabe destacar, sin embargo, que UML es sólo un estándar de notación. Esencialmente, define un cierto número de diagramas que se pueden dibujar para describir un sistema y el significado de dichos diagramas. UML no describe el proceso a seguir al desarrollar el software, también considerado en la metodología formal tradicional.

OMA

OMA (Object Management Architecture) o arquitectura de gestión de objetos es el centro de toda la actividad emprendida en el OMG. Se trata de una visión a alto nivel de un entorno distribuido completo y se compone de un modelo de objeto y un modelo de referencia.

En el modelo de objeto de OMA, un objeto es una entidad encapsulada con una identidad inmutable y distinguible, cuyos servicios pueden ser accedidos a través de interfaces bien definidas.

                                                            Figura 1.  Modelo Referencia OMA

En la Figura 1 se muestran los componentes del modelo de referencia de OMA, encargado de caracterizar las interacciones entre objetos. El componente fundamental es el denominado ORB (Object Request Broker). El ORB es, principalmente, el responsable de facilitar la comunicación entre clientes y objetos. Puede verse como el microkernel de un sistema distribuido. Utilizando el componente ORB hay cuatro categorías de interfaces de objetos, descritas a continuación:

• Servicios comunes a todos objetos. Son interfaces independientes del dominio, que son utilizados por varios programas de objetos distribuidos. Ejemplos de estos servicios son: el servicio de nombres, que permite a los clientes encontrar objetos en función de sus nombres; el servicio de intercambio, que permite a los clientes encontrar objetos a partir de sus propiedades; el de control de la concurrencia; el de transacciones; etc.
• Facilidades comunes. Están orientadas a las aplicaciones del usuario final (por ejemplo, facilidades para la gestión de la información, administración del sistema, gestión de tareas, etc.).
• Interfaces del dominio. Son semejantes a los servicios de objetos y facilidades comunes, pero están orientadas a dominios de aplicación específicos (por ejemplo, telemedicina, aplicaciones financieras, etc.).
• Interfaces de aplicación. Están orientadas a una aplicación específica y por lo tanto no están estandarizadas por el OMG.

OMG

El OMG es un consorcio internacional sin ánimo de lucro establecido en 1989. Su objetivo es, ayudar a reducir la complejidad, disminuir los costes y acelerar la introducción de nuevas aplicaciones software, promoviendo la teoría y la práctica de la tecnología de objetos en los sistemas distribuidos.

Originalmente estaba formada por 13 compañías, pero los miembros del OMG han crecido progresivamente y en la actualidad es el consorcio de software más grande del mundo, compuesto por más de 760 vendedores, programadores y usuarios. De hecho todas las grandes compañías de software interesadas en el desarrollo orientado a objetos distribuidos son miembros del OMG.

El OMG alcanza sus objetivos promoviendo la adopción de especificaciones de interfaz y de protocolo, que permiten la interoperabilidad y portabilidad de las aplicaciones orientadas a objetos distribuidos. En este consorcio no se producen guías de cómo implementar o producir software, sólo especificaciones.

Los miembros del OMG contribuyen tecnológicamente y con ideas en respuesta a RFI (Request For Information) y RFP (Request For Proposals), emitidas por el OMG. El OMG no establece estándares en la industria, se formó para promover mediante el consenso de sus participantes, la adopción de estándares de facto por parte de los vendedores. El estándar a ser adoptado, debe existir como una implementación; es decir, sólo se aprueba un estándar si alguien lo ha implementado y se comprueba su correcto funcionamiento.

Computación distribuida a objetos      

La computación distribuida a objeto es un paradigma de computación que le permite a los objetos ser distribuidos a través de una red heterogénea, y permite que cada uno de los componentes interactuar como un todo unificado. Para una aplicación a un entorno de objetos distribuidos, y tal como se expresa en el lema de Sun Microsystem, la red es el ordenador. La orientación a objetos puede simplificar radicalmente el desarrollo de sistemas. Distribuye los modelos de objetos y herramientas de extender un sistema de programación orientado a objetos. Los objetos pueden ser distribuidos en distintos ordenadores a través de una red, que viven dentro de su biblioteca propia dinámica fuera de una aplicación, y sin embargo aparecen como si fueran locales en la aplicación. 

Varias ventajas técnicas el resultado de un entorno de objetos distribuidos es que: 

• Los activos heredados se pueden aprovechar. 
• Los programadores tienen la posibilidad de distribuir los componentes de una aplicación a los equipos que mejor se adapten a la tarea de cada objeto, sin tener que cambiar el resto de la aplicación que utiliza estos objetos. 
• Dado que los objetos parecen ser locales a sus clientes, el cliente no sabe lo que la máquina, o incluso qué tipo de máquina, un objeto se encuentra en. 
• La integración de sistemas se puede realizar en un grado superior. El objetivo general técnica de la computación de objetos distribuidos es clara: para avanzar en tecnologías de la información distribuida de manera que puedan ser más eficientes y flexibles, pero menos complejo. Los beneficios de objetos distribuidos son de hecho las soluciones a los problemas con los actuales, monolítica cliente / servidor paradigmas.

                                        Desarrollo basado en componentes

 Representa la "industrialización" de desarrollo de software. Cuando cualquier proceso de fabricación se desarrolla hasta el punto en que puede estar basado en componentes pre-construidos y subconjuntos, la calidad del producto, la cantidad y velocidad de entrega se disparan. Este principio se aplica igualmente a los sistemas de desarrollo de software, lo que permite una calidad sin precedentes, la velocidad de desarrollo y gestión de cambios muy eficaz. Sin embargo, un cambio de mentalidad hacia los componentes fundamentales es necesario marcar el comienzo de la era industrial, el desarrollo de software.

COM:  Proporciona la tecnología de componentes para aplicaciones de Microsoft Internet de Windows distribuido (Windows DNA), la arquitectura, que permite a los desarrolladores integrar aplicaciones basadas en Web (cliente / servidor) en una arquitectura única y unificada. Mediante los COM, los desarrolladores pueden crear componentes distribuidos que están escritas en cualquier idioma y que pueden interactuar en cualquier red.

COM +: Hará que sea aún más fácil para los desarrolladores para crear componentes de software en cualquier idioma con cualquier herramienta. COM + se basa en los factores que han hecho de COM de hoy la elección de los desarrolladores en todo el mundo, incluyendo los siguientes: 

• Los más ricos de servicios integrados, incluyendo las transacciones, la seguridad de colas de mensajes y acceso a la base de datos para apoyar la más amplia gama de escenarios de aplicación. 
• La más amplia selección de herramientas de múltiples proveedores con múltiples lenguajes de desarrollo. 
• La mayor base de clientes de aplicaciones personalizables y componentes reutilizables. 
• Demostrado su interoperabilidad con los usuarios y los desarrolladores de 'las inversiones existentes. (Microsoft)

CORBA

Common Object Request Broker Architecture. 
Desarrollado por el Object Management Group (OMG) en 1990, permite a las invocaciones de los métodos de objetos distribuidos que residen en cualquier parte de una red, como si fueran objetos locales. Una implementación de CORBA Object Request Brokers emplea (ORB), que se encuentra tanto en el cliente y el servidor, para crear y administrar comunicaciones cliente / servidor entre objetos. Orbes son la clave de la arquitectura de objetos distribuidos CORBA. Para facilitar estas peticiones y proporcionar interoperabilidad ORB, la especificación CORBA 2.0 describe un protocolo llamado Internet Inter-ORB Protocol, que ha sido rápidamente adoptada por los líderes de la industria (IBM, Oracle Netscape). (EarthWeb)

JavaBeans: La plataforma neutral en la arquitectura de componentes de Java, ha demostrado ser invaluable en el desarrollo de la red de las aplicaciones compatibles. Usted puede hacer cualquier clase Java en un grano con sólo cambiar la clase a que se adhieran a la especificación de JavaBeans. Depende de usted decidir lo que quiere el diseño como un grano y lo que quiere para el diseño como una clase Java: Es una buena idea dejar todas las librerías de clases como clases de Java, pero la interfaz gráfica de usuario (GUI) los elementos se pueden diseñar a los frijoles, los frijoles y algunos - como los frijoles en un servidor - pueden ser no-GUI-relacionados. Independientemente de su funcionalidad, cada grano debe apoyar las siguientes características y el comportamiento: la persistencia, la manipulación visual, la introspección, eventos y personalización.