• No se han encontrado resultados

Universidad Central Marta Abreu de Las Villas

N/A
N/A
Protected

Academic year: 2021

Share "Universidad Central Marta Abreu de Las Villas"

Copied!
62
0
0

Texto completo

(1)

Universidad Central “Marta Abreu” de Las Villas

Facultad de Matemática Física y Computación

T

T

R

R

A

A

B

B

A

A

J

J

O

O

D

D

E

E

D

D

I

I

P

P

L

L

O

O

M

M

A

A

Asistente para la caracterización de sitios de

procesamiento para un Sistema de Diseño de Bases de

Datos Distribuidas

Autor: Alain Cárdenas Castillo

Tutores: Msc. Abel Rodríguez Morffi

Dra. Luisa González González

(2)

Hago constar que el presente trabajo fue realizado en la Universidad Central Marta Abreu de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencias de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.

_________________ Firma del autor

Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.

_________________ __________________________ Firma del tutor Firma del jefe del Seminario

(3)

A mi familia, y muy especialmente a mi madre,

que ha soñado tanto con este momento...

(4)

AGRADECIMIENTOS

A mi familia, por su cariño y preocupación.

A lillyta, por su amor incondicional y sus inventos…por su optimismo.

A mis amigos Will y Norma.

A mi tutora Luisa, por sus orientaciones.

A mi amigo y tutor Abel, que aunque lejos, no ha dejado de estar.

A Carlos García, por su ayuda en el momento más oportuno.

A mis suegros, a Niorlis, Segundo, Felo, Maricel, Armandito y a todos los que

sin dudarlo, me han dedicado parte de su tiempo.

(5)

RESUMEN

El proceso de distribución en el área de las Bases de Datos Distribuidas necesita información que puede estar dividida en cuatro categorías: información sobre la base de datos, información sobre las aplicaciones, información sobre el sistema de las computadoras e información sobre la comunicación de la red.

Debido a la necesidad de contar con un software para el diseño de Bases de Datos Distribuidas, se hace imprescindible la caracterización de los sitios de procesamiento y de la red. En este trabajo se realizará un estudio de la tecnología distribuida .Net Remoto, con el objetivo de implementar una aplicación capaz de captar la información necesaria para la caracterización de la red, que formará parte de un Sistema Integrado de Ayuda al Diseño de Bases de Datos Distribuidas.

(6)

ABSTRACT

The distribution process, in the area of the Distributed Databases need information that can be divided into four categories: information about the database, information about the applications, information about the computers, and information about the communication network.

Due to the need of having a software for the design of Distributed Databases, it is essential the characterization of the processing sites and network communications. The current work was carried out by means a deep study of the distributed technology Dot Net Remoting with the purpose of implementing an application to grasp the information needed for the characterization of the network would be part of an Integrated System for Help to the Design of Distributed Databases.

(7)

ÍNDICE

INTRODUCCIÓN ...1

CAPÍTULO 1. GENERALIDADES...4

1.1DE LAS BASES DE DATOS DISTRIBUIDAS...4

1.2DE LAS REDES DE COMPUTADORAS. ...9

1.3DE LA UNIÓN DE LAS REDES Y LAS BASES DE DATOS...11

1.4PARÁMETROS DE DESEMPEÑO. ...11

1.5TECNOLOGÍAS PARA LA COMUNICACIÓN REMOTA. ...12

1.5.1 DCE/RPC...13 1.5.2 CORBA. ...13 1.5.3 DCOM...14 1.5.4 MTS/COM+. ...14 1.5.5 Java RMI...15 1.5.6 Java EJB. ...15 1.5.7 Servicios WEB/SOAP/XML-RPC. ...16 1.5.8 .Net Remoto...16 1.6ANTECEDENTES. ...17 1.7CONCLUSIONES PARCIALES...18 REFERENCIAS BIBLIOGRÁFICAS...19

CAPÍTULO 2. TECNOLOGÍAS UTILIZADAS ...20

2.1INTRODUCCIÓN A .NET REMOTO. ...20

2.1.1 Clientes y servidores remotos. ...21

2.1.2 Activación y tiempo de vida. ...24

2.1.3 Canales. ...27

2.1.4 Sumideros...28

2.1.5 Puertos. ...29

2.1.6 Comunicaciones remotas. ...30

2.1.7 Marshalling de datos en .Net Remoto. ...31

(8)

2.1.9 Proxy en .Net Remoto. ...33

2.1.10 Seguridad en .Net Remoto...34

2.2WMI(WINDOWS MANAGEMENT INSTRUMENTATION) ...35

2.2.1 .Net y WMI. ...37

2.3CONCLUSIONES PARCIALES. ...38

REFERENCIAS BIBLIOGRÁFICAS...39

CAPÍTULO 3. ASPECTOS DEL DISEÑO Y LA IMPLEMENTACIÓN ...40

3.1CASOS DE USO Y ACTORES DEL ASISTENTE. ...40

3.2ARQUITECTURA DEL SISTEMA. ...42

3.3DISEÑO DE CLASES. ...42

3.4EL SERVIDOR. ...44

3.5EL CLIENTE...45

3.6VISTA DEL USUARIO...46

CONCLUSIONES...49

RECOMENDACIONES...50

(9)

INTRODUCCIÓN

La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha promovido un cambio en la forma de observar los sistemas de información y, en general, las aplicaciones computacionales. Existen avances tecnológicos que se realizan continuamente en circuitos, dispositivos de almacenamiento, programas y metodologías. Sin embargo, los cambios tecnológicos van de la mano con la demanda de los usuarios y programas para la explotación exhaustiva de tales dispositivos mejorados, por tanto, existe un continuo desarrollo de nuevos productos que incorporan ideas nuevas desarrolladas por compañías e instituciones académicas.

Los sistemas distribuidos se adaptan mejor a las necesidades de las organizaciones descentralizadas ya que reflejan más adecuadamente su estructura y tienen importantes ventajas con respecto a los centralizados (Öszu and Valduriez, 1999); pero al mismo tiempo añaden nuevas complejidades en su diseño e implementación.

Existen buenas razones técnicas para distribuir datos. La más obvia es la referente a la sobrecarga de los canales de entrada y salida a los discos en donde se almacena, finalmente, la información; es mucho mejor distribuir los accesos a la información sobre diferentes canales que concentrarlos en uno solo. Otra razón de peso es que las redes de computadoras empezaron a trabajar a velocidades razonables, abriendo una puerta a la distribución del trabajo y la información.

El hacer una descentralización de la información se justifica desde el punto de vista tecnológico por las siguientes razones:

• Para permitir autonomía local y promover la evolución de los sistemas y los cambios en los requerimientos de usuario.

• Para proveer una arquitectura de sistema simple, flexible y tolerante a fallas. • Para ofrecer buenos rendimientos.

(10)

Existen aplicaciones que nacieron distribuidas. Para ellas ha sido necesario el uso de nuevas tecnologías para integrar sistemas de información diferentes, de forma que no se afecte de manera sustancial el estilo de trabajo. Aunque la idea de distribución de datos es bastante atractiva algunos de los resultados que se deben lograr son:

• Asegurar que el acceso entre diferentes sitios o nodos y el procesamiento de datos se realice de manera eficiente, presumiblemente óptima.

• Transformar datos e integrar diferentes tipos de procesamiento entre nodos de un ambiente distribuido.

• Distribuir datos en los nodos del ambiente distribuido de una manera óptima. • Controlar el acceso a los datos disponibles en el ambiente distribuido.

• Soportar la recuperación de errores de diferentes módulos del sistema de manera segura y eficiente.

• Asegurar que los sistemas locales y globales permanezcan como una imagen fiel del mundo real evitando la interferencia destructiva que pueden ocasionar diferentes transacciones en el sistema.

Un Sistema de Bases de Datos Distribuidas (SBDD) es un sistema en el que múltiples sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma, que un usuario en cualquier sitio puede acceder a los datos en cualquier parte de la red, exactamente como si los datos estuvieran almacenados en su sitio propio (López, 2001).

Un Sistema de Manejo de Bases de Datos Distribuidas (SMBDD) es aquel que se encarga del manejo de la Base de Datos Distribuida (BDD) y proporciona un mecanismo de acceso que hace que la distribución sea transparente a los usuarios. El término transparente significa que la aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBDD ejecutado en una sola máquina, administrara esos datos. Un SBDD es entonces el resultado de la integración de una base de datos distribuida con un sistema para su manejo (López, 2001). En el diseño de bases de datos distribuidas se debe considerar el problema de cómo distribuir la información entre diferentes sitios. Existen razones organizacionales, que determinan, en gran medida, lo anterior; sin embargo, cuando se busca eficiencia en el acceso a la

