4.5 ESTUDIO DETALLADO DE CORBA

4.5 ESTUDIO DETALLADO DE CORBA

El desarrollo de aplicaciones distribuidas no es una tarea sencilla. La arquitectura CORBA proporciona las herramientas necesarias para facilitar este desarrollo: un modelo de programación sencillo y cómodo, debido a que la ubicación de los objetos resulta transparente al programador. El estudio de los componentes internos de un ORB permitirá conocer qué ocurre en este entorno. Los protocolos de interoperabilidad se utilizan para intercomunicar aplicaciones que han sido desarrolladas sobre diferentes sistemas CORBA. Su estudio permite decidir la conveniencia de elegir un ORB u otro a la hora de implementar una aplicación.

CORBA es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas, de tal forma que el programador no se tiene que ocupar de tratar con sockets, flujos de datos, paquetes, sesiones etc. CORBA oculta todos estos detalles de bajo nivel. No obstante CORBA también brinda al programador una tecnología orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funciones normales dentro de su programa.

Veamos un ejemplo:

… GNOME_Evolution_Calendar_Cal__setMode (object, MODE_LOCAL, &ev);

…

Esta función ejecutaría el método setMode sobre el objeto object, para el programador esta llamada es como una operación local, no hay más complejidad.

Los métodos y datos CORBA se agrupan formando lo que se demoninan interfaces, los interfaces pueden ser interpretados como objetos que grupan datos y métodos para acceder a estos. Todos estos interfaces se definen usado un lenguaje IDL (Interface Definition Language), que es precisamente esto, un lenguaje para la definición de interfaces. Este lenguaje es estandar y lo soportan todas las implementaciones CORBA.