(11)

información, se deben abordar dos problemas relacionados. El primero: cómo fragmentar la información, y el segundo: cómo asignar cada fragmento entre los diferentes sitios de la red. La información que se necesita para el diseño de distribución puede estar dividida en cuatro categorías: información sobre la Base de Datos, información sobre las aplicaciones, información sobre la comunicación de la red e información sobre el sistema de las computadoras. Las últimas categorías son completamente cuantitativas en cuanto a su naturaleza y son usadas en los modelos de ubicación (Öszu and Valduriez, 1999).

El concepto de optimalidad que se usa durante el proceso de distribución y localización de fragmentos, hace necesario el manejo y medición de alguno de los parámetros que caracterizan las redes de computadoras, ya que de su control y conocimiento depende en gran medida el buen desempeño del sistema que se está diseñando.

En “NetWizard. Asistente para la caracterización de sitios de procesamiento” (López, 2001) se reporta el desarrollo de un asistente para la caracterización de sitios de procesamiento para un entorno de BDD, como parte de un trabajo de tesis de culminación de estudios de Licenciatura en Ciencia de la Computación. Este antecedente sirve de base para el presente trabajo, que tiene, sobre la base de la sustitución de las tecnologías anteriores por nuevas, como una continuación del trabajo anterior en la etapa de mantenimiento, los siguientes objetivos:

Objetivo general:

• Implementar una aplicación capaz de captar la información necesaria para la caracterización de la red, que formará parte de un Sistema Integrado de Ayuda al Diseño de Bases de Datos Distribuidas (SIADBDD).

Objetivos específicos:

• Estudiar la tecnología .Net Remoto como sucesora de COM y DCOM.

• Obtener una nueva versión del Asistente utilizando .Net Remoto, sustituyendo las tecnologías COM y DCOM utilizadas en la versión anterior.

(12)

CAPÍTULO 1. GENERALIDADES

El uso y generalización de los Sistemas de Bases de Datos Distribuidas está condicionado por dos motivos fundamentales: el continuo descenso del costo del hardware y el incremento del costo del software de aplicación a gran escala.

Su objetivo fundamental es integrar la manipulación de datos para presentarlos como una única colección global y coherente En muchos casos en la práctica se presentan organizaciones geográficamente distribuidas para las cuales las vías centralizadas no representan una alternativa factible, y la migración hacia Sistemas de Bases de Datos Distribuidas resulta natural, ya que esta alude de manera natural la estructura descentralizada de la organización.

1.1 De las Bases de Datos Distribuidas.

El término de Bases de Datos Distribuidas se puede definir como una colección de bases de datos lógicamente interrelacionada y distribuida sobre una red de comunicación. Se escoge esta definición pues en ella están imbricados los aspectos neurálgicos de las Bases de Datos Distribuidas. La distribución está dada por el hecho de que los datos no residen en el mismo sitio; y por otra, las implicaciones lógicas que hacen que estos datos posean algunas propiedades comunes que los vinculan, y a los que se accede a través de una interfaz común. Es necesario destacar que el enlace ente los datos se lleva a cabo en una red de comunicación, lo que determina que los sitios - por generalización - estén localizados en diferentes áreas geográficas y con capacidad de procesamiento autónomo.

Por todo lo anterior se puede decir que un Sistema de Gestión de Base de Datos Distribuidas es el software capaz de realizar la administración de la Base de Datos Distribuida y en el que esta distribución es totalmente transparente al usuario. Estos sistemas heredan las complejidades propias de los sistemas centralizados e incorporan una nueva problemática asociada al hecho de que los datos están distribuidos sobre una red de computadoras.

(13)

Las tecnologías de los Sistemas de Bases de Datos Distribuidas son la unión de conceptos implícitamente opuestos para el procesamiento de los datos. Por una parte están los Sistemas de Bases de Datos y por otro las redes de computadoras. Los Sistemas de Bases de Datos han eliminado el concepto tradicional de procesamiento de ficheros, donde cada aplicación define y mantiene sus propios datos, para convertirse en un sistema en el cual los datos son definidos y administrados centralizadamente. Estos nuevos derroteros conllevan a una deseada independencia de datos, y a que los programas de aplicación se hagan poco sensibles a cambios en la organización física o lógica y viceversa.

Uno de los principales incentivos para el uso de los Sistemas de Bases de Datos es integrar los datos involucrados en las operaciones y permitir su acceso centralizado. Pero en el otro lado se encuentra la perspectiva distinta que impone las tecnologías de redes de computadoras, con proyecciones opuestas a la centralización. Pudiera parecer un tanto contradictoria la posibilidad de hacer coincidir ambas perspectivas a fin de promover una tecnología más poderosa y prometedora que ambas por sí solas.

Esto pudiera ser explicado dado a que la proyección más importante de las Bases de Datos Distribuidas es la integración, no la centralización. De igual forma es válido resaltar que un término no implica el otro, o sea, es posible hablar de integración, sin que esto conduzca necesariamente a una centralización. Este es uno de los objetivos fundamentales de los modernos Sistemas de Bases de Datos Distribuidas.

Las diferentes técnicas de diseño de las Bases de Datos Distribuidas (generalmente basadas en la semántica de los datos) se rigen por idénticos principios que las bases de datos centralizadas, pero se incorporan detalles específicos como la fragmentación de las entidades y su posterior localización en los diferentes sitios de la red. Esta fragmentación es muy útil a fin de mejorar los tiempos de respuesta y garantizar el paralelismo del sistema.

Las Bases de Datos Distribuidas brindan importantes beneficios, entre los cuales se pueden enumerar:

1. El incremento del rendimiento 2. El paralelismo

(14)

4. La participación directa y el control de los usuarios sobre los datos y recursos

La principal desventaja se refiere al control y manejo de los datos, dado a que éstos residen en muchos nodos diferentes y se pueden consultar por nodos diversos de la red, la probabilidad de violaciones de seguridad es creciente si no se toman las precauciones debidas.

La habilidad para asegurar la integridad de la información en presencia de fallas no predecibles, tanto de componentes de hardware como de software, es compleja. La integridad se refiere a la consistencia, validez y exactitud de la información, dado a que los datos pueden estar replicados, el control de concurrencia y los mecanismos de recuperación son mucho más complejos que en un sistema centralizado. Esto amplía el grado de complejidad de los sistemas con respecto a los sistemas centralizados.

Para garantizar estas metas es necesario desarrollar soluciones óptimas o con un grado aceptable de optimalidad que derivan en la implementación de algoritmos sumamente engorrosos, generalmente de complejidad exponencial.

Tradicionalmente se ha clasificado la organización de los Sistemas de Bases de Datos distribuidas sobre tres dimensiones: el nivel de compartimentación, las características de acceso a los datos y el nivel de conocimiento de esas características de acceso (ver la figura 1.1).

El nivel de compartimentación presenta tres alternativas:

1. Inexistencia (cada aplicación y sus datos se ejecutan en un ordenador con ausencia total de comunicación con otros programas u otros datos)

2. Se comparten sólo los datos y no los programas (en tal caso existe una réplica de las aplicaciones en cada máquina y los datos viajan por la red).

3. Se comparten datos y programas (dado un programa ubicado en un determinado sitio, éste puede solicitar un servicio a otro programa localizado en un segundo lugar, el cual podrá acceder a los datos situados en un tercer emplazamiento. Como se comentó líneas atrás, en este caso se optará por el punto intermedio de compartimentación.)

(15)

Figura 1.1 Enfoque de la distribución.

Respecto a las características de acceso a los datos existen dos alternativas principalmente: puede ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico. Se puede comprender fácilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, en cuántas variaciones sufre a lo largo del tiempo. Esta dimensión establece la relación entre el diseño de Bases de Datos Distribuidas y el procesamiento de consultas.

El problema del diseño de Bases de Datos Distribuidas podría enfocarse a través de esta trama de opciones. En todos los casos, excepto aquel en el que no existe compartimentación, aparecerá una serie de nuevos problemas que son irrelevantes en el caso centralizado.

A la hora de abordar el diseño de una base de datos distribuida se puede optar, principalmente, por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. Ambos tipos no son excluyentes, y no resultaría extraño a la hora de realizar un trabajo real de diseño de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. La estrategia ascendente podría aplicarse en aquel caso en el que haya que proceder a un diseño a partir de un número de pequeñas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partiría de los esquemas conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual global. Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso en el que se parte de cero y se avanza en el desarrollo del trabajo siguiendo la estrategia descendente.

(16)

Incluir en los Sistemas de Bases de Datos todas las funcionalidades es una tarea compleja, pero lo es más encontrar soluciones óptimas. Nuevas retos se crean al considerar el diseño de la distribución de Sistemas de Bases de Datos, el decidir cómo fragmentar y distribuir los datos sobre los diferentes sitios y cuáles de estos datos deben ser replicados.

En un primer momento las entidades de la relación global se dividen en subconjuntos llamados fragmentos; y en un segundo momento los fragmentos son localizados (con o sin réplica) en los diferentes sitios distribuidos. Esta distribución de datos es una cualidad deseable porque permite al administrador desplegar los datos en los sitios particulares donde serán más frecuentemente usados, con lo cual se incrementa la localidad de referencia y se reduce drásticamente el tráfico en la red.

Asumiendo que la Base de Datos es adecuadamente fragmentada, entonces se decide sobre la ubicación de los fragmentos en los diferentes sitios de la red. Cuando los datos son ubicados, éstos pueden estar replicados o mantenidos como una sola copia. Las razones para la replicación son la disponibilidad y la eficiencia de las solicitudes de sólo lectura. Si existen múltiples copias de un artículo de datos, habrá una mayor probabilidad de que alguna copia de los datos esté accesible en algún lugar, incluso si ocurriera una falla en el sistema. Mejor aún, las solicitudes de sólo lectura que acceden a los mismos artículos de datos, pueden ser ejecutadas en paralelo ya que las copias existen en múltiples sitios. Por otra parte, la ejecución de solicitudes de actualización causa problemas, ya que el sistema tiene que asegurar que todas las copias de los datos sean propiamente actualizadas. De aquí, que la decisión en relación con la replicación es una cuestión que depende de la proporción de las solicitudes de sólo lectura con respecto a las solicitudes de actualización. Esta decisión afecta a casi todos los algoritmos del Sistema Manejador de Bases de Datos Distribuidas y a las funciones de control. En este caso se considerará que se tiene instalado un SMBDD en cada servidor en los que se deseen almacenar los datos, que garantice prestaciones adicionales como:

• Posibilidad de acceder a sitios remotos y transmitir solicitudes y datos entre varios sitios en la red de comunicación.

• Posibilidad de trazar estrategias de ejecución para solicitudes y transacciones que acceden a datos en más de un sitio

(17)

• Posibilidad para mantener la consistencia de las copias de datos replicados.

• Posibilidad para recuperarse de fallas individuales en los sitios o en los enlaces de comunicación.

El resultado primordial del proceso de diseño de un sistema de base de datos distribuido es la fragmentación y su posterior distribución óptima en los diferentes sitios de la red, que es el soporte físico sobre el que se implementan las arquitecturas multiusuario.

1.2 De las redes de computadoras.

El concepto de redes que se maneja es el de colección interconectada de estaciones autónomas. Se dice que dos ordenadores están conectados si estos son capaces de intercambiar información. Al indicar que los ordenadores son autónomos, se excluye de esta relación a todos los sistemas organizados sobre la arquitectura cliente/servidor, ya que un sistema constituido por una unidad central de control y varios clientes no es una red.

En una forma más general, el tema aquí consiste en compartir recursos, y el objetivo es hacer que todos los programas, datos y equipos estén disponibles para cualquiera en la red que así los solicite, sin importar la localización física del recurso ni del usuario. En otras palabras, el hecho de que un usuario se encuentre a 1000 Km. de distancia de los datos, no debe evitar que éste los pueda utilizar como si fueran originados localmente.

Otro objetivo de las redes de computadoras consiste en proporcionar una alta fidelidad, al poder contarse con fuentes alternativas de información. Por ejemplo, todos los archivos podrían duplicarse en dos o tres máquinas, de tal manera que si una de ellas no se encuentra disponible, podría utilizarse alguna de las otras copias. Además, la presencia de múltiples procesadores significa que si una deja de funcionar, las otras pueden encargarse de su trabajo, aunque se tenga un rendimiento global menor. Para aplicaciones militares, bancarias, de control de tráfico aéreo y muchas otras es indispensable la capacidad de los sistemas de continuar funcionando a pesar de existir problemas de disponibilidad.

Un aspecto de importancia y en el que se vierte el interés de las redes de computadoras es en el renglón económico. Las estaciones pequeñas tienen una mejor relación costo/rendimiento, comparada con la ofrecida por máquinas grandes. En muchos casos, las máquinas grandes son

(18)

diez veces más rápidas que el más rápido de los microprocesadores, pero su costo es miles de veces mayor. Este equilibrio ha determinado que muchos desarrolladores de sistemas construyan sistemas constituidos por poderosos procesadores personales.

La mayoría de las redes están organizadas en una serie de capas o niveles con el objetivo de reducir la complejidad de su diseño. Cada una de ellas se construye sobre su predecesora. El número de capas, el nombre, contenido y función de cada una varían de una red a otra. Pero, independientemente de esto, el propósito de cada capa es el de ofrecer ciertos servicios a las capas superiores de tal manera que entre cualquier par de capas se define una interfaz, la que aglutina servicios y funcionalidades que la capa anterior le brinda a la superior. Al conjunto de capas e interfaces de una red de computadoras se le denomina arquitectura de la red.

Independientemente de su arquitectura, cada red de comunicación deberá asegurar ciertas funcionalidades de manera global. Se necesita definir un medio a través del cual un proceso defina con quién desea establecer conexión, así como de un mecanismo para terminarla. Otro conjunto de funcionalidades que deben quedar definidas son las referidas a la transferencia de datos: determinar el número de canales lógicos que corresponde a una conexión y cuales son sus prioridades; la detección y recuperación de errores de transmisión y los controles de flujo de sincronización, entre otras.

Es fundamental detenerse alrededor de las especificaciones básicas de transferencia de datos, a fin de aclarar ciertos conceptos usados a continuación. En algunos sistemas, los datos viajan en una sola dirección (comunicación unilateral o simplex); en otros, los datos pueden viajar en ambas direcciones, aunque no en forma simultánea (comunicación semidúplex o bilateral alternada). Existen también otros sistemas en los que los datos viajan a la vez y en ambas direcciones (comunicación dúplex o bilateral simultánea). Un número considerable de redes posee, al menos, dos canales lógicos por conexión: uno para datos normales y otro para datos urgentes.

Otra de las complejidades propias de las redes es lo referente a los enrutamientos. Siempre que existan varios caminos entre la fuente y el destino se tienen que tomar decisiones de encaminamiento, lo cual implica un gasto adicional de procesamiento a nivel de los sitios. Algunas veces estas decisiones deben tomarse en dos o más capas. Por ejemplo, para enviar

(19)

datos desde Amberes a Luxemburgo debe, presuntamente, tomarse una decisión importante para saber si se opta por ir a través de Francia o Alemania, basándose, por ejemplo, en sus respectivas leyes de privacidad; en tanto que, por otra parte, se podría tomar una decisión de menor importancia que permitiera escoger alguno de los circuitos disponibles de acuerdo con el tráfico real.

1.3 De la unión de las redes y las Bases de Datos.

Como se ha podido apreciar son muchos los puntos de coincidencia entre los objetivos que animan a los Sistemas de Bases de Datos Distribuidas y a las redes de computadoras. Estas semejanzas están basadas en un conjunto de problemáticas comunes que deben enfrentar en su gestión de comunicación, así como en la proyección de sus objetivos.

Existe confusión en la literatura entre una red y un sistema distribuido, la clave de la diferencia radica en que en un sistema distribuido la existencia de múltiples estaciones es transparente al usuario, él puede teclear un comando (ejecutar un proceso o una solicitud) y constatar que se ejecuta, pero el hecho de seleccionar el mejor procesador, encontrar y transportar los datos de entrada al procesador y poner los resultados en el lugar apropiado, dependen, íntegramente, del sistema operativo.