es algo más que una abstracción que oculta la complejidad de red, -> TODAS LAS LLAMAS PARA EL PROGRAMADOR SON IGUALES -> SE DEFINEN OBJETOS Y METODOS -> LOS OBJETOS SON REMOTOS -> NO PORQUE CORBA OCULTE COSAS DEBEMOS DEJAR DE PENSAR EN LA EFICIENCIA DE RED Hay una multitud de sistemas con un propósito muy similar a CORBA circulando por el mundo, los más usados son: el RPC (Remote Procedure Call) de Sun Microsystems y DCOM (Distributed que los desarrolladores de GNOME han adoptado es individuales CORBA -> muy importante especificación, OMG.

Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.

4.4 LOS ESTANDARES PARA EL DISEÑO DE SISTEMA DISTRIBUIDOS CON OBJETOS

4.4 LOS ESTANDARES PARA EL DISEÑO DE SISTEMA DISTRIBUIDOS CON OBJETOS

El establecimiento de estándares

Aquellas normas usuales, los propósitos, los objetivos, a alcanzar, los datos de carácter histórico las directrices que guían las actividades, las predicciones sobre el volumen de estas, las metas a alcanzar y aquellos índices que integran los planes , y todo dato o cifra que pueda emplearse como medida para cumplirlas, son considerados como estándares.

Estas medidas son indispensables para el control, ya que indican la manera en que deseas que se ejecute una actividad. En la práctica, son los objetivos declarados y definidos de la organización y por esa razón los estándares deben abarcar las funciones básicas y áreas clave de los resultados logrados.

Estándares estadísticos o históricos: parten del análisis de datos de experiencias logradas, que muchas veces son complementadas con el criterio personal.

Los estándares elaborados técnicamente se fundamentan en el estudio objetivo y cuantitativo de una situación de trabajo específica.

Los estándares puedes ser físicos, intangibles, de costos, de inversión, de recursos o medios de producción, de ingresos o de resultados, y expresarse cuantitativamente, en unidades numéricas, de uno u otro tipo(moneda, volumen, capacidad ), o cualitativos, cuando se establecen subjetivamente y lo que se mide y evalúa se refiere a cierta calidad(impacto en el mercado, nombre de la empresa, precio en la competencia).

Los estándares pueden representar calidad, mediante índices o calificaciones convencionales o por medio de coeficientes.

Para los sistemas distribuidos son necesarios los estándares por dos razones:

Diversidad. El trabajar en diferentes lugares , la recolección y almacenamiento de la información se realiza en diferentes locaciones. Para lograr una interaccion entre todos,es necesario obtener respuestas rápidas e independencia Los sistemas distribuidos se tienen que adaptar a diferentes requerimientos operacionales.

Fragmentación. Hasta ahora, no existe una arquitectura abierta que facilite la construcción de sistemas distribuidos en una base de diversos vendedores, la cual pueda expandirse a diversos dominios de aplicación.

Integrar los procesos de negocio interempresariales.

La integración de las aplicaciones de diferentes compañías, y de la semántica de los procesos de negocio que los soportan, necesita de un lenguaje universal común.

XML se creó con este objetivo y tiene, pues, un papel básico facilitando la comunicación entre procesos de negocio y, finalmente, entre las personas.

Para conseguir una integración process to process se creó XML (eXtensible Mark up Lenguage) como un conjunto de estándares del Consorcio World Wide Web pensado, inicialmente, para integrar procesos de Internet de forma alternativa a EDI (Electronic Data Interchange). La robustez, sencillez y eficacia de la idea lo ha convertido en un estándar para la integración de procesos distribuidos independientemente de si la plataforma es Internet o Sistema Operativo.

La presencia de XML es básica ya que permite avanzar en la integración sin costosas reprogramaciones.

Actuaciones como las de RosetaNet, grupo formado por IBM, Microsoft y American Express entre otros, y BizTalk de Microsoft e IBM, para estandarizar las descripciones, bajo XML, de producto, precios, inventarios, pedidos, facturas, etc.., y de UDDI para crear un estándar bajo XML para disponer un directorio donde registrar los servicios, potencian el camino a seguir.

Obviamente estos estándares pueden utilizarse también en la interconexión de procesos internos. Es más, los nuevos sistemas de información deben primar estos modelos de comunicación, proceso contra proceso, (Process to Process Communication) internamente.

Estandares

Plataforma de desarrollo de Servicios WEB: Java de SUN versus .Net de Microsoft.

J2EE basada en Java y .NET no son más que dos tecnologías para construir servicios WEB.

.NET es la plataforma de Microsoft. Es un conjunto completo de herramientas basadas en XML, XSML y el resto de estándares que proporcionan recursos para desarrollar, utilizar y administrar servicios WEB.

Proporciona un lenguaje de descripción de clases que permite crearlas en los lenguajes de programación más habituales y utilizarlas después de forma transparente en el entorno .NET.

Aporta también un Framework que marca una guía de cómo construir aplicaciones distribuidas para dar servicios WEB.

J2EE es la plataforma de SUN basada en Java, estándar de facto del mundo Internet. J2EE potencia y complementa Java con una biblioteca de herramientas, funciones y servicios como JDBC para acceso ODBC a bases de datos, EJB, un modelo de servidor para localizar los servicios creados, Java IDL para interactua con CORBA, uso de XML; etc..

J2EE es, más que un producto, una propuesta de estándares a los que los fabricantes deben adherirse. J2EE implica a diversas empresas proveedoras de Middleware cooperando entre sí, siempre con Java como lenguaje de desarrollo.

Orientación: Net está centrada en Windows y es independiente del lenguaje. J2EE está centrada sobre Java y es independiente de la plataforma.

4.3 LA TECNOLOGIA DE OBJETOS PARA EL DESARROLLO DE SISTEMAS DISTRIBUIDOS

4.3 LA TECNOLOGIA DE OBJETOS PARA EL DESARROLLO DE SISTEMAS DISTRIBUIDOS

En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un “método de invocación remota”.

El cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.

JavaBeans

Un componente software es una parte básica para la construcción de una aplicación.

CARACTERÍSTICAS QUE LO DIFERENCIAN DEL RESTO DEL CÓDIGO DE UN PROYECTO:

§Independencia de la plataforma

§Independencia del lenguaje

§Encapsulación

§ basados en un modelo estándar permitiendo a los componentes interactuar entre sí

Ofrece flexibilidad, reutilización y que puede ser visualizado por un lenguaje de programación Java

Los beans pueden ser aplicaciones que se pueden personalizar.

Incluyen clases e interfaces para personalizar en tiempo de diseño y en tiempo de ejecución. Se pueden personalizar sus propiedades.

DCOM Distributed Component Object Model . El Modelo de Objeto Componente Distribuido

Es un estándar que permite la creación de objetos que ejecuten tareas que resuelven problemas específicos pero comunes a varias aplicaciones que puedan desear hacer uso de ellos.

COM/DCOM/ActiveX, que son mecanismos de comunicación entre procesos diseñados principalmente para los sistemas Windows.

Utilizar características de cualquier otro objeto de la aplicación, o del sistema operativo, y permite actualizar el software de un componente sin afectar a la operación de la solución global COM  soporta comunicación entre objetos de equipos de cómputo distintos, en una LAN, WAN, o incluso en Internet.

DCOM extiende el estándar COM de objetos remotos, para su utilización en redes. Inicialmente se desarrolló para Windows NT 4.0, y posteriormente para Solaris 2.x y Macintosh, así como para diferentes versiones UNIX.

Se encarga DCOM olvida completamente la localización de los componentes, no importando que  estén en el mismo proceso que el cliente o en una máquina en cualquier lugar del mundo.

CORBACommon Object Request Broker Architecture .-

Es una  tecnología de integración que define un marco estándar para interoperabilidad entre objetos con independencia del lenguaje y de forma transparente al programador.

Elementos principales en los cuales se basa:

§El lenguaje de definición de interfaces IDL (Interface Definition Language)

§El ORB (Object Request Broker)

§El protocolo GIOP (General Inter-ORB Protocol).

Hace uso del modelo cliente/servidor para el manejo de los mensajes y así establecer la comunicación entre ellos, cuando un objeto en una aplicación cliente requiere ejecutar los métodos de un objeto remoto en una aplicación servidor, hace uso del ORB que es específico para el lenguaje y la plataforma de cada aplicación, el cual traduce la llamada del cliente a un formato neutro, totalmente independiente, que puede transportarse  sobre cualquier  medio para el  cual  exista un protocolo de comunicación.

4.2 EVOLUCION DE LOS SISTEMAS DISTRIBUIDOS

4.2 EVOLUCION DE LOS SISTEMAS DISTRIBUIDOS

El modelo de sistema distribuido es el más general, por lo que, aunque no se ha alcanzado a nivel comercial la misma integración para todo tipo de recursos, la tendencia es clara a favor de este tipo de sistemas.

APLICACIONES

Sistemas Comerciales

Algunos ejemplos son:

•Sistemas de reservas de líneas aéreas.

•Aplicaciones bancarias.

•Cajas y gestión de grandes almacenes

Redes WAN.-

ejemplos:

• Los servicios comunes que brinda Internet: Correo electrónico, servicio de noticias, transferencia de archivos, la Wrld Wide Web, etc.

Aplicaciones Multimedia.-

Los ejemplos de estos sistemas son:

• Videoconferencia.

•Televigilancia.

•Juegos multiusuarios.

UNIDAD 4 LA TECNOLIGIA DE OBJETOS DISTRIBUIDOS

4.1 DE LOS MODELOS DE OBJETOS CENTRALIZADOS A LOS MODELOS DE OBJETOS DISTRIBUIDOS

BASE DE DATOS CENTRALIZADA

Los sistemas de bases de datos centralizados son aquellos que se ejecutan en un único sistema informático sin interaccionar con ninguna otra computadora.

Grupo de Servidores.-  son un grupo de ordenadores actuando como servidores, normalmente de archivos o de impresión, poco inteligentes para un número de Minicomputadores que hacen el procesamiento conectados a una red de área local.

Definición:

En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un “método de invocación remota”.

Tecnologías orientadas a los objetos distribuidos:

1.RMI

2.DCOM

3.CORBA

BASE DE DATOS DISTRIBUIDA

Definición:

Es una colección de datos (base de datos) construida sobre una red y que pertenecen, lógicamente, a un solo sistema distribuido, es decir, se almacena la base de datos en varias computadoras.

Inconvenientes de las base de datos distribuidas.

El rendimiento que es una ventaja podría verse contradicho, por la naturaleza de la carga de trabajo, pues un nodo puede verse abrumado, por las estrategias utilizadas de concurrencia y de fallos, y el acceso local a los datos. Se puede dar esta situación cuando la carga de trabajo requiere un gran número de actualizaciones concurrentes sobre datos duplicados y que deben estar distribuidos.

3.7 ESQUEMAS PROPIETARIOS PARA EL DESPLIEGUE DE APLICACIONES EN EL WEB

 

El mecanismo de manejo de peticiones de la capa de presentación recibe muchos tipos diferentes de peticiones, cada uno de los cuales requiere varios tipos de procesamiento. Algunas peticiones simplemente requieren su reenvió al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.

Problema:

Se requiere un pre-procesamiento y un post-procesamiento de unas peticiones o respuestas de un cliente Web.

Cuando una petición entra a una aplicación Web, normalmente debe pasar varios test de entrada antes del estado de procesamiento principal. Por ejemplo,

§  ¿Se ha autentificado el cliente?

§  ¿Tiene el cliente una sesión válida?

§  ¿La dirección IP del cliente es de una red conocida?

§  ¿Viola alguna restricción el path de la petición?

§  ¿Qué codificación usa el cliente para enviar los datos?

§  ¿Soportamos el tipo de navegador del cliente?

Algunos de estos chequeos son tests, que resultan en una respuesta de si o no que determina si continuará el procesamiento. Otros chequeos manipulan el stream de datos entrantes a una forma aceptable para el procesamiento.

 Causas

§  Procesamiento común, como un chequeo del esquema de codificación de datos o la información de login de cada petición, completo por cada petición.

§  Se desea la centralización de la lógica común.

§  Se debería facilitar la adición o eliminación de servicios sin afectar a los componentes existentes, para que se puedan utilizar en gran variedad de combinaciones, como

§  Logging y autentificación.

§  Depuración y transformación de la salida para un cliente específico

§  Descomprensión y conversión del esquema de codificación de la entrada.

3.6 ESQUEMAS ACTUALES QUE HACEN USO DE LA ARQUITECTURA DEL CGI

DISTRIBUCIÓN DE APLICACIONES VIA SISTEMA CLIENTE-SERVIDOR

Presentación del proyecto ATF

El sistema telemático que aquí se presenta (ATF o Asistente Telemático a la Formación) es un desarrollo de Divisa Informática S.A., empresa de Ingeniería en Informática y Telecomunicaciones ubicada en Castilla y León, en el que colabora la Universidad de Valladolid a través de la Escuela Técnica Superior de Ingenieros de Telecomunicación de Valladolid.

Arquitectura del sistema ATF. Servidor Educativo

La arquitectura definida, sigue la estructura tradicional cliente servidor, aunque esta se encuentra modificada de forma parcial: donde el Servidor Educativo es el compendio de todos los servidores asociados, localizados en el proveedor de servicios telemáticos. Un requisito necesario a la hora de diseñar la arquitectura, fue el considerar una distribución de estos en diferentes máquinas, tal que se permita su futura escalabilidad. Además la arquitectura elegida deberá ser fácilmente repetible.

El cliente del sistema ATF

El cliente, denominado Aula Virtual y desarrollado para sistemas operativos Windows95 y NT, realiza las funciones fundamentales de un navegador tradicional, siendo la interfaz personal de trabajo del alumno y profesor.

Como aspecto favorable a la interfaz, el alumno nunca asocia los contenidos a direcciones de formato URL (o cualquier otro formato no entendible). De una forma más pedagógica, los contenidos se pueden relacionan con frases breves (herramienta de favoritos) o a textos personales más largos (herramienta de notas) creados por el mismo alumno.

La interfaz también dispone de una herramienta de correo. Otra herramienta interesante desarrollada fue el cliente de news, aquí bajo la denominación de tablón de anuncios. Estos dos clientes permiten la comunicación directa entre los participantes del curso y su tutor o tutores. Al implementar estas herramientas, se buscó la facilidad de uso. No son herramientas avanzadas o complejas, por contra, son altamente intuitivas en su manejo. Un objetivo que guía el desarrollo es no desmotivar nunca al usuario, obligándole aprender a utilizar un entorno complejo, más aún si no se encuentra familiarizado con las redes telemáticas. También, como se advierte en la figura, el atractivo visual se consideró como un elemento importante, que incita al usuario, y lo introduce en el entorno ficticio del aula.

La interfaz de cliente incorpora otras herramientas importantes: Aquellas asociadas al acceso al curso y su gestión.

Junto a estas, se dispone de la posibilidad de realizar los exámenes propuestos por el tutor o acceder a los eventos definidos por este (por ejemplo, avisos de clases presenciales). Los eventos se definen como aquellos hechos o noticias de especial relevancia que emitidos por el profesor, deben ocupar un papel diferenciado del resto de noticias del tablón.

PROCESAMIENTO PARALELO DE APLICACIONES

PROTOCOLOS DE APLICACION STANDARD Y NO STANDARD

Cualquier programador que haga uso de la librería de funciones para la implementación de una aplicación que realice su labor en paralelo tendrá que crear dos programas o procesos distintos:

El servidor, encargado de implementar la función de proceso sobre un conjunto o zona de datos con una estructura concreta.

El cliente, encargado de la interacción con el usuario y de controlar la operación de los servidores.

Para coordinar la ejecución de los procesos cliente y servidor es necesario establecer un protocolo de comunicación entre ambos, es decir una serie de normas que han de ser conocidas por los dos procesos y que han de ser cumplimentadas para que una solicitud de servicio pueda llevarse a cabo de forma correcta. Esto es lo que se conoce como Protocolo de Aplicación.

SERVICIOS PPL STANDARD

Los procesos cliente y servidor definidos en la librería PPL utilizan un protocolo de aplicación, lo llamaremos protocolo PPL, el cual define los servicios más comunes que van a ser empleados por las aplicaciones paralelas que van a poder ser desarrolladas con PPL. A estos servicios predefinidos se los denominaremos Servicios PPL Standard. El programador que haga uso de la librería PPL es libre de añadir cuantos servicios adicionales sean necesarios para la aplicación que esté desarrollando, del mismo modo puede modificar los servicios predefinidos para adaptarlos a sus necesidades. Veamos detalladamente cada uno de los servicios predefinidos por el protocolo PPL:

SERVICIO GET_DATA

Este servicio es empleado por el cliente para obtener el resultado del procesamiento llevado a cabo por el servidor sobre una zona de datos previamente transmitida por el cliente al servidor.

Protocolo GET_DATA.

El cliente compone una trama en cuya cabecera se indica al servidor que desea el servicio GET _DATA. Si no hay nada que lo impida, el servidor responde al cliente con la siguiente trama  en la cual le indica que se va a iniciar la transmisión de bytes, así como la cantidad de bytes a transferir.