Con una red, el usuario debe, explícitamente, iniciar una sesión en una estación, acceder a ficheros remotos, mover archivos y por lo general, gestionar de maneras personal toda la administración de la red. A partir de estos razonamientos, un sistema distribuido es un caso especial de red, donde el software brinda un alto grado de cohesión y transparencia.

1.4 Parámetros de desempeño.

En el diseño óptimo de distribución influyen muchos factores: la organización lógica de la Base de Datos, la ubicación de las aplicaciones, las características de acceso de las aplicaciones a la Base de Datos y las propiedades de los sistemas de computación en cada sitio; todas tienen influencia sobre la decisiones de distribución. Esto hace que sea muy complicada la formulación de un problema de distribución.

(20)

La información que se necesita para el diseño de distribución puede estar dividida en cuatro categorías: información sobre la Base de Datos, información sobre las aplicaciones, información sobre la comunicación de la red e información sobre el sistema de las computadoras. Las últimas dos categorías son completamente cuantitativas en cuanto a su naturaleza y son usadas en los modelos de ubicación y no en los algoritmos de fragmentación. El concepto de optimalidad que se usa durante el proceso de distribución y localización de fragmentos hace necesario el manejo y medición de alguno de los parámetros que caracterizan las redes de computadoras, ya que de su control y conocimiento depende, en gran medida, el buen desempeño del sistema que se está diseñando.

Para simplificar, se define una red de computadoras como un grafo orientado, donde cada uno de los nodos corresponde a un sitio de procesamiento y cada arco, a una línea de comunicación. Sería muy acertado etiquetar los caminos sobre la base de algunos factores que midan el desempeño de la red, estos podrían ser: distancia geográfica, ancho de banda, promedio de tráfico, costo de comunicación, longitud promedio de la cola de espera, tiempo de retardo medido, entre otros.

También se hace necesario analizar otros factores, ya no directamente relacionados con las redes de computadoras, pero de igual importancia durante el proceso de diseño de Sistemas de Bases de Datos Distribuidas. Estos parámetros son los relacionados con los propios sitios de procesamiento: la capacidad de procesamiento, el tiempo de acceso de lectura y escritura en disco, la velocidad del procesador, el espacio libre en disco, etc.

Dichos parámetros determinan, y en cierta medida caracterizan, una red de computadoras sobre la cual, en definitiva, va a estar implementado el sistema de gestión de Bases de Datos Distribuidas. Según la combinación de estos factores un sitio es más conveniente que otro para recibir determinado fragmento.

1.5 Tecnologías para la comunicación remota.

La gran cantidad de aplicaciones distribuidas en la actualidad sólo han sido posibles debido a la evolución constante de tecnologías remotas. La realización de aplicaciones comerciales de alguna manera distribuida fue posible sólo después que se solucionarán algunos problemas

(21)

técnicos de estas tecnologías. CORBA, COM+, y EJB comenzaron este proceso hace varios años, el cual se vio simplificado con la aparición de .Net Remoto.

1.5.1 DCE/RPC.

DCE (Distributed Computing Enviroment), diseñado por la OSF (Open Software Foundation) durante principios de los años 90 del siglo XX, fue creado para proporcionar una colección de herramientas y servicios que permitirían un desarrollo más fácil de aplicaciones distribuidas. El framework DCE proporciona varios servicios base como Llamadas a Procedimientos Remotos (DCE/RPC Remote Procedure Calls), Servicios de Seguridad, Servicios de Tiempo, etcétera.

La implementación DCE es una tarea desalentadora; las interfaces tienen que ser especificadas en IDL (Interface Definition Language) y compiladas por un compilador IDL. Al implementar el servidor, se tiene que conectar el binario con Hilos/DCE, los cuales están disponibles sólo para C/C++. El uso de otros lenguajes de programación está algo restringido debido a la dependencia en los servicios bases, como Hilos/DCE, con la consecuencia de que no se puede usar servidores multihilos si se usa C/C ++.

El DCE/RPC, sin embargo, es la base para muchos protocolos de alto nivel como DCOM y COM+. Varios protocolos del nivel de aplicación como el SMB (Server Message Block) están también basados en DCE/RPC.

1.5.2 CORBA.

CORBA (Common Object Request Broker Arquitecture), diseñado por el OMG (Object

Management Group), un consorcio internacional de aproximadamente 800 compañías, tiene el

objetivo de ser el software intermedio para comunicar sistemas heterogéneos; es sólo una colección de estándares. La implementación de agentes de solicitud de objetos (ORBs) es hecha por terceras partes. Dado que algunas partes del estándar son opcionales y a los programadores de agentes ORB se les permite incluir rasgos adicionales que no están en las especificaciones, es fácil encontrase con agentes incompatibles. Cuando se compra una

(22)

aplicación basada en los estándares CORBA, no se puede estar seguros de que se integrará a las aplicaciones CORBA, que probablemente fueron desarrolladas para un agente diferente. Aparte de este problema potencial, CORBA tiene además una curva de aprendizaje muy pronunciada. El estándar es como una lista de todo lo que es posible con componentes remotos, que a veces es demasiado extensa. Probablemente se termine leyendo documentos durante días o semanas antes de que la primera petición sea enviada a un objeto servidor. Sin embargo, cuando se logre implementar la primera aplicación CORBA, se podrá integrar muchos lenguajes de programación y plataformas. Existen capas hasta para la integración de COM o EJB. Aparte de SOAP, CORBA es el único ambiente multiplataforma para aplicaciones distribuidas.

1.5.3 DCOM.

DCOM (Distributed Component Object Model) es una "extensión" que se ajusta a la arquitectura COM (Component Object Model), el cual es un estándar binario de interoperabilidad que permite el desarrollo de aplicaciones orientado a componente.

DCOM permite la distribución de componentes entre computadoras diferentes. La escalabilidad, la manejabilidad y su uso en las redes WAN plantean varias cuestiones que tienen que ser manejadas. DCOM usa un proceso de ping para controlar las vidas de sus objetos; todos los clientes que usan un objeto servidor enviarán mensajes después de ciertos intervalos. Cuando un servidor recibe estos mensajes sabe que el cliente está todavía disponible; en otro caso destruirá el objeto remoto.

Además, los requerimientos del protocolo binario DCE/RPC plantean la necesidad de conexiones TCP (Transfer Control Protocol) directas entre el cliente y su servidor. DCOM solo está disponible para Microsoft Windows y para algunas implementaciones de UNIX.

1.5.4 MTS/COM+.

COM+, anteriormente MTS (Microsoft Transaction Server), fue el primer intento serio de Microsoft de entrar en el mundo de las aplicaciones corporativas. COM+ no sólo sirvió como

(23)

una plataforma remota, sino que también proporcionó transacción, seguridad, escalabilidad, y un amplio despliegue de servicios.

A pesar de sus ventajas, COM+ no soporta todavía el ordenamiento automático de objetos pasados por valor entre aplicaciones; sino que se tienen que pasar las estructuras de datos usando recordsets de ADO (ActiveX Data Objects) o algún otro medio de serialización. Otra desventaja que impide el amplio uso de COM+ es su difícil configuración y desarrollo, lo que complica su uso para aplicaciones reales.

1.5.5 Java RMI.

Java RMI (Remote Method Invocation) usa un ciclo manual de compilaciones de esqueletos (stub). A diferencia de DCE/RPC y DCOM, las interfaces no son escritas en IDL abstracto, sino en Java. Esto es posible debido a que Java es el único lenguaje que implementa RMI. Esta limitación dejó a RMI fuera del juego de la integración de aplicaciones corporativas. Incluso aunque todas las plataformas relevantes soporten una Maquina Virtual de Java, la integración de aplicaciones de herencia no se hace fácilmente.

1.5.6 Java EJB.

EJB (Enterprise Java Beans) fue la respuesta de Sun Microsystems a COM+ de Microsoft. A diferencia de CORBA, que es sólo un estándar, EJB vino con referencias de implementación. Esto le permitió a los desarrolladores comprobar si sus productos se ejecutaban en paquetes EJB que se ajustaban al estándar. EJB ha sido extensamente aceptado por la industria, y existen varias implementaciones que van desde código abierto (opensource) hasta implementaciones comerciales hechas por conocidos productores de software.

Uno de los problemas EJB es que aunque exista una referencia de implementación, la mayor parte de productores de software añade nuevas características a sus servidores de aplicación. Cuando un desarrollador escribe un componente que usa una de esas características, la aplicación no se ejecutará en el paquete EJB de otro productor.

(24)

Las antiguas versiones de EJB están limitadas a la plataforma Java debido a su dependencia con RMI. Las versiones actuales permiten el uso de HOP, que es el mismo protocolo de transferencia que usa CORBA, y algunos productores ya brindan enlaces COM/EJB con propósitos comerciales.

1.5.7 Servicios WEB/SOAP/XML-RPC.

Los Servicios Web proporcionaron una forma fácil para entender e implementar soluciones realmente multiplataformas y multilenguajes. Un Servicio Web es, técnicamente, llamadas a componentes remotos vía HTTP POST con una carga útil codificada en algún formato de XML (Extensible Markup Language).

Actualmente están en uso dos codificaciones diferentes de XML: XML-RPC y SOAP. El XML-RPC define un protocolo muy ligero con un tamaño de especificación de aproximadamente cinco páginas impresas. Están disponibles implementaciones para muchos ambientes de programación, desde AppleScript a C/C ++, COM, Java, Perl, PHP, Pitón, Tcl, y Zope, y por supuesto también para .Net.

SOAP (Simple Object Access Protocol), define un conjunto mucho más rico de servicios; la especificación cubre no solo llamadas a procedimientos remotos, sino también el Lenguaje de Descripción de Servicios Web (WSDL Web Service Description Languaje) y Descripción Universal, Descubrimiento, e Integración (UDDI Universal Description, Discovery, and

Integration). El WSDL es la lengua de definición de interfaz del SOAP, y UDDI sirve como

un servicio de directorio para el descubrimiento de Servicios Web. Estos protocolos adicionales y especificaciones están también basados en XML, lo que permite que todas las características de SOAP estén disponibles en muchas plataformas.

1.5.8 .Net Remoto.

Como se ha visto, existen varias arquitecturas diferentes para el desarrollo de aplicaciones distribuidas. Puede preguntarse entonces, por qué .Net introduce otra forma bastante diferente para desarrollar este tipo de aplicaciones. Una de las ventajas principales de .Net Remoto es

(25)

que se centra alrededor de estándares bien conocidos y definidos como HTTP (Hipertext

Transfer Protocol) y SOAP.

Con .Net el concepto de facilidad de implementación ha sido ampliado al desarrollo de aplicaciones distribuidas. No hay ciclos de compilaciones como en Java RMI. No se tienen que definir las interfaces en un lenguaje abstracto como en CORBA o DCOM. Una característica única es que se tiene que decidir el formato de codificación de las peticiones remotas; en cambio, se puede cambiar de un formato binario rápido a SOAP, cambiando solo una palabra en un archivo de configuración. Se puede proporcionar incluso, ambos canales de comunicación para los mismos objetos añadiendo otra línea a la configuración. No se está atado a una plataforma ni a un lenguaje de programación como con DCOM, COM+, o Java EJB. La configuración y el desarrollo es mucho más fácil que como era en DCOM.

1.6 Antecedentes.

Se conoce de las investigaciones del mexicano Rodolfo A. Pazos acerca de las bases de datos distribuidas, en especial su trabajo: “Fragmentación, Ubicación y Reubicación Dinámica de Datos en Bases de Datos Distribuidas”, en el año 1997. El asistente que se presenta es aparentemente inédito, ya que no se ha encontrado referencia alguna en la bibliografía revisada.

Este trabajo tiene como antecedente una primera versión (López, 2001) en la cual se usó como soporte principal una arquitectura cliente-servidor, basada, fundamentalmente, en la tecnología distribuida DCOM. Esta versión anterior se implementó sobre la plataforma Delphi de Borland y no fue totalmente funcional. En la versión actual se decidió migrar a .Net de Microsoft debido a las grandes facilidades de programación que esta tecnología brinda y a las ventajas de .Net Remoto sobre DCOM, entre las que se pueden mencionar las siguientes:

• .Net Remoto utiliza estándares muy bien establecidos como SOAP para mensajería y HTTP y TCP como protocolo de comunicación, eliminando así las dificultades que tiene DCOM para atravesar firewalls.

• .Net Remoto es más flexible y más personalizable, permitiendo definir nuevos formateadotes y canales de comunicación.

(26)

• No necesita definir las interfaces en un lenguaje abstracto.

• .Net Remoto oculta todos los detalles de implementación del trabajo con sockets, entregando al programador final una interfaz de programación que se distingue por las facilidades de uso y su potente alcance.

1.7 Conclusiones parciales

En este capítulo se analizó lo referente a las bases de datos distribuidas y su relación con las redes de computadoras. También se realizó un estudio de la evolución de las tecnologías distribuidas desde las más sencillas hasta las más novedosas, escogiéndose .Net remoto como vía de comunicación de la aplicación propuesta.

En el siguiente capítulo se profundizará en las tecnologías utilizadas en la elaboración de la aplicación.

(27)

Referencias bibliográficas.

LÓPEZ, Á. V. (2001) NetWizard. Asistente para la caracterización de sitios de procesamiento. Departamento de Ciencia de la Computación. Facultad MFC. Villa Clara. Cuba, UCLV.

ÖSZU, M. T. & VALDURIEZ, P. (1999) Principles Of Distributed Database Systems, Prentice-Hall.

(28)

CAPÍTULO 2. TECNOLOGÍAS UTILIZADAS

En este capítulo se expone el modelo distribuido con el que se trabajó y se verán algunas de las especificaciones de .Net Remoto, sucesor en el mundo .Net de la tecnología DCOM de Microsoft, así como una descripción de WMI, tecnología utilizada para captar la información necesaria de cada sitio de procesamiento.

A grandes rasgos, la tecnología que se describe en este capítulo, fue la utilizada para la creación de objetos remotos a través de la red con el objetivo de lograr la comunicación entre los servidores y el cliente para almacenar los datos que describen la red de computadoras, así como para la gestión de los tiempos de comunicación entre las estaciones escogidas.

2.1 Introducción a .Net Remoto.

.Net Remoto es la tecnología elegida por los programadores .Net para hacer llamadas a objetos remotos desde sus aplicaciones .Net. ¿Qué es exactamente una llamada a un objeto remoto? Una llamada remota es una petición enviada a una interfaz de un objeto fuera del proceso en que este se encuentra. Este objeto remoto estaría en la misma máquina o en una máquina separada. Cuando el objeto que está siendo llamado no está en el mismo proceso que el que está llamándolo, los datos que se intercambian entre estos dos objetos deben ir a través de un proceso especial de orden o de paquete para transferir entre los procesos. Sus llamadas a la interfaz no utilizarán .Net Remoto cuando el objeto que está siendo llamado está en el mismo proceso o dominio de la aplicación que el que está llamando. Se puede considerar que las llamadas remotas son como tener que atravesar un portador de teléfono a grandes distancias, y hacer llamadas en el mismo proceso como usar un portador telefónico local. Éstas son llamadas a larga distancia que pueden realmente ejecutarse con la cuenta telefónica local (Vitter and Templeman, 2002).

Los programadores con experiencia en DCOM deben encontrar a .Net Remoto un poco más fácil para trabajar con él, aunque aquellos programadores que son nuevos en las comunicaciones con objetos distribuidos pueden encontrarse que aún con .Net Remoto este

(29)

proceso es complicado. Probablemente las mejores noticias de todas, cuando hablaron sobre .Net Remoto, es que se aprovecharían las tecnologías opensource tales como SOAP y HTTP para hacer las llamadas de objeto a objeto. Este cambio de protocolo no derriba el muro que previamente separaba los componentes de la aplicación Visual Studio desde componentes que no sean de Microsoft, aunque también extiende la obtención de sus llamadas a objetos más allá de sus límites previos. En la siguiente sección se discutirán algunos conceptos de alto nivel en los cuales se basa .Net Remoto.

2.1.1 Clientes y servidores remotos.

Cuando un objeto llama a otro objeto, el que hace la llamada inicial se llama objeto cliente. El que responde y proporciona alguna función o datos de retorno se llama objeto servidor. La conexión que se forma entre estos dos objetos se llama canal; se examinarán estos objetos más adelante. Antes de entrar en los detalles de cómo se comunican estos objetos, es importante establecer los roles correspondientes a cada uno de ellos.

Durante una llamada sencilla, sólo un objeto puede ser el cliente y el otro puede ser el servidor. Éste es un concepto sencillo, aunque crítico, que es necesario entender cuando está desarrollando objetos para usarlos con .Net Remoto. Es posible crear un objeto que permita actuar como ambos, como un servidor de otros objetos y como un cliente que llama a otro objeto servidor.

Un objeto, en un proceso de un dominio de una aplicación, se puede poner como remoto o no. Un objeto no se puede poner remoto cuando no se puede llamar a un objeto fuera de su dominio de la aplicación. Dependiendo de las necesidades del diseño puede elegir hacer que pueda ser remoto, haciéndolo disponible sólo para una aplicación simple. Las clases base en la plataforma .Net serán por defecto no remotas, aunque se pueden derivar clases desde las clases base que sí lo puedan ser.

(30)

Los objetos servidor son un poco más difíciles de crear que los objetos cliente, así que una vez que obtenga la clave de cómo se crea un objeto servidor, el resto de .Net Remoto es sencillo. Un objeto servidor no es parte de la aplicación del objeto cliente, incluso, aunque las llamadas del objeto cliente al objeto servidor sean para ayuda. El objeto servidor está en su propio dominio de aplicación, normalmente, en una máquina diferente que el objeto cliente. Su equipo de desarrollo podría tener una mano en el desarrollo del objeto servidor, o su aplicación podría llamar a un objeto servidor desde una fuente exterior (también conocidas como “cajas negras” ya que no conoce qué hay dentro de esos objetos). En muchas circunstancias, el objeto servidor no se ejecutará cuando el objeto cliente haga una llamada, así que el objeto necesitará inicializarse y conectarse al canal remoto. Como los objetos servidor son muy complicados, necesitan una gran cantidad de ideas para su desarrollo y configuración.

Aplicaciones Host

Un objeto servidor debe escuchar activamente las peticiones de los objetos cliente. Estos se crearán normalmente en proyectos de la clase Library, que no son capaces de estar activos y escuchar un puerto en una máquina host por sí mismos. En MTS y COM+ existía la posibilidad de registrar la clase Libraries dentro de un paquete MTS que manejaba la labor de escucha. Para un objeto servidor .Net, se necesita crear una aplicación que actúe como el oyente y el agente para su objeto servidor. Esta aplicación se cargará en el servidor host y se quedará activa para mostrar los canales registrados. Si la aplicación host del objeto servidor se cierra, el objeto servidor no será accesible a sus clientes.

Se puede alojar un objeto servidor desde muy diferentes tipos de aplicaciones, incluidos servicios Windows o un proyecto de consola. En la mayoría de los casos, hacer que la aplicación se aloje en un servicio Windows, que se carga cuando el servidor arranca, es la mejor solución. Los servicios Windows están estrechamente vinculados con el sistema operativo, pueden comenzar automáticamente y pueden operar detrás del escenario sin abrir formularios o ventanas.

Cuando se inicia la aplicación host, registra el canal y el objeto servidor con la plataforma .Net. Una vez que el objeto servidor se ha inicializado, la aplicación host escucha las

(31)

peticiones del cliente en el canal registrado. Cuando se recibe una petición, la aplicación host carga el objeto servidor en su dominio de aplicación y pasa la llamada del cliente al servicio. En la figura 2.1, se ve una aplicación host y un proyecto de la clase Library que contiene un objeto servidor. Ambas aplicaciones se ejecutan en el mismo proceso aplicación.

Figura 2.1 Las aplicaciones host y objeto servidor

Vale recordar que ésta es la aplicación host que registra el canal y configura el medio remoto mediante programación o a través del uso de un archivo de configuración externa. La clase Library, que contiene el objeto servidor actual, puede permanecer inactiva y quieta hasta que la llame un cliente. Si la clase que contiene el servidor no está contenida en la aplicación host, esa aplicación necesitará una referencia a la clase para que pueda cargarla cuando necesite. Cuando se llame al objeto servidor, se cargará en el dominio de la aplicación host y se procesará.

Clientes Remotos

El objeto cliente es el receptor en una transacción cliente-servidor. Un cliente no tiene ningún control sobre cómo trabaja el objeto servidor o cómo hace su trabajo. Sólo tiene la posibilidad de preguntar algo y esperar obtener los resultados esperados. Para usar un objeto servidor, el objeto cliente debe tener una comprensión de la interfaz del objeto servidor y de cómo el objeto servidor se comunica con el mundo exterior. Obtener el código fuente del objeto servidor o una descripción detallada de la configuración de sus interfaces y de su canal es un primer paso crucial para usar este objeto. Por supuesto, si su equipo de desarrolladores creó el

(32)

objeto servidor, esta información es fácil de obtener. Pero si está trabajando con un objeto de una tercera parte, el trabajo puede ser un poco más costoso (Vitter and Templeman, 2002). Cuando un objeto cliente necesita trabajar con un objeto servidor, este objeto cliente necesita configurar un canal de comunicación para utilizar su llamada. Si el objeto servidor está usando la activación simple o llamada única, el objeto cliente no tiene control sobre el intervalo de tiempo de ese objeto servidor (véase Activación y Tiempo de Vida). Si el servidor permite CAO (Client-Activated Objects), el cliente tendrá alguna configuración adicional para hacer el control del tiempo de vida del objeto servidor.

Llamando a un servidor remoto

Desde la perspectiva del objeto cliente, hay dos formas de llamar a un objeto servidor: usando la activación del lado del servidor remota y utilizando la activación del lado del cliente. No hay diferencia entre objetos servidores de activación simple y llamada única desde el punto de vista del objeto cliente. En las próximas dos secciones se discuten los dos modos en que los objetos cliente pueden llamar a los objetos servidor remotos y se explica cómo estos pueden trabajar usando los archivos externos de configuración del objeto cliente y los comandos de configuración programada.

2.1.2 Activación y tiempo de vida.

Cuando un objeto de una aplicación cliente llama a un objeto servidor, el objeto servidor debe estar activado para responder a las peticiones. El comienzo de un objeto en el lado del servidor se llama activación y, el tiempo que el objeto está activo se llama tiempo de vida del objeto. En .Net Remoto, hay tres métodos de activación, cada uno de los cuales tienen sus tiempos de vida. Ellos son:

• Llamada única. • Activación simple. • CAO.

(33)

Llamada única (Singlecall)

Un objeto se dice que tiene una activación de llamada única cuando una copia de ese objeto se activa por cada petición del cliente. Si simultáneamente cuatro objetos cliente hacen la misma petición al mismo objeto del lado del servidor, se crearán cuatro instancias de ese objeto para manejar esas cuatro llamadas. Una llamada única desde un cliente da por resultado uno nuevo, haciendo que se cree un objeto en el lado del servidor. El tiempo de vida de un objeto con llamada única es el suficiente para satisfacer la llamada del objeto cliente.

Si el cliente hace una segunda llamada al objeto servidor, se creará completamente una nueva petición del objeto del lado del servidor para manejar la llamada. Con el recolector de basura decidiendo cuándo eliminar las peticiones del objeto desde la memoria en .Net, es posible, para un objeto de llamada única estar en la memoria del servidor cuando llegue la segunda llamada desde el mismo objeto cliente. Un objeto de llamada única creará una nueva instancia para responder a la nueva petición del cliente.

Activación simple (Singleton)

Cuando un servidor utiliza una activación simple, sólo se activará una petición de ese objeto en el servidor. Si esos mismos cuatro objetos clientes utilizados en el ejemplo anterior, hacen una llamada a un objeto del lado del servidor Singleton, uno, y sólo un objeto, se creará para servir a los cuatro objetos clientes requeridos. En la primera llamada cliente, el servidor creará una petición simple del objeto servidor Singleton. Tan pronto como el primer objeto Singleton se cargue en memoria, todas las llamadas a objetos adicionales se conectarán a este objeto activo.

Un objeto Singleton tiene un tiempo de vida limitado y, cuando expira, la petición actual del objeto se destruye, necesitando que el servidor cree una nueva petición para la próxima llamada cliente. Por esta razón, su objeto cliente podría hacer múltiples llamadas a objetos servidor que usen la misma petición del objeto Singleton y, a continuación, hacer otra llamada y, de repente, encontrar una nueva petición de ese objeto.

(34)

Cada objeto Singleton tiene un tiempo de vida que dicta que la vida de ese objeto se va a acabar. De hecho, este período de vida es tan estricto que si un objeto cliente está utilizando el objeto servidor en el mismo momento en que este objeto Singleton alcanza su tiempo de vida, éste se destruye (y se reemplaza por su versión más actual).

Objetos activados por los clientes (CAO)

La activación, tiempo de vida y desactivación de los objetos de llamada única y de activación simple se controlan por el servidor que hospeda a estos objetos. Al trabajar con objetos de llamada única y de activación simple se necesita pensar un poco más que al tratar con objetos locales que su aplicación activa y desactiva directamente. Con los objetos activados por los clientes (CAO), sus objetos cliente pueden tener la misma influencia en objetos remotos como tiene en objetos locales. Al igual que los objetos de llamada única, el servidor crea una nueva petición del objeto servidor para cada cliente que lo llame a través de CAO. Cada petición del objeto servidor creada soportará una referencia directa al cliente que llama, y su tiempo de vida se controla por ese objeto cliente.

Cuando mira el tiempo de vida de un CAO, encontrará un tiempo de vida similar al de los objetos Singleton. La gran diferencia con el tiempo de vida del CAO es que el cliente define y controla ese intervalo, no el objeto servidor.

Objetos sin estado frente a objetos con estado

Un objeto sin estado no mantiene el estado de una llamada a la siguiente. Cada vez que llama a un objeto sin estado, es como hablar con un extraño que no recuerda nada sobre su última llamada. A consecuencia de que el método de activación de llamada única conecta el objeto cliente a una nueva petición del objeto servidor cada vez, esto es una forma sin estado de .Net Remoto. El método de activación simple continúa para conectar llamadas cliente a la misma petición de un objeto servidor hasta que expire el tiempo de vida del objeto. Esto significa que el objeto de activación simple puede recordar partes de información de una llamada a la siguiente. El CAO también es un método de comunicaciones con estado porque la misma petición del objeto servidor está activa hasta que el objeto cliente decide liberarla.

(35)

2.1.3 Canales.

Cuando un objeto cliente y uno servidor se conectan, crean un canal de comunicaciones entre ellos. DCOM también crea un canal entre objetos y usa un protocolo propio para intercambiar mensajes entre los dos objetos. .Net Remoto tiene la posibilidad de crear y utilizar dos tipos de canales diferentes para sus objetos cliente y servidor: el canal TCP y el canal HTTP. El canal TCP es muy parecido al predecesor de .Net Remoto, DCOM. El canal HTTP concuerda con el tema de fuente recurrente abierta de .Net. El canal a utilizar depende del objetivo de la comunicación. Se revisarán los dos tipos de canales de .Net Remoto y se discutirá cuándo se debería utilizar un tipo determinado de canal.

El canal TCP

Similar al método de transmisión propio de DCOM, el canal TCP de .Net Remoto envía los datos entre los objetos cliente y servidor usando un formato binario propio. Los objetos finales en un canal TCP deben permitir entender este mensaje en formato binario, lo que significa que sólo debería pensar en utilizar el canal TCP para comunicarse entre objetos .Net.

El canal TCP es bidireccional, es decir, que sus objetos pueden enviar y recibir datos a través de este canal. Desafortunadamente, aparte del hecho de que los mensajes que se están intercambiando sobre un canal TCP son codificados en binario, no puede encriptar sus comunicaciones TCP. Despreciando esta limitación, cuando se compara con el canal HTTP, el canal TCP es el canal remoto más rápido y el más eficiente que puede utilizar.

El canal HTTP

SOAP es una herramienta que permite a las aplicaciones enviar sus llamadas objeto a objeto a través de Internet usando el protocolo de transmisión HTTP. Las llamadas HTTP van tradicionalmente por el puerto 80 de los ordenadores, que es el mismo puerto usado para las peticiones y respuestas del navegador estándar Web. Debido a que SOAP le permite enviar sus peticiones de objetos a través de este puerto aceptado universalmente, sus llamadas pueden

(36)

pasar a través de muchos firewalls. Esta posibilidad de pasar a través de firewalls le da al canal HTTP una mayor libertad que el canal TCP, más restrictivo, y que al antiguo método DCOM. Como al canal TCP, el canal HTTP permite el tráfico de mensajes en ambas direcciones. SOAP se basa en la tecnología XML, lo que significa que el mensaje y su entorno cerrado se auto describen y pueden leerse y crearse por otra aplicación. Debido a esto, los objetos cliente y servidor involucrados en un escenario .Net Remoto que utilicen el canal HTTP no tienen que ser creados en .Net. Como se precisó en la descripción del canal TCP, no se cuanta con este tipo de libertades cuando conecta objetos a través del canal TCP, porque un objeto que usa este canal debe ser capaz de entender su formato propio de mensajes binarios. Como consecuencia del formato de texto XML del canal HTTP y al hecho de que utiliza el popular y a veces ocupado puerto 80, el canal HTTP es un poco menos eficiente que el canal TCP.

Registrando un canal

Antes de que un objeto cliente y servidor se puedan comunicar a través de un canal, se debe configurar dicho canal y registrarlo con el servidor. El objeto cliente registrará un canal en la máquina que llama y el objeto servidor tendrá un canal registrado para escuchar las peticiones de los clientes. Dado que un objeto servidor puede tener configurados múltiples canales que escuchen, el desarrollador del objeto cliente debe conocer qué tipo de canal se está usando para configurar y registrar el canal del cliente apropiadamente.

Los canales se pueden crear al vuelo con el código de su aplicación o puede utilizar un canal predefinido que use una plantilla de canal o archivos de configuración. Las plantillas de canales son archivos de configuración externos que se pueden abrir en la aplicación al comienzo y ahorrar un gran esfuerzo en el código.

2.1.4 Sumideros.

Una cadena de sumideros de comunicaciones es el punto de entrada y salida que los mensajes usan cuando entran o abandonan un dominio de una aplicación particular. En esta cadena son múltiples los sumideros, cada uno de ellos con su función propia. Un sumidero maneja el

(37)

formato del mensaje preparándolo para su transmisión, mientras otro maneja la tarea de transmitir ese mensaje con formato a través de la red. En recepción, otro sumidero recibe el mensaje de la red y lo pasa al sumidero que decodifica el formato del mensaje y entrega el mensaje original al dominio de la aplicación receptora. Este proceso podría sonar muy familiar a alguien con conocimientos de las siete capas de red y de cómo trabajar para dar formato y transmitir datos de aplicaciones a través de una red.

La figura 2.2 muestra un objeto cliente y uno servidor, cada uno encerrado en su dominio de aplicación. El objeto cliente, en este ejemplo, envía una petición a una función situada en el objeto servidor.

Se puede observar en esta figura cómo el mensaje original se pasa desde un sumidero a otro en el dominio de la aplicación cliente hasta que los mensajes llegan a la red. En los servidores de la red, los mensajes realizan un proceso similar pero en orden inverso hasta que el mensaje original se presenta en el objeto servidor.

Figura 2.2 Sumideros de comunicación y .Net Remoto

2.1.5 Puertos.

Las comunicaciones salen o entran de un ordenador a través de un puerto. Cuando su navegador Web pide una página Web desde un servidor remoto Web, normalmente, esta llamada sale a través del puerto 80, y el servidor Web escucha sus peticiones en su puerto 80. Otras utilidades de Internet como Telnet o FTP (File Transfer Protocol) utilizan sus propios

(38)

puertos para enviar datos a la red. DCOM usa diferentes puertos para comunicarse, y el puerto que usa está fuera de su control. Tiene que contar DCOM para decidir qué puerto elegir. Por el contrario muchos firewalls bloquean los puertos que DCOM usa para la comunicación.

En .Net Remoto, tiene la posibilidad de definir qué puerto usará su canal para comunicarse. Por defecto, el canal HTTP usa el puerto 80 para enviar sus peticiones mezcladas con el tráfico Web, que al menos, asegura que sus llamadas no serán bloqueadas por firewalls entre los objetos cliente y servidor. Puede optar por usar otro puerto para enviar sus peticiones, aunque necesitará examinar la red entre sus objetos cliente y servidor para asegurarse de que este puerto no se bloquee a lo largo del camino, lo que produciría que sus llamadas a objetos fallen. Incluso puede cambiar los puertos con el canal HTTP, que le permite enviar mensajes que usan el protocolo HTTP y mensajes SOAP a través de cualquier puerto de la misma forma que usaría el puerto 80.

Cuando se elija un puerto para usar, debe tenerse cuidado de no utilizar uno que ya esté en uso. No se deberá emplear un número de puerto personalizado por debajo de 100, puesto que la mayoría de estos números están reservados para usos de aplicaciones específicas.

2.1.6 Comunicaciones remotas.

Una vez que se ha entendido cómo .Net Remoto usa los canales para enviar mensajes entre los objetos cliente y servidor, es hora de echar un vistazo en profundidad a sus mensajes. Se examinará cómo la llamada cliente se formatea y cómo los parámetros que se pasan al objeto servidor se ordenan. Se precisa el papel que juega el sumidero de formateo en el proceso remoto y cómo sus objetos del lado del cliente trabajan con versiones proxy del objeto del lado del servidor.

Mensajes remotos

Los datos se envían a través del canal de comunicaciones de un mensaje .Net Remoto. Durante este viaje, este mensaje se puede transformar y modificar de muchas formas. El mensaje inicial se genera por una rutina que llama al objeto servidor remoto. Esta llamada al

(39)

procedimiento remoto puede incluir parámetros para pasar la información necesaria por el objeto servidor para realizar sus obligaciones. El mensaje pasa a través de la cadena de sumideros del cliente y servidor, y se altera el formato del mensaje preparándolo para la transmisión al final del cliente, que extrae el mensaje original durante la transmisión a través de CallContext del mensaje. Los mensajes creados en .Net Remoto implementan la interfaz IMessage que, en esencia, es un objeto diccionario que contiene los datos y las propiedades de ese mensaje. Encontrará la interfaz IMessage en la plataforma .Net bajo el ámbito System.Runtime.Remoting.Messaging. Vale recordar que el mensaje es la petición del cliente y sus parámetros asociados. Este mensaje se envía desde un objeto a otro a través de un canal y, el formato del mensaje se modifica por uno o más sumideros. A continuación se verá cómo los parámetros se ordenan en una llamada .Net Remoto.

2.1.7 Marshalling de datos en .Net Remoto.

Cuando se utiliza el método para llamar a objetos locales, hay que elegir si pasar sus datos por referencia (ByRef) o por valor (ByVal). La opción ByRef guarda una copia de los datos en la localización fuente y sólo pasa un puntero de referencia al procedimiento receptor para decir donde necesitan estar los datos. La opción ByVal hace una copia de los datos y pasa esa copia al objeto receptor. ByVal da al objeto receptor su propia copia de los datos, así que, si se hacen cambios en él, el dato original no se ve afectado. Aunque ByVal proporciona una protección para los valores de los datos originales, hay un precio que pagar para pasar los valores del dato real entre los objetos, frente a los punteros eficientes y pequeños en el método ByRef.

En .Net Remoto el objeto servidor reside en un dominio de aplicación separado, frecuentemente, en una máquina separada. Los punteros ByRef pasados no serían entendidos porque los datos quedan en el dominio de la aplicación nativa, fuera del ámbito del objeto servidor. Por defecto, un método de una clase es publicable, por sí mismo, lo que significa que una copia exacta de sus datos se envía al objeto servidor para procesarlo. Para objetivos .Net Remoto los objetos que se auto-publican no pueden utilizarse en .Net Remoto y se dice que no se pueden hacer remotos. Para proporcionar intercambios de datos entre objetos .Net Remoto

(40)

necesita un método ordenado ByRef que puede viajar entre dos diferentes dominios de aplicación.

Se puede evitar la tendencia natural de la clase para publicarse a través del uso de la herencia. La clase base System.MarshalByRefobject no se publica, aunque mantiene una copia del objeto en el dominio propio de la aplicación del objeto (Vitter and Templeman, 2002).

Al igual que en el método que ordena los datos ByRef, el objeto que se hereda de la clase base MarshalByRefObject mantendrá una copia de los datos en el dominio de la aplicación del objeto y pasa una referencia sencilla para copiar el objeto remoto. El Framework .Net y el CLR (Common Language Runtime) reconocen una situación MarshalByRefObject y utilizan ese puntero de referencia para hacer llamadas al dominio de la aplicación del cliente para examinar y acceder al objeto ordenado.

Puede verse la ordenación por referencia de forma abreviada como MBR. El uso de un MarshalByRefObject puede disminuir el tráfico en la red entre sus objetos cliente y servidor. Como un solo puntero de la petición del objeto original se pasa en lugar del objeto completo, MarshalByRefObject es sin duda el camino más eficiente para ordenar datos en .Net Remoto.

2.1.8 Formateadores.

El sumidero formateador se responsabiliza en publicar el mensaje del objeto cliente y aplica cualquier formato específico del canal para ese mensaje. Si está utilizando el canal TCP, el sumidero formateador pone el mensaje en un archivo binario. El sumidero formateador para un canal HTTP sitúa el mensaje en un envoltorio SOAP preparándolo para la transmisión. El formateador solamente se responsabiliza de transformar el mensaje a un formato adecuado para la transmisión.

Gracias a los sumideros formateadores, el programador no tiene que tratar con la complejidad de la publicación ni con el formateo de los mensajes para cumplir con los formatos específicos de los canales. El sumidero formateador utiliza una de las dos clases para hacer esto. Si sus objetos están usando un canal TCP para comunicarse, el formateador utiliza la clase Binary.BinaryFormatter.

(41)

SOAP en .Net Remoto

Con SOAP, se puede encapsular un mensaje o una llamada a un objeto en un envoltorio basado en XML que permite enviar este mensaje usando el protocolo HTTP. Una ventaja primaria del uso de realizar mensajes SOAP a través de Internet utilizando el protocolo HTTP es que usa un formato de mensajes y un protocolo de red aceptados universalmente y ampliamente comprensibles. SOAP, XML y HTTP no son tecnologías controladas por Microsoft, y a ningún programador le va a importar la herramienta en la que prefiera trabajar, es libre de usar estas tecnologías en sus aplicaciones (Vitter and Templeman, 2002).

Otra ventaja del uso de mensajes SOAP en .Net Remoto es que SOAP hace lo posible para que cualquiera lea sus mensajes, lo cual no es verdad para los métodos de canal TCP y DCOM de .Net Remoto. SOAP es auto descriptivo, así que el receptor de su mensaje no tiene que tener conocimiento previo de ese formato de mensaje, ni haber realizado ningún acuerdo o uso de protocolo de comunicaciones propio para recibir esos mensajes. SOAP abre un nuevo mundo de posibilidades en el asunto de las llamadas procedurales remotas. En los próximos años, SOAP sobre HTTP llegará a ser, probablemente, el estándar universal para todos los lenguajes de desarrollo siguientes.

2.1.9 Proxy en .Net Remoto.

Cuando las rutinas .Net llaman a una función remota, lo hacen a través del uso de una versión local de esa función, que se conoce como un proxy. Un proxy es una imagen fantasma vacía del objeto localizado en el servidor remoto, que aparece localmente en la función que llama. Éste es el trabajo del proxy para reencaminar esa llamada a la función al objeto remoto y, a continuación, recibir la respuesta del objeto y presentar los resultados en el llamador.

En .Net Remoto hay dos niveles de proxy. El proxy de nivel superior que el objeto cliente llamante trata, conocido como un TransparentProxy (proxy transparente). Como el nombre indica, es una clase muy delgada que actúa como la intermediaria para la clase RealProxy (proxy real). Todo el trabajo del proxy real se hace en la clase RealProxy. El TransparentProxy

Referencias

Documento similar

El aporte teórico y práctico consiste en la actualización de material bibliográfico y la evaluación del impacto de la Teleserie Cubana “Rompiendo el Silencio” en los

diabetes, chronic respiratory disease and cancer) targeted in the Global Action Plan on NCDs as well as other noncommunicable conditions of particular concern in the European

Para orientar a quienes decidan iniciar su andadura por Internet, amén de buscar con palabras o frases temas de su interés con las utilidades anteriormente

Volviendo a la jurisprudencia del Tribunal de Justicia, conviene recor- dar que, con el tiempo, este órgano se vio en la necesidad de determinar si los actos de los Estados

[r]

[r]

¡adrid, vizcaya y Guipúicoa se eLeva al, 20% de tos otrora emigrantes; mientras que en Badajoz sólo retornan 16 de cada cien imigrantes que/ en su día, se dirig'ieron hacia

Gastos derivados de la recaudación de los derechos económicos de la entidad local o de sus organis- mos autónomos cuando aquélla se efectúe por otras enti- dades locales o