CURSO INTRODUCCI“N A LOS SISTEMAS DISTRIBUIDOS - Inicio

Introducción a los Sistemas Distribuidos

CURSO

INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS

Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. II

BIENVENIDA Nos es grato recibirte en esta iniciativa de preparación y actualización de tus conocimientos en el panorama que presentan las aplicaciones de los sistemas distribuidos en la industria del Software. Este curso de introducción a los sistemas distribuidos presenta tanto las bases teóricas como la aplicación práctica en plataformas actuales de desarrollo, al final del mismo, contarás con los conocimientos fundamentales requeridos en los desarrolladores de software modernos. Bienvenido(a) al curso de introducción a los sistemas distribuidos, deseándote mucho éxito en el curso y aprovechamiento del mismo.

INTENCIÓN EDUCATIVA Contribuir al fortalecimiento de tu formación profesional en los temas relevantes de tecnologías de la información, especialmente en el campo de los sistemas distribuidos, los cuales se han popularizado por la alta demanda de aplicaciones de Internet. Con ello tendrás más y mejores oportunidades de incorporarte o mantenerte actualizado en e l mercado laboral.

OBJETIVOS GENERALES Al finalizar el curso, el participante será capaz de: 1. Entender y emplear los conceptos principales que caracterizan a los sistemas distribuidos. 2. Distinguir los temas más importantes sobre la implementación de sistemas distribuidos. 3. Desarrollar una aplicación de sistema distribuido en una plataforma de desarrollo conveniente. 4. Apreciar las ventajas y desventajas del ambiente distribuido en aplicaciones de computación móvil.

INTRODUCCIÓN El proyecto PROSOFT surge como una alternativa en la capacitación y formación de estudiantes y profesionales de la informática, a través de cursos, que


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. III

comprenden desde temas básicos hasta avanzados, estructurados de acuerdo a estrategias didácticas comprobadas y metas de aprendizaje alcanzables. Especialmente, el curso de Introducción a los Sistemas Distribuidos comprende temas fundamentales como el paradigma cliente -servidor, middleware y computación móvil. Temas que encierran aspectos representativos y novedosos de los ambientes distribuidos con aplicación práctica en plataforma de tecnologías como Java, .NET y CORBA. Es importante destacar que por la intensidad de la temática del curso, en principio se aplican técnicas didácticas orientadas a un aprendizaje basado en problemas y que en conjunto con la comprobación de lecturas y ejercicios, los participantes en forma individual y grupal estarán en posibilidades de alcanzar metas comunes para: • Proponer la solución de un problema. • Decidir en el estudio de un caso. • El diseño y desarrollo de un proyecto. De tal forma que el curso esta organizado de la manera siguiente: El tema 1, “Introducción”, trata sobre los fundamentos, ventajas, desventajas y evolución de los sistemas distribuidos, se realizarán actividades de lectura y análisis de la información. El tema 2, “Arquitectura cliente-servidor”, muestra conceptos fundamentales de este paradigma sobre los cuales, para su mejor comprensión, se llevarán a cabo ejercicios prácticos de sockets, RPC y modelado de capas. El tema 3, “Tecnologías de desarrollo”, se analizará el concepto de middleware y su importante papel en el paradigma de los ambientes distribuidos, se plantean ejercicios prácticos de las tecnologías Java y .Net que van en dirección de estos ambientes. Por otro lado CORBA se tratará como un caso de estudio. El tema 4, “Lenguajes de programación”, hasta este punto una vez tratados los temas previos, se estará en posibilidad de desarrollar un pequeño proyecto de implementación de un sistema distribuido. El tema 5, “Computación móvil”, siendo un tema notable dentro de los ambientes distribuidos, se abordan los antecedentes, paradigmas y lenguajes de programación. Realizarán un ejercicio práctico de aplicación móvil. Ahora bien, los exhortamos a cubrir en orden y forma las actividades de aprendizaje de cada uno de los temas, con la finalidad de que alcance un nivel satisfactorio del curso.


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. IV

Agradecimiento y Reconocimiento

Después de una ardua tarea de investigación se ha logrado la creación de una obra vasta en conocimiento en el desarrollo de las Tecnologías de la Información y Comunicación. La presente obra no hubiera sido posible sin la valiosa aportación de destacados autores y especialistas en la materia. Es por ello que a manera de reconocimiento queremos agradecer su participación:

INTRODUCCIÓN A LOS SISTEMAS DISTRIBUIDOS

Mtro. Sergio González Nava

Universidad La Salle

Ing. Guillermo Cheang León CETYS Universidad Campus Mexicali

M. en C. Eiso Jorge Kashiwamoto Yabuta

Instituto Latinoamericano de la Comunicación Educativa, Universidad La Salle


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. V

METODOLOGÍA Se emplearán diferentes técnicas didácticas para cubrir los temas del curso y se hará referencia en las actividades de aprendizaje sobre el manejo de ellas y la forma de evaluación basada en rúbricas. Las técnicas didácticas son las siguientes: APRENDIZAJE BASADO EN PROBLEMAS (ABP) La técnica de aprendizaje basado en problemas esta orientada al constructivismo, que tiene por objeto conjuntar ideas o conocimientos individuales o grupales de los alumnos sobre un tema, tarea o problema y colectivamente llegar a una síntesis, conclusiones o realización de metas de aprendizaje. En esta técnica los roles del profesor o tutor, y de cada alumno de un grupo es de suma importancia. Los pasos del ABP son los siguientes: 1. Presentación del problema o tema 2. Lluvia de ideas y preguntas 3. Si idea relevante con respuesta, sigue paso 7 4. Si pregunta relevante sin respuesta y se puede investigar, sigue paso 5 5. Fijar meta de aprendizaje 6. Investigación individual 7. Discusión y reporte. 8. Si todavía hay ideas y preguntas sigue paso 3 9. Integración de solución. COMPROBACIÓN DE LECTURA La técnica de comprobación de lectura tiene como finalidad fomentar en el alumno la habilidad de leer, analizar y comprender. Los materiales que se utilicen deben ser recopilaciones de diferentes autores de un tema, para homogenizar los conceptos e ideas referentes al tema. La técnica de comprobación de lectura es una de las más empleadas en los procesos de enseñanza-aprendizaje y tiene como finalidad conformar conceptos e ideas propias al alumno, por lo que no pretende que se memoricen los temas tratados. ESTUDIO DE CASOS (EC) El estudio de casos difiere de los sistemas de enseñanza tradicionales porque exige que el alumno tome parte activa en el análisis de los problemas y en la toma de decisiones para la solución a situaciones reales muy específicas. El proceso que se siga para tomar decisiones y las decisiones mismas, sustentadas en un análisis adecuado, son la clave. Este tipo de ejercicios nos permite aprender a


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. VI

comunicar criterios, defender hechos y opiniones en debates. Los pasos del EC son los siguientes: 1. Presentación del caso 2. Preparación individual 3. Grupos de discusión 4. Plenaria APRENDIZAJE ORIENTADO A PROYECTOS (AOP) La técnica de aprendizaje orientado a proyectos permite consolidar el proceso de aprendizaje en un proyecto final que representa una conexión con la realidad, dado que en pequeños grupos, los alumnos tienen la oportunidad de identificar sus propias necesidades de aprendizaje, localizando los recursos y construyendo con base en ellas. Los pasos del AOP son los siguientes: 1. Analizar el problema 2. Resolver el problema 3. Elaborar el producto 4. Generar el reporte

FUENTES DE INFORMACIÓN Referencias bibliografías: · Distributed Systems, Concepts and Design. Couloris Addison Wesley/Pearson http://www.cdk3.net/ · Distributed Systems: Principles and Paradigms

Tanenbaum Prentice Hall http://www.prenhall.com/divisions/esm/app/author_tanenbaum/custom/dist_sys_1e/

· Distributed Computing: Principles and Applications Liu Addison Wesley

http://www.csc.calpoly.edu/~mliu/book/


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. VII

REGLAS Y EVALUACIÓN El curso tiene una serie de actividades que sirven como medio para que los alumnos encuentren significado y propicien la construcción de los conocimientos bajo las estrategias didácticas que el programa señala. No se trata de ejercicios memorísticos o de una labor informativa del tutor sino de desafíos, ejercicios e investigaciones desarrolladas por los alumnos con un enfoque de aprendizaje cooperativo e independiente. Los alumnos deberán entregar con oportunidad las tareas individuales y en equipo determinadas para cada tema y con el formato adecuado. El informe de los ejercicios prácticos que deban presentar tiene la modalidad de que detallen o amplíen el funcionamiento de ellos o en su caso la compilación correspondiente. Los alumnos deberán participar interactivamente mediante los apoyos de e-mail, foros, y Chat para retroalimentar su trabajo en equipo y comunicación con el tutor. Rúbrica de evaluación de comprobación de lecturas como Evaluación Síntesis. Tareas que se integran: TI (1) y TE (1) · Rúbrica de evaluación de ejercicios prácticos como Evaluación Ejercicios. Tareas que se integran: TI (2.1, 2.2.1, 2.2.2, 2.3), TI (3.2, 3.4, 3.5, 3.6) y TI (5). · Rúbrica de evaluación de aprendizaje basado en problemas como Evaluación ABP. Tareas que se integran: TE (3.1) · Rúbrica de evaluación de estudio de casos como Evaluación EC. Tareas que se integran: TI (3.3) y TE (3.3) · Rúbrica de evaluación de aprendizaje orientado a proyectos como Evaluación AOP. Tareas que se integran: TE (4.2)


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. VIII

CONTENIDO BIENVENIDA.....................................................................................................................................................................II INTENCIÓN EDUCATIVA ...........................................................................................................................................II OBJETIVOS GENERALES ...........................................................................................................................................II INTRODUCCIÓN .............................................................................................................................................................II METODOLOGÍA ..............................................................................................................................................................V FUENTES DE INFORMACIÓN.................................................................................................................................VI REGLAS Y EVALUACIÓN.......................................................................................................................................VII 1. INTRODUC CIÓN ................................................................................................................................................... 1

1.1. FUNDAMENTOS.................................................................................................................................................3 1.2. VENTAJAS Y FACTORES DE DISTRIBUCIÓN.................................................................................................23 1.3. DESVENTAJAS Y FACTORES A CONSIDERAR...............................................................................................25 1.4. EVOLUCIÓN.....................................................................................................................................................26

2. ARQUITECTURA CLIENTE SERVIDOR..................................................................................................33 2.1. FUNDAMENTOS DE ARQUITECTURA CLIENTE SERVIDOR.........................................................................33 2.2. COMUNICACIÓN ENTRE PROCESOS..............................................................................................................40 2.3. MODELO DE CAPAS........................................................................................................................................80

3. TECNOLOGÍAS DE DESARROLLO............................................................................................................ 91 3.1. INTRODUCCIÓN AL MIDDLEWARE................................................................................................................98 3.2. PROGRAMACIÓN DE TRANSACCIONES......................................................................................................104 3.2 PROGRAMACIÓN DE TRANSACCIONES...............................................................................................................108 3.3. CORBA ........................................................................................................................................................124 3.4. RMI...............................................................................................................................................................161 3.5. COM+ ...........................................................................................................................................................166 3.6. WEB SERVICES.............................................................................................................................................221

4. LENGUAJES DE PROGRAMACIÓN.........................................................................................................227 4.1. LENGUAJES Y PLATAFORMAS DE DESARROLLO.....................................................................................227 4.2. DESARROLLO DE UN SISTEMA DISTRIBUIDO...........................................................................................237

5. COMPUTACIÓN MÓVIL...............................................................................................................................248

5.1. ANTECEDENTES EN COMPUTACIÓN MÓVIL.............................................................................................248 5.2. PARADIGMAS DE LA COMPUTACIÓN MÓVIL .............................................................................................260 5.3. LENGUAJES Y AMBIENTES DE PROGRAMACIÓN DE COMPUTACIÓN MÓVIL .......................................263 5.4. APLICACIONES MÓVILES............................................................................................................................293

1. Introducción

Objetivos Al término del estudio del tema de introducción, el participante comprenderá: • Los conceptos fundamentales que caracterizan a los sistemas distribuidos. • Las ventajas y desventajas que presentan los sistemas distribuidos. • La evolución de los sistemas distribuidos. Actividades (1) Actividad 1.1 Realizar una síntesis sobre los conceptos de introducción del curso, tomando como base el Material de Apoyo . · Utilice tablas, ilustraciones, mapas mentales o en su caso mapas conceptuales. · Consultar por lo menos otra fuente de información y mencionarla, con el fin de enriquecer su trabajo de síntesis. · La síntesis no debe de exceder más de seis cuartillas. · Agregar sus objetivos de aprendizaje que desea alcanzar del curso. Una vez completada la Actividad 1.1, colocar su documento en Tarea Individual (1) Actividad 1.2 Discutir en equipo las características que muestran los sistemas distribuidos y elaborar una síntesis. · Intercambien sus mensajes de discusión en el Foro Actividad 1.2 Una vez completada la Actividad 1.2, colocar su documento en Tarea en Equipo (1) Nota Importante: Ambas actividades 1.1 y 1.2 serán evaluadas de acuerdo a la rúbrica localizada en Evaluación Síntesis.


Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0. 2

Introducción La computación distribuida ha ido tomando más y más importancia con el impresionante desarrollo de las telecomunicaciones y conforme los avances tecnológicos han hecho posible la construcción de computadoras que caben en un escritorio pero con procesadores muy poderosos y grandes capacidades de memoria y disco; Millones de usuarios dependen de sistemas distribuidos diariamente para hacer transacciones bancarias, reservaciones de vuelos, telefonía, enviar correos electrónicos, obtener información de todo tipo y realizar operaciones de compra-venta. Se pueden resaltar las siguientes peculiaridades del tema: Es un área de cambios constantes, debido al vertiginoso avance de tecnologías, tanto de hardware como de software de nuevas ideas, modelos conceptuales y herramientas matemáticas. La complejidad de un sistema distribuido que abarca gran cantidad de problemas de muy diversos tipos. Sin embargo, existe ya un cuerpo de principios fundamentales, de ideas básicas subyacentes que permiten entender muchos de los aspectos de un sistema distribuido. El objetivo de este curso es introducir al alumno a modelos, técnicas y conceptos relevantes, independientemente de las tecnologías del momento. Desarrollar en el alumno una capacidad de análisis, creatividad y razonamiento que lo ayuden a atacar problemas de tipo distribuido. El temario del curso trata de identificar aspectos esenciales de lo que es un problema distribuido. Intenta ser una presentación coherente y continua, buscando que los temas presentados parezcan suceder unos a otros de manera natural. Más que aspirar a un alcance en cantidad de los temas presentados, es decir, de información, el curso intenta desarrollar en el alumno habilidades. Consideramos de primera importancia formar alumnos que puedan resolver problemas complejos de sistemas distribuidos, así como alumnos con capacidad crítica y creadora. Pensamos que la manera de lograr esto es: a) logrando un entendimiento a fondo, y b) aprendiendo resolver problemas difíciles; enfocándose en material esencial, en principios fundamentales subyacentes no solo a las tecnologías del momento, sino a cualquier otra que aparezca en el futuro. Esto es especialmente importante en vista de las dos siguientes peculiaridades de esta área. Primero, es esta un área de cambios constantes, debido al vertiginoso avance de tecnologías, tanto de hardware como de software: las redes de computadoras cambian constantemente, incorporando líneas de comunicación más rápidas cada vez, y de nuevos tipos, como fibra óptica y redes móviles de radio. Nuevas arquitecturas como ATM, sistemas cada vez mías sofisticados de televisión



interactiva, telefonía celular, comunicadores personales (pagers) que pueden transmitir además de recibir. Multiprocesadores más poderosos, redes de estaciones de trabajo. Se generan constantemente nuevas ideas, y modelos conceptuales que cambian nuestra manera de ver el cómputo y manejo de información distribuida; quizás el ejemplo más dramático es Web, pero existen otros como las listas de correo y noticias electrónicas, nuevos lenguajes y paradigmas, que generan nuevos problemas fascinantes y que cambian las suposiciones de problemas conocidos (por ejemplo, la relación entre la velocidad de procesamiento y la de transmisión). Entre tanto, se descubren nuevas y más poderosas herramientas matemáticas para solucionar los problemas, como probabilidad, álgebra combinatoria y topología. Segundo, la enorme complejidad de un sistema distribuido, que se aprecia al detenerse a pensar en la gran diversidad de problemas que abarca, algunos de ellos son: aspectos de comunicación : códigos para detección de errores, protocolos de enlaces, problemas de ruteo, congestión, ATM, etc. Sincronización: exclusión mutua, relojes, abrazos mortales, etc. Manejo de procesos: administración de recursos, threads, tolerancia a fallas, tiempo real, calendarización, etc. Seguridad y criptología. Uso compartido de memoria. Especificación, modelado y verificación. Complejidad y análisis de algoritmos. Problemas que pueden observarse en sistemas de archivos, bases de datos y sistemas operativos distribuidos.

1.1. Fundamentos 1.1.1 ¿Qué es un Sistema Distribuido? Antes de definir lo que es un Sistema Distribuido, vamos a definir un término más general: La Computación Distribuida, podemos definirla de muchas maneras, este término se utiliza indiscriminadamente para referirse a cualquier sistema en el que múltiples agentes autónomos, cada uno con capacidades de cómputo individual, se comunican entre sí y afectan mutuamente su comportamiento. Los agentes, usualmente llamados procesadores, procesos o nodos, pueden ser desde computadoras completas hasta autómatas celulares con capacidad de cómputo y memoria muy limitados que se pueden comunicar mediante mensajes. La Computación Distribuida hace referencia a cualquier evento en el cual se maneja un sistema en una red de computadoras y trata de describir las tendencias hacia la funcionalidad distribuida: sistemas distribuidos, procesamiento distribuido, bases de datos distribuidas y cualquier otro término computacional que sea distribuido. Podemos decir entonces, que la Computación Distribuida se refiere a los servicios que provee un Sistema de Computación Distribuido.



Una de las primeras caracterizaciones de un Sistema Distribuido fue realizada por Enslow, ya en 1978, que le atribuye las siguientes propiedades:

• Está compuesto por varios recursos informáticos de propósito general, tanto físicos como lógicos, que pueden asignarse dinámicamente a tareas concretas.

• Estos recursos están distribuidos físicamente, y funcionan gracias a una red de comunicaciones.

• Hay un sistema operativo de alto nivel, que unifica e integra el control de los componentes.

• El hecho de la distribución es transparente, permitiendo que los servicios puedan ser solicitados especificando simplemente su nombre (no su localización).

• El funcionamiento de los recursos físicos y lógicos está caracterizado por una autonomía coordinada.

A pesar del tiempo transcurrido, esta definición sigue siendo, en esencia, válida. Así, para Coulouris un sistema distribuido es aquél que está compuesto por varias computadoras autónomas conectadas mediante una red de comunicaciones y equipadas con programas que les permitan coordinar sus actividades y compartir recursos. Bal ofrece una definición muy similar: ``Un sistema de computación distribuida está compuesto por varios procesadores autónomos que no comparten memoria principal, pero cooperan mediante el paso de mensajes sobre una red de comunicaciones''. Y según Schroeder, todo sistema distribuido tiene tres características básicas:

• Existencia de varias computadoras. En general, cada una con su propio procesador, memoria local, subsistema de entrada/salida y quizás incluso memoria persistente.

• Interconexión. Existen vías que permiten la comunicación entre las computadoras, a través de las cuales pueden transmitir información.

• Estado compartido. Las computadoras cooperan para mantener algún tipo de estado compartido. El funcionamiento correcto del sistema se describirse como el mantenimiento de una serie de invariantes globales que requiere la coordinación de varias computadoras.

Como lo hemos observado, el término de Computación Distribuida se define de varias maneras y lo mismo se aplica al término de Sistema Distribuido, así que en lugar de seguir dando más definiciones de estos términos, nos concentraremos en el análisis de las características más importantes de los Sistemas Distribuidos, de esta manera podremos construir una definición propia de lo que es un Sistema Distribuido al finalizar este capítulo. Una característica muy importante es que las diferencias entre las computadoras y las maneras en que estas se comunican no son transparentes para el usuario



final, esto mismo aplica para la organización interna del sistema distribuido. Otra característica importante es que los usuarios y las aplicaciones pueden interactuar con un Sistema Distribuido de manera consistente y uniforme, sin importar donde y cuando se lleve a cabo la interacción. Todo Sistema Distribuido bebe también ser relativamente fácil poder expandir, lo cual se logra al tener computadoras independientes, pero al mismo tiempo “esconder” las funciones de dichas computadoras en el sistema. Normalmente un sistema distribuido debe de estar siempre disponible a pesar de que ciertas partes que lo conforman puedan no estar funcionando. Los usuarios y las aplicaciones no deben de notar en ningún momento que estas partes están siendo reemplazadas o reparadas, o que se han agregado nuevas partes al sistema para poder dar servicio a más usuarios o aplicaciones. 1.1.2 Características de un Sistema Distribuidos Cualquier diseñador de sistemas debe tener los conocimientos necesarios para enfrentarse a todas las complicaciones que pueden surgir al momento de considerar los requerimientos para el desarrollo de un sistema distribuido. A continuación explicaremos cada una de las características de los Sistemas Distribuidos, según Coulouris son estas características, los desafíos que presentan los sistemas distribuidos. 1.1.2.1 Heterogeneidad Al hablar de heterogeneidad nos referimos a la variedad y diferencia que podemos encontrar en los elementos que componen una red de computadoras sobre la que se ejecuta un sistema distribuido, dicha heterogeneidad no sólo se aplica a las redes y al hardware de las computadoras, sino también a los sistemas operativos, los lenguajes de programación y las implementaciones en las que trabajan los diferentes desarrolladores. Un ejemplo de esto lo podemos ver muy claro en Internet, ya que es una red que esta conformada por muchos tipos de redes (Figura 1) cuyas diferencias se encuentran enmascaradas, puesto que todas las computadoras que se conectan a este utilizan los protocolos de Internet para comunicarse una con otra, así una computadora conectada a una red Ethernet puede comunicarse con otra computadora conectada a una red Token Ring, basta con que se haga una implementación de los protocolos de Internet para cada una de esas redes.



Figura 1. Un esquema clásico de la conexión a Internet

Otro ejemplo lo podemos ver en los lenguajes de programación y en las aplicaciones escritas por diferentes programadores; en el caso de los lenguajes de programación es importante tener en cuenta las diferencias que puede haber en la representación de los caracteres y estructuras de datos como cadenas de caracteres y registros, las cuales pueden variar y pueden ocasionar conflictos entre programas que necesitan comunicarse entre ellos. De igual manera dos programas que son desarrollados por programadores diferentes tienen que utilizar estándares comunes para la comunicación en red y para la representación de los datos elementales y las estructuras de datos en los mensajes, ya que si no se cuenta con dichas similitudes, los programas no podrán comunicarse entre sí aunque se hayan desarrollado en el mismo lenguaje de programación. Un término que no podemos dejar de mencionar al hablar de heterogeneidad es el de Middleware (Figura 2); este término se aplica a la capa de software que provee una abstracción de programación, así como un enmascaramiento de la heterogeneidad subyacente de las redes, hardware, sistemas operativos y lenguajes de programación; además, el Middleware proporciona un modelo computacional uniforme al alcance de programadores de servidores y aplicaciones distribuidas que permite la invocación sobre objetos remotos, notificación de eventos remotos, acceso a bases de datos remotas y procesamiento distribuido de transacciones. Algunos ejemplos de Middleware son CORBA y Java RMI, los cuales se describirán con más detalle en el capítulo 3 de este curso.



Figura 2. Un sistema distribuido organizado como Middleware

Otro término importante para este apartado es el de código móvil, que se emplea para referirse al código que pude ser enviado de una computadora a otra para que esta última la ejecute, un ejemplo de un código móvil son los applets de java, que son enviados del servidor a la computadora del cliente para que este los ejecute en su explorador de Internet. Al implementar un código de este tipo podemos encontrarnos con el problema de que el conjunto de instrucciones (a nivel máquina) de una computadora puede no ser el apropiado para otra máquina, por ejemplo, un usuario de una PC puede enviar un archivo ejecutable a un usuario de Linux y este último no será capaz de ejecutar dicho archivo. Para solucionar este problema se han creado lo que se conocen como máquinas virtuales, las cuales proveen un modo de crear código ejecutable sobre cualquier hardware, ya que el compilador de un lenguaje concreto generará un código para una máquina virtual y esta se encargará de “traducir” dicho código al apropiado para un hardware particular, así, un compilador de Java producirá un código para la máquina virtual de Java, y esta última sólo necesitará ser implementada una sola vez para cada máquina en la que se va a ejecutar. 1.1.2.2 Extensibilidad y Apertura La extensibilidad y la apertura son dos características de un sistema distribuido que están ampliamente ligadas la una con la otra. Algunos autores dicen que un sistema abierto debe de ser extensible y otros sostienen que un sistema extensible puede ser etiquetado como un sistema abierto. De cualquier manera lo que es importante saber y tener en cuenta es que un sistema distribuido debe de contar con ambas características. Un sistema distribuido abierto es un sistema que ofrece servicios desarrollados de acuerdo a reglas estandarizadas que describen la sintaxis y la semántica de dichos servicios. Por ejemplo, en una red de computadoras, estas reglas son las que regulan el formato, contenido y significado de los mensajes que se envían y se reciben a través de dicha red. Estas reglas son formalizadas en protocolos. En el caso de los sistemas distribuidos, los servicios se especifican generalmente a través de interfaces que por lo general son descritas en un Lenguaje de Definición de Interfaz (IDL por sus siglas en ingles), dicho lenguaje especifica los nombres de las funciones que están disponibles así como los



parámetros de entrada, los valores de salida y los posibles errores que pueden obtenerse al invocarse dichas funciones. Si la definición de una interfaz se hace de manera adecuada, esta permitirá que dos procesos puedan comunicarse entre sí, siempre y cuando ambos procesos cuenten con la misma interfaz. Esto también permite que cada dos desarrolladores independientes construyan su propia implementación de dichas interfaces, lo cual conlleva al desarrollo de dos sistemas distribuidos desarrollados por separado que operan de la misma manera. Una especificación se considera adecuada cuando es completa y neutral. Completa significa que todo lo necesario para hacer una implementación de la interfaz ha sido especificado y que no será necesario que el propio desarrollador sea quien agregue detalles específicos de la implementación. Neutral significa que las especificaciones no deben tener ninguna tendencia hacia como se debe de hacer la implementación de dicha especificación. La completitud y la neutralidad son muy importantes para la interoperabilidad y la portabilidad, que son características que complementan la apertura de un sistema distribuido. La interoperabilidad, también conocida como compatibilidad, caracteriza el grado en el que la implementación de sistemas o componentes de diferentes fabricantes pueden coexistir y trabajar juntos, siempre y cuando se utilicen los servicios como este especificado por el estándar común bajo el cual dichos sistemas fueron desarrollados. La portabilidad por su parte caracteriza a que nivel puede ser ejecutada una aplicación desarrollada para un sistema distribuido “A” sobre un sistema distribuido “B” que implementa las mismas interfaces del sistema “A”, pero sin hacerle modificaciones. Uno de los principales objetivos que se persiguen al desarrollar un sistema operativo abierto, es que este sea flexible, lo que implica que dicho sistema puede ser integrado por diferentes componentes (tanto de hardware como de software), posiblemente de diferentes proveedores, que nuevos componentes pueden agregarse al sistema y que componentes existentes pueden ser reemplazados sin afectar el funcionamiento de los componentes ya existentes, en otras palabras, un sistema distribuido abierto debe de ser extensible. Para lograr la flexibilidad en un sistema distribuido abierto es necesario que el sistema este organizado en módulos o componentes relativamente pequeños y fáciles de reemplazar, esto implica que además de definir las especificaciones y la documentación de las interfaces de alto nivel a las que tienen acceso los usuarios y las aplicaciones, también es necesario definir las especificaciones de las interfaces de las partes internas que componen el sistema y describir de que manera interactúan entre sí.



1.1.2.3 Seguridad La gran mayoría de la información que maneja un sistema distribuido tiene un alto valor para los usuarios de dicho sistema, y es por eso que la seguridad de la información juega un papel clave al momento de desarrollar dicho sistema. La seguridad de la información es todo lo que concierne a asegurar que no ocurrirán cosas malas con los mensajes que envían los clientes para solicitar información a un servidor, y por su puesto, con la información que estos reciben como respuesta a sus peticiones. No basta con asegurar que estos mensajes serán transmitidos de forma oculta, sino que también hay que asegurar que la información sea entregada únicamente a quien debe de ser entregada y que esto se hará siempre de forma correcta y en el momento en que se requiere. La seguridad es relativa a la amenaza que cada sistema afronta, afecta a todos los puntos del sistema y debe de ser fácil de obtener. La seguridad debe ofrecer los siguientes servicios: • Confidencialidad, es decir, el manejo privado de la información: proteger la

información de ser accedida por usuarios no autorizados. • Autentificación, o capacidad de asegurar la identidad de un usuario. • Integridad, que asegura que la información que empleamos no ha sido

manipulada, alterada o corrompida desde el origen. • No repudio, de una operación de emisión y recepción de información por

parte de los agentes. • Control de acceso a la información y/o recursos administrados por un

sistema. • Disponibilidad de los recursos necesarios de un sistema cuando estos sean

requeridos, lo que protege la información contra interferencia con los procedimientos de acceso a los recursos.

El alto valor de que tiene la información es la razón principal por la que esta se puede ver amenazada de muchas formas, entre las principales podemos encontrar: Interrupción: Destruye la información o la inutiliza. Ataca la disponibilidad.

Interceptación: Obtiene acceso a información. Ataca la confidencialidad.



Modificación: Modifica la información. Ataca la integridad.

Fabricación: Falsifica la información. Ataca la autenticidad.

Para defenderse de este tipo de amenazas se han desarrollado diversas técnicas de encriptación, firmas digitales, implementación de barreras perimetrales (firewalls), modelos de seguridad internos y externos, etc. Sin embargo, estas técnicas parecen no ser suficientes para evitar que intrusos logren interferir con el flujo de información óptimo de un sistema, ya que encuentran formas de “brincarse” las barreras de seguridad de muchas organizaciones y además siguen ideando nuevas formas de atacar y amenazar la información, un ejemplo de estos nuevos ataques son los ataques de denegación de servicio. Estos ataques consisten en bombardear un servicio con un gran número de peticiones simultáneas (y por lo general inútiles) de modo que el sistema se colapse, obstaculizando el servicio a los usuarios que desean utilizarlo. Como hoy en día la capacidad de los sistemas distribuidos ha crecido mucho, en ocasiones resulta muy difícil o incluso imposible bloquear el servicio utilizando una sola computadora atacante, por lo que ahora se han desarrollado los ataques de denegación de servicio distribuidos, los cuales hacen uso de miles o incluso millones de computadoras para generar las peticiones al sistema que se desea bloquear, por lo que bloquear un ataque de esta magnitud resulta sumamente complicado. Si bien no podemos asegurar que un sistema distribuido sea cien por ciento seguro, es importante contar con un esquema de seguridad lo más robusto posible, que a pesar de no ser inmune a todo tipo de ataques, si será capaz de frenar la gran mayoría de dichos ataques. Algunas recomendaciones muy útiles para los desarrolladores, administradores e implementadotes de un sistema distribuido se presentan a continuación: a) Efectuar un análisis de riesgos Esto se suele mencionar en la literatura como el primer paso a realizarse cuando se plantea la seguridad en un sistema. La idea es muy sencilla: trazar todos los elementos que conforman nuestro sistema (hardware y software) y observar



cuáles involucran más o menos riesgo. Esto desembocará en un plan de seguridad cuyo objetivo es disminuir el riesgo total del sistema, que se puede modelar como la suma de los riesgos de sus componentes: RIESGO TOTAL = RIESGO (componente 1) + RIESGO (componente 2)... El riesgo de cada componente está en función directa a las pérdidas que ocasionaría el que éste deje de operar, así como en función de cuán vulnerable es dicho componente en este momento. Por ejemplo, una base de datos de clientes involucra un gran riesgo debido al gran valor que la información representa para una organización; pero una simple PC Windows de la misma organización conectada directamente al Internet (sin firewall/proxy de por medio) también lo representa, debido a que puede ser objeto de un ataque desde el exterior, con el posible riesgo de fácil propagación hacia otros computadores de nuestra red. b) Lo más valioso debe alejarse de lo más vulnerable En la fórmula del "riesgo" propuesta arriba, es evidente que los componentes de nuestro sistema con alto valor y alta vulnerabilidad serán de lejos los que presenten mayor riesgo. Sin embargo, en muchos casos no es sencillo disminuir el valor de cierto componente (y por tanto la pérdida en caso de problemas), y tampoco se puede eliminar completamente la vulnerabilidad del mismo (por ejemplo, si está de cara a Internet.) En este caso lo que conviene es separar o dividir este componente en dos partes suficientemente alejadas e independientes a fin de que el riesgo total disminuya. Por ejemplo, los portales de comercio electrónico deben dar cara a Internet (siendo vulnerables en principio) y a la vez manejar información muy costosa (como transacciones con tarjeta de crédito.) Esto los convierte en un sistema de alto riesgo. Sin embargo es casi universal la separación que se efectúa entre los componentes dedicados a dar cara a Internet (como los Web Servers) y los componentes que manipulan la información comercial (generalmente sistemas DBMS.) En términos prácticos, esto significa que el hacker no puede acceder directamente al DBMS (lo que sería catastrófico), y sólo podría atacar al Web Server, lo que en principio no acarrea mayores consecuencias.



c) Mantener las cosas simples Un sistema complejo es más difícil de asegurar y potencialmente proporciona una mayor cantidad de puertas abiertas a los atacantes. En general, es recomendable intentar dividir el problema mediante la simplificación de la configuración, para así identificar los puntos o rutas de control vulnerables para incrementar la seguridad. La seguridad debe estar en todos los niveles Esto se puede expresar más sencillamente como: no confiar el sistema a un único mecanismo de seguridad. La información fluye a través de los distintos componentes y/o capas del sistema y son muchas las instancias en las que se puede mejorar su seguridad. La recomendación estipula que utilicemos todas estas instancias a pesar de que en principio puedan parecer redundantes. Por lo general los administradores tienden a preocuparse por un único punto de acceso desde donde supuestamente hay una gran probabilidad de ser atacados (por ejemplo, la conexión a Internet.) Por tanto se invierte esfuerzo y dinero en controlar este único punto bajo la asunción de que es la única puerta de entrada a los maleantes y que por tanto, tras asegurarla, todo el sistema quedará seguro. Esto tiene dos problemas: Muchos ataques o "vulnerabilidades" se originan (de forma inocente o intencional) desde dentro de la organización. El sistema que controla la "puerta" siempre puede fallar. Esto obliga a implementar la seguridad no en un único punto evidentemente vulnerable, sino en todos los lugares por donde fluye la información al interior de cada componente involucrado. Encriptar tanto como sea posible La encriptación es un tema complejo pero cuya implementación resulta cada vez más sencilla conforme aparecen más productos. Los cambios del año pasado en la legislación norteamericana con respecto a la exportación de productos que encriptan, son un incentivo claro para que los desarrolladores y vendedores se interesen más en el tema. En general, los canales de comunicación más vulnerables o de mayor cercanía al público requieren una encriptación "más fuerte", es decir, más difícil de descifrar por los curiosos o atacantes. Cierta información conlleva más riesgo que otra, y por tanto requerirá un nivel de encriptación diferenciado. Las herramientas capaces de hacer esto son muchas, dependiendo del contexto en que nos encontremos. Por ejemplo, los sistemas DBMS más avanzados



incorporan la encriptación como una opción normal para los datos almacenados, generalmente bajo esquemas propietarios. La tecnología de encriptación de información destinada a pasar a través de la red ha evolucionado bastante, haciéndose popular el término VPN para hacer referencia a canales que encriptan la información de un modo más o menos transparente. Hay soluciones propietarias así como estándares relativamente implementados como IP Sec. Ciertas aplicaciones estándares han recibido soluciones de encriptación también estándar. El caso del Web encriptado bajo SSL (HTTPS) junto con la industria de certificados digitales es el caso más conspicuo. De igual modo los estándares para correo electrónico PGP (o derivados) y S/MIME son integrados cada vez con mayor frecuencia en las aplicaciones de los usuarios finales. En nuestra organización deberíamos encriptar todo lo que sea posible. La razón de esto es evidente si de lo que se trata es de enviar un mensaje privado por Internet. Sin embargo, al interior de la organización la encriptación puede ayudar también. Naturalmente hay que sopesar los inconvenientes que trae la encriptación en términos de incomodidad de uso, costo de licencias, ciclos de CPU, etcétera; con el hecho de que cierta información es definitivamente de carácter público y por tanto no tiene sentido que esté encriptada. Además de estas hay muchas más recomendaciones de seguridad que podemos mencionar, por ejemplo: no confiar en la autenticación estándar, no usar la configuración "estándar", educar a los usuarios, ejecutar sólo los servicios imprescindibles, mantenerse al día con las actualizaciones y hacer chequeos regulares, establecer planes de contingencia y sistemas de respaldo, mantener contacto con el proveedor de líneas de comunicación, no permitir conexiones directas desde la red interna a Internet, hacer uso de una red perimétrica o zona desmilitarizada, prácticas de programación segura, vigilancia, establecimiento de políticas, etc. 1.1.2.4 Escalabilidad La escalabilidad es una de las características más importantes para los desarrolladores de un sistema distribuido. Se dice que un sistema es escalable si logra conservar su efectividad cuando hay el número de recursos y el número de usuarios incrementa significativamente. La escalabilidad de un sistema pude medirse en tres aspectos diferentes: Con respecto a su tamaño: lo que significa que se pueden agregar más usuarios y más recursos al sistema de una manera muy fácil. Con respecto a su localización o área de implementación: lo que significa que tanto los usuarios como los recursos pueden estar en locaciones remotas y separadas el uno del otro.



Con respecto a su administración: lo que significa que puede ser fácil de administrar a pesar de que se utiliza en diferentes organizaciones independientes que cuentan con diferentes políticas de seguridad y que hacen un uso particular del sistema. Desafortunadamente, un sistema que es escalable en uno o más de estos aspectos por lo general afecta el rendimiento del sistema conforme al crecimiento del mismo. Problemas de la Escalabilidad Cuando se necesita escalar un sistema a un nivel más alto es muy común que surja algún tipo de problema. Si consideramos la escalabilidad con respecto al tamaño de un sistema, nos encontramos con las limitaciones que presentan los servicios, los datos y los algoritmos centralizados. En muchos sistemas distribuidos es común encontrar servicios centralizados, es decir, que son implementados en un mismo servidor, lo que puede ocasionar un problema muy obvio: este servidor puede convertirse en un cuello de botella si el número de usuarios crece, y a pesar de tener una capacidad de procesamiento y almacenamiento virtualmente ilimitada, la comunicación con este servidor puede llegar a tener un límite y eventualmente impedir el crecimiento del sistema. Desafortunadamente el uso de un sólo servidor puede ser inevitable, ya que por lo general tenemos servicios que trabajan con información muy sensible y que tiene que ser lo más segura posible, por lo que el tener esta información almacenada en diferentes servidores puede llegar a poner la información en riesgo y hacer el sistema más vulnerable. De la misma manera, el almacenamiento centralizado de la información puede ser un grave problema para un sistema distribuido, ya que a pesar de que un sólo servidor nos puede ofrecer la capacidad de almacenamiento que necesitamos, es muy poco probable que dicho servidor permita el acceso simultáneo a miles o incluso millones de usuarios que desean consultar la información almacenada en él. Un ejemplo de esto es el Sistema de Nombre de Dominio, que a pasar de poder almacenar todos los registros en una sola base de datos de varios gigabytes, no podría dar una respuesta a los millones de usuarios de Internet que accedan este servicio simultáneamente. El uso de algoritmos centralizados es en teoría la solución óptima a un problema de computación distribuida, sin embargo, en la práctica podemos ver que el uso de este tipo de algoritmos en un sistema distribuido grande no es una buena idea, ya que colectar y transportar los datos de entrada y salida del sistema hacia un sólo punto en el que se computan dichos datos pudiese sobrecargar parte de la red con todos los mensajes que necesita enviar y recibir, además de que el computo de toda la información en una sola máquina tiene más riesgo a fallos y puede resultar más tardada. La solución a este problema es el uso de algoritmos descentralizados, los cuales cuentan con ciertas características que



los diferencian de los algoritmos centralizados, entre las que podemos mencionar: Ninguna máquina tiene información completa del estado del sistema. Cada máquina toma decisiones propias basándose solamente en información local. Problemas o fallos de una máquina no arruinan el procesamiento de todo el algoritmo. No necesariamente se cuenta con un reloj global (algoritmos no sincronizados). A pesar de que en una LAN pudiese sincronizarse la ejecución de un algoritmo descentralizado, este mismo procedimiento pudiese ser muy complicado o incluso imposible si el algoritmo esta distribuido en una red más amplia, por lo que no se debe de depender en la existencia de un reloj global para hacer posible la ejecución de un algoritmo de este tipo. Por otro lado tenemos los problemas de la escalabilidad con respecto a la localización o área de implementación de un sistema distribuido. Una de las principales razones por las cuales resulta difícil escalar los sistemas distribuidos que existen actualmente, es que dichos sistemas fueron diseñados para trabajar redes de acceso locales (LANs) y que están basados en una comunicación síncrona. En este tipo de comunicación el cliente hace la solicitud de un servicio y hace un bloqueo de la comunicación hasta que recibe la respuesta. Este acercamiento por lo general trabaja bien en LANs en las que la comunicación entre dos máquinas por lo general no toma más de algunos cientos de microsegundos. En el caso de las WANs, tenemos que tomar en cuenta que la comunicación entre los procesos pudiese tomar varios cientos de milisegundos, lo que representa un alentamiento muy considerable del sistema. Otro problema a considerar es que la comunicación en una WAN es poco confiable y en la gran mayoría de los casos es punto a punto, al contrario de las redes locales que generalmente son muy confiables y permiten hacer difusiones o transmisiones de tipo “broadcast”, lo que hace mucho más fácil el desarrollo de sistemas distribuidos. La escalabilidad con respecto a la localización o área de implementación esta directamente relacionada con los problemas de soluciones centralizadas comentados anteriormente. Si tenemos un sistema con muchos componentes centralizados, es muy claro que la escalabilidad del área de implementación será imitada gracias a los problemas de desempeño y confiabilidad que trae consigo la implementación en un área de redes extensa. Además, los componentes centralizados también provocan el desperdicio de recursos de red. Finalmente, podemos mencionar los problemas que acarrea la escalabilidad de la administración de un sistema distribuido. Este problema se da cuando un sistema distribuido de expande a otro dominio, que por lo general contará con



diferentes políticas de uso y pago de recursos, administración y seguridad. Por lo general cuando esto pasa se deben de tomar al menos dos tipos de medidas de seguridad: El sistema distribuido tiene que protegerse de ataques malignos provenientes del nuevo dominio, y restringir el acceso a los servicios y datos que no están a disponibilidad de los usuarios del mismo. El nuevo dominio tiene que protegerse de ataques malignos provenientes del sistema distribuido. Básicamente, el nuevo dominio no sabe que tipo de información puede esperar del código enviado por el nuevo dominio por lo que pudiera decidir limitar los permisos de acceso a dicho código. Técnicas de Escalabilidad Una vez que mencionamos ya los problemas de la escalabilidad, analizaremos algunas maneras de solucionar dichos problemas. Como los problemas de escalabilidad de los sistemas distribuidos se manifiestan como problemas de rendimiento causados por la capacidad limitada de servidores y de las redes de comunicaciones, existen solamente tres técnicas de escalabilidad: eliminar la latencia de las comunicaciones, distribución y replicación. Eliminar la latencia de las comunicaciones es útil en el caso de querer lograr la escalabilidad geográfica de un sistema, la idea básica es simple: tratar de evitar la espera de respuestas a las peticiones que se hagan a servicios remotos lo más que se pueda. Esencialmente, esto significa que se tiene que construir la aplicación que realiza las peticiones de tal manera que use solamente métodos de comunicación asíncronos, es decir, que el cliente envía la petición al servidor, mientras espera la respuesta el cliente aprovecha ese tiempo para realizar tareas locales más importantes y cuando recibe la respuesta del servidor, el proceso que se estaba realizando se interrumpe y se atiende la respuesta recibida. Esta solución parece fácil, sin embargo, hay muchas aplicaciones que no pueden hacer un uso efectivo de la comunicación asíncrona, por ejemplo, aplicaciones interactivas en las que el usuario no tiene nada mejor que hacer más que esperar la respuesta del servidor, por que esta se tiene que dar lo más rápido que sea posible. En dichos casos, es mucho mejor solucionar el problema de la latencia reduciendo el tráfico generado entre el cliente y el servidor cuando se comunican entre sí; esto lo podemos lograr moviendo parte de la computación que normalmente se hace del lado del servidor al cliente, para que así sea el mismo proceso que hace la solicitud del servicio quien tenga que procesarlo. Otra técnica importante para lograr la escalabilidad es la distribución, que consiste en tomar un elemento, separarlo en partes pequeñas y distribuir esas partes en todo el sistema. Un ejemplo de un sistema distribuido que hace uso de la distribución es el servicio de nombre de dominio (DNS), el cual esta distribuido en diferentes servidores que permiten el acceso a la misma información a todos



los usuarios, sin necesidad de tener un sólo servidor que proporcione este servicio. En la mayoría de los casos, los problemas de escalabilidad los vemos reflejados en el rendimiento del sistema, por lo que generalmente la replicación de los componentes del sistema distribuido puede resultar ser una buena idea. La replicación aumenta la disponibilidad de los componentes del sistema y además ayuda a balancear la carga entre los componentes que se replican, con lo que se logra una mejora del rendimiento del sistema. Si consideramos un sistema que se encuentra distribuido en una red muy extensa, el hecho de tener una copia de algún componente más cerca, también mejora el rendimiento del sistema puesto que soluciona los problemas de latencia de las comunicaciones que ya mencionamos anteriormente. Una forma especial de replicación es el Cacheo, el cual consiste en guardar una copia de algún recurso (por lo general, de datos) de forma temporal en un lugar cercano al cliente, para que éste lo pueda acceder más fácilmente. En contraste con la replicación, el cachear un recurso es una decisión que es tomada por el cliente, y no por los diseñadotes del sistema. Un problema muy serio que puede traer el cacheo, es que las copias que se hacen del recurso (o de datos) pueden no actualizarse a su debido tiempo, por lo que al haber varias copias diferentes del mismo recurso, lo que provoca problemas de consistencia dentro del sistema; el nivel de inconsistencia que pueda ser tolerado por un sistema depende del uso que se le da a al recurso que se esta replicando, en el caso de páginas Web estáticas, por ejemplo, pudiese ser bastante tolerable, sin embargo, en el caso de páginas dinámicas o de sistemas en tiempo real, la replicación puede traer consigo muchos problemas. 1.1.2.5 Tratamiento de Fallos El fallo tanto del hardware como el software es algo prácticamente inevitable, y por más confiable que pueda parecer algún componente, siempre es importante estar preparado para cuando este falle. En un sistema centralizado por lo general el fallo de cualquier componente del sistema provoca que todos los servicios que este ofrece dejen de funcionar, en cambio, en un sistema distribuido, los fallos son parciales, puesto que solo afectan a los servicios que el componente que fallo este prestando, mientras que otros servicios que prestan otros componentes siguen funcionando. El tratamiento de fallos en un sistema distribuido es una tarea difícil, pero que se puede lograr si se utilizan las técnicas adecuadas, según el sistema que se desee proteger. Algunas de las técnicas más comunes son: Detección de Fallos: obviamente no es posible tratar un fallo si este no se ha detectado, sin embargo, la detección de un fallo dentro de un sistema distribuido puede no ser tan sencillo como parece, recordemos que además de



componentes de hardware y software, los sistemas distribuidos operan gracias a la transmisión de mensajes, y el funcionamiento del sistema depende en gran parte de estas transmisiones de datos entre los diferentes componentes; un fallo en la transmisión de datos entre componentes no es fácil detectar, pero es algo que podemos esperar (dependiendo del medio por el que se haga la transmisión y otras condiciones) y al saber que existe la posibilidad de ese fallo, podemos monitorear y aplicar técnicas que aseguren que dicha transmisión siempre sea correcta. Enmascaramiento de Fallos: una vez que un fallo es detectado, es importante encontrar la manera para que un usuario del sistema no note dicho fallo y que pueda seguir utilizando el sistema de manera normal, esto es, ocultar los fallos del sistema y encargarse de que los servicios que se ofrecen al cliente nunca sean interrumpidos. Son muchos ejemplos del enmascaramiento de fallos, en el caso de un mensaje que se corrompió al ser enviado, una manera de ocultar el fallo es haciendo la solicitud de reenvío del mensaje, y de esta manera el usuario nunca notará que hubo un problema. Otro ejemplo lo dan las técnicas de redundancia que explicaremos más adelante, pero que básicamente consiste en tener disponibles varios elementos que puedan dar el mismo servicio y que en caso de que uno falle, otro este en la disponibilidad de realizar el trabajo en su lugar, esto puede darse cuando fallan componentes de un servidor (discos duros, tarjetas de red, etc.), o incluso cuando fallan las conexiones a la red o los sistemas de bases de datos. Tolerancia a Fallos: es importante saber cuando un sistema puede llegar a tener ciertos problemas sin que estos afecten de manera grave al usuario de los servicios proporcionados, para así, ignorar la ocurrencia de dichos fallos cuando la aplicación lo soporte, o bien, hacer saber al cliente que hay un problema en lugar de gastar tiempo y recursos innecesarios para corregirlo cuando probablemente el problema no se pueda arreglar rápido y el cliente termine por abortar el proceso; Pretender arreglar de manera inmediata todos los problemas que puedan surgir en un sistema puede resultar incluso dañino para el mismo sistema, puesto que hay problemas que mientras son arreglados pueden afectar el rendimiento de otros componentes del sistema que sí están trabajando. Recuperación Frente a Fallos: Una vez que fue detectado un fallo y que se ha decidido arreglarlo, hay que encontrar la mejor manera de hacerlo, y además, de recuperar el estado del sistema antes de que ocurriera el fallo; esto requiere del software adecuado para poder reconstruir o bien retractar los cambios que no fueron completados al momento en que fue interrumpido el sistema, un ejemplo de esto lo podemos ver en los sistemas manejadores de bases de datos, que se sirven de una bitácora de las transacciones que se realizan y de acuerdo a esta bitácora se decide reconstruir o retractar las transacciones hechas sobre la base de datos antes de que se interrumpiera el funcionamiento de la misma.



Redundancia: un sistema distribuido puede lograr ser tolerante a fallos gracias a la utilización de componentes redundantes dentro del sistema. La redundancia se logra con la replicación de dichos componentes y con la habilidad del sistema de recurrir a los componentes de respaldo en caso de que el componente de uso primario falle, todo esto por supuesto, sin que el usuario se percate de lo que esta sucediendo. La redundancia se puede dar en muchas partes del sistema: componentes internos de los servidores, servidores de aplicaciones, de Web, de archivos, de correo o de bases de datos, sistemas de almacenamiento, conexiones a la red de comunicación, etc. Es muy importante tomar en cuenta que todos los componentes que estén replicados en el sistema deben mantenerse actualizados para evitar problemas de consistencia, y además, la actualización de la información entre dichos componentes no debe de tener un efecto significativo para las necesidades de transmisión de datos del sistema. Las técnicas antes mencionadas no son las únicas, pero si las más utilizadas, estas técnicas deben de proporcionar las herramientas necesarias para aumentar el grado de disponibilidad de cualquier sistema distribuido, ya que al saber como tratar un fallo del sistema, también es posible encontrar la manera de reconfigurar el sistema para que los servicios que este proporciona no sean interrumpidos, o que en el peor de los casos sólo sean afectados los servicios proporcionados por los componentes afectados. 1.1.2.6 Concurrencia El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia de un sistema distribuido asegura que la consistencia de los datos que se almacenan y que se procesan en el sistema se mantienen en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin embargo, esto puede afectar mucho el desempeño de un sistema distribuido dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, es decir, el número de transacciones simultáneas activas, es probablemente el parámetro más importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de los datos y el mantenimiento de un alto nivel de concurrencia. Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalías. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en los datos almacenados. En segundo término, pueden presentarse recuperaciones de información inconsistentes. Las técnicas que se utilizan para asegurar un control de concurrencia de un sistema distribuido, como hilos, semáforos, candados, etc., se discutirán más adelante, en la parte de análisis de la arquitectura de cliente-servidor.



1.1.2.7 Transparencia Se dice que un sistema distribuido es transparente, cuando este es capaz de presentarse ante los usuarios y las aplicaciones como si fuese un sistema que corre en una sola computadora, y no como un sistema cuyos procesos y recursos están distribuidos físicamente en varias computadoras. 1.1.2.7.1 Tipos de Transparencia Según el Manual de Referencia ANSA y el Modelo de Referencia para el Procesamiento Distribuido Abierto de la Organización Internacional de Estándares (ISO 1995), el concepto de transparencia de puede aplicar a 8 aspectos diferentes de un sistema distribuido: Transparencia de Acceso: oculta las diferencias entre la representación de los datos y la manera en que los recursos son accedidos. Transparencia de Ubicación: oculta la localización de los recursos y permite el acceso a los mismos sin la necesidad de conocer su localización. Transparencia de Migración: oculta que un recurso o un cliente del sistema sea reubicado, lo que permite hacer dichas reubicaciones sin afectar la operación de los usuarios y los servicios. Transparencia de Recolocación: oculta que un recurso o un cliente del sistema pueda moverse a una ubicación diferente mientras están en uso. Transparencia de Replicación: oculta la existencia de múltiples ejemplares del mismo recurso. Transparencia de Concurrencia: oculta que un recurso sea compartido por varios usuarios sin interferir entre ellos mismos. Transparencia Frente a Fallos: oculta el fallo y recuperación de un recurso dentro del sistema, dejando que los usuarios terminen sus tareas a pesar de los fallos de hardware o software que pudieran presentarse. Transparencia de Persistencia: oculta si un recurso (de software) esta almacenado en memoria o en disco. Desde el punto de vista de los usuarios, la transparencia se logra cuando: Sus pedidos se satisfacen con ejecuciones en paralelo en distintas máquinas. Se utilizan una variedad de servidores de archivos. El usuario no necesita saberlo ni notarlo. La transparencia desde el punto de vista de los programas significa diseñar la interfaz de llamadas al sistema de modo que no sea visible la existencia de varios procesadores.



No es transparente un sistema donde el acceso a los archivos remotos se realice mediante: El establecimiento explícito de una conexión en la red con un servidor remoto. El envío posterior de mensajes, donde el acceso a los servicios remotos será distinto al acceso a los servicios locales. Con todo esto en mente es posible diseñar un sistema que cuente con las características necesarias para lograr la transparencia en tantos aspectos como sea posible. Los dos más importantes son la transparencia de acceso y la transparencia de ubicación, la primera se relaciona con la forma en que representamos los datos en un sistema distribuido, es importante presentar al usuario o a los programadores el acceso indistinto a recursos locales o remotos, sin que este se de cuenta de la ubicación de los mismos, lo que al mismo tiempo nos conduce a tener transparencia de ubicación dentro del sistema. Como no se sabe donde están localizados los recursos, tampoco se debe de saber si estos se mueven a una nueva ubicación, se este o no utilizando el sistema, esto es lo que se conoce como transparencia de Migración y Recolocación respectivamente. Ejemplos de transparencia de acceso, ubicación y migración es el sistema de nombre de dominio utilizado por los usuarios de Internet, estos utilizan un nombre de dominio como “dominio.com” para acceder este sitio, sin importar en donde este localizado el sitio de Internet, el usuario podrá acceder al servidor en el que se este hospedando la página, y si se decide mover este sitio a otro servidor, basta con redireccionar al cliente al servidor adecuado, sin que el cliente lo note. Por su lado, si el cliente esta accediendo al sitio desde una conexión inalámbrica dentro de su lugar de trabajo y esta en movimiento, es posible seguir proporcionando servicios sin interrupciones al cliente siempre y cuando el sistema sea transparente a la recolocación y permita que el cliente siga conectado a pesar de cambiar su ubicación física. Por otro lado, la replicación juega un papel muy importante dentro de un sistema distribuido, en el caso de los nombre de domino, los servidores DNS trabajan en un sistema de replicación distribuida organizado jerárquicamente que hace posible el acceso simultáneo a millones de usuarios que requieren de la información que contiene esta base de datos, sin embargo, la transparencia de la replicación en el sistema consiste en esconder que existen varias copias de un mismo recurso, y por lo general implica que dentro del mismo sistema se cuenta con transparencia de ubicación, puesto que de otra manera sería imposible acceder a las copias de los recursos con que se cuenta. La idea de un sistema distribuido es poder proporcionar a sus usuarios un servicio simultáneo a un mismo recurso; es entonces muy común que varios usuarios intenten hacer uso del mismo recurso al mismo tiempo y que traten de



competir por el uso de dicho recurso; en estos casos la transparencia de concurrencia nos ayuda a ocultar al usuario que además de él, hay otros usando o intentando usar el mismo recurso. El reto más interesante de esta parte del diseño de un sistema distribuido es que también se tiene que considerar la consistencia de los datos que se almacenarán en el sistema, por lo que habrá que tomar decisiones en cuanto a las técnicas de candados y de uso de semáforos a utilizarse para lograr tener un sistema concurrente y a su vez consistente. La transparencia frente a fallos consiste en esconder cualquier falla que ocurra en el sistema para que el usuario pueda hacer uso del mismo a pesar de que alguno de sus componentes no este trabajando como es debido, uno de los retos más desafiantes de esta tarea es saber distinguir entre recursos que están fallando y recursos que simplemente están siendo accedidos por muchos usuarios y cuya respuesta puede alentarse. Es importante tener un buen esquema de replicación y de balanceo de cargas para evitar estas situaciones, pero al ser prácticamente inevitables es necesario considerar que hacer cuando el sistema esta en una situación como la antes mencionada, y sobre todo determinar que tipo de respuesta enviar al cliente para que este no se de cuenta de las fallas del sistema. 1.1.2.7.2 Grado de Transparencia A pesar de que la transparencia es una característica generalmente deseable para cualquier sistema distribuido, hay situaciones en las que el pretender enmascarar todos los aspectos relacionados con la distribución de los componentes del sistema puede no ser lo más óptimo; en algunas ocasiones es mejor hacer del conocimiento del usuario que el sistema esta compuesto por varios elementos y que por más óptima que sea la transmisión de mensajes o la distribución y replicación de componentes, habrá cierto tiempo de respuesta mínimo entre cada transacción que es imposible evitar. Hay también una relación directa entre el nivel de transparenc ia y el rendimiento de un sistema distribuido, por lo que lo ideal es encontrar un bien equilibrio entre ambos factores. Por ejemplo, si pretendemos garantizar la transparencia de replicación en un sistema, es necesario que el usuario sepa que para garanti zar la consistencia de la información es necesario actualizar todos los componentes replicados cuando se hace un cambio, por lo que el acceso al sistema puede verse interrumpido por algunos segundos mientras esta operación se lleva a cabo. Es muy importante considerar la transparencia como uno de los principales objetivos del diseño e implementación de un sistema distribuido, sin embargo, es importante tener en consideración otros factores que pueden ser afectados por la transparencia, principalmente el desempeño general del sistema.



1.2. Ventajas y Factores de Distribución En general, los sistemas distribuidos exhiben algunas ventajas sobre los sistemas centralizados que se describen enseguida. 1.2.1 Factores Estratégicos Hoy en día, los clientes, proveedores y compañías se encuentran generalmente en diferentes localidades alejados los unos de los otros. Debido a que todos estos utilizan computadoras, las redes de información que los unen y que les permiten interactuar pueden ofrecer a las empresas mayor competitividad. 1.2.2 Costos de Equipo El cociente precio/desempeño de la suma del poder de los procesadores separados, contra el poder de uno solo centralizado, es mejor cuando están distribuidos, esto lo podemos calcular con base al costo promedio de MIPs (Millones de Instrucciones por Segundo), el cual es mucho mayor en mainframes que en un número fijo de estaciones de trabajo. Sin embargo, cabe mencionar que los mainframes soportan cientos de dispositivos y permiten que miles de clientes compartan los mismos recursos computacionales del mismo, aunque la diferencia en costos es enorme. 1.2.3 Conocimiento y control de los usuarios La gran mayoría de los usuarios de los servicios computacionales son cada vez más cultos y competentes por lo que dichos usuarios desean operar sus propios sistemas, a su manera, por lo que no están contentos con los sistemas centralizados que llevan el control sobre los sistemas que son desarrollados, cuándo, cómo y por quiénes son operados. La computación distribuida ofrece a los usuarios estar más cerca de los procesos y de los datos. 1.2.4 Costos de Desarrollo Cuando se trabaja con un sistema distribuido que cuenta con diferentes módulos de software que pueden integrase como parte de un solo sistema, los usuarios finales interesados en desarrollar sus propias aplicaciones pueden hacerlo utilizando sus propias máquinas, lo que trae como consecuencia la reducción del costo y tiempo de desarrollo de una nueva aplicación. 1.2.5 Interfaces de Usuarios La mayoría de las estaciones de trabajo que se utilizan hoy en día soportan el uso de interfaces gráficas sofisticadas con dispositivos de señalamiento y sistemas de audio y video; esta tecnología resulta ser muy atractiva especialmente para usuarios con diferentes estilos de aprendizaje que por lo



general se decepcionan por los tradicionales repotes o interfaces presentadas en formato de texto o con gráficos de poca calidad. 1.2.6 Flexibilidad y Facilidad de Configuración Los sistemas distribuidos, y en general la computación descentralizada, ofrece muchas opciones para mejorar el desempeño y la fiabilidad de un sistema mediante el uso de procesos y datos redundantes. 1.2.7 Explotación del Hardware Las estaciones de trabajo y computadoras personales permiten el desarrollo de software especializado que hace uso de las características específicas del hardware de la estación de trabajo, cada una de estas estaciones puede ser utilizada como un servidor especializado (por ejemplo, de correos, de Web, de archivos, de bases de datos, etc.) y estos servidores con los que satisfacen las peticiones de clientes que desean hacer uso de los servicios con los que cuenta dicho servidor. A esta configuración se le conoce comúnmente como configuración “cliente-servidor” y se explicará a detalle más adelante. 1.2.8 Nuevas aplicaciones Muchas aplicaciones nuevas de tiempo real requieren ser procesadas y acceder datos de manera local, lo cual es posible solamente si se utiliza un sistema distribuido con estaciones de trabajo distribuidos en los lugares que más se requiera. 1.2.9 Crecimiento El poder total del sistema puede irse incrementando al añadir pequeños sistemas, lo cual es mucho más difícil en un sistema centralizado y caro. Por otro lado, los sistemas distribuidos también exhiben algunas ventajas sobre sistemas aislados. Estas ventajas son: Compartir datos: un sistema distribuido permite compartir datos más fácilmente que los sistemas aislados, que tendrían que duplicarlos en cada nodo para lograrlo. Compartir dispositivos: un sistema distribuido permite acceder dispositivos desde cualquier nodo en forma transparente, lo cual es imposible con los sistemas aislados. El sistema distribuido logra un efecto sinergético. Comunicaciones: la comunicación persona a persona es factible en los sistemas distribuidos, en los sistemas aislados no.



Flexibilidad: La distribución de las cargas de trabajo es factible en el sistema distribuido, se puede incrementar el poder de cómputo.

1.3. Desventajas y Factores a Considerar Así como los sistemas distribuidos exhiben grandes ventajas, también se pueden identificar algunas desventajas, algunas de ellas tan serias que han frenado la producción comercial de sistemas distribuidos en la actualidad. 1.3.1 Falta de Estándares La falta de estándares y herramientas de desarrollo para ambientes distribuidos pueden crear graves problemas de compatibilidad, portabilidad e interconectividad en los sistemas distribuidos. Esto se da cuanto se crean muchas copias incompatibles de la misma aplicación. El desarrollo y uso de estándares para aplicaciones, computadoras y redes son desarrolladas en lugares, por personas y en tiempos diferentes, lo cual resulta muy complicado, y es por eso que es común ver este tipo de problemas en un sistema distribuido. 1.3.2 Complejidad del Diseño Los grandes sistemas de computadoras pueden distribuirse en muchas computadoras, sin embargo, separar el sistema en muchas partes y decidir en que lugar van a residir dichas partes, no es una tarea trivial. Los problemas de compartir datos y recursos son tan complejos que los mecanismos de solución generan mucha sobrecarga al sistema haciéndolo ineficiente. El verificar, por ejemplo, quiénes tienen acceso a algunos recursos y quiénes no, el aplicar los mecanismos de protección y registro de permisos consume demasiados recursos. En la actualidad, las soluciones para estos problemas son incipientes. 1.3.3 Falta de Infraestructura en Soporte y Administración Hasta ahora muchos de los problemas de administración y soporte que demanda un sistema distribuido no han sido solucionados, y las soluciones que existen para algunos otros problemas son limitadas. Algunos ejemplos de estos problemas son la planeación de sistemas de información de acuerdo a la cambiante tecnología que hay hoy en día, el manejo de recursos distribuidos y el diseño de la estructura organizacional para la computación distribuida. 1.3.4 Seguridad e Integridad La distribución de datos y de programas en múltiples localidades pueden crear muchos problemas de seguridad e integridad que no con fáciles de solucionar y que por lo general requieren también de un proceso paralelo que ayude a solucionar dichos problemas, por lo que la carga del sistema aumenta y el rendimiento en general puede verse afectado.



1.3.5 Opciones La disponibilidad de muchas opciones y decisiones puede ser tanto buena, como mala. En ocasiones tener muchas opciones nos quita tiempo, puesto que tenemos que analizar, entender y probar todas las que están disponibles antes de llegar a tomar una decisión cobre cual es la mejor. Por el lado contrario, el tener muchas opciones nos permite diseñar un sistema que este conformado por los elementos que mejor satisfagan las necesidades de los usuarios.

1.4. Evolución 1.4.1 Etapas de la evolución de los sistemas distribuidos La computación distribuida ha evolucionado en los últimos veinte años y continuará evolucionando por muchos años más. Durante esta evolución, hemos acumulado muchos términos tal como procesamiento distribuido, procesamiento distribuido cooperativo, procesamiento distribuido de datos, computación cliente-servidor, computación en red y computación en súper-red. Brevemente veremos la evolución y trataremos de poner en perspectiva algunos de éstos términos. Durante los 70’s, la computación distribuida estaba caracterizada por mainframes y mini computadoras interconectadas a través de redes de área amplia (WANs). Éstas redes eran lentas, en el rango de 2400 a 9600 bits por segundo (bps) y las computadoras intercambiaban información a través de emulación de terminales y transferencia de archivos. Regularmente, las mini computadoras eran emuladas como terminales tal que los datos en la mainframe pudieran ser accedidos a través de emulación de terminal. En algunos casos, los archivos eran transferidos entre mainframes y mini computadoras a través de paquetes de transferencia de archivos. Muchos paquetes de transferencia de archivos y emulación de terminal fueron desarrollados en este periodo. Aunque se realizó mucha investigación en bases de datos distribuidas en este periodo, esta tecnología no fue utilizada ni comercializada. Dos términos se volvieron populares en esta época: (1) procesamiento distribuido que se refiere a procesos de aplicaciones en múltiples computadoras y (2) procesamiento distribuido de datos que se refiere a datos como a procesos en diferentes computadoras. Independientemente de los términos utilizados, las tecnologías de intercambio de información fueron transferencia de archivos y emulación de terminales. Durante los 80’s sucedieron tres cambios fundamentales: proliferación de computadoras de escritorio (desktop computers), disponibilidad de redes de área local (LANs) y el uso común de mayores velocidades de transferencia de datos (4 a 16 millones de bits por segundo para LANs y 56 Kbps a 1.54 Mbps para WANs). En esta época, los sistemas de computación distribuida consistían de mainframes, mini computadoras y computadoras de escritorio,



interconectadas a través de LANs y WANs. Además de procesamiento distribuido y procesamiento distribuido de datos, el término computación en red se volvió popular para describir a las redes como un valor agregado a las computadoras. Aunque alguna paquetería de bases de datos distribuidas y cliente-servidor salieron al mercado, lo más utilizado seguía siendo transferencia de archivos y emulación de terminal. Durante los 90’s se llevaron a cabo muchos cambios fundamentales, se desarrolló software de bases de datos distribuidas y cliente-servidor, para llevar a cabo la transferencia de datos de manera transparente entre procesos remotos, proliferación de poderosas y baratas computadoras de escritorio y computadoras portátiles, énfasis en estándares y disponibilidad de redes de transferencia de datos sumamente rápidas (100 Mbps y más para LANs, WANs y redes de área metropolitana MANs). Los sistemas de computación distribuida de esta época consistían en muchas computadoras de diferentes capacidades y de diferentes fabricantes conectadas a través de áreas geográficas grandes sobre redes de alta transferencia de datos de difere ntes proveedores. Además de los términos utilizados anteriormente, el término procesamiento cooperativo distribuido entra en boga porque señala la característica principal de éstos sistemas que permiten el intercambio de información interactivamente entre los procesos de diferentes computadoras. La computación Cliente -Servidor (C-S) es la forma más popular de procesamiento cooperativo distribuido. Permite que las aplicaciones del cliente (procesadores de consultas a bases de datos, interfaces de usuario, etc.) tengan acceso a servidores (servidores de bases de datos, servidores de archivos, servidores de impresoras, etc.) transparentemente a través de una red. La computación C-S representa un gran avance con respecto a los sistemas distribuidos basados en la emulación de terminal y transferencia de archivos. En la actualidad, los Sistemas de Computación Distribuida hacen que toda la red computacional parezca como una sola gran computadora donde diferentes actividades se llevarán a cabo en diferentes computadoras. Estos sistemas también incluyen supercomputadoras conectadas a través de redes Gigabit por segundo, y supervisados por software de administración (Sistemas Operativos Distribuidos). Dichos sistemas, llamados súper computación en red, son ampliamente utilizados debido a su gran potencial. Por otro lado, el desarrollo en computación neuronal es de gran interés porque intenta simular los procesos de pensamiento del cerebro humano. Básicamente, el cerebro humano consta de millones de millones de neuronas, donde cada neurona se comporta como un CPU. Sin embargo, las neuronas son lentas (cada neurona opera a 100 Hertz, inferior a 40 millones de Hertz, velocidad de algunos procesadores actuales). Pero las neuronas están interconectadas entre sí a través de nervios (cada neurona puede tener cuando menos 1000 interacciones con otras neuronas). Por lo tanto, el cerebro humano se puede visualizar como una red (Red Neuronal) en la que millones de millones de



neuronas están interconectadas de muchas maneras. Sin embargo, una neurona aislada es lenta. Computadoras muy rápidas conectadas a través de redes sumamente rápidas crean grandes oportunidades para el desarrollo de nuevas aplicaciones en inteligencia artificial, medicina, ingeniería, finanzas, etcétera. 1.4.2 Impacto de la orientación a objetos y componentes Para entender el proceso que llevó al nacimiento del concepto que hoy se conoce como orientación a objetos habría que volver unas cuantas décadas atrás, hasta la época en la que reinaban FORTRAN y BASIC. La programación de ese tiempo o de ese entonces estaba dedicada a procesos lineales (época de la programación lineal), en los cuales las tareas se ejecutaban una a una en una secuencia preestablecida. Pero ese enfoque funcionó sin problemas durante los primeros años, hasta que los requerimientos comenzaron a crecer en tamaño y complejidad, por lo tanto cada vez se volvía más difícil agregar adaptaciones y ampliaciones a los programas ya existentes. La programación estructurada atacó este problema descomponiendo los procesos complejos en otros más sencillos (es una actividad conocida como descomposición modular), y así permitió la reutilización de las partes comunes a toda una aplicación a través de procedimientos y funciones. Para completar la descomposición modular se usaba la metodología “hacia abajo” (topdown), yendo de lo general a lo particular. Se buscaba, primero, entender cuál era la función principal que se necesitaba representar y se la iba subdividiendo en tareas menos complejas. Se intentaba que cada módulo fuera lo más independiente posible del resto para, a futuro, poder restringir el impacto de los cambios en áreas específicas de la aplicación. Hasta el momento se dominaba la complejidad. Pero no fue así. La rueda siguió girando y, aunque resulte sorprendente la fecha, a mediados de los '60 apareció una nueva forma de ver las cosas en el mundo de la programación. La orientación a objetos propulsó el encapsulamiento de comportamientos y datos en un solo conjunto, apartándose del esquema tradicional, en el cual se consideraba de manera aislada la información que se quería manipular de la lógica para conseguirla. Las ventajas que prometía esa nueva perspectiva eran facilitar la colaboración entre desarrolladores, ayudar a administrar la complejidad y brindar la flexibilidad necesaria para lidiar con requerimientos que cambian todo el tiempo. Lentamente, este paradigma fue creciendo y difundiéndose cada vez más. Hoy en día, de ninguna manera podemos ignorarlo como programadores. No creo que alguien considere la creación de un nuevo lenguaje sin incorporar orientación a objetos en su estructura. Así, los lenguajes estructurados (o basados en procedimientos) siguen siendo el primer contacto formal con la programación.



La idea fundamental detrás de cua lquier lenguaje de programación orientado a objetos es combinar en un mismo elemento información y funciones que puedan actuar sobre ella; comportamiento y propiedades fusionados en una sola entidad. La información contenida en un objeto está representada por sus atributos. Cuando se define un atributo o un método como privado, solamente el objeto en cuestión puede accederlo; lo contrario ocurre con aquellos atributos o métodos definidos como públicos, que pueden ser accedidos por cualquier otro objeto. El conjunto de atributos y métodos públicos que permiten a un objeto interactuar con otros se conoce como la interfaz del objeto o de la clase que lo define. El hecho de que la implementación del comportamiento de los objetos esté aislada del entorno nos permite hacer todos los cambios que queramos en ella mientras conservemos intacta la interfaz del objeto, su cara hacia el exterior. Encontraremos además, que la única manera de acceder a la información contenida en un objeto es a través de sus métodos. A pesar de que es posible definir atributos públicos, esto no se considera un buen diseño orientado a objetos, ya que altera el encapsulamiento y hace una especie de "agujero en esa coraza protectora". Cuando conservamos el encapsulamiento, los objetos pueden manipular la información de otros sólo si existen métodos públicos para ese fin (getters y setters). Así, la información se mantiene protegida de alteraciones accidentales o no deseadas. Esto tiene una importancia tremenda. Imaginemos que por error hubiéramos implementado el atributo diámetro como público. Cualquier otro objeto podría modificar destrozando la abstracción del mundo real que tratamos de representar. Diseñar un sistema orientado a objetos también tiene sus riesgos. Las Clases: En casi todos los lenguajes orientados a objetos usamos el concepto de clase para definir y crear las aplicaciones. Una clase es, a la vez, una especificación (como el plano de una casa) y una plantilla o molde para la creación de objetos. Es la definición conceptual de un objeto y, como tal, describe todas las características de un tipo particular de objetos, sus atributos, métodos y los correspondientes privilegios de acceso. Cuando escribimos un programa, definimos clases, una por cada tipo de objeto, para que puedan utilizarse en la creación o en la instanciación de nuevos objetos en memoria durante la ejecución de la aplicación. "Instanciar" objetos a partir de una clase hace que esos objetos se denominen instancias de la clase. Usamos el mismo "molde" para crear todas las instancias de un mismo tipo en nuestro sistema, y podemos pensar en las clases como tipos en nuestro



sistema, y podemos pensar en las clases como tipos de datos, al igual que int o char, pero con una responsabilidad específica en el sistema. Así, una clase Válvula define el comportamiento de todas las instancias (de todas las válvulas) que tengamos en nuestro sistema. A pesar de representar entidades distintas (cada una con su propio estado), todas se comportarán exactamente igual o del mismo modo. Si durante nuestro proceso de diseño descubrimos nuevos tipos de objetos, directamente modificaremos el punto del programa en donde se define la clase que los genera. Ahora, ¿qué ocurre cuando queremos incorporar un nuevo conjunto de objetos que resulta muy similar a algunos de los ya existentes? (Herencia) Podemos manejar esta situación dentro de la orientación a objetos creando una nueva clase derivada de la existente, que retiene o "hereda" los métodos y atributos de su clase padre, y que permite sumar nuevos elementos. Las clases que heredan se denominan subclases de la clase padre o superclase, y el proceso de agregarlas es el de subclasificar (subclassing). Por ejemplo (retomando el ejemplo del sistema para la industria del petróleo, la válvula), supongamos que una vez que tenemos nuestro sistema funcionando, los ingenieros deciden incorporar otro tipo de válvula, una que proporcione un mayor grado de apertura (o en todo caso que es más sofisticada que las demás), junto con un nuevo método para abrir la válvula en la posición deseada y otros métodos privados que permiten conectarla a sensores de posición para saber cuál es su estado. A través de la herencia, los cambios que hagamos a nuestro modelo se propagarán de padres a hijos y así atravesarán todos los niveles que definamos. Podemos construir jerarquías de clases para transmitir estos cambios automáticamente. Polimorfismo: Significa, literalmente, muchas formas. Es una característica de la orientación a objetos que permite que objetos similares puedan reaccionar al mismo mensaje de diferentes maneras. Si consideramos una interfaz de usuario, en el evento de carga podríamos incluir la inicialización de todos los controles (objetos) que contiene. Lo hacemos enviando a todos el mismo mensaje, Reset, pero cada uno de ellos lo implementará a su manera. El polimorfismo juega un papel fundamental, al dejar que objetos que poseen estructuras internas totalmente diferentes puedan compartir una misma interfaz externa. Esto quiere decir que una clase general de operaciones puede ser accedida del mismo modo a pesar de que las implementaciones específicas asociadas con esa operación difieren de un objeto a otro.



La forma más común de implementar este tipo de polimorfismo es a través de una clase con un método abstracto (solamente su definición, no tiene implementación) que es heredado a varias subclases. Cada una de ellas redefine este método de acuerdo con sus necesidades y hace lo que se conoce como overriding. Uno de los problemas que pueden surgir en este caso es que la redefinición del método en las subclases sea totalmente inconsistente con las intenciones originales de ese método en la superclase. También podemos tener polimorfismo por overriding de un método. Para eso definimos conjuntos diferentes de argumentos bajo el nombre de un único método. La acción específica a seguir en cada caso estará determinada por la naturaleza de los parámetros que reciba ese método. Una buena jerarquía de clases será la base la reutilización del código en el que hayamos invertido tiempo y esfuerzo para desarrollar y probar. Con el encapsulamiento podremos modificar las implementaciones de los métodos sin alterar el código existente que depende de la interfaz de nuestras clases. Integrando en un todo las dos anteriores, el polimorfismo nos permitirá crear el código para que se pueda mantener, sencillo de interpretar y flexible. La OOP (Programación Orientada a Objetos) no es sólo clases: Si vamos a ser estrictos, las clases no son una parte esencial de la OOP (sigla en inglés). Pero dada la influencia de C++ y Java, la mayoría de las personas piensa que usar clases es la única manera de escribir un programa con orientación a objetos. En realidad existen dos formas de abordar a la orientación a objetos en un lenguaje: mediante clases (como en todos los lenguajes comerciales, tales como C++, C#, Java y otros) y a través de prototipos (como en Self, Kevo, Omega, todos lenguajes de uso académico). En los primeros, las clases se utilizan como "fábricas" de objetos. En los últimos no se necesita la noción de clase; los objetos pueden crearse de la nada en forma visual o por herencia (a partir de otro objeto), y el código resultante es mucho más claro. 1.4.3 Internet y nueva tecnología en la red Internet surge como consecuencia del establecimiento de estándares de sistemas abiertos. Estos esquemas permitieron la creación una red de redes. De hecho, Internet proviene del inglés inter-networking. Particularmente el protocolo TCP/IP fue uno de los estándares que favoreció la conexión a través de Internet y las aplicaciones que podían trabajar sobre este protocolo.



Conceptualmente, generalmente se confunde la programación para Internet y la programación Web; éste último es un subconjunto del primero. La programación Web utiliza el protocolo HTTP (Hyper Text Transfer Protocol). Tradicionalmente la utilización de aplicaciones Web se efectúa por seres humanos. Sin embargo, nuevos protocolos como SOAP basado en XML abrieron el horizonte a programas cliente que solicitan servicios a otras aplicaciones Web a través de servicios. Tarea Individual Entregar la síntesis del tema de introducción en documento Word, con el nombre INTRODUCCION.DOC Tarea en Equipo Entregar la síntesis en equipo sobre las características de sistemas distribuidos, como CARACTERISTICAS.DOC.



2. Arquitectura Cliente Servidor

2.1. Fundamentos de Arquitectura Cliente Servidor Actividad 2.1 Actividad 2.1 Fundamentos de Arquitectura Cliente Servidor Contestar las preguntas que a continuación se plantean: 1. ¿Qué entiende por Arquitectura Cliente Servidor? 2. ¿Cuáles son los elementos de una Arquitectura Cliente Servidor? 3. ¿Qué características muestra el modelo Cliente Servidor? 4. ¿Cuáles son las ventajas y desventajas del modelo Cliente Servidor? 5. ¿Qué servicios ofrece el modelo Cliente Servidor? Se proporciona Material de Apoyo 2.1, pero además es conveniente que consulte otra fuente de información para resolver las preguntas. Colocar el cuestionario resuelto en Tarea Individual 2.1 Nota Importante: Hasta aquí se han desarrollado las actividades como comprobaciones de lectura, debido al esquema teórico y de fundamentos requeridos en el inicio del curso, más adelante esto nos servirá como base en aplicaciones prácticas. Material de Apoyo 2.1 2.1.1 Definiciones Básicas Para entender el concepto de la arquitectura de cliente servidor, antes es necesario conocer algunas definiciones. Entre las principales definiciones se tiene: 1. Desde un punto de vista conceptual: «Es un modelo para construir sistemas de información, que se sustenta en la idea de repartir el tratamiento de la información y los datos por todo el sistema informático, permitiendo mejorar el rendimiento del sistema global de información»



2. En términos de arquitectura: Los distintos aspectos que caracterizan a una aplicación (proceso, almacenamiento, control y operaciones de entrada y salida de datos) en el sentido más amplio, están situados en más de un computador, los cuales se encuentran interconectados mediante una red de comunicaciones. 3. IBM define al modelo Cliente/Servidor Es la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas. El modelo soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o "clientes'', resultan en un trabajo realizado por otros computadores llamados servidores. Para entender mejor las definiciones antes mencionadas, analizaremos ahora algunos de los conceptos mencionados en dichas definiciones: Un Cliente es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o de las aplicaciones es totalmente transparente para el cliente. Un Servidor es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a través de redes LANs o WANs, para proveer de múltiples servicios a los clientes tales como impresión, acceso a bases de datos, fax, procesamiento de imágenes, etc. Es importante mencionar que un servidor no es necesariamente un dispositivo físico (una computadora) sino que hay que entender al servidor como un proceso que se encarga de atender las peticiones de un cliente. Con estos elementos podemos ya darnos una idea de lo que es el modelo cliente servidor, sin embargo, es necesario analizar más a fondo las características de la arquitectura si queremos llegar a entender por completo el funcionamiento de la misma. 2.1.2. Elementos de la Arquitectura Cliente/Servidor Una arquitectura es un entramado de componentes funcionales que aprovechando diferentes estándares, convenciones, reglas y procesos, permite integrar una amplia gama de productos y servicios informáticos, de manera que pueden ser utilizados eficazmente dentro de la organización.



Debemos señalar que para seleccionar el modelo de una arquitectura, hay que partir del contexto tecnológico y organizativo del momento y, que la arquitectura Cliente/Servidor requiere una determinada especialización de cada uno de los diferentes componentes que la integran. En esta aproximación, y con el objetivo de definir y delimitar el modelo de referencia de una arquitectura Cliente/Servidor, debemos identificar los componentes que permitan articular dicha arquitectura, considerando que toda aplicación de un sistema de información está caracterizada por tres componentes básicos: • Presentación/Captación de Información • Procesos • Almacenamiento de la Información Y se integran en una arquitectura Cliente/Servidor en base a los elementos que caracterizan dicha arquitectura, es decir: • Puestos de Trabajo • Comunicaciones • Servidores De estos elementos debemos destacar: • El Puesto de Trabajo o Cliente “Una Estación de trabajo o microcomputador (PC: Computador Personal) conectado a una red, que le permite acceder y gestionar una serie de recursos”, el cual se perfila como un puesto de trabajo universal. Nos referimos a un microcomputador conectado al sistema de información y en el que se realiza una parte mayoritaria de los procesos. Se trata de un fenómeno en el sector informático. Aquellos responsables informáticos que se oponen a la utilización de los terminales no programables, acaban siendo marginados por la presión de los usuarios. Debemos destacar que el puesto de trabajo basado en un microcomputador conectado a una red, favorece la flexibilidad y el dinamismo en las organizaciones. Entre otras razones, porque permite modificar la ubicación de los puestos de trabajo, dadas las ventajas de la red. • Los Servidores o Back-End. «Una máquina que suministra una serie de servicios como Bases de Datos, Archivos, Comunicaciones,...)». Los Servidores, según la especialización y los requerimientos de los servicios que debe suministrar pueden ser: o Mainframes o Minicomputadoras o Especializados (dispositivos de red, imagen, etc.)



Una característica a considerar es que los diferentes servicios, según el caso, pueden ser suministrados por un único Servidor o por varios Servidores especializados. Las Comunicaciones en sus dos vertientes: • Infraestructura de redes Componentes Hardware y Software que garantizan la conexión física y la transferencia de datos entre los distintos equipos de la red. • Infraestructura de comunicaciones Componentes Hardware y Software que permiten la comunicación y su gestión, entre los clientes y los servidores. La arquitectura Cliente/Servidor es el resultado de la integración de dos culturas. Por un lado, la del Mainframe que aporta capacidad de almacenamiento, integridad y acceso a la información y, por el otro, la del computador que aporta facilidad de uso (cultura de PC), bajo costo, presentación atractiva (aspecto lúdico) y una amplia oferta en productos y aplicaciones. 2.1.3 Características del modelo Cliente/Servidor En el modelo Cliente/Servidor podemos encontrar las siguientes características: 1. El Cliente y el Servidor pueden actuar como una sola entidad y también pueden actuar como entidades separadas, realizando actividades o tareas independientes. 2. Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o en la misma plataforma. 3. Un servidor proporciona servicio a múltiples clientes en forma concurrente. 4. Cada plataforma puede ser escalable independientemente. Los cambios realizados en las plataformas de los Clientes o de los Servidores, ya sean por actualización o por reemplazo tecnológico, se realizan de una manera transparente para el usuario final. 5. La interrelación entre el hardware y el software están basados en una infraestructura poderosa, de tal forma que el acceso a los recursos de la red no muestra la complejidad de los diferentes tipos de formatos de datos y de los protocolos. Un sistema de servidores realiza múltiples funciones al mismo tiempo que presenta una imagen de un sólo sistema a las estaciones Clientes. Esto se logra combinando los recursos de cómputo que se encuentran físicamente separados en un sistema lógico, proporcionando de esta manera el servicio más efectivo para el usuario final.



También es importante hacer notar que las funciones Cliente/Servidor pueden ser dinámicas. Ejemplo, un servidor puede convertirse en cliente cuando realiza la solicitud de servicios a otras plataformas dentro de la red. Tiene capacidad para permitir integrar los equipos ya existentes en una organización, dentro de una arquitectura informática descentralizada y heterogénea. 6. Además se constituye como el nexo de unión más adecuado para reconciliar los sistemas de información basados en mainframes o minicomputadoras, con aquellos otros sustentados en entornos informáticos pequeños y estaciones de trabajo. 7. Designa un modelo de construcción de sistemas informáticos de carácter distribuido. 8. Su representación típica es un centro de trabajo (PC), en donde el usuario dispone de sus propias aplicaciones de oficina y sus propias bases de datos, sin dependencia directa del sistema central de información de la organización, al tiempo que puede acceder a los recursos de este host central y otros sistemas de la organización ponen a su servicio. En consecuencia, parte del control de las aplicaciones se transfieren del computador central (servidor) a los PCs o estaciones de trabajo (clientes), adquiriendo estas plataformas, entonces, un papel protagonista en conjunto del sistema de información. En conclusión, Cliente/Servidor puede incluir múltiples plataformas, bases de datos, redes y sistemas operativos. Estos pueden ser de distintos proveedores, en arquitecturas propietarias y no propietarias y funcionando todos al mismo tiempo. Por lo tanto, su implantación involucra diferentes tipos de estándares: APPC, TCP/IP, OSI, NFS, DRDA corriendo sobre DOS, OS/2, Windows o PC UNIX, en Token-Ring, Ethernet, FDDI o medio coaxial, sólo por mencionar algunas de las posibilidades. Dependiendo de estas características y de su combinación, es el grado de complejidad de una solución C/S. 2.1.4 Ventajas y Desventajas del modelo Cliente/Servidor El esquema Cliente/Servidor posee las siguientes ventajas: a) Uno de los aspectos que más ha promovido el uso de sistemas Cliente/Servidor, es la existencia de plataformas de hardware cada vez más baratas. Esta constituye a su vez una de las más palpables ventajas de este esquema, la posibilidad de utilizar máquinas considerablemente más baratas que las requeridas por una solución centralizada, basada en sistemas grandes. Además, se pueden utilizar componentes, tanto de hardware como de software, de varios fabricantes, lo cual contribuye considerablemente a la reducción de costos y favorece la flexibilidad en la implantación y actualización de soluciones.



b) El esquema Cliente/Servidor facilita la integración entre sistemas diferentes y comparte información permitiendo, por ejemplo que las máquinas ya existentes puedan ser utilizadas pero con interfaces más amigables al usuario. De esta manera, podemos integrar PCs con sistemas medianos y grandes, sin necesidad de que todos tengan que utilizar el mismo sistema operacional. c) Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo este esquema tienen mayor interacción más intuitiva con el usuario. El uso de interfaces gráficas para el usuario, el esquema Cliente/Servidor presenta la ventaja, con respecto a uno centralizado, de que no es siempre necesario transmitir información gráfica por la red pues esta puede residir en el cliente, lo cual permite aprovechar mejor el ancho de banda de la red. d) Una ventaja adicional del uso del esquema Cliente/Servidor es que es más rápido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las herramientas existentes (por ejemplo los servidores de SQL o las herramientas de más bajo nivel como los sockets o el RPC). e) La estructura inherentemente modular facilita además la integración de nuevas tecnologías y el crecimiento de la infraestructura computacional, favoreciendo así la escalabilidad de las soluciones. f) El esquema Cliente/Servidor contribuye además, a proporcionar, a los diferentes departamentos de una organización, soluciones locales, pero permitiendo la integración de la información re levante a nivel global. El esquema Cliente/Servidor tiene algunos inconvenientes que se mencionan a continuación: a) Tiene escasas herramientas para la administración y ajuste del desempeño de los sistemas. b) En el desarrollo de aplicaciones Cliente/Servidor se deben considerar los aspectos, que se mencionan a continuación:

• Los clientes y los servidores deberán utilizar el mismo mecanismo (por ejemplo sockets o RPC), lo cual implica que se deben tener mecanismos generales que existan en diferentes plataformas.

• Además, hay que tener estrategias pare el manejo de errores y para mantener la consistencia de los datos. La seguridad de un esquema Cliente/Servidor es muy importante. Por ejemplo, se deben hacer verificaciones en el cliente y en el servidor. También se puede recurrir a otras técnicas como el encripción.

• El desempeño. Problemas de este estilo pueden presentarse por congestión en la red, dificultad de tráfico de datos, etc.



• Un aspecto directamente relacionado con lo anterior es el de cómo distribuir los datos en la red. En el caso de una organización, por ejemplo, éste puede ser hecho por departamentos, geográficamente, o de otras maneras. Hay que tener en cuenta que en algunos casos, por razones de confiabilidad o eficiencia, se pueden tener datos replicados, y que puede haber actualizaciones simultáneas.

• A otro nivel, una de las decisiones que deben tomar las organizaciones es la de si comprar o desarrollar los diferentes componentes.

2.1.5 Servicios basados en Cliente/Servidor IBM ha orientado sus esfuerzos de desarrollo de productos ha satisfacer los siguientes servicios: a) Servicios de Datos e Impresión: Servicios que permiten compartir archivos, bases de datos, impresoras y graficadores (plotters). Administración de las colas de impresión en diferentes dispositivos. b) Servicios de Comunicaciones: Aseguran que cada componente físico de la red sea capaz de comunicarse exitosamente con otros componentes, tales como LAN a LAN y LAN a WAN. El sistema puede incluir dispositivos de comunicaciones que manejen diferentes tipos de protocolos para conectar sistemas heterogéneos. c) Servicio de Administración: Administración de Sistemas involucra administración de cambios, de problemas, operaciones, configuración y rendimiento. Administración de Cambios: es definida como las actividades involucradas en la planeación, programación, distribución, instalación y registro de hardware y software en una red distribuida. Administración de Problemas: involucra la determinación de los mismos, la identificación de su origen en una red y su solución. Administración de Operaciones: es definida como la administración del uso de los sistemas y de los recursos para soportar la carga de trabajo de la organización, la cual incluye operaciones automatizadas y remotas. Administración de Configuración: es el manejo de las relaciones lógicas y físicas entre los recursos de la red.



Administración del Rendimiento: es un conjunto de actividades tales como la recopilación de datos de desempeño, afinamiento, distribución de carga de trabajo y el planeamiento de la capacidad para las redes distribuidas. Administración de Sistemas: también incluye servicios de respaldo, recuperación de datos, seguridad de recursos de cómputo y distribución y mantenimiento de software. d) Servicios de Aplicación: Si el recurso compartido es una parte de una aplicación (una función de la aplicación), estamos hablando de servicios de aplicación. Cada uno de los procesadores participantes en un ambiente Cliente/Servidor puede mantener parte del código de la aplicación, el cual debe ser compartido por todos ellos (interoperabilidad). Esto significa que las partes de una aplicación pueden ser distribuidas en varios procesadores, locales o remotos. El diseño de las funciones de la aplicación no debe estar ligado a un computador, lo que permite transportar la aplicación de un procesador a otro, sin modificaciones (portabilidad). Una ventaja derivada de esto, es que la aplicación puede estar óptimamente ubicada dentro de una red en base a las necesidades: de recursos de cómputo y de la organización. Tarea Individual 2.1 Entregar el cuestionario de Fundamentos de Arquitectura C/S en documento Word, con el nombre FUNDAMENTOSCS.DOC

2.2. Comunicación entre Procesos Objetivos 2.2 Objetivos Comunicación entre Procesos Con la finalidad de enfatizar los conceptos más representativos del entorno de comunicación entre procesos se realizarán dos ejercicios prácticos sobre el manejo de sockets y RPC. El protocolo TCP/IP y conjuntos de UDP son dominantes, incluso para los sistemas distribuidos que son implementados sobre redes de área local. Los sockets son mecanismos en estos protocolos que permiten que un cliente y servidor puedan comunicarse escribiendo a o leyendo de sus sockets. La mayoría de los servicios Web y las aplicaciones de acceso remoto actuales utilizan un enfoque de llamadas a procedimientos remotos (RPC, Remote



Procedure Call). Se crea lo que parece ser una llamada de función y se pone en marcha un sistema de fondo que hace que tenga lugar en el servidor. El sistema controla el intercambio de mensajes entre cliente y servidor. Actividades 2.2 Actividades Comunicación entre Procesos Realizar el Ejercicio Sockets TCP anexo. Colocar informe de ejercicio en Tarea Individual 2.2.1 Realizar el Ejercicio RPC anexo. Colocar informe de ejercicio en Tarea Individual 2.2.2 Nota Importante: Antes de iniciar el ejercicio de RPC debe concluir el ejercicio de Sockets TCP. Sugerencia: Antes de realizar los ejercicios se recomienda que revise el Material de Apoyo 2.2 para reafirmar sus conocimientos sobre comunicación entre procesos. EJERCICIO SOCKETS TCP En aplicaciones Cliente Servidor, el servidor proporciona algún servicio, como procesamiento de consultas en base de datos o envío de precios actualizados de existencias. El cliente utiliza el servicio proporcionado por el servidor, ya sea el despliegue de resultados de la consulta de base de datos al usuario o hacer recomendaciones de compra de existencias a un consumidor. La comunicación que ocurre entre el cliente y el servidor debe ser confiable. Es decir, ningún dato puede dejarse caer y debe llegar en el lado del cliente en el mismo orden en el que el servidor lo envió. En el primer caso ambos programas deben conectarse entre ellos con un socket y hasta que no esté establecida correctamente la conexión, ninguno de los dos puede transmitir datos. Esta es la parte TCP del protocolo TCP/IP, y garantiza que todos los datos van a llegar de un programa al otro correctamente. Se utiliza cuando la información a transmitir es importante, no se puede perder ningún dato y no importa que los programas se queden "bloqueados" esperando o transmitiendo datos. Si uno de los programas está atareado en otra cosa y no atiende la comunicación, el otro quedará bloqueado hasta que el primero lea o escriba los datos. En el segundo caso, no es necesario que los programas se conecten. Cualquiera de ellos puede transmitir datos en cualquier momento, independientemente de que el otro programa esté "escuchando" o no. Es el



llamado protocolo UDP, y garantiza que los datos que lleguen son correctos, pero no garantiza que lleguen todos. Se utiliza cuando es muy importante que el programa no se quede bloqueado y no importa que se pierdan datos. En este ejercicio práctico trataremos como da soporte Java a Socket TCP. ESCENARIO En este ejercicio veremos las clases de Java que nos permite trabajan de forma sencilla con sockets TCP. La interfaz Java que da soporte a sockets TCP está constituida por las clases ServerSocket y Socket. 1. ServerSocket: es utilizada por un servidor para crear un socket en el puerto en el que escucha las peticiones de conexión de los clientes. Su método accept toma una petición de conexión de la cola, o si la cola está vacía, se bloquea hasta que llega una petición. El resultado de ejecutar accept es una instancia de Socket, a través del cual el servidor tiene acceso a los datos enviados por el cliente. 2. Socket: es utilizada tanto por el cliente como por el servidor. El cliente crea un socket especificando el nombre DNS del host y el puerto del servidor, así se crea el socket local y además se conecta con el servicio. Esta clase proporciona los métodos getInputStream y getOutputStream para acceder a los dos streams asociados a un socket (son bidireccionales), y devuelve tipos de datos InputStream y OutputStream, respectivamente, a partir de los cuales podemos construir BufferedReader y PrintWriter, respectivamente, para poder procesar los datos de forma más sencilla. La forma general de implementar un cliente será: 1. Crear un objeto de la clase Socket, indicando host y puerto donde corre el servicio. 2. Obtener las referencias al stream de entrada y al de salida al socket. 3. Leer desde y escribir en el stream de acuerdo al protocolo del servicio. Para ello emplear alguna de las facilidades del paquete java.io. 4. Cerrar los streams. 5. Cerrar el socket. La forma de implementar un servidor será:



1. Crear un objeto de la clase ServerSocket para escuchar peticiones en el puerto asignado al servicio. 2. Esperar solicitudes de clientes 3. Cuando se produce una solicitud:

• Aceptar la conexión obteniendo un objeto de la clase Socket • Obtener las referencias al stream de entrada y al de salida al socket

anterior. • Leer datos del socket, procesarlos y enviar respuestas al cliente,

escribiendo en el stream del socket. Para ello emplear alguna de las facilidades del paquete java.io.

4. Cerrar los streams. 5. Cerrar los sockets. Vamos a ver todo esto con un sencillo ejemplo: una aplicación cliente/servidor de eco, es decir, el servidor repite lo mismo que le envía el cliente, hasta que el cliente quiere finalizar el servicio, para lo cual envía la palabra "Bye" al servidor. CÓDIGO DEL CLIENTE Analizar el siguiente código del cliente EcoCliente.java: import java.net.*; import java.io.*; public class EcoCliente { public static void main(String[] args) throws IOException { Socket socketCliente = null; BufferedReader entrada = null; PrintWriter salida = null; // Creamos un socket en el lado cliente, enlazado con un // servidor que está en la misma máquina que el cliente // y que escucha en el puerto 4444 try { socketCliente = new Socket("localhost", 4444); // Obtenemos el canal de entrada entrada = new BufferedReader(new InputStreamReader(socketCliente.getInputStream()));



// Obtenemos el canal de salida salida = new PrintWriter(new BufferedWriter(new OutputStreamWriter(socketCliente.getOutputStream())),true); } catch (IOException e) { System.err.println("No puede establer canales de E/S para la conexión"); System.exit(-1); } BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in)); String linea; // El programa cliente no analiza los mensajes enviados por el // usario, simplemente los reenvía al servidor hasta que este // se despide con "Bye" try { while (true) { // Leo la entrada del usuario linea = stdIn.readLine(); // La envia al servidor salida.println(linea); // Envía a la salida estándar la respuesta del servidor linea = entrada.readLine(); System.out.println("Respuesta servidor: " + linea); // Si es "Bye" es que finaliza la comunicación if (linea.equals("Bye")) break; } } catch (IOException e) { System.out.println("IOException: " + e.getMessage()); } // Libera recursos salida.close(); entrada.close(); stdIn.close(); socketCliente.close(); } } CÓDIGO DEL SERVIDOR



Analizar el siguiente código del servidor EcoServidor.java: import java.io.*; import java.net.*; public class EcoServidor { public static final int PORT = 4444; public static void main(String[] args) throws IOException { // Establece el puerto en el que escucha peticiones ServerSocket socketServidor = null; try { socketServidor = new ServerSocket(PORT); } catch (IOException e) { System.out.println("No puede escuchar en el puerto: " + PORT); System.exit(-1); } Socket socketCliente = null; BufferedReader entrada = null; PrintWriter salida = null; System.out.println("Escuchando: " + socketServidor); try { // Se bloquea hasta que recibe alguna petición de un cliente // abriendo un socket para el cliente socketCliente = socketServidor.accept(); System.out.println("Connexión acceptada: "+ socketCliente); // Establece canal de entrada entrada = new BufferedReader(new InputStreamReader(socketCliente.getInputStream())); // Establece canal de salida salida = new PrintWriter(new BufferedWriter(new OutputStreamWriter(socketCliente.getOutputStream())),true); // Hace eco de lo que le proporciona el cliente, hasta que recibe "Bye" while (true) { String str = entrada.readLine(); System.out.println("Cliente: " + str); salida.println(str); if (str.equals("Bye")) break; }



} catch (IOException e) { System.out.println("IOException: " + e.getMessage()); } salida.close(); entrada.close(); socketCliente.close(); socketServidor.close(); } } Ejercicio RPC Los RPC o Llamados a Procedimientos Remotos (“Remote Procedure Call”) son mecanismos que permiten crear una comunicación entre procesos (cliente-servidor), al igual que los Sockets, pero la diferencia con estos es que mientras que los Sockets permiten enviar y transmitir caracteres, los RPC utilizan a los Sockets para crear una comunicación de más alto nivel. Los RPC permiten llamar a una función que está en otro programa y generalmente en otra máquina, para lo cual el paso de parámetros a la función remota se efectúa a través de algún protocolo de representación de datos (XDR, eXternal Data Representation). Mientras que a nivel de la capa de transporte el concepto de puerto existe para poder enviar información entre procesos, los RPC definen un concepto llamado número de programa. Este, junto con el uso de la versión del programa permite que los servidores y clientes puedan comunicarse. Programación con RPCs Dentro de las funciones para programar con RPC existen tres niveles:

• Nivel alto: En la práctica se usa sólo para aplicaciones muy específicas con poca utilidad.

• Nivel Bajo: Es en donde se pueden mezclar programación con RPCs y Sockets.

• Nivel Medio: Permite disponer de la mayor parte de las ventajas de RPCs sin tener que entrar en el detalle de su implementación bajo Sockets. En este nivel representaremos nuestro ejercicio práctico.

En este ejercicio práctico trataremos el uso de RPC de Sun. ESCENARIO



En este ejercicio veremos como se implementa un servidor y un cliente para obtener la hora de una máquina, con RPCs. Analizar los programas. PROGRAMA SERVIDOR El programa servidor (listado 1) llama a la función “registerrpc”, sus primeros tres parámetros son: el número de programa a registrar, el número de versión de programa y el número de procedimiento a registrar. Listado 1: /* Ejemplo del uso de los RPC de Sun Este programa permite obtener la hora de una máquina rpc_server _hora */ #include <rpc/rpc.h> #include <time.h> #include "def_rpc.h" { /* programa servidor de hora con rpcs */ void *servidor_hora(); /* registramos el programa, versión y procedimiento */ registerrpc(HORA_PROG, HORA_VERS, PIDEHORA_NUM, servidor_hora, xdr_void, xdr_hora); svc_run(); /* nunca regresa */ perror("regreso de svc_run"); exit(1); } void *servidor_hora() { /* servidor de hora */ struct tiempo str_tiempo, *ap_str_tiempo = &str_tiempo; time_t t; printf ("RECIBI RPC\n"); t = time(NULL); ap_str_tiempo->segundos = t; ap_str_tiempo->s_tiempo = localtime(&t); ap_str_tiempo->cad_hora = ctime(&t); return (void *) ap_str_tiempo; }



El cuarto parámetro es el nombre de una función de "C" (esto es, la dirección de la función), de tal forma que cuando el cliente llame a este programa, versión y número de procedimiento, el mecanismo de RPCs llamará a la función "servidor_hora" con un parámetro de llamada de tipo "xdr_void" (en este caso ningún parámetro), y con un valor de regreso de tipo xdrcadena_32. Después, el programa servidor llama a la función "svc_run", la cual a su vez se queda en un ciclo infinito en espera de RPCs; esta función al recibir la petición del procedimiento "PlDEHORA_NUM" llamará a la función "servidor_hora" la que simplemente regresa la dirección de una cadena de caracteres. PROGRAMA CLIENTE El programa cliente (listado 2) toma los argumentos con los que fue mandado a ejecutar y entra en un ciclo llamando a la función "callRPC”, que se encarga de ejecutar el llamado a un RPC. Listado 2 /* Ejemplo del uso de los RPC de Sun Este programa permite obtener la hora de una máquina rpc_cliente_hora */ #include <stdio.h> #include <rpc/rpc.h> #include "def_rpc.h" #define T_ESPERA 10 /* tiempo de espera en segundos */ main(narg,arg){ char **arg;/* programa cliente de hora con rpcs */ struct tiempo hora; int espera = T_ESPERA; enum clnt_stat stat; if( narg < 2 ){ fprintf(stderr,"uso: %s máquina tiempo_de_espera\n",arg[0]); exit(1); } if( narg == 3 ) espera = atoi(arg[2]); printf ("VOY A MANDAR\n"); while( (stat = callrpc(arg[1], HORA_PROG, HORA_VERS, PIDEHORA_NUM, xdr_void,NULL, xdr_hora, &hora)) ==0){



printf ("YA RECIBI\n"); /*printf("Hora de %s es %Id \n", arg[1] ,hora.segundos);*/ sleep(espera); } /* algun error */ clnt_perrno(stat) ; exit(2); } La función "callRPC" recibe ocho parámetros. Estos son: 1) El nombre de la máquina hacia donde se envía el RPC. 2) El número de programa que se quiere llamar. 3) La versión del programa. 4) El número de procedimiento que se quiere llamar. 5) xdr del tipo de argumento de llamada. 6) La dirección del argumento de llamada 7) xdr del argumento de regreso. 8) La dirección del argumento de regreso. La función "callrpc" trabaja bajo el protocolo de UDP, para un manejo de retransmisión. Si después de cierto tiempo no llega una contestación "callRPC" simplemente reintenta, después de cierto número de reintentos "callRPC" regresa un error de 'timeout', pero si la contestación llega y no hubo error "callRPC' regresa un 0. En el archivo def_RPC.h (listado 3), están definidos los números de programa, versión y procedimiento, además de la función xdr_cadena_32. Listado 3 /* Definiciones para rpcs del ejemplo de hora Sirven tanto para el cliente como el servidor */ #define HORA_PROG 555555555 /* Número del programa */ #define HORA_VERS /* versión */ #define PIDEHORA_NUM /* procedimiento 1 pide hora */ bool_t xdr_hora(); bool_t xdr_cadena_32(); bool_t xdr_stiempo(); struct tiempo { time_t segundos;



struct tm *s_tiempo; char *cad_hora; } XDRs El archivo xdrhora.c (listado 4) tiene la definición de la función xdr_cadena_32, que permite manejar cadenas de hasta 32 caracteres con los RPCs. Los xdrs constituyen simultáneamente un protocolo de presentación de datos y una implementación del mismo. La biblioteca de manejo de RPCs trae una gran cantidad de funciones de xdrs. Listado 4 /* Ejemplo del programa de hora con rpcs xdrs */ #include <rpc/rpc.h> #include <time.h> #include "def_rpc.h" XDR *xdrsp; struct tiempo *ap_hora; { /* xdr para la estructura tiempo */ if(xdr_u_long(xdrsp,&ap_hora->segundos) && xdr_stiempo(xdrsp,ap_hora->s_tiempo) && xdr_cadena_32(xdrsp,ap_hora->cad _hora)) return (TRUE); else retum (FALSE); } bool_t xdr_cadena_32(xdrsp,cadena) XDR *xdrsp; char *cadena; { /* xdr para cadenas de 32 bytes */ return xdr_string(xdrsp,&cadena,32); bool_t xdr_stiempo (xdrsp,ap_tiempo) XDR *xdrsp; struct tm *ap_tiempo; { if (xdr_int(xdrsp,&ap_tiempo->tm_sec) && xdr_int(xdrsp,&ap_tiempo->tm_min) && xdr_int(xdrsp,&ap_tiempo->tm_hour) &&



xdr_int(xdrsp,&ap_tiempo->tm_mday) && xdr_int(xdrsp,&ap_tiempo->tm_mon) && xdr_int(xdrsp,&ap_tiempo->tm_year) && xdr_int(xdrsp,&ap_tiempo->tm_wday) && xdr_int(xdrsp,&ap_tiempo->tm_yday) && xdr_int(xdrsp,&ap_tiempo->tm_isdst)) return (TRUE); else return (FALSE); } Los XDRs son funciones que realizan las operaciones de serializar y deserializar. Seriali zar se llama el proceso de convertir datos que están en representación interna de una máquina y se convierten al formato de representación externa lo que permite intercambiar información entre máquinas con representaciones de datos distintas; deserializar es el proceso inverso. 2.2. Comunicación entre Procesos 2.2.1 Generalidades de IPC El rendimiento de un sistema de computación distribuida depende en gran medida de la comunicación rápida entre procesos. Esta última depende de dos partes: las primitivas de comunicación entre procesos y el protocolo de transporte sobre el cual trabajan esas primitivas. La comunicación entre procesos en un ambiente distribuido no puede hacerse por memoria compartida; la única posibilidad es intercambio de mensajes. Diferentes conjuntos de primitivas pueden ser usados en la comunicación entre procesos remotos. Los tres más comunes están basados en:

• Paso de mensajes • Llamado a procedimientos remotos • Transacciones

El orden en la lista anterior indica que cada forma de comunicación puede ser construida en base a la anterior. En otras palabras, a mayor número, mayor nivel de abstracción. Paso de mensajes



Un mensaje es una colección de datos de cierto tipo consistente en un encabezado y un cuerpo de longitudes fijas o variables, la cual puede ser manejada por un proceso y entregada a su destinatario. La comunicación orientada a mensajes está íntimamente ligada al modelo cliente-servidor. El proceso cliente envía un mensaje (petición) a un proceso servidor y espera una respuesta o continúa ejecutándose. Las primitivas de comunicación por paso de mensajes son send y receive. En algunos sistemas, la primitiva receive puede ser selectiva o condicional si se agrega un guardia al llamar a la primitiva. Existen diversas formas o interpretaciones semánticas de las primitivas: 1. Direccionamiento Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la dirección de éste. Existen varios métodos por los que un cliente puede conocer o determinar la dirección del servidor, a continuación se mencionan tres de ellas: Asignación numérica fija predeterminada.- en este caso la dirección del servidor es acordada en forma anterior o durante el desarrollo de las aplicaciones cliente-servidor, y por ello se puede incluir en el programa ejecutable (ejemplo en un archivo de encabezados header.h). Aunque esta estrategia podría funcionar en un sistema particularmente sencillo, es necesaria una forma más sofisticada de direccionamiento. Aquí cabe señalar que no se ha determinado que es lo que significa el número asignado, es decir, no especifica si es la identificación de un proceso o de un equipo.

Asignación aleatoria de número de proceso.- este método consiste en dejar que cada proceso elija su propio identificador de un espacio de direcciones



grande y disperso, como el espacio de enteros de 64 bits. La probabilidad de que dos procesos elijan el mismo número es muy pequeña. Este método puede utilizarse en sistemas grandes. Sin embargo existe el problema de saber ¿a que máquina enviar el mensaje?. Para ello el emisor podría enviar un paquete especial de localización con la dirección del proceso destino. Puesto que es un paquete de transmisión, será recibido por todas las máquinas de la red. Todos los núcleos verifican si la dirección es la suya y, en caso de que lo sea, regresa el mensaje de aquí estoy con su dirección en la red (número de máquina).

Servidor de nombres.- aunque el esquema anterior es transparente, la transmisión provoca carga adicional en el sistema. Esta carga se puede evitar mediante una máquina adicional para la asociación a alto nivel (es decir en ASCII) de los nombres de servicios con las direcciones de las máquinas. Al utilizar este sistema, se hace referencia a los procesos del tipo de los servidores mediante cadenas en ASCII, las cuales son las que introducen en los programas y no los números en binario de las máquinas o procesos. Cada vez que se ejecute un cliente, en su primer intento por utilizar el servidor, el cliente envía una solicitud de cuestionamiento a un servidor especial de asociaciones, el cual se conoce como servidor de nombres para pedirle el número de máquina donde se localiza en ese momento el servidor.



2. Primitivas de Comunicación Primitivas con bloqueo o sin bloqueo.- una primitiva tiene una semántica sin bloqueo cuando su ejecución no produce un retardo en el proceso que la invoca; de otra manera la primitiva es con bloqueo. Existen básicamente cuatro tipos de comunicación para este tipo de primitivas: 1. Send con bloqueo (CPU inactivo durante la transmisión de los mensajes) 2. Send sin bloqueo, sin copia (no se puede sobrescribir hasta que el mensaje

haya sido leído) 3. Send sin bloqueo, con copia (se desperdicia el tiempo del CPU para la copia

adicional) 4. Send sin bloqueo, con interrupción (dificulta la programación)



Primitivas almacenadas con buffer y no almacenadas.- cuando se efectúa un intercambio de mensajes se presentan dos casos en relación a donde se va a almacenar la información. En el primero de estos es el proceso servidor el que destina una área para recibir un mensaje al efectuar la operación receive (no almacenado); mientras que en el segundo el proceso servidor solicita la creación de un buzón para alojar los mensajes que a ser recibidos mientras los puede procesar (almacenamiento con buffers). En sistemas sin buffer, la ejecución de un send se detiene hasta que en el otro extremo se ejecuta un receive (si se utilizó bloqueo). En ese momento el mensaje es enviado y ambos procesos pueden continuar su ejecución. Ambos procesos se sincronizan o se encuentran cuando el mensaje es transferido. Los sistemas con buffer son más difíciles de controlar debido a la necesidad de crear, destruir y mantener los buffers.

Primitivas confiables y no confiables.- existen tres distintos enfoques de este problema. El primero consiste en volver a definir la semántica de send para hacerlo no confiable. El sistema no da garantía alguna acerca de la entrega de mensajes. La implantación de una comunicación se deja enteramente en manos de los usuarios El segundo método exige que el núcleo de la máquina receptora envíe un reconocimiento al núcleo de la máquina emisora. Sólo cuando se reciba este reconocimiento, el núcleo emisor liberará al proceso usuario (cliente). El reconocimiento va de un núcleo al otro; ni el cliente, ni el servidor ven alguna vez un reconocimiento. De la misma forma que la solicitud de un cliente a un servidor es reconocida por el núcleo del servidor, la respuesta del servidor de regreso al cliente es reconocida por el núcleo del cliente. Así una solicitud de respuesta consta de cuatro mensajes.



El tercer método aprovecha el hecho de que la comunicación cliente-servidor se estructura como una solicitud del cliente al servidor, seguida de una respuesta del servidor al cliente. En este método, el cliente se bloquea después de enviar un mensaje. El núcleo del servidor no envía de regreso un reconocimiento sino que la misma respuesta funciona como tal. Así, el emisor permanece bloqueado hasta que regresa la respuesta. Si tarda demasiado, el núcleo emisor puede volver a enviar la solicitud para protegerse contra la posibilidad de una pérdida del mensaje. Una consideración más dentro de la comunicación por paso de mensajes es la determinación del receptor o receptores de un mensaje. Se tienen tres opciones:

• Transmisión a un sólo receptor (unicast) • Transmisión radial (broadcast) • Transmisión radial múltiple (multicast)

Llamados a Procedimientos Remotos El llamado a procedimientos remotos (RPC) implica que un proceso cliente envía una petición y permanece bloqueado hasta que el proceso servidor devuelve una respuesta. El objetivo de los RPCs es permitir que los programas en un ambiente distribuido se escriban con el mismo estilo que los programas en un sistema de cómputo centralizado. Una de las principales ventajas de este esquema de comunicación es que los programadores no requieren saber si un llamado a procedimiento se atenderá local o remotamente. La responsabilidad del mecanismo RPC es convertir llamadas escritas en un lenguaje de programación y manejar los tipos de datos de alto nivel traduciéndolos en llamadas a servicios del nivel de Transporte en una red. El mecanismo RPC está asociado con servicios en los niveles de Presentación y Sesión en el modelo OSI: Las primitivas de comunicación en RPC son: Del lado del cliente: call service (value_args; result_args) Del lado del servidor: accept service (in value_parameters; out result_parameters) body El RPC ocurre normalmente en la forma de un rendezvous.



Transacciones Dentro de los sistemas distribuidos, hay muchos casos en que una sola comunicación no resuelve problemas específicos de interacción entre dos procesos (por ejemplo, un retiro de una cuenta bancaria). La interacción entre los procesos puede ser una secuencia de comunicaciones y cálculos. En estas situaciones, es adecuado operar en base a transacciones. El concepto de transacción se desarrolló en sistemas de manejo de bases de datos para mantener la consistencia de la información almacenada. Los mecanismos de transacciones simplifican la construcción de sistemas confiables, y son transparentes para las aplicaciones de usuario (nivel de Sesión en el modelo OSI). En general, el término transacción describe una secuencia de operaciones sobre una o más bases de datos que transforma un estado consistente del sistema en otro estado consistente. No todos los estados de un sistema son consistentes y, por lo tanto, algunos cambios no son permitidos. Las aseveraciones que describen los cambios permitidos reciben el nombre de restricciones de consistencia. 3. Propiedades Las transacciones tienen las siguientes propiedades:

• Consistencia.- debe mantener la consistencia del sistema en que se aplica.

• Atomicidad.- debe ejecutarse completamente o no ejecutarse. • Durabilidad.- una vez que se completó con buen éxito, una transacción no

se puede cancelar (al menos que se aplique otra transacción).

Los sistemas de transacciones deben soportar las siguientes operaciones: terminación, concurrencia y recuperación (Commitment, Concurrency and Recovery [CCR]). 4. Algoritmo de Compromiso de 2 Fases (two-phase commit) Supongamos que hay un proceso maestro y N procesos esclavos. En la primera fase del algoritmo two-phase commit, el proceso maestro envía peticiones a los N esclavos solicitando algunas operaciones. Cada esclavo verifica si puede atender la petición. Si en efecto puede, el esclavo almacena la petición y el estado inicial del objeto en cuestión, bloquea el objeto (para que las peticiones de otros maestros no puedan interferir), y envía un mensaje confirmando su disposición a realizar el trabajo. De otro modo, envía un mensaje rechazando la petición.



La segunda fase inicia cuando todas las respuestas de los esclavos han llegado. En este momento, el maestro verifica si todos los esclavos pueden llevar a cabo su trabajo. Si la respuesta es afirmativa, el maestro les informa que ejecuten el trabajo. En caso contrario, es decir, si uno o más esclavos rechazan la petición inicial, el maestro aborta la operación y pide a los esclavos que desbloqueen su objeto y restablezcan su estado inicial. Un esclavo puede caerse después de recibir una petición y antes de ejecutar su trabajo. En este caso, el esclavo puede recuperarse cuando es reactivado, en base al estado inicial y a la petición que debe tener almacenados.



2.2.2 Modelo de Referencia OSI (Open Systems Interconnection) Propuesto en 1977 por la ISO (International Organization for Standardization). Toma ideas de SNA (Systems Network Architecture) (1974) de IBM. Arquitectura de capas; la capa N usa servicios de la capa N-1 y provee servicios a la capa N+1. En contraste, una arquitectura jerárquica (como la de TCP/IP), permite que un nivel dado se pueda comunicar con todos los niveles inferiores. El modelo OSI tiene siete capas. Los principios aplicados para el establecimiento de siete capas fueron: Una capa se creará en situaciones en donde se necesite un nivel diferente de abstracción. Cada capa deberá efectuar una función bien definida. La función que realizará cada capa deberá seleccionarse con la intención de definir protocolos normalizados internacionalmente. Los límites de las capas deberán seleccionarse tomando en cuenta la minimización del flujo de información a través de las interfaces. El número de capas deberá ser lo suficientemente grande para que funciones diferentes no tengan que ponerse juntas en la misma capa y, por otra también deberá ser suficientemente pequeñas para que su arquitectura no llegue a ser difícil de manejar. Capa Física Comprende: Transmisión de cadenas de bits, sin importar su estructura, a través de algún medio físico. Características: a) Mecánicas (conectores, cables, etc.). b) Eléctricas (voltajes, técnicas de modulación, etc.). c) Funcionales (por ejemplo, definición de funciones de cada pin en un conector). d) Procedurales (por ejemplo, mecanismos de "handshake"). Ejemplos: RS-232C, RS-449 Capa de Enlace de Datos Comprende: Detección y control de errores producidos en la capa física. Sincronización de la transmisión.



Control de acceso al medio de comunicación (redes locales). Activación, mantenimiento y desactivación de enlaces entre dos o más nodos. Control de flujo (control, por parte del nodo receptor, de la cantidad de datos aceptados o la velocidad de transmisión). Ejemplos: SDLC, HDLC, LAPB, LLC (IEEE 802.2). Capa de Red (ó Inter-red) Comprende:

• Entrega de paquetes entre dos o más nodos a través de inter-redes (redes de redes), proporcionando independencia de las tecnologías de transmisión de datos o de conmutación usadas entre los sistemas conectados.

• Establecimiento, mantenimiento y terminación de conexiones (en servicios orientados a la cone xión).

Ejemplos: CLNP de OSI IP de la familia TCP/IP IPX de Novell X.25 PLP (Packet-Level Protocol) Capa de Transporte Comprende:

• Comunicación entre procesos residentes en distintos sistemas, permitiendo "multiplexar" dos o más enlaces proceso-a-proceso sobre un solo canal de comunicación.

• En servicios orientados a la conexión, entrega de datos confiable por medio de recuperación de errores, secuenciación de paquetes, control de flujo y control de retardos en la transmisión.

Ejemplos: TP0-TP4 de OSI TCP y UDP de la familia TCP/IP SPX de Novell Capa de Sesión Comprende:

• Control y sincronización de diálogos o sesiones.



• Control de puntos de verificación (checkpoints) en transacciones. • Manejo de errores en sesiones (por ejemplo, una impresora inteligente a

la que se le termina el papel). • Llamados a procedimientos remotos.

Ejemplos: RPC de Sun Microsystems Protocolo OSI Session Capa de Presentación (ó Representación) Comprende:

• Representación y/o sintaxis de los datos. • Encripción de información. • Compresión de datos.

Ejemplos: ASN.1 (Abstract Syntax Notation) de OSI XDR (External Data Representation) de Sun Microsystems DES (Data Encryption Standard) Capa de Aplicación Comprende:

• Aplicaciones de red. • Interfaces de programación para aplicaciones de usuario (APIs).

Entre las aplicaciones de red (con ejemplos) se cuentan: Transferencia de archivos (FTP de TCP/IP, FTAM de OSI, NFS de Sun) Emulación de terminal (Telnet de TCP/IP) Correo electrónico (X.400 de CCITT, SMTP de TCP/IP) Administración de redes (SNMP de TCP/IP, CMIP de OSI) Servicios de directorio (OSI Directory Services, X.500 de CCITT)



2.2.3 Protocolos TCP/IP La familia de protocolos conocida como TCP/IP fue desarrollada a mediados de los años 70s por la Universidad de Stanford y la compañía Bolt, Beranek and Newman. Quien patrocinó su desarrollo fue el Departamento de Defensa de E.U. a través de la agencia Advanced Research Projects Agency (DARPA). El objetivo era desarrollar una familia de protocolos para interconectar equipos de diversos tipos. La primera red que adoptó TCP/IP, hacia 1980, fue la ya existente ARPANET. Esta red se convirtió en la base de la Internet que en nuestros días conecta a más de 30,000 subredes y 2.5 millones de computadoras en unos 107 países. La tabla 1 muestra algunos de los protocolos más comunes en la familia TCP/IP, los servicios que proporcionan y el nivel del modelo OSI en que se ubican. Protocolo Servicio Capa OSI Internet Protocol (IP) Entrega de paquetes entre nodos. 3 Internet Control Message Protocol (ICMP)

Controla la transmisión de mensajes de error y de control entre nodos y gateways.

3

Address Resolution Protocol (ARP)

Mapea direcciones IP a direcciones físicas.

3

Reverse Address Resolution Protocol (RARP)

Mapea direcciones físicas a direcciones IP.

3

Transmission Control Protocol (TCP)

Entrega confiable de mensajes entre nodos.

4

User Datagram Protocol (UDP)

Entrega no confiable y sin conexión de paquetes entre nodos.

4

File Transfer Protocol (FTP) Transferencia de archivos. 5-7 Telnet Emulación de terminal. 5-7 Tabla 1.- Protocolos TCP/IP más comunes.



La figura 1 muestra las capas de la arquitectura TCP/IP. Al igual que en el modelo OSI, cada capa en la máquina fuente se comunica con la misma capa de la máquina destino.

Network Hardware

Network Interface

Internet

Transport

Application

Network Interface

Internet

Transport

Application

source host destination host

messages or streams

IP datagrams

Datagrams (UDP) orsegments (TCP)

network frames

Figura 1.- Modelo de capas TCP/IP. Direcciones Físicas y Direcciones IP Cada nodo tiene una dirección física (llamada dirección MAC en el contexto de redes locales) asociada con el dispositivo de hardware que lo conecta con la red. Por ejemplo, en Ethernet, una dirección física es un número de 6 bytes; las redes X.25 usan el estándar X.121 que define direcciones físicas como números de 14 dígitos. La dirección IP de un nodo es una dirección lógica (independiente del hardware). Consiste de 32 bits (4 bytes) que identifican tanto a la red como al host particular dentro de esa red. Típicamente, las direcciones IP se representan en notación decimal con puntos. (Por ejemplo, 129.71.6.17 corresponde a 0x81.0x47.0x6.0x11).



Dado que las direcciones IP son independientes del tipo de red, éstas pueden ser usadas para enviar paquetes entre distintos tipos de redes. En cada tipo de red, el software de TCP/IP hace la correspondencia entre direcciones físicas y direcciones IP. En redes conectadas a la Internet, las direcciones IP deben ser asignadas por el NIC (Network Information Center). Clases de Direcciones IP Cada dirección IP se divide en dos partes: la porción de red y la porción de host. La división de cuántos bits corresponden a cada porción queda definida por la clase de dirección. Se manejan tres clases principales, denominadas A, B y C. Una dirección clase A consta de 1 byte para la porción de red y 3 bytes para el host. El bit más significativo de la porción de red es siempre 0. Esto permite 126 redes clase A (1 a 126) con más de 16 millones de nodos en cada una. Una dirección clase B consta de 2 bytes para la porción de red y 2 bytes para el host. Los bits más significativos de la porción de red son siempre 10. Así, es posible tener 16 mil (214) redes clase B con más de 65,000 nodos cada una. Una dirección clase C consta de 3 bytes para la porción de red y 1 byte para la porción de host. Los tres bits más significativos de la porción de red son siempre 110. Esto permite aproximadamente dos millones de redes clase C con un máximo de 254 nodos cada una. Direcciones Reservadas Direcciones de red. Estas son direcciones IP donde la porción de host está puesta en ceros. Por ejemplo, 129.47.0.0 es la dirección de una red clase B. Direcciones de broadcast. Estas son direcciones donde la porción de host está puesta en unos. Dirección de loopback. La dirección 127.0.0.0 está diseñada para pruebas y comunicación entre procesos en forma local. Un paquete enviado a la dirección de red 127 no debe aparecer jamás en ninguna red.



Protocolos El Protocolo IP IP proporciona un servicio de entrega de paquetes no confiable y sin conexión. El servicio es no confiable porque la entrega de un paquete no está garantizada. Un paquete puede ser ruteado erróneamente, duplicado o puede desaparecer en su camino al destino final. El servicio es sin conexión porque cada paquete es transmitido independientemente de cualquier otro paquete. IP define el formato de los paquetes (llamados datagramas IP) y la forma de manejarlos. El software de IP de un nodo crea un datagrama que cabe dentro del marco (frame) de la red física. Sin embargo, durante su viaje un paquete puede cruzar distintos tipos de redes con marcos de tamaño menor. El protocolo IP define la forma de fragmentar los paquetes en cada nodo que requiera retransmitir paquetes. Una vez que un paquete ha sido fragmentado, no es re-ensamblado sino en su destino final. Asimismo, el software de IP utiliza un algoritmo de ruteo para determinar si un paquete recibido del nivel de transporte debe ser entregado directamente (a un nodo de la misma red), o debe ser enviado a un gateway (ruteador) para ser enviado a otra red. Los paquetes recibidos son verificados y luego se determina si el paquete debe ser procesado localmente o retransmitido. Protocolos de Transporte Los protocolos de transporte proveen un servicio de intercambio de información entre procesos específicos residentes en distintas máquinas. En este nivel, las entidades direccionables reciben el nombre de puertos. Cada puerto identifica a un proceso distinto dentro de un computador. TCP/IP define una serie de puertos conocidos (well-known ports), asignados a aplicaciones específicas (por ejemplo, Telnet utiliza el puerto 23). Otros números de puerto son asignados dinámicamente. Dentro de la familia TCP/IP se manejan principalmente dos protocolos de transporte: UDP y TCP.



El Protocolo UDP UDP provee un servicio de transporte no confiable y sin conexión. Cada datagrama UDP es encapsulado en uno o más datagramas IP. UDP se utiliza en aplicaciones que requieren intercambiar poca información, o donde el costo de establecer una conexión virtual es muy alto (ya sea por restricciones de velocidad o por espacio en memoria para almacenar el software requerido). El Protocolo TCP TCP es un protocolo confiable de entrega de mensajes orientado a la conexión. TCP mantiene un circuito virtual entre dos aplicaciones, controlando las formas en que esta conexión se establece y se termina. TCP controla que los paquetes sean entregados a las aplicaciones en la secuencia correcta y corrige errores tales como la pérdida o duplicación de paquetes. 2.2.4 Sockets Introducción La interfaz de sockets es una API (Application Programming Interface) que permite el desarrollo de programas donde se requiera comunicación entre procesos, ya sea local o remotamente, con base en distintos protocolos de comunicación (principalmente TCP/IP, XNS y mecanismos de comunicación entre procesos de Unix). El uso más común de esta interfaz es en el desarrollo de programas dentro de un ambiente distribuido cliente-servidor, trabajando sobre la familia de protocolos TCP/IP. La disponibilidad de una API de sockets está en función del sistema operativo que se esté usando así como del lenguaje de programación. Originalmente, la interfaz de sockets fue desarrollada para el Unix de Berkeley (léase 4.1cBSD), hacia el año 1982. No sorprende que esta herramienta se haya diseñado en lenguaje C. En sistemas Unix existe otra API de comunicaciones estándar, el Transport Layer Interface (TLI) del Unix System V de la AT&T. Ésta también fue desarrollada en lenguaje C y en términos generales tiene la misma funcionalidad que la interfaz de sockets de Berkeley. La TLI se usa sobre SPX e IPX de Novell, entre otros protocolos.



¿Qué es un socket? Definición Informal Un socket es un extremo o un punto terminal de un canal de comunicación entre dos procesos. Obviamente, para formar un canal de comunicación se requieren dos sockets, a los cuales se les conoce como socket local y socket remoto. La comunicación a través de una conexión de sockets es bidireccional. Los sockets trabajan normalmente al nivel de transporte (en el caso de TCP/IP, sobre los protocolos TCP o UDP), aunque existen también los raw sockets que operan en la capa de red del modelo OSI (por ejemplo, dentro de la suite de protocolos TCP/IP, los raw sockets se usan en programas basados en el protocolo ICMP, como es el caso del programa Ping). Definición Formal Una conexión de red entre dos procesos queda completamente definida por una asociación, la cual es una quinteta formada de la siguiente manera: {protocolo, dirección_local, proceso_local, dirección_remota, puerto_remoto} Un ejemplo de asociación usando la suite de protocolos TCP/IP es el siguiente: {tcp, 192.43.235.2, 1500, 192.43.235.6, 21} Con base en el concepto de asociación, se puede definir un socket como una media-asociación, la cual tiene dos posibles definiciones: {protocolo, dirección_local, proceso_local} {protocolo, dirección_remota, proceso_remoto} A una media-asociación también se le llama dirección de transporte. Operaciones sobre Sockets El principal objetivo de la interfaz de sockets es facilitar al programador el desarrollo de aplicaciones distribuidas. Casi todos los programadores están familiarizados con el manejo de archivos por medio de las operaciones básicas open-read-write-close. La interfaz de sockets intenta que la programación en ambientes distribuidos se realice con las mismas operaciones, sólo que en lugar de actuar sobre un archivo actúan sobre un punto terminal de un canal de comunicaciones (socket). De esta manera tenemos las siguientes analogías:



Operaciones sobre un archivo Operaciones sobre un socket open(archivo) open(socket)

read(archivo, datos) read(socket, datos)

o receive(socket, datos)

write(archivo, datos) write(socket, datos) o send(socket, datos)

close(archivo) close(socket) En realidad las operaciones sobre sockets son más complicadas. Por ejemplo, la acción de “abrir” un socket se divide en tres pasos: Crear el socket (local). Asociar la interfaz de red y el número de puerto sobre los cuales va a operar. Conectar el socket local con un socket remoto. Una vez que un socket está conectado (es decir, abierto) se pueden realizar operaciones de lectura y escritura sobre él. Los siguientes puntos deben ser considerados en las operaciones de entrada/salida con una red, contrastando con operaciones de entrada/salida sobre archivos: La relación cliente-servidor es asimétrica. Antes de establecer una conexión en red se requiere que el programa sepa qué función (cliente o servidor) va a desempeñar. Una conexión de red puede ser orientada a la conexión o sin conexión. La primera se parece más al manejo de archivos que la segunda, dado que, una vez que se ha establecido (es decir, abierto) una conexión, las operaciones de entrada/salida se aplican sobre el mismo proceso pareja. En el caso de un protocolo sin conexión, no existe una operación de “open” debido a que cada operación de entrada/salida sobre la red se puede hacer con un proceso distinto en un host distinto. La definición de asociación comprende cinco parámetros, para una conexión de red se requieren manejar más parámetros que para operaciones de entrada/salida sobre archivos. La API de red debe soportar diferentes protocolos de comunicación. Distintas familias de protocolos trabajan con direcciones de red e identificaciones de proceso en distintos formatos, por lo cual se requiere que la API tenga algún mecanismo genérico para operar sobre cualquier protocolo.



Principales Llamadas de Sockets La interfaz de sockets comprende decenas de llamadas a función. El uso y la semántica de cada función depende del contexto en que se aplica, influyendo aspectos como el tipo de protocolo de transporte utilizado (orientado a la conexión o sin conexión) y el rol del programa (lado cliente o lado servidor). A continuación se presentan sólo las llamadas elementales. Socket Una aplicación llama a socket para crear un nuevo socket. La llamada regresa un descriptor (el cual es del tipo entero) del socket creado. Uso: s = socket (family, type, protocol); Argumentos:

Argumento Tipo Significado family int Familia de protocolos (AF_INET para

TCP/IP). type int Tipo de servicio (SOCK_STREAM para TCP

o SOCK_DGRAM para UDP). protocol int Número de protocolo para la familia de

protocolos dada; normalmente 0. Connect Después de crear un socket, un cliente llama a connect para establecer una conexión activa a un servidor remoto. Uso: retcode = connect (socket, addr, addrlen); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket. addr sockaddr * Punto de conexión en la máquina remota. addrlen int Longitud del segundo argumento.

Write Tanto clientes como servidores usan write para enviar información a través de una conexión de red. Esta función se usa principalmente sobre TCP.



Uso: retcode = write (socket, buf, buflen); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket. buf char * Apuntador al buffer que contiene los datos. buflen int Longitud en bytes del buffer.

Read La llamada read es usada tanto por clientes como por servidores para recibir datos de una conexión de red, principalmente sobre TCP. Uso: retcode = read (socket, buf, buflen); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket. buf char * Apuntador al buffer que recibe los datos. buflen int Longitud en bytes del buffer.

Close Una vez que un cliente o un servidor ha terminado de usar un socket, llama a close para destruir el socket. Uso: retcode = close (socket); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket.

Bind Cuando se crea un socket, éste no sabe cuáles son las direcciones local y remota de la conexión. Una aplicación llama a bind para especificar la dirección local del socket. Esta llamada es usada principalmente por servidores para indicar el puerto conocido en el cual esperarán conexiones.



Uso: retcode = bind (socket, localaddr, addrlen); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket. localaddr sockaddr * Apuntador a la estructura que especifica la

dirección IP y el número de puerto de protocolo.

addrlen int Tamaño en bytes del segundo argumento. Listen Cuando se crea un socket, éste no queda ni activo (listo para ser usado por un cliente) ni pasivo (listo para ser usado por un servidor). Los servidores orientados a la conexión llaman a listen para poner un socket en modo pasivo, es decir, listo para aceptar peticiones de conexión. Esta llamada no aplica para UDP. Uso: retcode = listen (socket, queuelen); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket. Queuelen int Tamaño de la cola de conexiones

pendientes. Accept Después de que un servidor llama a socket para crear un socket, bind para especificar la dirección local, y listen para poner el socket en modo pasivo, se llama a la función accept con el fin de crear un nuevo socket que atienda a la nueva conexión. El socket original, que maneja un puerto conocido, se usa para aceptar otras peticiones de conexión. Uso: newsock = accept (socket, addr, addrlen); Argumentos:

Argumento Tipo Significado socket int Descriptor del socket original.



addr sockaddr * Apuntador a una estructura de dirección TCP/IP. Accept llena la estructura con la dirección IP y el número de puerto de protocolo de la máquina remota

addrlen int * Apuntador a un entero que inicialmente especifica el tamaño del argumento addr y, cuando la llamada regresa, especifica el número de bytes almacenados en addr.

Las figuras 1 y 2 ejemplifican la secuencia en que se efectúa el envío y recepción de datos para comunicaciones orientadas a conexión y no orientadas a conexión; y las figuras 3 y 4 muestran las secuencias típicas de llamadas hechas por un cliente y un servidor usando los protocolos TCP y UDP, respectivamente.



2.2.5 Remote Procedure Call (RPC) Introducción Un llamado a procedimiento remoto tiene lugar en los siguientes pasos: El cliente llama a un procedimiento local, llamado acoplador del cliente (client stub). Para el cliente, el acoplador aparenta ser el procedimiento real que desea llamar en el lado servidor. La función del acoplador es empacar los argumentos para el procedimiento remoto, posiblemente ponerlos en un formato estándar (como se comentará más adelante) y luego construir uno o más mensajes de red. El empaquetamiento de los argumentos del cliente en un mensaje de red recibe el nombre de alineación (en inglés, marshaling). El acoplador del cliente envía los mensajes de red al sistema remoto. Esto requiere una llamada de sistema en el kernel local. Los mensajes de red son transmitidos al sistema remoto. Se puede usar un protocolo orientado a la conexión o uno sin conexión, dependiendo del producto utilizado. Un acoplador del servidor en el sistema remoto espera la llegada de la petición del cliente. Este componente obtiene o “desalinea” a partir de los mensajes de (acción conocida en inglés como unmarshaling) y posiblemente convierte su formato. El acoplador del servidor ejecuta un llamado a procedimiento local para invocar a la función real del lado servidor, pasándole los argumentos que recibió en los mensajes de red del acoplador del cliente.



Cuando el procedimiento del lado servidor termina, regresa el control al acoplador del servidor, entregándole algún o algunos valores de regreso. El acoplador del servidor convierte los valores de regreso, si es necesario, y los alinea en uno o más mensajes de red para enviarlos de vuelta al acoplador del cliente. Los mensajes se transfieren de regreso a través de la red al acoplador del cliente. El acoplador del cliente lee los mensajes del kernel local. Después de convertir, posiblemente, los valores de regreso, el acoplador del cliente finalmente regresa el control al programa cliente. Para este último, todo lo anterior es visto como el regreso de un procedimiento normal.

Consideraciones de Transparencia Aunque el objetivo del mecanismo de RPC es hacer que un procedimiento remoto se pueda invocar en forma transparente, es necesario considerar los siguientes puntos: Paso de parámetros. Asociación entre el cliente y el servidor. Protocolo de transporte. Manejo de excepciones. Semántica de la llamada. Representación de datos. Rendimiento.



1. Paso de Parámetros El paso de parámetros entre cliente y servidor puede no ser transparente. Los parámetros que se pasan por valor son simples: El acoplador del cliente copia el valor del programa cliente y lo empaca en un mensaje de red. El problema se presenta con los parámetros que se pasan por referencia (es decir, cuando se pasa la dirección de una variable en lugar de su valor). Obviamente el servidor no puede hacer referencias directamente a la memoria del sistema cliente. La solución típica consiste en sólo permitir el paso de argumentos por valor. Para cada procedimiento remoto se define específicamente cuáles son los parámetros de entrada y cuáles son los parámetros de regreso. 2. Asociación entre el cliente y el servidor La asociación entre el cliente y el servidor se refiere a contactar el sistema remoto apropiado. Esto tiene dos partes: Encontrar un host remoto para el servicio deseado. Encontrar el proceso servidor correcto en el host remoto. 3. Protocolo de transporte Existen varios protocolos que pueden ser usados para la implementación de RPC, entre ellos podemos mencionar UDP, TCP, SPX, TP. Cabe señalar que estos no fueron diseñados específicamente para dicho fin. 4. Manejo de excepciones Dentro de una llamada a una función remota hay muchas cosas que pueden fallar. Podemos experimentar problemas con la red, con nuestra máquina o incluso con la máquina que corre el procedimiento remoto. Muchas veces el cliente desea detener el procedimiento que llamo por problemas en los datos, por falta de tiempo o incluso por indecisiones. También puede suceder que el cliente salga de su sesión de Internet cuando todavía no se termina de ejecutar el procedimiento remoto, lo que generaría un fallo cuando el servidor intente mandar el resultado o la conclusión del procedimiento al usuario. Para todos estos problemas se debe tener un manejo de excepciones, las cuáles son generadas cuando se suscita algunos de los problemas que mencionamos. Las excepciones son una lista de valores numéricos que representan el fallo que ocurrió.



5. Semántica de la llamada Cuando se hace una invocación a un procedimiento local, no hay ninguna duda respecto a cuántas veces se ejecutó el procedimiento. Si regresa al programa que lo llamó, sabemos que se ejecutó exactamente una vez. Sin embargo, con un procedimiento remoto, si no obtenemos ninguna respuesta después de cierto tiempo, no sabemos cuántas veces se ejecutó éste en el otro equipo. Hay varias posibilidades: El cliente no puede localizar el servidor.- en este caso pueden existir varias razones que van desde que el servidor no se encuentre levantado, hasta que el resguardo utilizado no sea compatible con el del servidor. Pérdida de mensajes de solicitud.- este es un caso sencillo, ya que lo único que es necesario hacer es que el núcleo inicialice un cronómetro al enviar la solicitud. Si el tiempo se termina antes de que regrese una respuesta o reconocimiento, el núcleo vuelve a enviar el mensaje. Pérdida de mensajes de respuesta.- la pérdida de las respuestas es más difícil de enfrentar. La solución más obvia es basarse de nuevo en un cronómetro. Si no llega una respuesta en un periodo razonable, solo hay que volver a enviar la solicitud. El problema con esta solución es que el núcleo del cliente no está seguro de la razón por la que no hubo respuesta. ¿Se perdió la respuesta? ¿ Ocurre que el servidor es lento?. Esto puede ser la diferencia. Cuando una operación, tal como un llamado a procedimiento, se puede ejecutar cualquier número de veces “sin causar ningún daño”, se dice que es idempotente. Ejemplos de procedimientos idempotentes son: una función que regrese la hora del día, una función para calcular la raíz cuadrada, un procedimiento para leer los primeros 512 bytes de un archivo en disco y una función para obtener el saldo actual de una cuenta bancaria. Ejemplos de procedimientos que no son idempotentes son: una función para agregar 512 bytes al final de un archivo en disco, una función para hacer un retiro de una cuenta bancaria. Una forma de resolver este problema es intentar estructurar de alguna manera todas las solicitudes de modo que sean idempotentes. Otro método sería que el núcleo del cliente asigne un número secuencial a las solicitudes. Si el núcleo del servidor mantiene un registro del número secuencial de recepción más reciente de cada uno de los núcleos clientes que lo utilizan, el núcleo servidor podrá indicar la diferencia entre una solicitud original y una retransmisión. Una protección adicional es tener un bit en el encabezado del mensaje para distinguir las solicitudes de las retransmisiones. Fallos del servidor.- este también se relaciona con la idempotencia, pero por desgracia no se puede resolver mediante números secuenciales.



La razón de ello es que existen diferencias en el proceso de la llamada, estas son relativas al momento de fallo del servidor. Se tienen los casos siguientes: Si el proceso servidor se cayó antes de ser invocado por el acoplador del servidor, entonces no se ejecutó. Si el servidor se cayó después de ejecutar el procedimiento y el mensaje con la respuesta se perdió, el procedimiento se ejecutó una vez. Si el cliente alcanza un tiempo fuera y retransmite una petición, las cosas se confunden más: es posible que la petición original se haya retardado en algún punto de la red pero que tarde o temprano se haya ejecutado, y que la petición retransmitida también se haya ejecutado. Hay tres semánticas posibles en RPC: Exactamente una vez significa que el procedimiento remoto fue ejecutado una vez, nada más. Este tipo de operación es difícil de lograr debido a la posibilidad de caídas de los servidores. Como máximo una vez significa que el procedimiento remoto no fue ejecutado o que fue ejecutado cuando más una vez. Si el cliente obtiene un regreso normal, sabemos que el procedimiento remoto fue ejecutado una vez. Pero si se obtiene una condición de error, no se sabe si el procedimiento remoto fue ejecutado una vez o ninguna. Al menos una vez significa que el procedimiento remoto fue ejecutado en una ocasión pero posiblemente más veces. Esto es típico para procedimientos idempotentes: el cliente se mantiene transmitiendo su petición hasta que recibe una respuesta válida. Pero si el cliente tiene que enviar su petición más de una vez para recibir una respuesta válida, hay una posibilidad de que el procedimiento remoto fue ejecutado más de una vez. 6. Representación de datos Un elemento que afecta a la comunicación entre dos equipos distintos es la forma de representación de los datos. Para solucionar esta problemática es necesario definir un estándar de representación. 7. Rendimiento En relación a este punto es necesario señalar que cada máquina en conjunción con el sistema operativo con que cuenta, representa una problemática diferente para efectuar una RPC, y que ello se refleja en el rendimiento del equipo para efectuar este tipo de llamadas. En estos casos lo mejor que se puede hacer es optimizar el código relacionado con estos procedimientos.



2.3. Modelo de Capas Actividad 2.3 Para estudiar el Modelo de Capas o de Aplicación para diseñar programas estudiaremos algunos fundamentos teóricos y posteriormente se plantearán escenarios de una aplicación modelada Instrucciones Coloque los programas solicitados en Tarea Individual 2.3 Material 2.3.

Una estrategia fundamental para diseñar aplicaciones, particularmente aquellas basadas en componentes, consiste en utilizar el modelo de aplicación. El modelo de aplicación sugiere modelar las aplicaciones por capas. El término capa deriva del término en inglés tier (no proviene del término layer en inglés). Independientemente del número de capas que se empleen para diseñar una aplicación, son básicamente 3 tipos de servicios que pueden proveer estas capas:

• Servicios de usuario o presentación • Servicios de negocio • Servicios de datos



Cuando una aplicación se diseña a una capa, estos 3 tipos de servicios se encuentran fusionados en el código de este componente. Cuando se diseña a 2 capas, en una de las capas se ubican uno de los tipos de servicios y en la otra capa se encuentran fusionados los otros 2 tipos de servicios. Las combinaciones posibles para fusionar servicios son:

• Servicios de presentación y servicios de negocio • Servicios de negocio y servicios de datos

La combinación exclusiva de servicios de presentación con servicios de datos en una capa es inválida. Las aplicaciones diseñadas a mayor número de capas son posibles, ya que aunque estos servicios persisten, las capas pueden comenzar a estratificarse en subcapas y es en dónde aparecen un mayor número de capas. Por ejemplo, si partimos de un modelo a 3 capas, y el arquitecto de software decide que la capa de negocio se estratifique en 2 subcapas, en total tendremos una aplicación de 4 capas. A partir de la tercera capa, podemos hablar de modelos multicapa o n-capas.

Los servicios de usuario o presentación son los que proveen la interfaz al usuario. El usuario puede ser una persona u otro programa o componente. Cuando es una persona los servicios de presentación son proporcionados por una Interfaz Gráfica del Usuario (GUI – Graphic User Interface). Cuando el usuario es un programa o componente, los servicios de presentación son proporcionados a través de una API o interfaz programática.



Aunque la capa de presentación no debe procesar información puesto que corresponde a la capa de “negocio”; es válido que la capa de presentación tenga código de procesamiento para validar entrada de datos en forma básica o formatear información de salida.

Los Servicios o Reglas de Negocio de una aplicación corresponden a los algoritmos principales de ésta. El emplear el término “Negocio” no implica que forzosamente correspondan a algoritmos de aplicaciones administrativas; sino que, como se ha denotado, es cualquier algoritmo principal de la aplicación. Por ejemplo, en un programa que pida números al usuario, los ordene y los imprima en pantalla; la regla de negocio correspondiente es el algoritmo de ordenamiento. Es la capa responsable de administrar las transacciones de negocio, la cual generalmente es implementada a través de la tecnología de componentes basada en objetos. El empleo del paradigma de la orientación a objetos nos hace recurrir a un conjunto de herramientas denominadas Monitores de Transacciones (también conocidos en inglés como TP Monitors – Transaction Processing Monitors). La capa de negocio tiene dentro de sus facultades el solicitar el cambio o consulta de los datos, pero no le corresponde llevar a cabo esta tarea, lo cual será el trabajo a realizar por la capa de datos. Por ejemplo, en una aplicación de créditos hipotecarios, en un punto de ejecución de la misma se requerirá que para otorgar un crédito el cliente debe ser mayor de edad, contar con un aval, contar con una propiedad valor superior o igual a $500,000.00 y ser de nacionalidad mexicana. Para tal efecto, la aplicación deberá realizar una serie de consultas y cálculos para autorizar el crédito. Este tipo de algoritmos corresponden a las reglas de negocio.



La capa de datos realiza los servicios u operaciones de manipulación de bajo nivel de base de datos. Los servicios u operaciones podrán ser los de inserción, borrado, modificación y consulta en una base datos. Como se comentó en la sección anterior, la capa de negocio solicita estos servicios más no los implementa o lleva a cabo. La capa de datos si los implementa.



De esta manera, aunque la capa de negocio hace solicitudes a la capa de datos respecto a las operaciones a realizar sobre los mismos; la capa de negocio no requiere conocer dónde se localizan los datos, como se implementa el acceso a los mismos y los pormenores de éste.

Ejemplo a 2 Capas

Presentación

Reglas de Negocio(Lógica de Aplicación)

Datos

Red

Cliente

Presentación(Servicios de Usuario)


Datos y Recursos(Servicios de Datos)

Servidor

Presentación


Datos

Cliente

Presentación(Servicios de Usuario)



Servidor

Red

En el modelado a 2 capas, existen 2 formas en que las capas pueden fusionarse:

1) Capa de presentación – Capa de negocio, o 2) Capa de negocio – Capa de datos

Ejemplo a 3 Capas

Presentación


Datos

Red

ClientePresentación

(Servicios de Usuario)



Base de Datos

Red

Middleware+

Servidor1

Servidor2



En el modelado a 3 capas, los servicios se distribuyen para cada uno de estos tipos de servicios: presentación, negocio y datos.

Por ejemplo, para una aplicación diseñada a 3 capas podemos tener una aplicación cuya capa de presentación pueda ser provista de dos formas. Una de ellas a través de la interfaz gráfica que puede ser construida con un lenguaje de programación. La otra a través de un navegador para Internet (browser) empleando páginas Web (construidas en forma estática o dinámica). La capa de negocio puede ser implementada a través tecnología de componentes. Y la capa de datos a través de componentes de acceso a manejadores de bases de datos. Existe una discusión respecto a la implementación de la capa de datos. Algunos autores o diseñadores consideran que el manejador de base de datos y los procedimientos almacenados conforman la capa de datos. Otros consideran que debe existir por lo menos una capa de objetos que administren e interactúen con el manejador de bases de datos y los procedimientos almacenados; y todos estos elementos



Escenario 2.3.

La aplicación del ejemplo consiste en una interfaz gráfica que solicita al usuario su nombre y fecha de nacimiento. A través de dos botones principales, el primero “Calcular edad” y el segundo “Guardar”. “Calcular edad” obtendrá la fecha de sistema y calculará la diferencia en años entre ésta y la fecha de nacimiento capturada. “Guardar” almacenará la información en una base de datos.

Una propuesta o sugerencia de la interfaz gráfica.



Pseudocódigo para diseñar la aplicación a 1 capa

Pseudocódigo para diseñar la aplicación a 2 capas



Pseudocódigo para diseñar la aplicación a 3 capas



Rúbrica para evaluación de ejercicios prácticos

Atributos Arriba del Estándar En el Estándar Debajo del

Estándar

Puntos de Atributo

Obtenidos (10-9) (8.5-7) (6.5-0)

Aplicación de la

Información

La información revisada permitió a los estudiantes comprender con

claridad los ejercicios y programas.

La información revisada permitió a los estudiantes

comprender solamente los

ejercicios y programas.

La información revisada no

permitió a los estudiantes comprender

los ejercicios y programas.

(10-9) (8.5-7) (6.5-0)

Conexiones Especialistas

Los estudiantes han demostrado el

significado del material

elaborando correctamente,

mientras extienden y explican la

información, incorporándola en

el estudio del tema.

Los estudiantes han demostrado el significado del

material incorporándolo correctamente

en el estudio del tema.

Los estudiantes no

han hecho contacto con el

material, simplemente sin incorporar la información en su estudio

del tema.

Total de Puntos Obtenidos



3. Tecnologías de Desarrollo

Panorama General

Tecnologías de Desarrollo Sistemas Distribuidos

Definición de Actividades

Metodología Actividades Evaluación

Agenda



Metodología

• Introducción • Estrategias de Aprendizaje o Aprendizaje Basado en Problemas o Estudio de Casos o Aprendizaje Orientado a Proyectos

Introducción

En el sentido de abordar el tema de tecnologías de desarrollo dentro de los sistemas distribuidos se plantearan las bases para que los alumnos trabajen en un ambiente de colaboración a través de los pasos de las técnicas didácticas de aprendizaje basado en problemas (ABP), estudio de casos (EC) y aprendizaje orientado a proyectos (AOP). Al incorporar las estructuras de estas técnicas se identifican los roles dentro de los grupos o equipos de alumnos, así como del profesor o tutor.



Con la técnica de ABP los alumnos aprenderán a: 1) Identificar sus necesidades de aprendizaje. 2) Dirigir su aprendizaje utilizando recursos adecuados. 3) Proveer a los demás con muestras de su aprendizaje. 4) Actuar en general en forma responsable.

Problema:

• Descripción de un conjunto de problemas o sucesos.

• Preparado por un equipo de docentes.

Discusión en un grupo reducido:

• “¿Qué es lo que ya sé sobre el problema?”.

• “¿Qué es lo que necesito saber sobre el problema?”

Estudio individual:

• Exploración de los diversos recursos de aprendizaje.

• Fuentes externas de información.

• Integración de los conocimientos de varias disciplinas.


• “¿Adquirimos una mejor comprensión de los procesos involucrados en el problema?”

Aprendizaje Basado en Problemas



ABP, Roles y Apoyos en General Dinámica ABP: • Presentación del problema. § Análisis, construcción de hipótesis

e identificación de la información necesaria.

§ Enumeración de las áreas de duda. § Búsqueda de la información § Discusión de la hipótesis según los

datos. § Replanteamiento / Conclusiones. Actividades ABP: § Resumen de que saben y que

necesitan investigar. § Distribución de tareas y forma de

recolectar la investigación, como colocar todo junto.

§ Evaluación y retroalomentación.

Roles: o Equipo de Trabajo (Miembro,

Moderador y/o Secretario). § Investigación individual. § Discusión grupal. § Discusión plenaria.

o Tutor o Profesor. § Planteamiento del problema. § Seguimiento e integración.

Apoyos: o Chat o Foro o E-mail o Fuentes de Información

Estudio de Casos Con la técnica de EC los alumnos aprenderán a: 1) Analizar y ejercitar sobre un caso típico de estudio. 2) Colaborar y dirigir el aprendizaje utilizando recursos adecuados. 3) Defender el conocimiento adquirido y actuar en forma responsable.

Problema:

• Descripción de una situación real pero abordable.

• Preparada por un equipo de docentes.


• Intercambio de propuestas.

• Confrontación de ideas.

• Preparación de propuesta definitiva.

Estudio individual:

• Exploración de los diversos recursos de aprendizaje.

• Identificación de alternativas.

• Integración de propuesta.

Discusión entre grupos:

• Defensa de postura.

• Conclusiones sobre hechos concretos del caso.

• Reflexión de cada participante.



Subtema Actividad de Aprendizaje

Introducción al middleware Utilizar ABP para abordar el paradigma del middleware

Programación de Transacciones

Realizar un ejercicio práctico

CORBA Utilizar EC para abordar el modelo de CORBA

RMI Realizar un ejercicio práctico

COM+ Realizar un ejercicio práctico

Web Services Realizar un ejercicio práctico

Actividades

Aprendizaje Orientado a Proyectos

Con la técnica de AOP los alumnos aprenderán a: 1) Construir sobre su propio conocimiento una situación real. 2) Colaborar a un ritmo apropiado y actuar con responsabilidad.

Problema:

• Descripción de un situación concreta y real.

• Preparada por un equipo de docentes o propuesta por los alumnos.


• “¿Que proyecto proponemos con base a los conocimientos adquiridos?”

• “¿Que deseamos resolver sobre el tema del curso?”

Tópico seleccionado:

• Análisis y definición de necesidades.

• Planeación de actividades. • Diseño y prototipo.

Producto terminado:

• Reporte técnico

• Manual de usuario

• Presentación



Evaluación

Rúbrica de evaluación para el proceso de

ABP

Actividades Con base al estudio del tema 3 de tecnologías de desarrollo, los alumnos propondrán por equipo, de forma preliminar, el tópico de implementación de un sistema distribuido trivial, con objeto de cubrir más adelante el tema 4, Lenguajes de Programación.

Utilizar AOP para abordar un proyecto sencillo.

Implementación de un sistema distribuido

Actividad de Aprendizaje Tema 4



Evaluación Rúbrica de evaluación para el proceso de AOP

Evaluación

Rúbrica de evaluación para el proceso de

EC



3.1. Introducción al Middleware Escenario Middleware

Evaluación Rúbrica de evaluación de Ejercicios Prácticos



Escenario Middleware • Un sistema distribuido organizado como un middleware:

o Sistema abierto independiente del fabricante. o Sin dependencia del hardware y sistema operativo subyacente.

§ DCE, CORBA, DCOM, …

Máquina C

Sistema Hardware

Máquina B

Sistema Hardware

Máquina A Aplicaciones

Lenguajes de Programación

MIDDLEWARE

Sistema Hardware

Red de Interconexión

Introducción al Middleware

Escenario



Actividad 3.1 Introducción al Middleware Utilizando la técnica de ABP discutir en equipo los modelos del middleware en la actualidad y proponer una representación abstracta de ellos. Foro de discusión Foro Middleware Coloque su trabajo de equipo en Tarea en Equipo 3.1 Se proporciona Material de Apoyo 3.1, solamente como introducción.

Escenario Middleware

• El paradigma significa "un diseño, ejemplo o modelo." En el estudio de cualquier tema de gran complejidad, es útil para identificar los diseños básicos o modelos y clasificar el detalle según estos modelos.

• Este escenario apunta para presentar una clasificación de los

paradigmas para las aplicaciones distribuidas basadas en el middleware.

• Básicamente los middleware pueden clasificarse en tres categorías,

orientados a transacciones, a mensajes y a objetos, entonces el objeto de estudio es la representación abstracta de los modelos en dirección del middleware en la actualidad.

• El desarrollo de este trabajo deberá ser en grupo mediante el proceso

de aprendizaje basado en problemas.



Material de Apoyo 3.1 Introducción al Middleware El middleware es un software de conectividad que consiste en la habilitación de un conjunto de servicios que permiten procesos múltiples corriendo sobre una o más máquinas interactuando por una red. El Middleware es esencial para la migración de aplicaciones de mainframe a aplicaciones cliente -servidor y para mantener la comunicación de plataformas heterogéneas. Esta tecnología ha evolucionado durante los años noventa para proporcionar interoperabilidad en apoyo del movimiento a arquitecturas de cliente-servidor. Las publicaciones más extensas de iniciativas del middleware han sido: Distributed Computing Enviroment (DCE) de Open Software Foundation's, Common Object Request Broker Architecture (CORBA) de Object Management Group's, Distributed Component Object Model (COM/DCOM) de Microsoft's, entre otras. Esquema del Middleware La figura esquematiza el uso del middleware, son servicios con un conjunto de software distribuido que existe entre la aplicación y el sistema operativo y servicios de red en un nodo del sistema en la red. Los servicios del middleware proporcionan un conjunto más funcional de Interfaces de programación de aplicaciones (API) que el sistema operativo y que los servicios de red para permitir una aplicación que permita:

• Localizar de forma transparente por la red, proporcionando interacción con otra aplicación o servicio

• Ser independiente desde los servicios de red. • Ser fiable y disponible. • Aumentar en capacidad sin perdida de función.

Formas de Middleware El middleware puede asumir las formas siguientes: Monitores de procesamiento de transacciones (TP) que proveen herramientas y un entorno para desarrollo y despliegue de las aplicaciones distribuidas. Llamada a procedimientos remotos (RPCs) que permite distribuir la lógica de una aplicación por la red. La lógica del programa en sistemas remotos puede ejecutarse tan simplemente como llamando una rutina local. El middleware orientado a mensaje (MOM) que proporciona el intercambio de datos de programa a programa, habilitando la creación de aplicaciones distribuidas. El MOM es análogo a envío de correo electrónico en el sentido que



es asincrónico y les exige a los destinatarios de mensajes interpretar su significado y tomar medidas apropiadas. Agentes de objetos para peticiones (ORBs) que habilitan los objetos que comprenden una aplicación para ser distribuida y compartida por redes heterogéneas. Consideraciones útiles El propósito principal de servicios del middleware es ayudar en la solución de varios problemas de conectividad de la aplicación y de interoperabilidad. Sin embargo, los servicios del middleware no son un remedio, debido a que:

• Hay un hueco entre los principios y práctica. Muchos servicios del middleware populares usan aplicaciones propietarias (aplicaciones que hacen dependencia en el producto de un sólo vendedor).

• El número de servicios del middleware es una barrera a usarlos. Para guardar su entorno informático manejablemente simple, los desarrolladores tienen que seleccionar un número pequeño de servicios que satisfacen sus necesidades por la funcionalidad y fondos de la plataforma.

• Mientras los servicios del middleware aumentan el nivel de abstracción de programar aplicaciones distribuidas, todavía dejan al desarrollador de aplicaciones con opciones de diseño pesadas. Por ejemplo, el desarrollador todavía debe decidir que funcionalidad poner sobre el lado del cliente y del servidor de una aplicación distribuida.

La clave para superar estos tres problemas es entender el problema de la aplicación y el valor de servicios del middleware que puedan habilitar la aplicación distribuida totalmente. Para determinar los tipos de servicios del middleware requeridos, el desarrollador debe identificar las funciones requeridas, qué entran en una de tres clases: Los servicios de sistemas distribuidos que incluyan comunicaciones críticas, programa-a-programa y servicios de administración de datos. Este tipo de servicio incluye RPCs, MOMs y ORBs. Aplicación que habilita servicios a los que dan acceso de las aplicaciones de servicios distribuidos y la red subyacente. Este tipo de servicios incluye los monitores de transacciones y los servicios de base de datos como el lenguaje de consulta estructurada (SQL). La administración de los servicios del middleware que habilite aplicaciones y funciones del sistema que sean continuamente monitoreados para asegurar el rendimiento óptimo del entorno distribuido.



Rúbrica para evaluación de tareas del proceso de ABP

Atributos Arriba del Estándar

En el Estándar

Debajo del Estándar

Puntos de Atributo

Obtenidos

(5-4.5) (4-3.5) (3-0)

Definición del Problema

Sus intervenciones

mostraron bastante

relación con el escenario y fueron la base para abordar el problema.

Sus intervenciones

mostraron relación con el escenario,

pero no lograron

aterrizarlas del todo para

abordar el problema.

Participación, pero sus

intervenciones no estaban

relacionadas con el

escenario ni condujeron

para abordar el problema.

(10-9) (8.5-7) (6.5 -0)

Profundidad de Estudio

La información

reunida incluye los elementos

esenciales del tema y un estudio en

profundidad del tema.

La información

reunida incluye los elementos

esenciales del tema y un

estudio normal del

tema.

La información reunida está incompleta y no incluye los

elementos esenciales del

tema.

(5-4.5) (4-3.5) (3-0)

Solución/explicación del problema

Su aportación fue

determinante para la

elaboración del reporte final de la

solución del problema.

Hizo bastantes

aportaciones, pero le falto

aterrizarlas en propuestas

concretas de solución al problema.

Hizo pocas aportaciones y sin relación

con las posibles

soluciones del problema.




3.2. Programación de Transacciones Escenario Transacciones

¿Qué es una transacción? • Una transacción es un conjunto de

tareas relacionadas que se realizan de forma satisfactoria o incorrecta como una unidad. En términos de procesamiento, las transacciones se confirman o se anulan. Para que una transacción se confirme, todos los participantes deben garantizar la permanencia de los cambios efectuados en los datos. Los cambios deben conservarse aunque el sistema se bloquee o tengan lugar otros eventos impre vistos.

Programación de Transacciones

Escenario



Escenario de Transacciones

• Si bien, las transacciones están clasificadas dentro de los tipos de middleware. Las transacciones son frecuentemente usadas en aplicaciones de bases de datos distribuidas, Microsoft las incorpora dentro de su infraestructura, como se menciona en el ejemplo previo, sin embargo las mejoras se presentan en COM+, que son los servicios de aplicaciones basadas en componentes de Windows.

• Por el momento en este escenario trataremos un ejercicio sencillo de transacciones y en el tema de COM+ trataremos las transacciones en conjunto con la infraestructura de Microsoft para aplicaciones distribuidas.

¿Qué es una transacción?

La creación de una transacción completa puede requerir la cooperación de varios componentes. En el ejemplo de la figura, la aplicación de entrada de pedidos consta de componentes que, mediante DCOM (Distributed Component Object Model), recuperan y procesan información de varios servidores. MTS(Microsoft Transaction Server) proporciona servicios integrados de programación que permiten a los programadores asegurarse de que toda la transacción tiene éxito o se anula por completo, sin necesidad de escribir grandes cantidades de código personalizado para controlar los mecanismos de la transacción.



Actividad 3.2 Programación de Transacciones Realizar el ejercicio del Escenario Transacciones y colocar su reporte en Tarea Individual 3.2 Se anexa Material de Apoyo 3.2 como consulta y ampliación de comprensión del rubro de transacciones.

Escenario de Transacciones EJERCICIO Utilice un manejador de base datos relacionales. Cree una tabla llamada Cuentas con los campos Clave y Saldo. Inserte 2 registros, la cuenta con clave 100 y la cuenta con clave 200; ambas con $1000.00 El código SQL para crear una transferencia bancaria de $100.00 de la cuenta 100 a la 200 es: UPDATE Cuentas SET Saldo=Saldo – 100.00 WHERE Clave = 100 UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE Clave = 200 Ejecute las instrucciones de SQL para ver que resultados produce en las cuentas: SELECT * FROM Cuentas Ejecute sólo la primera instrucción Cierre la aplicación con la que introduce los comandos SQL Vuelva a entrar a la aplicación y consulte el contenido de la cuenta. Obviamente sólo quedó afectada una cuenta y eso es una falta de consistencia en la información. Con esto se simula la falla de la aplicación y el rompimiento de las propiedades ácidas. Ahora ejecute el siguiente código BEGIN TRANSACTION UPDATE Cuentas SET Saldo=Saldo – 100.00 WHERE Clave = 100 UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE Clave = 200 COMMIT TRANSACTION Analice el resultado Ahora sólo ejecute sólo las primeras 2 líneas del código anterior que consta de 4 líneas. Cierre la aplicación con la que introduce los comandos SQL Vuelva a entrar a la aplicación y consulte el contenido de la cuenta. Analice la importancia del manejo de transacciones.



Rúbrica para evaluación Ejercicios Prácticos


En el Estándar Debajo del Estándar

Puntos de Atributo

Obtenidos (10-9) (8.5-7) (6.5-0)

Aplicación de la

Información



La información revisada


solamente los ejercicios y programas.

La info rmación revisada no



(10-9) (8.5-7) (6.5-0)



material elaborando

correctamente, mientras

extienden y explican la






Los estudiantes no

han hecho contacto con el material,

simplemente sin incorporar la información en su estudio

del tema.




Material de Apoyo 3.2

3.2 Programación de Transacciones

Desde una apreciación general, el hablar de la comunicación entre objetos o componentes a través de un middleware de objetos parece ser muy simple. Sin embargo, se presentan varias implicaciones de mayor complejidad en el contexto en el que trabajan los objetos implicados como: • Transacciones • Concurrencia • Descubrimiento/Nombrado • Seguridad • Etc. Para la Capa de Negocio de una aplicación el control de transacciones es crucial para mantener la consistencia e integridad de las operaciones. Una transacción es un conjunto de acciones que deben efectuarse como una unidad indivisible de trabajo. Ciertamente al ejecutarse el conjunto de acciones que conforma la transacción, puede ocurrir algún error físico o lógico en su ejecución, y de ser así todas las acciones que habían sido efectuadas deben revertirse. Esta acción ayuda a mantener la consistencia e integridad de la información. Este tipo de mecanismos deben conformarse en una serie de servicios disponibles al programador y ofrecer la característica de TRANSPARENCIA. Es decir, es transparente para el programador el revertir automáticamente las acciones u operaciones efectuadas; el programa se limita a especificar el inicio



de la transacción e indicar en qué punto se efectúa la confirmación (commit) y eventualmente, poder indicar en forma programática e intencional el retroceso (rollback) de la transacción. Obviamente, en forma inherente si ocurre un error, se llevará en forma automática el retroceso (rollback) de la operación.

Las transacciones deben de cumplir con 4 características básicas:

1. Atomicidad: “O todo o nada”. Es la característica inherente a la transacción en la que o todas las acciones se efectúan exitosamente o ninguna de ellas.

2. Consistencia: El efectuar exitosamente toda la transacción (commit) los datos involucrados fueron manipulados en forma correcta; o si se revierte (rollback) los datos quedan tal cual como estaban previamente al inicio de la transacción.

3. Aislamiento: Es inherente la característica de concurrencia o bloqueo; ya que mientras un proceso u objeto utiliza determinados datos, otro proceso u objeto no debe modificarlos.

4. Durabilidad: Una vez efectuada una transacción, los datos deben persistir o haberse almacenado en forma permanente.

Por las siglas de estas características en inglés resulta la palabra ACID, que significa ácido. Por lo que suele llamarse “pruebas o características ácidas” el que un administrador de transacciones cumpla con ellas.



EJERCICIO

1. Utilice un manejador de base datos relacional. 2. Cree una tabla llamada Cuentas con los campos Clave y Saldo. 3. Inserte 2 registros, la cuenta con clave 100 y la cuenta con clave 200;

ambas con $1000.00 4. El código SQL para crear una transferencia bancaria de $100.00 de la

cuenta 100 a la 200 es:

UPDATE Cuentas SET Saldo=Saldo – 100.00 WHERE Clave = 100 UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE Clave = 200

5. Ejecute las instrucciones de SQL para ver que resultados produce en

las cuentas:

SELECT * FROM Cuentas

6. Ejecute sólo la primera instrucción 7. Cierre la aplicación con la que introduce los comandos SQL 8. Vuelva a entrar a la aplicación y consulte el contenido de la cuenta.

Obviamente sólo quedó afectada una cuenta y eso es una falta de consistencia en la información. Con esto se simula la falla de la aplicación y el rompimiento de las propiedades ácidas.

9. Ahora ejecute el siguiente código

BEGIN TRANSACTION UPDATE Cuentas SET Saldo=Saldo – 100.00 WHERE Clave = 100 UPDATE Cuentas SET Saldo=Saldo + 100.00 WHERE Clave = 200 COMMIT TRANSACTION

10. Analice el resultado 11. Ahora sólo ejecute sólo las primeras 2 líneas del código anterior que

consta de 4 líneas. 12. Cierre la aplicación con la que introduce los comandos SQL 13. Vuelva a entrar a la aplicación y consulte el contenido de la cuenta. 14. Analice la importancia del manejo de transacciones.



Las transacciones pueden clasificarse de varias formas. Por el control de ejecución, particularmente por la relación que existe en el tiempo de ejecución entre una acción y la siguiente dentro de la transacción, hay transacciones síncronas o asíncronas. La situación más común en una transacción, es que ésta dure muy poco tiempo, algunos segundos (3 ó 4 segundos o menos es ideal, pero no una regla); por lo que la diferencia de tiempo entre una acción y la siguiente es una fracción muy pequeña de segundo. Este tiempo de transacción se denomina síncrona y son las que se tratan en este curso. Una transacción asíncrona es aquella donde existe un tiempo muy prolongado entre una acción y la siguiente dentro de una transacción. Las plataformas y mecanismos de control de transacciones tradicionales no están pensados para este tipo de situaciones. El tiempo de diferencia puede variar de varios minutos, horas o días. Para poder soportar transacciones asíncronas, se requiere una infraestructura adicional basada en colas o queues de mensajes, tanto de salida como de salida, entre el nodo o computadora cliente y la computadora o nodo servidor. Por la ubicación de los administradores de recursos involucrados en la transacción conectados a través de la red, las transacciones pueden ser locales o distribuidas. La transacción será local cuando los administradores de recursos involucrados en cada una de las acciones están en el mismo nodo o computadora.



La transacción será distribuida cuando los administradores de recursos involucrados en las acciones de ésta están en nodos o computadoras distintas y se comunican a través de la red.

Reiterando, una transacción trabajará en un ambiente de ejecución que le proporcione las propiedades ácidas en forma transparente y automática. Esto brinda o proporciona la simplicidad en la programación. El código creado manejando transacciones en la capa de negocios es muy simple bajo este contexto. Las transacciones síncronas son las más comunes y deseadas en el manejo de transacciones.



Como se ha visto en el modelo de aplicación, la capa o servicios de negocio solicitan las operaciones con los datos a la capa o servicios de datos; esta situación genera una pregunta interesante: Si la capa de negocio coordina la transacción entre los componentes que pueden estar en el mismo nodo o nodos diferentes ¿Cómo se controla la transacción en la capa de negocio en coordinación con los diferentes nodos involucrados en la capa de datos? En forma básica puede controlarse una transacción a partir de un componente u objeto el cual solicita una transacción a un DBMS o Sistema Manejador de Base de Datos. El mecanismo de intercambio de información se realiza a través del envío y recepción de mensajes de requerimiento (request) y respuesta (response). Para dar inicio a la transacción se envía un mensaje al DBMS de inicio de transacción, y posteriormente según el caso, se envía el mensaje para confirmar la transacción (commit) o revertirla (rollback). Por otro lado, puede efectuarse una transacción distribuida a través de los mecanismos que ofrecen manejadores de bases de datos distribuidas; sin embargo, este esquema excluye la participación de objetos por lo tanto el modelo de aplicación que divide la aplicación en capas. Ciertamente se efectúa la transacción distribuida pero únicamente a nivel de los manejadores de bases de datos.



Por lo expuesto anteriormente, el control de la transacción debe efectuarse en la capa de negocio. La acción más recurrente o común en una transacción es solicitar operaciones a un manejador de bases de datos. Si existiese un componente en la capa de negocio que solicita una información, éste se constituye en cliente; y si tuviéramos otro componente en la capa de datos constituido en servidor que proporciona esta información comunicándose con el DBMS bajo el contexto de una transacción tendríamos un “procesamiento de transacciones en línea”; el cual, puede llevarse a cabo de dos formas: • TP-Lite: Procesamiento ligero de transacciones realizado a través de

procedimientos o funciones de un API de un proveedor específico • TP-Heavy: Procesamiento robusto de transacciones llevado a cabo por un

TP Monitor o monitor de procesamiento de transacciones.



Un TP monitor es un software especializado para administrar transacciones. En sus orígenes, sólo controlaban las transacciones en la capa de datos. Actualmente, es una función fundamental el administrar la transacción desde la capa de negocio. Otra de sus características es controlar la transacción en forma DISTRIBUIDA. Los TP monitors son capaces de controlar la transacciones, la ruta de transacciones a través de todo el sistema, balancear la carga para su ejecución y restaurar las condiciones del sistema en caso de fallas.

Dada la naturaleza de las aplicaciones cliente/servidor o distribuidas de conformarse a través de un conjunto de objetos comunicándose entre sí, y utilizar un elemento del middleware denominado ORB para lograr esta comunicación.



Los objetos pueden disponerse en un nodo y constituirse como servidor de objetos de aplicación. En forma inherente, debe darse soporte a la concurrencia.

Por tal motivo, deben existir Monitores de Transacciones con Objetos que fungen como servidores de objetos de aplicación. Los cuales disponen los objetos o componentes hacia los objetos o componentes que solicitan estos servicios.

Dada la necesidad de las transacciones y todas sus implicaciones en aplicaciones distribuidas, el monitor de transacciones el software fundamental para administrarlas. Es una estructura de software preconstruida, ayuda a desarrollar y administrar en forma más sencilla una aplicación C/S garantizando



en forma transparente y automática las propiedades ácidas; está optimizada de tal forma que su diseño debe brindar un alto rendimiento.

Retomando la pregunta planteada en párrafos anteriores: ¿Cómo se controla la transacción en la capa de negocio en coordinación con los diferentes nodos involucrados en la capa de datos?; particularmente si esos nodos contienen DBMSs (Manejadores de Bases de Datos) que a su vez administran transacciones locales con los datos. Existe un estándar de comunicación entre elementos involucrados en transacciones distribuidas creados por una organización llamada XOpen, el estándar se llama XA, por lo que el estándar se conoce como XOpen/XA.



Los elementos involucrados en transacciones distribuidas son: 1. Programas de aplicación del proceso cliente que contienen los objetos

que solicitan acciones involucradas en la transacción.

2. Administradores de recursos: Son componentes o sistemas que proporcionan servicios para ejecutar las acciones de una transacción. Los administradores de recursos más comunes son DBMSs.

3. El Administrador de Transacciones (TP Monitor comúnmente) es quien coordina el flujo de información y control de la transacción.



4. Administrador de Comunicaciones que satisface los requerimientos de enlace y control entre los administradores de recursos involucrados en la transacción.

En términos generales, como el control de la transacción debe efectuarse en la capa de negocio; de no existir un monitor de transacciones, el programador tendría que programar toda la comunicación de información y control con los administradores de recursos o DBMSs involucrados utilizando el protocolo XOpen/XA. El Administrador de Transacciones o TP Monitor abstrae la funcionalidad de comunicación con los administradores de recursos, ofreciendo sus servicios a través de un API de objetos para que sea utilizado por el programa cliente. El



TP Monitor se comunicará a través de XOpen/XA con los administradores de recursos, los cuales, sus fabricantes ya implementan generalmente este protocolo en sus productos. El administrador de comunicaciones coordina todo el intercambio de información. El flujo de información y control parte del programa de aplicación cliente. El cual indica el inicio de transacción a través del API que se comunica con el TP Monitor. Cada acción que tenga que ver con un administrador de recursos se controla en el TP Monitor, la cual se controla y direcciona a través de XOpen/XA. Cuando la aplicación cliente indica la confirmación (commit) o reversión (rollback) el TP Monitor coordina la ejecución o reversión en los administradores de recursos involucrados.

3.2.1. Compromiso de 2 Fases (2-Phase Commit)

Dada la naturaleza de la participación de administradores de recursos distribuidos a través de la red, donde cada uno también ofrece el control de la transacción local, que en suma darán la transacción distribuida; la operación de confirmación (COMMIT) también se complica. De hecho, surge el concepto de Commit de 2 Fases (a veces traducido como compromiso o confirmación de 2 fases). A partir de 1980, cada vez más fue requerido los procesos de commit y rollback en los administradores de bases de datos. Al finales de los 80’s, el requerimiento de transacción trascendió a ser distribuido con el objetivo de brindar integridad y consistencia en la información.



De tal forma surge el Commit de 2 Fases, buscando la confirmación de la transacción distribuida con la sincronización de todos los administradores de recursos involucrados ya sea en commit o rollback. Requiere de un elemento coordinador de transacciones distribuidas en cada uno de los nodos que tenga un administrador de recursos.

La primera fase de denomina de Preparación, el nodo que inicia la transacción se convierte en el agente coordinador de la transacción, o también, se le denomina coordinador global. Todos los administradores de recursos van abren una transacción local aplicando las acciones solicitadas; quedando pendiente la confirmación hasta que se concluyan todas las acciones involucradas en la transacción.



En la segunda fase, ya una vez recibida la ejecución de las acciones por los administradores de recursos quedando pendiente la confirmación local en cada uno. Se manda la orden de confirmación en todos los administradores de recursos para que confirmen. Si un administrador de recursos provoca un error, el administrador de transacciones manda la señal de reversión a los administradores de recursos que anteriormente habían tenido éxito, cada uno de estos revierten su transacción local.

Todo el proceso de administración de transacción distribuida es transparente y automático, para ello se emplean Tablas de Transacciones Pendientes y Bitácoras (logs).



Actualmente muchos productos ofrecen el control transaccional y el soporte al commit de 2 fases. Lo esperado es que haya transparencia en la aplicación, pero algunos productos sólo permiten la programación específica, reduciendo en forma importante la transparencia y automatización en la administración de transacciones.

Actualmente se considera madura la tecnología de administración de transacciones distribuidas. Al grado de utilizarse en aplicaciones críticas de negocio como de tipo financiero, bancarios, etc.



Entre algunas de las limitaciones de la administración de transacciones distribuidas son los esquemas propietarios de los algoritmos y en XOpen/XA no hay un soporte de todos los proveedores, así como un diseño de origen basado en un API de programación estructurada.

3.3. CORBA

CORBA

Escenario



Arquitectura General de CORBA

¿Qué es CORBA?

• CORBA es un middeware o marco de trabajo estándar y abierto de objetos distribuidos que permite a los componentes en la red ínter operar en un ambiente común sin importar el lenguaje de desarrollo, sistema operacional, tipo de red, etc.

• En esta arquitectura, los métodos de un objeto remoto pueden ser invocados de forma transparente en un ambiente distribuido y heterogéneo a través de un ORB (Object Request Broker).

• Además del objetivo básico de ejecutar simplemente métodos en objetos remotos, CORBA adiciona un conjunto de servicios que amplían las potencialidades de éstos objetos y conforman una infraestructura sólida para el desarrollo de aplicaciones críticas de negocio.



Descripción de elementos • ORB: Provee un mecanismo de interfaz y de comunicación transparente

entre la referencia de un objeto y su implementación. Ofrece los servicios de localización, establecimiento de la conexión y la transmisión de llamadas de métodos y valores de retorno.

• IIOP: Protocolo para la comunicación entre ORBs a través de TCP/IP. El ORB se comunica a través de IIOP sin intervención del desarrollador.

• IDL (Interface Definition Language): Se utiliza para definir la interfaz para un Objeto CORBA, independiente del leng uaje en que está desarrollado. Utiliza el mecanismo de stub-skeleton (acopladores).

• Object Adapters: Proveen la implementación de tiempo de ejecución de las siguientes responsabilidades: o Generar e interpretar referencias de objetos. o Invocar métodos. o Garantizar la seguridad de las aplicaciones. o Activar y desactivar objetos. o Enlazar las referencias de objetos con las implementaciones.

ORB Interface

DII IDL Stubs

Organización General de un Sistema de CORBA

Proceso del Cliente

Referencia del Objeto

Proceso del Servidor Implementación

del Objeto

ORB IIOP (Internet Inter ORB Protocol)

E IDL Skeleton

DSI

Object Adapter



Procesos Cliente y Servidor • Cliente CORBA

o Stubs del IDL del Cliente o Inicializando el ORB o Usando el Servicio de Nombres o Invocando los Métodos Remotos o Usando los Parámetros Out e Inout

• Servidor CORBA o Skeleton del IDL del Servidor o Implementación de Objetos CORBA o Objetos CORBA y el Servicio de Nombres o Esperando por la Invocación o Usando los Parámetros In e Inout.

Descripción de elementos

o Registrar las implementaciones de objetos. • DII (Dynamic Invocation Interface): El DII permite al cliente aprender en

tiempo de ejecución las operaciones soportadas por el servidor y crear solicitudes, sin stub, que son enviadas directamente al ORB.

• DSI (Dynamic Skeleton Interface): Contraparte de DII, permite al servidor implementar una interfase no conocida en tiempo de ejecución, sin intervención del Skeleton.



Actividad 3.3 Estudio de Caso CORBA (Escenario CORBA) Realizar investigación individual y colocar en Tarea Individual 3.3 Discutir en equipo las investigaciones y colocar reporte en Tarea en Equipo 3.3. Utilice como apoyo el Foro CORBA. Se anexa Material de Apoyo 3.3.

Escenario CORBA

Mediante la técnica de Estudio de Caso, los alumnos realizarán en equipo las actividades siguientes:

• Investigar de forma individual el funcionamiento de CORBA. o Su relación con los lenguajes de programación. o Ejercitar con un ejemplo de implementación.

• Discutir en equipo las investigaciones individuales. o General reporte de discusión.



Rúbrica para evaluación de tareas del proceso de EC


En el Estándar

Debajo del Estándar

Puntos de Atributo

Obtenidos (5-4.5) (4-3.5) (3-0)

Definición del Problema

Sus intervenciones

mostraron bastante

relación con el escenario y fueron la base para abordar el problema.

Sus intervenciones

mostraron relación con el escenario,

pero no lograron

aterrizarlas del todo para

abordar el problema.

Participación, pero sus

intervenciones no estaban

relacionadas con el

escenario ni condujeron

para abordar el problema.

(10-9) (8.5-7) (6.5-0)

Aplicación de la Información

La información

revisada permitió a los estudiantes comprender con claridad

el ejercicio de algoritmos.

La información

revisada permitió a los estudiantes comprender parcialmente el ejercicio de

algoritmos.


permitió a los estudiantes

comprender el ejercicio de algoritmos.

(5-4.5) (4-3.5) (3-0)

Solución/explicación del problema

Su aportación fue

determinante para la

elaboración del reporte final de la

solución del problema.

Hizo bastantes

aportaciones, pero le falto

aterrizarlas en propuestas

concretas de solución al problema.

Hizo pocas aportaciones y sin relación

con las posibles

soluciones del problema.




Material de Apoyo 3.3 3.3 CORBA 3.3.1 Introducción El Object Management Group (OMG) es un consorcio integrado por varias industrias importantes, que ha desarrollado CORBA (Common Request Broker Architecture). CORBA ofrece servicios de interoperabilidad e interconexión de objetos. Los servicios de interoperabilidad e interconexión son normalmente conocidos como servicios middleware. Servicios Middleware Para resolver los problemas inherentes a sistemas heterogéneos y distribuidos, que dificultan la implementación de verdaderas aplicaciones empresariales, los proveedores de software están ofreciendo interfaces de programación y protocolos estándares. Estos servicios se denominan usualmente servicios middleware, porque se encuentran en una capa intermedia, por encima del sistema operativo y del software de red y por debajo de las aplicaciones de los usuarios finales. Un servicio middleware es un servicio de propósito general que se ubica entre plataformas y aplicaciones. Por plataformas se entiende el conjunto de servicios de bajo nivel ofrecidos por la arquitectura de un procesador y el conjunto de API´s de un sistema operativo. Como ejemplos de plataformas se pueden citar: Intel x86 y Win-32, Sun SPARCStation y Solaris, IBM RS/6000 y AIX, entre otros. Un servicio middleware está definido por las API´s y el conjunto de protocolos que ofrece. Pueden existir varias implementaciones que satisfagan las especificaciones de protocolos e interfaces. Los componentes middleware se distinguen de aplicaciones finales y de servicios de plataformas específicas por cuatro importantes propiedades:

• Son independientes de las aplicaciones y de las industrias para las que éstas se desarrollan.

• Se pueden ejecutar en múltiples plataformas. • Se encuentran distribuidos. • Soportan interfaces y protocolos estándar.

CORBA es el estándar propuesto por el OMG. EL OMG fue fundado en 1989 y es el más grande consorcio de industrias de la actualidad, con más de 700 compañías. Opera como una organización no comercial sin fines de lucro, cuyo



objetivo es lograr establecer todos los estándares necesarios para lograr interoperabilidad en todos los niveles de un mercado de objetos. Originalmente los esfuerzos de la OMG se centraron en resolver un problema fundamental: cómo lograr que sistemas distribuidos orientados a objetos implementados en diferentes lenguajes y ejecutándose en diferentes plataformas interactúen entre ellos. Más allá de los problemas planteados por la computación distribuida, problemas más simples como la falta de comunicación entre dos sistemas generados por compiladores de C++ distintos que corren en la misma plataforma frenaron los esfuerzos de integración no bien comenzados. Para opacar aún más el escenario, distintos lenguajes de programación ofrecen modelos de objetos distintos. Los primeros años de la OMG estuvieron dedicados a resolver los principales problemas de cableado. Como resultado se obtuvo la primera versión del Common Object Request Broker, publicado en 1991. Hoy en día, el último estándar aprobado de CORBA está por la versión 2.3, y la versión 3.0 está a punto de ser lanzada. Desde sus principios, el objetivo de CORBA fue permitir la interconexión abierta de distintos lenguajes, implementaciones y plataformas. De esta forma, CORBA cumple con las cuatro propiedades enumeradas como deseables de los servicios middleware. Para lograr estos objetivos, la OMG decidió no establecer estándares binarios (como es el caso de COM); todo está estandarizado para permitir implementaciones diferentes y permitir que aquellos proveedores que desarrollan CORBA pueden ofrecer valor agregado. La contrapartida es la imposibilidad de interactuar de manera eficiente a nivel binario. Todo producto que sea compatible con CORBA debe utilizar los costosos protocolos de alto nivel. CORBA está constituido esencialmente de tres partes: un conjunto de interfaces de invocación, el ORB (object request broker) y un conjunto de adaptadores de objetos (objects adapters). CORBA va más allá de simples servicios middleware, provee una infraestructura para construir aplicaciones orientadas a objetos. Las interfaces definen los servicios que prestan los objetos, el ORB se encarga de la localización e invocación de los métodos sobre los objetos y el object adapter es quien liga la implementación del objeto con el ORB. Para que las interfaces de invocación y los adaptadores de objetos funcionen correctamente, se deben cumplir dos requisitos importantes. En primer lugar, las interfaces de los objetos deben describirse en un lenguaje común. En segundo lugar, todos los lenguajes en los que se quieran implementar los objetos deben proveer un mapeo entre los elementos propios del lenguaje de programación y el lenguaje común. La primera condición permite generalizar los mecanismos de pasaje de parámetros (marshaling y unmarshaling). La segunda permite relacionar llamadas de o a un lenguaje en particular con el lenguaje de especificación común. Este lenguaje común fue una parte esencial de CORBA



desde sus orígenes y es conocido como el OMG IDL: Interfaz Definition Language. Existen mapeos del OMG IDL a C, C++, Java y Smalltalk. El desarrollo basado en componentes El desarrollo basado en componentes que se puedan comprar y poner en marcha sin mayores dificultades (Plug & Play) es una meta a alcanzar que facilitaría la reutilidad de software. En esta sección se hace una breve introducción al desarrollo basado en componentes y el rol que le compete a CORBA en este ámbito. Un componente ha sido definido en la European Conference on Object Oriented Programming (ECOOP) de 1996 como una “una unidad de composición con interfaces contractuales especificadas y dependencias de contexto explícitas.” Un componente de software puede ser desarrollado independientemente y utilizado por terceras partes para integrarlo mediante composición a sus sistemas.” Los componentes son para crear software utilizando composición, por eso es esencial que sean independientes y que se presenten en formato binario, permitiendo así distintos vendedores e integración robusta. Para que un componente pueda ser integrado por terceras partes en sus sistemas, éste deber ser suficientemente auto contenido y debe proveer una especificación de lo que requiere y provee. En otras palabras, los componentes deben encapsular su implementación e interactuar con otros componentes a través de interfaces bien definidas. Un componente no es un objeto. A diferencia de los objetos, los componentes no tienen estado. Esto quiere decir que un componente no puede distinguirse de una copia de sí mismo. Un componente puede tomar la forma de un archivo ejecutable o una biblioteca dinámica que usualmente cobra vida a través de objetos, pero no es este un requisito indispensable. De hecho, los primeros componentes conocidos (aunque en su momento no se los haya definido así) fueron las bibliotecas de procedimientos. Sin embargo, los objetos, con sus características de encapsulamiento y polimorfismo, facilitan la construcción e integración de componentes. Y al hablar de objetos vale la pena distinguir aquí los objetos de las clases. Una clase es una definición de propiedades y funcionalidades ha ser provistas por los objetos. A partir de una clase es posible la instancia objetos. Los componentes pueden contener una o más clases y serán los clientes de los componentes quienes soliciten la creación de las instancias de estas clases. Pero tomando el lugar del programador que debe integrar el componente a su aplicación, surgen algunas incógnitas que debería resolver. El fabricante del



componente solamente ha entregado un archivo ejecutable que se debe iniciar en la máquina en la que se ejecuta la aplicación y la interfaz definida en un lenguaje de definición de interfaces (IDL, Interface Definition Language) estándar. El programador desea ahora:

• Mapear la interfaz: ¿Cómo hace el programador para mapear las clases que el componente provee al lenguaje en que realizará su implementación final? Seguramente el lenguaje de programación elegido provee mecanismos para definir clases, pero es necesario que la definición que se haga de la clase en ese lenguaje corresponda a la definición que dio el fabricante del componente.

• Crear objetos: ¿Cómo hace el programador para crear una instancia del

objeto Venta? Es necesario que exista un mecanismo para indicar al componente que cree una instancia del objeto Venta. Una vez creada la instancia ¿Cómo se logra acceder a sus propiedades o métodos?

• Transparencia: El componente sería de poca utilidad si su utilización no

fuera transparente. Si para cada llamada al componente el programador tiene que utilizar un servicio del sistema operativo de llamada entre procesos (IPC), o peor aún si el componente es remoto, un servicio de llamada remota a procedimientos (RPC), está claro que dejaría el componente de lado pues es más trabajo utilizarlo que hacer un programa desde cero.

Estas son sólo algunas de las cuestiones que el programador tendrá que resolver para poder utilizar el componente. En el caso de que el programador llegara a comprar otro componente, es seguro que desea que los mecanismos de utilización sean uniformes para no tener que resolverlas nuevamente. Los servicios middleware que provee CORBA buscan resuelven estos problemas. 3.3.2 Generalidades de CORBA CORBA es un Middeware o marco de trabajo estándar y abierto de objetos distribuidos que permite a los componentes en la red ínter operar en un ambiente común sin importar el lenguaje de desarrollo, sistema operacional, tipo de red, etc. En esta arquitectura, los métodos de un objeto remoto pueden ser invocados “transparentemente” en un ambiente distribuido y heterogéneo a través de un ORB (Object Request Broker). Además del objetivo básico de ejecutar simplemente métodos en objetos remotos, CORBA adiciona un conjunto de servicios que amplían las potencialidades de éstos objetos y conforman una infraestructura sólida para el desarrollo de aplicaciones críticas de negocio. CORBA es la respuesta del “Grupo de Gestión de Objetos” (Object Management Group – OMG) a la necesidad de interoperabilidad ante la gran proliferación de productos hardware y software. CORBA permite a una



aplicación comunicarse con otra sin importar el tipo de red, protocolo, sistema operacional o lenguaje de desarrollo. CORBA automatiza muchas tareas comunes y “pesadas” de programación de redes tales como registro, localización y activación de objetos; manejo de errores y excepciones; codificación y decodificación de parámetros, y protocolo de transmisión. En un ambiente CORBA, cada Implementación de Objeto, define bien su Interfaz a través una especificación normalizada conocida como IDL (Interface Definition Language) a través de la cual en forma Estática (en el momento de compilación) o en forma Dinámica (en el momento de ejecución) un Cliente que requiera el servicio de una Implementación de Objeto, puede ser ejecutada. Las invocaciones a métodos remotos son enviadas por los clientes llamando objetos locales llamados “Stubs” (generados por un compilador de IDL - Estático), el cual intercepta dichas invocaciones y continúa el proceso de llevar y retornar automáticamente dicha invocación. La Implementación del objeto, no tiene que conocer el mecanismo por el cual un Cliente le ha invocado un servicio. Cuando el Cliente y una Implementación de Objeto están distribuidos por una red, usan el protocolo GIOP/IIOP suministrado por la arquitectura para lograr la comunicación. La forma en cómo una Implementación de Objeto (desarrollada por un programador de aplicaciones) se conecta a un ORB, es a través de un Adaptador de Objetos. Este adaptador recibe las peticiones por la red e invoca los servicios a la implementación correspondiente. Actualmente CORBA ya ha resuelto los problemas fundamentales de interoperabilidad y comunicación entre objetos y se han definido y especificado un conjunto de servicios comunes requeridos para la construcción de las aplicaciones, pero donde hay gran actividad es en la especificación de objetos comunes por dominio de aplicación o conocidas en CORBA como Interfaces de Dominio. Allí se trabajan en áreas como Telecomunicaciones, Medicina, Finanzas, Manufactura, etc. CORBA esta fundamentado en dos modelos: un modelo de objetos, el cual agrega todas las características de Orientación por Objetos como Tipos de Datos, Abstracción, Polimorfismo y Herencia y un modelo de referencia o arquitectura conocida como OMA (Object Management Architecture). 3.3.3 Object Management Group (OMG) La OMG fue fundada en abril de 1989 por 11 compañías, en octubre de 1989, la OMG comenzó operaciones independientes como una entidad sin ánimo de lucro. A través de sus comités, la OMG desarrolla especificaciones



independientes de cualquier proveedor para la industria del software. Actualmente el consorcio tiene más de 800 miembros. La OMG se esta moviendo a establecer a CORBA como el “Middleware que esta en todas partes” a través de sus especificaciones CORBA/IIOP, Servicios de Objetos, Facilidades de Internet y Especificaciones de Dominio, entre otras. La misión de la OMG es crear un mercado de software basados en componentes introduciendo las tecnologías de objetos. Establecer guías y especificaciones para proveer un marco común para el desarrollo de aplicaciones. Conforme a estas especificaciones, será posible desarrollar en ambientes heterogéneos a través de la gran variedad de productos hardware y software existente. La OMG define la administración de objetos como el desarrollo de software que modela el mundo real a través de la representación de “objetos”. Estos objetos son la encapsulación de los atributos, relaciones y métodos de software identificables como componentes de un programa. La administración de objetos facilita el desarrollo rápido de aplicaciones, facilidad de mantenimiento, escalabilidad y reutilidad del software. La OMG esta estructurado en tres grandes cuerpos: el Comité de Plataforma Tecnológica (Platform Technology Committee - PTC), el Comité de Dominio Tecnológico (Domain Technology Committee - DTC) y la Junta de Arquitectura (Architecture Board). Dentro de los Comités Técnicos y Junta de Arquitectura, trabajan las Fuerzas de Trabajo, Grupos de Interés Especial y Grupos de Trabajo quienes llevan a cabo los procesos de adopción tecnológica de la OMG. 3.3.4 Object Management Architecture - OMA Una de las metas principales de la arquitectura OMA, es introducir las tecnologías orientadas a objetos como soporte a la nueva generación de aplicaciones y sistemas distribuidos, por ello, un esquema de administración de objetos representa los siguientes beneficios: Interfaces de usuario orientadas a objetos. Funcionalidades comunes en diferentes aplicaciones, tal como almacenamiento y recuperación de objetos, correo de objetos, impresión, creación y borrado de objetos. Compartir información, desde el punto de vista de acceso múltiple a través de aplicaciones. La transición a un esquema orientado por objetos no quiere decir que las aplicaciones existentes son obsoletas. Las aplicaciones existentes pueden ser incorporadas en un ambiente orientado por objetos. El Modelo de Objetos



Provee una representación organizada de los conceptos y terminología de objetos. El modelo de la OMG es abstracto en el sentido que directamente no realiza una tecnología particular, el modelo descrito aquí es un modelo de objetos concreto. Un sistema de objetos es una colección de objetos que aíslan las peticiones de servicios (clientes) de la provisión de los servicios por el encapsulamiento de las interfaces. El modelo de objetos es un ejemplo del modelo clásico de objetos, donde un cliente envía un mensaje a un objeto. Conceptualmente, el objeto interpreta el mensaje para decidir que servicio ejecutar. En este modelo, la selección de métodos es ejecutada por el objeto o por el ORB. Semántica de Objetos Un sistema de objetos provee servicios a clientes. Un cliente de un servicio es cualquier entidad capaz de requerir servicios. Conceptos relevantes a un cliente: Objeto: un objeto es una entidad identificable y encapsulada que provee uno o más servicios que pueden ser requeridos por un cliente. Requerimientos: los clientes solicitan un servicio enviando un requerimiento. Un requerimiento es un evento. La información asociada a este evento consiste en una operación, objeto destino, cero o más parámetros y contextos opcionales del requerimiento. Creación y Destrucción de Objetos Aunque los objetos pueden ser creados o destruidos, desde el punto de vista del cliente no existen mecanismos especiales para la creación o destrucción. Tipos Un tipo es una entidad identificable con un predicado asociado definido sobre valores. Un valor satisface un tipo si el predicado es verdadero para este valor. Un valor que satisface un tipo es llamado un miembro del tipo. Un tipo de objeto es un tipo cuyos miembros son objetos. En otras palabras, un tipo objeto es satisfecho solo por objetos.

• Tipos básicos: Enteros de 16 y 32 bits con y sin signo, números IEEE de punto flotante de 32 y 64 bits, caracteres ISO Latin-1 (8859.1), booleano,



opaco de 8 bits, enumerados, string de longitud variable y tipo any el cual representa cualquier posible tipo básico o construido.

• Tipos complejos: estructuras, uniones, secuencias, arreglos, interfaces,

etc. Interfaces Una Interfaz es una descripción de un conjunto de posibles operaciones que un cliente puede requerir de un objeto. Un objeto satisface una Interfaz si este puede ser especificado como el objeto destino en cada requerimiento potencial descrito por la Interfaz. Un tipo de Interfaz es un tipo que es satisfecho por cualquier objeto que satisface una Interfaz particular. Las Interfaces en OMG son especificadas en IDL (Interface Definition Language). La herencia de Interfaces provee los mecanismos para permitir a un objeto soportar múltiples Interfaces. La Interfaz principal es simplemente la Interfaz más especifica que el objeto soporta y consiste en todas la operaciones en la transitive closure del grafo de herencia de Interfaz. Operaciones Una Operación es una entidad identificable que denota un servicio que puede ser requerido. Una operación es identificada por un identificador de operación y tiene una firma que describe los valores legítimos de los parámetros requeridos y resultados retornados. Las excepciones son una indicación que un requerimiento de operación no ha ejecutado exitosamente. Un contexto de requerimiento provee información adicional y especifica de la operación que puede afectar el rendimiento de un requerimiento. Semántica de ejecución Dos estilos de semántica de ejecución son definidos para el modelo de objeto:

• Al menos una vez: si un requerimiento de operación retorna exitosamente, este fue ejecutado exactamente una sola vez, si este retorna una indicación de excepción, este fue ejecutado al menos una vez.



• Mejor esfuerzo: una operación de mejor esfuerzo es una operación de requerimiento único, este no puede retornar cualquier resultado y el solicitante nunca se sincroniza con la terminación.

Atributos Una Interfaz puede tener atributos. Un atributo puede ser sólo lectura o lectura-escritura. Implementación de objetos El modelo de implementación consiste en dos partes: el modelo de ejecución y el modelo de construcción. El modelo de ejecución describe como los servicios son ejecutados y el modelo de construcción describe como los servicios son definidos.

• Modelo de ejecución: el servicio requerido es ejecutado en un sistema computacional por ejecución de un código que opera sobre los mismos datos. El código que es ejecutado para realizar un servicio es llamado método. Un método es una descripción inmutable de una computación que puede ser interpretada por el motor de ejecución. Un método tiene unos atributos inmutables llamados "formato de método" que define el conjunto de máquinas de ejecución que pueden interpretar el método. Un motor de ejecución es una máquina abstracta (no un programa) que puede interpretar métodos en ciertos formatos, causando que las computaciones descritas sean realizadas. Un motor de ejecución define un contexto dinámico para la ejecución de un método. La ejecución de un método es llamada "activación de método".

• Modelo de construcción: una implementación de objeto o implementación

es una definición que provee la información necesaria para crear un objeto y permitir al objeto participar en proveer un apropiado conjunto de servicios. Una implementación típicamente incluye, entre otras cosas, la definición de los métodos que operar sobre el estado de un objeto. también incluye información acerca de los tipos intended del objeto.

Elementos de OMA

• Object Request Broker – ORB: representa el medio o bus de objetos a través del cual se comunican todos los objetos participantes en el sistema. El ORB es el corazón de comunicaciones del estándar. Este es referido comercialmente como CORBA. Este provee una infraestructura que permite a objetos comunicarse, independiente de la plataforma especifica y técnicas usadas para implementar el objeto direccionado. El



ORB garantiza portabilidad e interoperabilidad de objetos sobre una red de sistemas heterogéneos.

• Objetos de Servicio – CORBAServices, son un conjunto de objetos

genéricos, que son usados por muchos programas distribuidos, como soporte a tareas muy comunes. Actualmente se tienen definidos los siguientes objetos de servicio: Nombres, Ciclo de Vida, Persistencia, Seguridad, Consulta, Propiedades, Transacciones, Eventos, Tiempo y Negociador entre otros.

• Objetos de Dominio – CORBADomain, es un conjunto de objetos que

son comunes y estándares dentro de un dominio o mercado de aplicación, se cuentan con dominios como: Telecomunicaciones, Finanzas, Comercio Electrónico, Medicina, Transportes, Transportes, etc.

• Facilidades Comunes – CORBAFacilities, conjunto de objetos

orientados hacia las aplicaciones de usuario final como Administración de Datos, Aplicaciones, Interfaces de Usuario, etc.

Objetos de Aplicación: son desarrollados por el programador. La figura muestra los elementos de OMA.

3.3.5 Object Request Broker - ORB El Object Request Broker (ORB) es el middleware que establece las relaciones cliente/servidor entre objetos. Usando un ORB, un cliente puede transparentemente invocar un método sobre un objeto remoto. El ORB intercepta la llamada y es responsable de encontrar el objeto que implementa el requerimiento, pasar los parámetros, invocar el método y retornar el resultado. El cliente no tiene que preocuparse de donde esta implementado el objeto, su lenguaje de desarrollo, sistema operacional o tipo de red. De esta forma el ORB



provee la interoperabilidad entre aplicaciones sobre diferentes máquinas en un ambiente heterogéneo distribuido. En el esquema actual de aplicaciones cliente/servidor, los desarrolladores usan su propio diseño o un “estándar” para definir el protocolo a ser usado entre los dispositivos. La definición de ese protocolo depende del lenguaje de implementación, transporte de red y otros factores. Un ORB simplifica este proceso, por ejemplo el protocolo es definido a través de una especificación de las Interfaces conocida como IDL. Una vez se tiene claro las Interfaces, el lenguaje de implementación o sistemas operacionales y de red, ya no es relevante. La especificación IDL de OMG provee una forma estándar de definir las Interfaces a los objetos CORBA. La definición IDL es una especie de contrato entre el desarrollador de un objeto y el cliente. IDL es independiente del lenguajes de programación y se mapea a los lenguajes más típicos para desarrollar, actualmente se encuentra generación de código a C, C++, SmallTalk, Java, Ada, COBOL, etc. Más importante aún, una solución basada en ORB, permite integrar aplicaciones existentes, simplemente describiendo sus Interfaces en IDL y escribiendo los "wrappers" que traslada entre el bus estandarizado y las Interfaces existentes. Lo que permite en el ORB la interoperabilidad e independencia de muchos factores, es la definición de los objetos en un lenguaje de especificación totalmente independiente del lenguaje de implementación, este lenguaje se conoce como Interface Definition Language (IDL) Elementos de un ORB Implementación del Objeto: realizado por el programador. Implementa las operaciones especificadas en la definición IDL. La implementación puede ser escrita en una variedad de lenguajes como C, C++, Java, SmallTalk, Ada, etc. Cliente: entidad que invoca una operación en una Implementación de Objeto remoto. De igual forma puede ser desarrollado en varios lenguajes y es realizado por un programador de aplicaciones. Núcleo ORB: provee mecanismos para transportar de manera transparentemente requerimientos de Clientes hacia Implementaciones de Objeto remotos. Es responsable de interceptar todas las llamadas del cliente, localizar el objeto, codificar y enviar el requerimiento y esperar la respuesta, la cual es retornada al Cliente.



Interfaz ORB: ofrece varias funciones de ayuda, tales como conversión de referencia de objetos a texto y viceversa, creación de lista de argumentos para invocación DII, entre otras. Stubs y Skeleton IDL: Los stubs y skeleton sirven como “pegante” entre el cliente y servidor respectivamente y el ORB. Son estáticos y generados en tiempo de compilación por un compilador IDL el cual transforma las Interfaces IDL hacia el lenguaje de desarrollo, esto reduce las posibilidades de errores al generar automáticamente los stubs y skeleton. Interfaz de Invocación Dinámica (DII): esta Interfaz permite a un cliente construir dinámicamente un requerimiento sin tener un stub, lo cual significa que los requerimientos son construidos en tiempo de ejecución. Otra ventaja de este esquema es permitir llamadas sincrónicas de no bloqueo (deferred) y llamadas asincrónicas de una sola vía (oneway) Interfaz Skeleton Dinámica (DSI): cumple las mismas funciones de DII pero en el lado del servidor. Permite que el ORB realice llamadas a una Implementación de Objeto del cual no se tiene conocimiento de la Interfaz. Adaptador de Objetos: este módulo asiste al ORB con la entrega de requerimientos a los objetos y con la activación de objetos de acuerdo a varias políticas. Un adaptador de objetos asocia una implementación de objetos con el ORB. Actualmente se tienen definidos dos tipos de adaptadores: BOA (Basic Object Adaptor) y POA (Portable Object Adaptor). La figura muestra los elementos de un ORB.



Un ORB no tiene que ser implementado como un componente único. Las Interfaces que ofrecen los ORB están organizadas en 3 categorías: Operaciones para todas las implementaciones de ORB Operaciones especificas a tipos particulares de Objetos Operaciones especificas a estilos particulares de implementación de objetos. El núcleo del ORB es el componente que provee la representación básica de objetos y la comunicación de requerimientos. Un cliente tiene acceso al objeto a través de una “Referencia al Objeto”, el cliente solo conoce la Interfaz que este objeto tiene con el entorno. Los clientes generalmente “ven” los objetos y el ORB bajo la perspectiva de un lenguaje mapeado, trayendo el ORB a niveles del programador. Una variedad de Implementaciones de Objetos se pueden soportar en CORBA, incluyendo servidores separados, librerías, un programa por método, una aplicación encapsulada, una base de datos orientada a objetos, etc. Referencias de Objeto Es la información necesaria para especificar un objeto dentro de un ORB. Tanto los clientes como las implementaciones del objeto tienen una noción “opaca” de la referencia de objeto de acuerdo al lenguaje de mapeo y así aislar la representación real de estos. Dos ORB pueden diferir en la elección de la representación de las Referencias de Objeto. Lenguaje de especificación de Interfaces IDL es la forma de especificar las Interfaces de un objeto en el ambiente CORBA. De estas defunciones en IDL, es posible mapearlos a una variedad de lenguajes de programación o sistemas de objetos. Este lenguaje de mapeo también define la interacción entre la invocación de los objetos y los hilos de control en el cliente o implementación. El lenguaje de mapeo provee llamadas sincrónicas, es decir, no retorna hasta que se termine de ejecutar el método en la implementación del objeto. Adaptador de objeto Es la forma principal para acceder los servicios de una implementación de objeto provistos por el ORB.



Los servicios provistos por el ORB a través de un Adaptador de Objetos incluye: generación e interpretación de referencia de objetos, invocación de métodos, seguridad de interacciones, activación/desactivación de objetos e implementaciones, mapeo de referencias de objeto a implementaciones y registro de implementaciones. Un adaptador de objetos exporta una interfaz pública a la implementación del objeto y una privada al skeleton. Es responsable de las siguientes funciones:

• Generación e interpretación de referencias de objetos • Invocación de métodos • Seguridad de interacciones • Activación/desactivación de objetos e implementaciones • Mapeo de referencias de objeto a las correspondientes implementaciones

de objeto • Registro de implementaciones

Ejemplos de Adaptadores de Objetos: Basic Object Adapter: define una especificación que puede ser usada por muchos objetos ORB con implementaciones convencionales. Para este adaptador, las implementaciones son generalmente programas separados. Esto permite activar un programa por: método, objeto y compartido para todas las instancias del tipo de objeto. Si la implementación no esta activa, el BOA comienza una. Library Object Adapter: es utilizado por los objetos que tienen implementaciones de librerías. Este accede el almacenamiento persistente en archivos y no soporta activación o autenticación, ya que los objetos se asume que están en los clientes. Object-Oriented Database Adapter: usa una conexión a una OODB para proveer acceso a los objetos almacenados. Los objetos pueden ser registrados implícitamente. Interfaz ORB Son las Interfaces que directamente llegan al ORB y que son las mismas para todas las implementaciones de ORBs y que no depende de la Interfaz de un objeto o adaptador. Ya que muchas de las funcionalidades del ORB son provistas a través del adaptador de objetos, stubs, skeleton o invocación dinámica; quedan pocas operaciones comunes a través de todos los objetos. Repositorio de Interfaces



Es un servicio que provee objetos persistentes que representan la información IDL en forma disponible en tiempo de ejecución. También el IR es un lugar común para almacenar información adicional asociada con Interfaces al ORB. (ej: debug, librerías de stubs/skeleton, etc.). Repositorio de implementación Contiene información que permite al ORB localizar y activar implementaciones de objetos, aunque esta información es muy dependiente de la implementación del ORB o del ambiente operativo. Ejemplos de implementaciones de ORB Cliente e Implementación residen en el ORB: Si hay un mecanismo adecuado de comunicaciones, un ORB puede ser implementado en rutinas residentes en el cliente e implementaciones. Los stubs en el cliente pueden utilizar un esquema de IPC o directamente acceder la localización de un servicio. El código enlazado con las implementaciones es responsable de configurar las bases de datos apropiadas para uso de los clientes ORB basado en Servidor: administración centralizada. Todos los clientes e implementaciones pueden comunicarse con uno o más servidores cuya función es enrutar los requerimientos de clientes a implementaciones. Se utilizan IPC para comunicación hacia el ORB. ORB basado en sistema: para mejorar la seguridad, robustez y rendimiento, el ORB puede ser provisto como un servicio del Sistema Operacional, pueden existir optimizaciones como evitar el marshalling cuando ambos están en la misma máquina. ORB basado en librería: para objetos que son de “peso liviano” y cuyas implementaciones pueden ser compartidas, la implementación del ORB podría ser en una librería. En este caso, los stubs pueden ser los métodos reales. Esto asume, que es posible para un cliente tener acceso a los datos para los objetos y que la implementación confía en que el cliente no dañara los datos. 3.3.6 CORBA Services OMA esta construida sobre un fundamento y arquitectura CORBA que desarrolla la visión de la OMG de componentes de software plug-and-play. Los CORBA Services especifican servicios básicos casi todos los objetos necesitan.



Para cada componente de OMA, la OMG provee una especificación formal descrita en OMG IDL (como invocar cada operación dentro de un objeto) y su semántica en lenguaje inglés (que hace cada operación y las reglas de comportamiento). Un proveedor no tiene que suministrar obligatoriamente ningún servicio adicional al ORB, pero si este lo ofrece, deberá esta de acuerdo a la especificación que para este servicio tiene la OMG. Los CORBA Services proveen servicios a nivel de aplicación fundamentales para las aplicaciones orientadas por objetos y componentes en entornos distribuidos. La OMG ha definido alrededor de 15 servicios de objetos. Los cuales son:

• Nombres • Trader • Notificación • Eventos • Transacciones • Seguridad • Ciclo de vida • Propiedades

• Persistencia • Consulta • Relaciones • Concurrencia • Externalización • Licenciamiento • Tiempo • Colección

De éstos 15 se destacan los siguientes servicios clave:

• Acceso a referencias de objetos a través de la red, soportada por el servicio de Nombres y de Trader.

• Notificación de eventos importantes o cambios de estado en un objeto, soportado por el servicio de Eventos y de Notificación.

• Soporte para semántica transaccional (two-phase commit y rollback) soportado por el servicio de Transacciones.

• Soporte para seguridad, soportada por el servicio de Seguridad. Nombres: permite a componentes descubrir otros componentes en un ambiente distribuido, básicamente es un servicio de localización que asocia identificadores a manejadores que proveen una forma de contactar el componente deseado en un sistema distribuidos. Este asocia nombres - organizados jerárquicamente - a objetos. Ciclo de vida: básicamente es un servicio de configuración, define servicios y convenciones para crear, borrar, copiar y mover componentes en un sistema distribuido. Eventos: implementa un modelo de comunicación desacoplado, basado en el paradigma publicación/suscripción. En este modelo, uno o más publicadores pueden enviar mensajes relacionados con un tópico específico, mientras que un grupo de suscriptores reciben los mensajes asincrónicamente. Con estos



mecanismos, los publicadores pueden generar evento sin tener que conocer la identificación de sus consumidores y viceversa. Hay dos acercamientos, modelo Push y modelo Pull, en el modelo Push los publicadores toman la iniciativa de iniciar la comunicación, en el modelo Pull, los suscriptores requieren eventos de los publicadores. Transacciones: gestiona interacciones entre objetos distribuidos estableciendo puntos de Commit y delimitación de transacciones. Este servicio soporta varios modelos y permite interoperabilidad entre diferentes arquitecturas de red y modelos de programación. Seguridad: controla la identificación de los elementos del sistema distribuido (usuarios, objetos, componentes, etc) que permite verificar que un cliente esta autorizado a acceder los servicios de una implementación remota. Adicionalmente permite la comunicación segura sobre enlaces de comunicación inseguros, ofreciendo confidencialidad e integridad de la información transmitida. Tiempo: suministra información del tiempo y permite la definición de llamadas periódicas. Licenciamiento: controla la utilización de objetos específicos, inhibiendo uso inadecuado de derechos y propiedad intelectual. Propiedades: provee la habilidad de dinámicamente asociar propiedades a los objetos los cuales pueden ser consultados o modificados por otros elementos. Relaciones: permite la definición del papel ejecutado por objetos CORBA en una relación. Consulta : permite a los usuarios y objetos invocar operaciones de consulta sobre colecciones de objetos. Persistencia: provee mecanismos para retener y mantener el estado de objetos persistentes. Concurrencia: permite la coordinación de múltiples accesos a recursos compartidos a través de la provisión de varios modelos de locks y permite resolución flexible de conflictos. Externalización: define convenciones y protocolos para representar el estado de información relacionado a un objeto en la forma de una secuencia de datos, permitiendo a esta información ser almacenada o transferida a otras localizaciones. 3.3.7 CORBA Facilities Horizontales



Las facilidades CORBA tanto horizontales como verticales, son diseñadas para completar la arquitectura entre los Servicios básicos de CORBA y las aplicaciones específicas de industria. Con una arquitectura completa, las compañías compartirán datos a nivel de aplicación y funcionalidades para la integración de diferentes sistemas de información. Las facilidades representan un punto medio entre una aplicación particular y los servicios y ORB. La OMG ha definido como Facilidades Horizontales las siguientes:

• Interfaz de usuario • Administración de información • Administración de sistemas • Administración de tareas

Hoy en día estas especificaciones han sido adheridas a ORBOS (ORB y Servicios) y ya no están como un grupo aparte. Específicamente a nivel de facilidades verticales la OMG ha definido las siguientes: Especificación para la administración de sistemas XCMF. Facilidad para colar de impresión. 3.3.8 CORBA Facilities Verticales o de Dominio La potencialidad que representa el lenguaje IDL para la especificación de un objeto u componente ha permitido trabajar en la normalización de intereses comunes para un sector de mercado particular y que una vez se llegue a un acuerdo en cuanto a estas especificaciones, sería estándar dentro de este mercado. Para esto se ha creado el Domain Technology Committee (DTC) y esta a su vez esta organizada en una serie de Domain Task Forces (DTF) los cuales escriben documentos de requerimientos (RFI y RFP) para nuevas especificaciones y evalúan y recomiendan especificaciones candidatas. Basados en las recomendaciones de los DTF, el DTC conduce un proceso formal de votación para asegurar que cumple todos los requerimientos del sector y no solo de quien haya propuesto. Posteriormente estas recomendaciones requieren ser enviadas a la Junta de Directores de la OMG para hacerla una especificación oficial. Actualmente hay 8 DTF:

• Objetos de negocio • Finanzas y seguros • Comercio Electrónico • Manufactura • Salud o Medicina



• Telecomunicaciones • Transportes • Investigación de ciencias de la vida

También bajo la OMG pero que no tienen DTF se encuentran dos Grupos de Interés Especial:

• Utilities (principalmente energía eléctrica) • Estadística

Seis especificaciones ya han sido adoptadas oficialmente como estándares de dominio vertical, ellos son:

• Facilidad Currency del DTF de Finanzas. • Un conjunto de Habilitadores para la administración de datos de

productos, del DTF de manufactura. • Servicio de Identificación de Personas (PIDS) de CORBAMed • Servicio de Consulta Lexicon de CORBAMed • Control y Administración de flujos de Audio/Vídeo, del DTF de

telecomunicaciones. • Servicio de Notificación, del DTF de Telecomunicaciones.

3.3.9 Nuevas especificaciones de CORBA Después que fue completada y normalizada la versión 2.0 en 1996, la OMG continuo trabajando en la incorporación de aspectos importantes que deben ser tenidos en cuenta en un sistema distribuido y ha ampliado su modelo de objetos para incorporar aspectos como: múltiples Interfaces por objeto, paso de objetos por valor, modelo de componentes, soporte para tiempo real y tolerancia a fallos entre otros. CORBA 3.0 se refiere a una serie de nuevas especificaciones que unidas dan una nueva dimensión a CORBA. Estas nuevas especificaciones están divididas en tres categorías:

• Integración con Internet. • Control de Calidad de Servicio • Arquitectura de componentes CORBA

Por otro lado, han aumentado las especificaciones de mercados verticales, o lo que en CORBA se conoce como Dominios Verticales y mediante la utilización de IDL, existen muchos mercados estandarizando en CORBA (Finanzas, Seguros, Comercio Electrónico, Medicina, Manufactura, Telecomunicaciones, Transportes, Investigación y Objetos de Negocio). A continuación se describen las características más importantes de los últimos adelantos en CORBA 3.0:



Integración con Internet Esta integración esta siendo desarrollada por la especificación “firewall”. La especificación CORBA 3 define firewalls a nivel de transporte, de aplicación y conexiones bidireccionales GIOP útiles para callbacks y notificación de eventos. Los firewalls de transporte trabajan a nivel de TCP, para lo que la IANA ha reservado los puertos bien conocidos 683 para IIOP y 684 para IIOP sobre SSL. También hay una especificación de CORBA sobre SOCKS. En CORBA es frecuente que un objeto invoque un método (callback) o notifique de algún suceso a su cliente, por esto el objeto puede comportarse como cliente, por esto generalmente se requiere abrir una nueva conexión TCP en sentido inverso el cual puede ser detenido por un firewall. Bajo esta especificación, a una conexión IIOP se le permite llevar invocaciones en el sentido inverso bajo ciertas condiciones que no comprometan la seguridad de la conexión. UML y MOF: Soporte para análisis y diseño El modelado es una pieza clave en el desarrollo de software robusto, antes que existiera UML de OMG, no había mecanismos estándares para intercambiar modelos de una herramienta a otra. UML es un lenguaje visual para el modelado e intercambio de modelos bien definidos para el desarrollo de software. Aunque a un nivel básico UML suple muchas de las necesidades de los usuarios, esta puede ser especializada para incorporar aspectos que no contemplaban otras herramientas. Esta diseñado para soportar herramientas y colaboración utilizando marcos de trabajo, patrones y componentes. UML define una notación gráfica para cada uno de los siguientes diagramas: de casos, de uso, de clases, de comportamiento, de implementación incluyendo diagramas de componentes y de desarrollo. Modelo de componentes de CORBA (CORBABeans) CORBA Components extiende el modelo de objeto de la OMG para incluir un número de características importantes en un sistema distribuido. La noción de componente puede no corresponder al modelo uno a uno ni de un objeto CORBA, esta centrado más en la relación de un Componente con un conjunto de Interfaces. Los componentes tienen identificadores de instancias, así como propiedades que son externamente accedidas y que soporta mecanismos de notificación (servicio de eventos) y validación cuando alguna propiedad cambia.



Los componentes de CORBA serán trasladados a los lenguajes ya soportados, y a otros modelos de componentes como los Java Beans. Igualmente se esta trabajando en una especificación para un lenguaje de scripting que facilite el nivel de usuario la utilización de componentes. Control de la Calidad del Servicio Mensajes Asincrónicos y Control de Calidad del Servicio. La nueva especificación de Mensajería define un número de modos de invocaciones asincrónicas e independientes del tiempo para CORBA el cua l permite tanto invocaciones estáticas como dinámicas en cada modo. Las invocaciones asincrónicas pueden ser realizadas de dos formas: censando (polling) o callback. Las políticas permite tener control de la Calidad del Servicio de las invocaciones, los clientes y objetos pueden establecer control de ordenación (por tiempo, prioridad, deadline), configurar prioridades, deadlines y tiempos de vida, configurar tiempos de inicio y finalización para invocaciones sensibles al tiempo y controlar las políticas de enrutamiento y número de saltos. Tiempo Real, Tolerancia a Fallos y CORBA Mínimo. Aunque ya hay muchos desarrollos de productos de tiempo real en CORBA y que hay un grupo de trabajo en el área en la OMG, la incorporación de aspectos de tiempo real en un ORB es opcional, es decir no es obligatorio que cumpla requisitos de tiempo real para un proveedor de ORBs. Pero si un proveedor ofrece esta característica en sus productos, deberá cumplir las especificaciones definidas para tal caso. La primera especificación cubrirá aspectos como Planificadores de prioridad fija, control de los recursos del ORB para predictibilidad extremo a extremo y comunicaciones flexibles. El nuevo Adaptador de Objetos Portable (POA), que permite a una implementación acoplarse a un ORB es lo suficientemente robusto y flexible para soportar redundancia y tolerancia a fallos en ambientes CORBA, pero aún es necesario trabajar directamente en este campo por parte de la OMG. Así se ha presentado una propuesta para tolerancia a fallos en modo de redundancia activa y pasiva. Aunque CORBA 2.0 especifica muchos requisitos para garantizar la interoperabilidad entre proveedores de ORBs, hay ciertos casos en los cuales una implementación “liviana” de un ORB sería altamente recomendable, por ejemplo en implementaciones en chips o en sistemas embebidos. Para esto se ha definido una RFP para CORBA mínimo que determine los requerimientos



mínimos que sí deben ser cumplidos para una especificación de “CORBA Mínimo”.



Cuestionario ¿Qué problema la OMG está probando para resolver con CORBA? ¿Por qué la orientación a objetos ayuda a resolver el problema de heterogeneidad? ¿Qué patrones de invocación de objetos soporta CORBA? ¿Cuál es la diferencia entre estilos de invocación síncrono y asincrónicos? ¿Qué es IDL y su utilidad? ¿Qué son los stubs y cómo se usan? ¿Qué son los skeletons y cómo se usan? ¿Cuál es la diferencia entre la invocación estática y dinámico y cómo se soportan tanto en lado del cliente como del servidor? ¿Qué es un almacén de la interfaz? ¿Qué es un adaptador del objeto? ¿Cómo trabaja el registro del objeto y referencia del objeto? ¿Cuál es la diferencia entre el adaptador del objeto y el skeleton? ¿Qué realiza un Adaptador del Objeto Portátil (POA)? ¿Qué es la activación / desactivación? ¿Qué es un objeto persistente? ¿Qué es un objeto transeúnte? ¿Cuál es la diferencia entre la llamada por referencia y llamada por valor? ¿Cómo la interoperabilidad del inter-orb se soporta? ¿Cuál es la diferencia entre GIOP e IIOP? ¿Qué transparencias proporciona CORBA? Ejercicio Práctico



Escenario Los programas del CORBA consisten en uno o más clientes y uno o más servidores. El ejemplo más simple es un cliente y un servidor. Los servidores en CORBA son a menudo llamados servicios. Los servicios simples exportan varios métodos y atributos mediante la Static Skeleton Interface (SSI). Los clientes tienen acceso a estos métodos y atributos que usan la Static Invocation Interface (SII). Los clientes tienen acceso a los servicios poniéndose en contacto con un servicio bien conocido, llamado Lookup Service. Definición de Interfaces con IDL El Interface Definition Language (IDL) se usa para describir los métodos, atributos, excepciones y tipos usados en su sistema distribuido. El código siguiente muestra el archivo de IDL: module library { typedef struct _Book { string isbn; string title; string author; } Book; typedef sequence<Book> BookList; interface Library { readonly attribute string name; readonly attribute string address; Book createBook(in string isbn, in string title, in string author); BookList findBooksByTitle(in string title); } } Guarde el archivo previo como 'library.idl' y lo compila usando el comando siguiente: idlj .fall library.idl



Se generan los archivos siguientes: BookListHelper.java Ésta es la clase del Auxiliador para el tipo de BookList (secuencia) BookListHolder.java Ésta es la clase del Poseedor para el tipo de BookList (secuencia) Library.java Ésta es la interfaz para el servicio de la Biblioteca Esta clase extiende LibraryOperations LibraryHelper.java Ésta es la clase del Auxiliador para el tipo de la Biblioteca (interfaz) LibraryHolder.java Ésta es la clase del Poseedor para el tipo de la Biblioteca (interfaz) LibraryOperations.java Estas son las Operaciones de interfaz para la Biblioteca de interfaz Esta interfaz define las operaciones en la Biblioteca LibraryPOA.java Éste es el POA (o server stub o skeleton) para la interfaz de la Biblioteca _BookHelper.java Ésta es la clase del Auxiliador para el tipo del Libro (estructura) _BookHolder.java Ésta es la clase del Poseedor para el tipo del Libro (estructura) _LibraryStub.java Ésta es la clase de client stub para la interfaz de la Biblioteca Clases del poseedor (Holder) Se usan clases del poseedor cuando un método define los parámetros out o inout, dado que Java no los soporta nativamente. Ellos almacenan los valores de los parámetros cuando ellos son pasados a un método (in) y/o después los métodos regresan (out). Cualquier tipo que se usa como un parámetro (o valor devuelto) para una operación debe tener una clase del Poseedor para cuando los parámetros in e inout se usan.



Clases del auxiliador (Helper) Las clases del auxiliador se usan para el suceso de ascenso y descenso. Downcasting es similar a (MyObject)obj en Java, pero debido a las diferencias en cómo la herencia trabaja en CORBA, debe usar el método narrow() en esta clase. Upcasting es similar a (Object)myObj en Java, pero de nuevo debe usar el método insert() en esta clase. Implementación del servicio Para implementar la interfaz de la Biblioteca, debemos crear una subclase de la clase de POA abstracta (LibraryPOA) que define e implementa los métodos descritos en la interfaz de las operaciones (LibraryOperations). Un ejemplo se muestra: package library; import java.util.ArrayList; public class LibraryServiceImpl extends LibraryPOA { private ArrayList books = null; public LibraryServiceImpl() { books = new Arra yList(); _Book book1 = new _Book(); book1.title = "Java: How to Program"; book1.author = "Deitel"; book1.isbn = "123456"; books.add(book1); _Book book2 = new _Book(); book2.title = "XML for Beginners"; book2.author = "Colouris"; book2.isbn = "234567"; books.add(book2); _Book book3 = new _Book(); book3.title = "Distributed Systems"; book3.author = "Romero"; book3.isbn = "345678"; books.add(book3); } public String name() { return "The U of W Online Library"; } public String address() { return "401 Sunset Ave."; } public _Book createBook(String isbn, String title, String author) { _Book newBook = new _Book(); newBook.title = title; newBook.isbn = isbn; newBook.author = autho r; books.add(newBook); return newBook; }



public _Book[] findBooksByTitle (String title) { ArrayList matchingBooks = new ArrayList(); for (int i = 0; i < books.size(); i++) { _Book book = (_Book)books.get(i); if (title.equals(book.title)) { matchingBooks.add(book); } } _Book[] matches = new _Book[matchingBooks.size()]; for (int i = 0; i < matchingBooks.size(); i++) { matches[i] = (_Book)matchingBooks.get(i); } return matches; } } Aquí un ArrayList se usa para almacenar los libros. Ésta es una clase predeterminada simple en Java que representa una matriz dinámicamente-dimensionada. Registrador del servicio Ahora, debe registrar el servicio con el lookup service. Esto puede hacerse en la misma clase, pero aquí se implementa separadamente para la demostración. package library; import org.omg.CORBA.*; import org.omg.CosNaming.*; import org.omg.PortableServer.*; public class LibraryRegistrar { public static void main(String[] args) { try { // initialize the ORB ORB orb = ORB.init(args, null); // create an instance of the service implementation LibraryServiceImpl service = new LibraryServiceImpl(); // get a reference to the root POA org.omg.CORBA.Object rootPOARef = orb.resolve_initial_references("RootPOA"); POA rootPOA = POAHelper.narrow(rootPOARef); // activate the POA rootPOA.the_POAManager().activate(); // use the root POA to get an object



// reference for the service org.omg.CORBA.Object serviceRef = null; serviceRef = rootPOA.servant_to_reference(service); // get a reference to the Naming service org.omg.CORBA.Object namingRef = orb.resolve_initial_references("NameService"); NamingContextExt naming = NamingContextExtHelper.narrow(namingRef); // create a name for the library service NameComponent[] path = naming.to_name("Library"); // bind the name in the registry naming.rebind(path, serviceRef); // block and wait for requests orb.run(); } catch (Exception e) { System.err.println("Exception: "+e.getMessage()); e.printStackTrace(); } } } Cliente Los clientes de CORBA inicializan el ORB (meramente como los servidores) primero, entonces buscan (normalmente usando el servicio de nombres) los servicios para usar. Los servicios se usan entonces apropiadamente para el propósito del cliente. Un cliente de ejemplo se muestra: package libraryclient; import library.*; import org.omg.CORBA.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; public class LibraryClient { public static void main(String args[]) { try { // create and initialize the ORB ORB orb = ORB.init(args, null); // get an object reference to the // Naming service org.omg.CORBA.Object namingRef = orb.resolve_initial_references("NameService");



NamingContextExt naming = NamingContextExtHelper.narrow(namingRef); // use the Naming service to get an // object reference to the service String name = "Library"; org.omg.CORBA.Object libraryRef = naming.resolve_str(name); Library library = LibraryHelper.narrow(libraryRef); String libraryName = library.name(); System.out.println("Library Name: "+libraryName); String libraryAddress = library.address(); System.out.println("Address: "+libraryAddress); _Book matches1[] = library.findBooksByTitle("Java: How to Program"); System.out.println("Searching for \"Java: How to Program\":"); for (int i = 0; i < matches1.length; i++) { System.out.println(" \t" + matches1[i].title + "," + matches1[i].author + "," + matches1[i].isbn); } _Book newBook = library.createBook("4567890", "Java: How to Program", "Deitel Jr."); System.out.println("Created new book:"); System.out.println(" \t" + newBook.title + "," + newBook.author + "," + newBook.isbn); Book matches2[] = library.findBooksByTitle("Java: How to Program"); System.out.println("Searching for \"Java: How to Program\" (again):"); for (int i = 0; i < matches2.length; i++) { System.out.println(" \t" + matches2[i].title + "," + matches2[i].author + "," + matches2[i].isbn); } } catch (Exception e) { System.err.println("Exception: " + e.getMessage()) ; e.printStackTrace(); } } } Compilación Cree un directorio en su sistema para este ejemplo. Este directorio será llamado ~/corba_tutorial. Debe reemplazar este nombre de directorio con el directorio que ha creado. Cree los directorios para el cliente y repare, como sigue:



mkdir ~/CORBA/client mkdir ~/CORBA/service Copie el archivo de IDL en el directorio ~/CORBA/service y compile el archivo de IDL: cd ~/CORBA/service idlj –fall library.idl El compilador idlj creará un directorio llamado ' library', dado que éste es el nombre del módulo en el archivo de IDL que fue convertido en un paquete cuando el IDL se mapeo a sus Java bindings. Por consistencia, se han puesto también el servicio y archivos del registrador en este mismo paquete. Por consiguiente, copie el servicio y código del registrador en los archivos apropiadamente nombrados (LibraryServiceImpl.java y LibraryRegistrar.java, respectivamente) en el directorio ~/corba_tutorial/service/library. Compile todos los archivos en este directorio: javac library/*.java El servicio y registrador son ahora compilados y preparan para ejecutar. Puede haber notado que el cliente está en un paquete diferente, libraryclient. Cree un directorio para este archivo, representar este paquete, así como un directori o para los archivos de servicio requeridos por el cliente. mkdir ~/CORBA/client/libraryclient mkdir ~/CORBA/client/library Copie el código del cliente anteriormente en un archivo apropiadamente nombrado (LibraryClient.java) en este directorio. Ahora, necesitamos copiar encima de los archivos del servicio que es requerido por el cliente. (Si está usando windows, use el 'copy' el comando en lugar de 'el cp' y asegure usar '\' como el separador del archivo en lugar de '/' como se muestra aquí) cd ~/CORBA cp service/library/BookHelper.class client/library cp service/library/BookListHelper.class client/library cp service/library/Library.class client/library cp service/library/LibraryHelper.class client/library cp service/library/LibraryOperations.class client/library cp service/library/_Book.class client/library cp service/library/_BookHelper.class client/library cp service/library/_LibraryStub.class client/library



Dado que el cliente y los archivos del servidor están en directorios completamente diferentes, es más fácil decir si cualquier clase está relegada, ya que el cliente no compilará, o no ejecutará. Esto lo hace más fácil cuando queremos mover el cliente a otra máquina. Puede compilar el cliente ahora: cd ~/CORBA/client javac libraryclient/LibraryClient.java Ejecución El servicio y cliente están ahora listos para ejecutar. La primera cosa para hacer es empezar un servicio de nombres, para que el registrador pueda registrar el servicio cuando ejecuta. Esto debe hacerse antes que el registrador ejecute. orbd –ORBInitialPort 1050 –ORBInitialHost localhost El número 1050' representa el puerto de red dónde el servicio de nombres está ejecutando. Puede usar cualquier valor para esto cuando le gusta. El nombre 'localhost' se refiere al nombre de dominio dónde el servicio de nombres está ejecutando. Si ejecuta esto en una máquina remota, se asegura de notar su nombre de dominio para el uso al ejecutar el registrador y cliente. Podemos empezar el registrador que inicializará el servicio y lo registrará con el servicio de nombres ahora. El registrador debe ejecutar antes que el cliente sea ejecutado. cd ~/CORBA/service java library.LibraryRegistrar –ORBInitialPort 1050 –ORBInitialHost localhost Finalmente, ejecute el cliente. cd ~/CORBA/client java libraryclient.LibraryClient –ORBInitialPort 1050 –ORBInitialHost Localhost Está ahora listo para escribir un simple cliente/servicio CORBA. Mucho del código en el ejemplo anterior puede ser considerado una plantilla del CORBA estándar. Puede identificar la mayoría de este código dado que esta documentado. Un acercamiento recomendado es extraer el código de la plantilla para el cliente, registrador y servicio, para el uso cuando crea sus propios clientes y servicios. Esto lo salvará de la mecanografía e disminuye la preocupación por tantos errores de compilación.



3.4. RMI Escenario RMI ¿Qué es RMI?

• Invocación de Métodos Remotos (RMI) es una implementación orientada a objetos del modelo de RPC. Sólo es un API para los programas Java.

• Con RMI, un servidor del objeto exporta un objeto remoto, el cual tiene sus registros. El objeto proporciona métodos remotos que pueden invocarse en programas clientes.

• Un objeto remoto se declara con una interfaz remota, una extensión de la interfaz de Java.

• La interfaz remota es llevada a cabo por el servidor del objeto. • Un cliente del objeto tiene acceso al objeto invocando los métodos

remotos asociados con los objetos que usan la sintaxis proporcionada por las invocaciones de métodos remotas.

Arquitectura RMI

Skeleton Stub Capa de Referencia Remota

Cliente del Objeto

Servidor del Objeto

Capa de Transporte

Activa, mantiene y desactiva las conexiones, y

moviliza el protocolo de transporte

Mapea la plataforma independiente de la capa

Stub/Skeleton a la plataforma dependiente de la capa de transporte, moviliza los protocolos de

referencia remota

Soporta la interfase con el programa de aplicación

Registro de Objetos



Interacción entre Stub y Skeleton

Escenario RMI

skeleton

Marshal parámetros; Envía petición

Unmarshal parámetros Invoca método

Método Remoto

Ejecuta código y regresa valor

Recibe valor de retorno Marshal Contestación Envía contestación

Unmarshall Contesta ción Regresa valor

Tiempo

stub

• Con base en el proceso para aplicaciones RMI realizar el ejercicio RMI (anexo)

Definir su interfaz remota

Implemente la interfaz

javac

rmic

Client stub (.class) Server Skeleton (.class)

Server class (.class) Implemente

el cliente

javac

Inicie cliente

Iniciar el RMI Registry

Iniciar objetos del servidor

Registrar objetos remotos

1

2

3 4

5

6 7

8

9

10



Actividad 3.4 Actividad RMI Realizar el Ejercicio RMI anexo y coloque su reporte en Tarea Individual 3.4 Ejercicio RMI RMI es una tecnología de Middleware, RMI proviene de las siglas Remote Method Invocation (o Invocación de Métodos Remotos). Particularmente son tecnologías dependientes del lenguaje, y en ocasiones de algún tipo de arquitectura o framework que lo soporta. Obedece a las mismas reglas de todos los middleware de objetos. Tanto el objeto cliente como el servidor requieren elementos middleware stub y skeleton. JavaRMIEl concepto de JavaRMI se explicará a través del siguiente ejemplo guiado por código. EJERCICIO /*** Intefaz remota para el ejemplo Hola, Mundo ***/ public interface InterfazHola extends Remote { /*** Método remoto invocable ***/ public String saludar() throws RemoteException; } import java.rmi.server.*; /*** Clase Remota para el ejemplo “Hola, Mundo!” ***/ public class Hola extends UnicastRemoteObject implements InterfazHola { private String mensaje; /*** Constructor de la clase ***/ public Hola (String msj) throws RemoteException { mensaje = msj; }



/*** Implementación del método remoto a invocar */ public String saludar() throws RemoteException { return mensaje;

} } /*** Programa Cliente para el ejemplo: Hola, mundo. */ public static void main (String[] argv) { try {

System.setSecurityManager (new RMISecurityManager() { public void checkConnect (String host, int port) {} public void checkConnect (String host, int port, Object context){}

} InterfazHola hola = (InterfazHola) Naming.lookup ("//NombreHost/Hola"); System.out.println (hola.saludar()); } catch (Exception e) {

System.out.println ("Excepción de ClienteHola: " + e); }

} } /* Constructor */ public HelloServer() { } /** Programa Servidor del Ejemplo Hola,Mundo. */ public static void main (String[] argv) { try { System.setSecurityManager (new RMISecurityManager() { public void checkConnect (String host, int port) {} public void checkConnect (String host, int port, Object context){} } Naming.rebind ("//NombreHost/Hola", new Hola ("¡Hola, Mundo!")); System.out.println ("ServidorHola listo."); } catch (Exception e) {

System.out.println ("Excepción de ServidorHola: " + e); }

}



}grant codeBase "file:C:/dat/Java/Java_RMI/RMIEjemplo/-" { permission java.security.AllPermission; } Arranque del Servicio de Registro Arranque del servidor start java -Djava.security.manager -Djava.security.policy=java.policy ServidorHola Arranque del cliente start ClienteHola



Estándar

Puntos de Atributo

Obtenidos (10-9) (8.5-7) (6.5-0)

Aplicación de la Información

La información revisada permitió a

los estudiantes comprender con


La información revisada permitió a los estudiantes

comprender solamente los ejercicios y programas.


permitió a los estudiantes

comprender los ejercicios y programas.

(10-9) (8.5-7) (6.5-0)



material elaborando correctamente,

mientras extienden y explican la información,

incorporándola en el estudio del tema.


material incorporándolo

correctamente en el estudio del

tema.

Los estudiantes no han hecho

contacto con el material,

simplemente sin incorporar la

información en su estudio del

tema.




3.5. COM+ Escenario COM+ .Net y COM+

• COM+ se refiere a la versión de COM que combina las características basadas en servicios de Microsoft Transaction Server (MTS), con COM distribuido (DCOM). COM+ proporciona un conjunto de servicios orientados a la capa media. En particular, COM+ proporciona administración de procesos, servicios de sincronización, un modelo de transacción declara tivo y agrupación de conexiones a objetos y bases de datos.

• Los servicios COM+ están principalmente orientados hacia el desarrollo

de la aplicación de capa intermedia y se enfoca en proporcionar confiabilidad y escalabilidad para aplicaciones distribuidas a gran escala. Estos servicios son complementarios a los servicios de programación proporcionados por el Entorno .NET; y la BCL (Base Class Library) proporciona acceso directo a ellos.

Capacidades de COM+

• Integración completa de MTS en COM o Facilita el desarrollo de aplicaciones distribuidas mediante la

reducción del trabajo asociado con el desarrollo, la depuración, la distribución y el mantenimiento de una aplicación que anteriormente utilizaba COM para determinados servicios y MTS para otros.

• Componentes en cola o Los componentes en cola son una característica de los Servicios

de componentes que aprovecha las ventajas de MSMQ para permitir que los componentes de servidores participen de forma lógica en las transacciones mientras están fuera de línea o no disponibles.

• Eventos de COM+ o Permite a los programadores de aplicaciones escribir código de

aplicaciones (llamados publicadores) que pueden notificar código de aplicaciones del cliente (llamados suscriptores) cuando tiene lugar un evento concreto.

Ejemplo de aplicación de entrada de pedidos mediante el uso de eventos de COM+: El servidor de inventarios de productos puede publicar un aviso cuando los niveles de inventario descienden debajo de un determinado nivel.



Si un área se ve afectada por las condiciones de inventario, puede utilizar esa información en sus aplicaciones con la suscripción al servicio de notificación de eventos de software de inventario.

Se anexa material de apoyo para el tema de COM+, que se extiende por las capacidades que presenta COM+, por lo que deberá realizar las actividades siguientes:

• Resolver los cuestionarios del material de apoyo 3.5 • Realizar los ejercicios del material de apoyo 3.5

Actividad 3.5 Actividad COM+ Contestar los cuestionarios y realizar los ejercicios del Material de Apoyo 3.5. Coloque el informe de su actividad en Tarea Individual 3.5



3.5. COM+

3.5.1. Introducción a los Servicios COM+ 3.5.1.1. Historia de las aplicaciones basadas en servidor Introducción Cuando apareció el sistema operativo Microsoft Windows, se utilizó principalmente para ejecutar aplicaciones independientes en equipos personales. Con el paso del tiempo, se han ampliado las capacidades del sistema operativo Windows para admitir aplicaciones que ofrecen cada vez más posibilidades. El sistema operativo incluye un conjunto integrado de tecnologías, llamado servicios de aplicaciones, que permite a las organizaciones crear y personalizar rápidamente aplicaciones distribuidas mediante software basado en componentes. Para ayudar a los programadores de aplicaciones a escribir rápidamente software sofisticado que abarca operaciones tanto de clientes como de servidores, los servicios de aplicaciones han evolucionado considerablemente durante la década pasada. Los servicios de aplicaciones de Windows, también conocidos como COM+, constituyen la piedra angular de la arquitectura de Aplicaciones distribuidas de red de Windows (Windows DNA). Las aplicaciones distribuidas se crean con el fin de aprovechar la capacidad de procesamiento que ofrecen los servidores, como los que se utilizan para aplicaciones sectoriales y de bases de datos, y las capacidades de cliente de los equipos personales y otros dispositivos. Al separar entre equipos distintos los procesos utilizados en una aplicación, las organizaciones pueden crear software escalable y flexible por medio de hardware de consumo. Un buen ejemplo de aplicación distribuida sería el proceso de entrada de pedidos de comercio electrónico, que integra datos y procesos desde diversas ubicaciones, incluidos servidores y clientes. En el entorno de desarrollo actual, dicho proceso suele combinar elementos del software tradicional, como una base de datos, con las tecnologías basadas en Internet, como un explorador.



Componentes de software

Los componentes son los pilares de las aplicaciones distribuidas. Un componente es un módulo de software escrito para controlar un tipo concreto de información o un proceso en particular. Por ejemplo, se puede crear un registro de cliente con un componente que proporcione el nombre, la dirección y otro tipo de información distintiva. Cada componente se diseña de manera que pueda modificarse fácilmente para ajustarse a unos requisitos determinados. De esta manera, en vez de escribir el mismo tipo de código una y otra vez, los programadores pueden utilizar código de software prefabricado y sólo necesitan ajustar los elementos que son diferentes en cada aplicación. Los programadores crean aplicaciones mediante la integración de componentes, de la misma manera que puede construir una casa a partir de un conjunto de piezas prefabricadas, como puertas, ventanas y armarios. El software de componentes sirve para mucho más aparte de reducir la cantidad de código que los programadores tienen que escribir desde el principio. Puesto que las aplicaciones creadas con componentes pueden vincularse a través de redes, el software de componentes también supone una manera eficaz de crear aplicaciones distribuidas, que dividen el proceso entre los equipos cliente y servidor. Los servicios de aplicaciones basadas en componentes de Windows se basan en COM+, la última generación del Modelo de objetos componentes (COM) de Microsoft. Desde que apareció por primera vez a principios de los noventa, COM ha sido una importante tecnología de Windows en constante evolución. Windows presenta COM+, que constituye un elemento básico de la plataforma Windows. Para comprender COM+, resulta útil comprender la evolución de COM, así como los servicios de colas de transacciones y de mensajes. Está sección proporciona una introducción a estas tres tecnologías antes de explicar sus mejoras en COM+.



Aplicaciones distribuidas y COM COM permite a los programadores de aplicaciones dividir aplicaciones de software grandes y complejas en una serie de componentes creados previamente, que son fáciles de comprender, programar y cambiar. Los componentes pueden contener una lógica empresarial relevante para controlar cada elemento de una transacción, como especificar la longitud adecuada de un número de teléfono. Los programadores conectan entre sí los componentes para crear un proceso empresarial. Este método reduce el costo de programación de software y permite que las organizaciones puedan modificar fácilmente las aplicaciones a medida que cambian las condiciones empresariales. Para resolver las necesidades de los modelos de programación de aplicaciones cada vez más sofisticados gracias a los equipos personales conectados en red, COM ha evolucionado desde que se incluyó por primera vez con el sistema operativo Windows NT Server 3.51. En concreto, Windows NT Server 4.0 amplió COM en tres áreas principales. En primer lugar, COM distribuido (DCOM) amplió el modelo COM para abarcar varios equipos conectados en red. En segundo lugar, los Servicios de Microsoft Transaction Server (MTS) permitían a los programadores crear aplicaciones basadas en componentes con transacciones que abarcan componentes y bases de datos. En tercer lugar, los Servicios de Microsoft Message Queue Server (MSMQ) permitían a los programadores escribir aplicaciones con componentes que se ejecutan de forma asincrónica, con pausas entre el comienzo y el fina l de un proceso. Con Windows Server, estos servicios se han integrado y refinado aún más para permitir a los programadores escribir software basado en componentes complejos con menor cantidad de código personalizado. Los servicios de aplicaciones COM de Windows están diseñados para admitir una arquitectura de tres niveles (también llamada de n niveles o distribuida). La arquitectura de n niveles separa una aplicación en tres componentes distintos:

• Presentación. Es la parte de la aplicación con la que interactúa un usuario, como el formulario de pedidos utilizado en aplicaciones de comercio electrónico.

• Lógica de la aplicación. Este componente contiene todas las reglas y la lógica empresariales asociadas con la aplicación, como la aplicación de comprobación de crédito utilizada para admitir una aplicación de comercio electrónico.

• Datos. Se trata del mecanismo que almacena y administra los datos asociados con la aplicación, como la información de inventario de un producto para una aplicación de comercio electrónico. Habitualmente se trata de bases de datos relacionales, pero puede incluir también otros contenedores de almacenamiento, como un sistema de archivos.



Arquitectura de aplicaciones de tres niveles

La división de aplicaciones en las secciones de presentación, lógica de la aplicación y datos da lugar a un modelo de programación simplificado que es la manera estándar de crear aplicaciones que aprovechan las ventajas de las comunicaciones de Internet y de Intranet. Si las organizaciones agregan más hardware donde sea necesario, también podrán ampliar las aplicaciones de n niveles para controlar más usuarios y mayor información. El paso a un modelo de desarrollo de n niveles es el resultado de una gran evolución del modelo de desarrollo de aplicaciones para equipos personales durante la década anterior. A finales de los ochenta, las aplicaciones se escribían por lo general para que se ejecutaran por completo en un único equipo. A principios de los noventa, apareció el modelo cliente -servidor de dos niveles. Esto permitió a los programadores descargar a los equipos cliente de parte del trabajo con mayor procesamiento de da tos y trasladarlo a servidores de fondo con más capacidad. En este modelo de dos niveles, el software de presentación (la interfaz de usuario) permaneció en el equipo personal, mientras que la mayor parte del trabajo de procesamiento se trasladó al servidor. El modelo de tres niveles agrega un elemento adicional de separación entre los niveles de datos y de presentación, ya que permite controlar la lógica de procesamiento en un servidor independiente de las funciones de base de datos y de presentación.

El Modelo de objetos componentes Para hacer posible la creación de aplicaciones distribuidas, tiene que haber una manera de separar la aplicación en pilares más pequeños encargados de funciones específicas. Además, estos pilares deben ser capaces de ejecutarse en un único proceso, en varios procesos diferentes e incluso en máquinas diferentes, de ahí el nombre distribuido. COM cumple estos requisitos previos, además de proporcionar estos requisitos adicionales:



• Ubicación transparente. Se puede llamar a cada componente COM dentro de un proceso, a través de procesos en un único equipo o a través de varios equipos sin necesidad de volver a compilarlo.

• Independencia del lenguaje. COM es un estándar binario. Así, una implementación de COM escrita en un lenguaje es compatible con otras implementaciones de COM; es decir, es independiente del lenguaje. Esto significa, por ejemplo, que un programador de Java puede reutilizar otros componentes COM escritos en lenguajes como VBScript o C++. Esto permite a los programadores crear una aplicación a partir de componentes escritos en cualquier lenguaje que sea apropiado y conveniente.

• Interfaces intuitivas. Las interfaces intuitivas proporcionan herramientas y otras aplicaciones que permiten a los programadores descubrir las interfaces y los parámetros admitidos por el componente. De esta forma, los programadores pueden trabajar con el componente sin necesidad de comprender su funcionamiento interno.

Una vez que COM se popularizó, los programadores se dieron cuenta de que necesitaban que los componentes pudieran funcionar juntos a través de las redes. Por esa razón, con Windows NT Server 4.0 Microsoft presentó el Modelo de objetos componentes distribuido (DCOM), que amplía COM para que la tecnología de componentes pueda funcionar a través de redes y de Internet, como sucede en una arquitectura de n niveles. Desde su presentación, se ha utilizado con frecuencia el término COM para incluir también las tecnologías distribuidas DCOM. Servicios de transacciones A mediados de los noventa, Microsoft amplió la aplicabilidad de COM con la aparición de Microsoft Transaction Server (MTS). En Windows NT 4.0, MTS es una tecnología independiente que amplía el modelo de programación COM para el desarrollo, distribución y administración de aplicaciones distribuidas basadas en componentes. MTS simplifica el desarrollo de aplicaciones en el nivel medio de la arquitectura de n niveles, ya que proporciona gran parte de la infraestructura de software necesaria para ejecutar la lógica empresarial que se ejecuta allí. MTS incluye código de infraestructura para administración de conectividad, directorios, seguridad, procesos y subprocesos, así como las conexiones de bases de datos necesarias para crear una aplicación preparada para realizar transacciones. Una transacción es un conjunto de eventos que se confirman o se deshacen como una unidad: o suceden todos los eventos o ninguno de ellos. La creación de una transacción completa puede requerir la cooperación de varios componentes. En el ejemp lo de la figura, la aplicación de entrada de pedidos consta de componentes que, mediante DCOM, recuperan y procesan



información de varios servidores. MTS proporciona servicios integrados de programación que permiten a los programadores asegurarse de que toda la transacción tiene éxito o se anula por completo, sin necesidad de escribir grandes cantidades de código personalizado para controlar los mecanismos de la transacción.

Servicios de transacciones

La manera más fácil de comprender cómo funcionan juntos MTS y COM es observar un escenario típico, como el que se ilustra en la figura previa. Suponga que un cliente solicita productos a través de Internet. Todo el sistema de entrada de pedidos puede crearse mediante componentes COM que contengan la lógica empresarial necesaria para procesar pedidos. Los elementos individuales del pedido del cliente utilizarán con toda probabilidad varios procesos y bases de datos, alojados en diferentes servidores. Por ejemplo, el proceso utilizaría una base de datos con información de clientes para registrar el nombre y la dirección del cliente, una base de datos de inventario para asegurarse de que hay disponibilidad del producto para atender el pedido, una base de datos de envío para realizar el seguimiento del envío y un proceso de comprobación de crédito para asegurarse de que la tarjeta de crédito del cliente es válida. Cuando el cliente realiza el pedido, todos los procesos y las transacciones de bases de datos deben registrarse como un conjunto. MTS supervisa toda la transacción y sólo confirma todos los cambios si la transacción tiene éxito en su



totalidad. Si se interrumpe el proceso de pedido debido a un error de hardware o en las comunicaciones, MTS anulará todo el pedido o lo mantendrá para su procesamiento completo una vez restauradas las comunicaciones. Asimismo, si el cliente cancela el pedido, MTS permite anular todos los procesos y entradas de las bases de datos. Nota: Los Servicios de componentes no pueden anular los cambios realizados en el sistema de archivos o en otros recursos sin transacciones. Antes de MTS, los programadores tenían que escribir secuencias de comandos y componentes para hacer un seguimiento manual de los cambios solicitados y, en caso de que éstos fallaran, restaurar los datos. Con MTS, los programadores sólo tienen que designar que las secuencias de comandos o los componentes necesitan transacciones. Esto significa que los programadores pueden poner juntas aplicaciones que usan componentes sin tener que escribir el código especializado necesario para tratar dichos problemas. Entre las características básicas de MTS se incluyen:

• Transacciones automáticas. MTS admite transacciones automáticas, que permiten configurar los requisitos de transacción de un componente cuando se distribuye dicho componente. El resultado es un potencial mucho mayor para la reutilización de objetos empresariales creados como componentes MTS.

• Seguridad configurable. Al permitir a un administrador definir funciones y especificar las interfaces y los componentes a los que pueden tener acceso los clientes identificados para cada función, MTS simplifica en gran medida el trabajo necesario para crear aplicaciones de servidor seguras. Por ejemplo, un administrador puede designar que sólo aquellos clientes identificados como administradores puedan cambiar el historial de crédito. Nota: el modelo de seguridad de MTS se basa en la infraestructura de seguridad de Windows.

• Agrupación de conexiones de bases de datos. Los componentes pueden volver a utilizar conexiones existentes con una base de datos en lugar de crear otras nuevas, lo que mejora notablemente el rendimiento y la escalabilidad de las aplicaciones.

• Compatibilidad con diversas bases de datos y administradores de recursos. Las aplicaciones basadas en MTS pueden tener acceso a bases de datos de Microsoft SQL Server, Oracle y DB2, así como a otros administradores de recursos como Servicios de Microsoft Message Queue Server. También están disponibles los controladores de Conectividad abierta de bases de datos (ODBC) compatible con MTS y Base de datos de vinculación e incrustación de objetos (OLE DB) para muchas otras bases de datos de proveedores terceros.

• Compatibilidad con subprocesos automática. Los programadores de aplicaciones pueden escribir componentes de un único subproceso y, a continuación, permitir a MTS asignar subprocesos a dichos componentes según sea necesario.



• Administración de estado de componentes. Los componentes tienen que abandonar cualquier estado de la memoria cuando finaliza cada transacción. Esto facilita la creación de aplicaciones correctas a la vez que permite compartir los recursos de manera eficaz. MTS también proporciona el Administrador de propiedades compartidas (SPM) de manera que los componentes puedan almacenar y recuperar posteriormente su estado de la memoria.

• Aislamiento de procesos mediante paquetes. Las aplicaciones individuales pueden agruparse en uno o más paquetes y cada paquete puede ejecutarse en su propio proceso. Esto permite una mayor tolerancia a errores, ya que si falla un único componente, eso supone únicamente la inactividad del paquete en el que está ubicado ese componente.

• Integración con transacciones de grandes sistemas. A través del Integrador de transacciones COM, las transacciones MTS pueden iniciar y controlar transacciones CICS en grandes sistemas de IBM.

• Una gran variedad de herramientas de desarrollo. MTS permite a los programadores crear aplicaciones en cualquiera de los lenguajes más conocidos en la actualidad, incluido el sistema de programación Visual Basic, Java, C++ y Cobol.

Message Queue Server Como puede no ser necesario completar todos los pasos del proceso de una aplicación a la vez, muchas aplicaciones distribuidas necesitan poder controlar los retardos entre una solicitud y su respuesta. En estas situaciones se utilizan los Servicios de Message Queue Server (MSMQ). MSMQ es una tecnología independiente que complementa las capacidades inherentes a COM y MTS. MSMQ permite a las aplicaciones utilizar componentes que se comunican entre sí de forma asincrónica mediante mensajes en cola, que es un concepto similar al de un mensaje de correo electrónico que espera en una bandeja de entrada. El hecho de que los programadores puedan escribir aplicaciones que no requieren respuestas inmediatas de los equipos cliente o servidor les permite proporcionar la flexibilidad necesaria para controlar pausas rutinarias en los procesos empresariales. El uso de este servicio también ayuda a los programadores a escribir aplicaciones de mayor disponibilidad y más escalables.



Servicios de Message Queue Server

Cuando los programadores escriben componentes que aprovechan las ventajas de MSMQ, sus aplicaciones pueden enviar mensajes a otras aplicaciones sin necesidad de esperar una respuesta (de hecho, la aplicación de destino podría no estar ni siquiera en ejecución). Dichos mensajes se envían a una cola, donde se almacenan hasta que una aplicación receptora los quita. Si se espera una respuesta, el remitente puede comprobar una cola de respuesta cuando lo desee. La cola de mensajes es un método de comunicación flexible y confiable, apropiado para diversos tipos de aplicaciones. Los programadores no tienen que preocuparse por los detalles y la arquitectura del sistema se encarga de los procesos de cola, incluso aunque el cliente y el servidor no estén ejecutándose al mismo tiempo. Por ejemplo, un programador puede utilizar MSMQ para escribir una aplicación que permitirá a los clientes realizar pedidos a través de Internet, incluso si el servidor Web encargado de la recepción no está disponible. Las colas de mensajes también pueden utilizarse para realizar procesos de fondo más eficaces. Por ejemplo, cuando un cliente realiza un pedido, no es necesario procesar todos los componentes del pedido inmediatamente. En el ejemplo descrito anteriormente, el departamento de envío no tiene que recibir el pedido del cliente hasta que se haya completado el resto de la transacción. Con MSMQ, la aplicación de entrada de pedidos puede seguir ejecutándose incluso si la aplicación de envíos no está disponible.



Cuando se completa un pedido, un componente de entrada de pedidos envía un mensaje a un almacén para indicar que hay que empaquetar y enviar el pedido. Como no es necesario que el componente espere a que se envíe el pedido, esta solicitud se realiza mediante MSMQ. Cuando es preciso, una aplicación del almacén extrae los pedidos de una cola y se asegura de que se atienden debidamente. Los programadores pueden utilizar servicios de transacciones con MSMQ para asegurarse de que la transacción se completa correctamente. Entre las características de MSMQ que admiten las capacidades anteriormente descritas se incluyen:

• Acceso basado en COM. Es posible tener acceso a los servicios de MSMQ a través de una interfaz sencilla proporcionada por componentes COM. Esta configuración hace que sea elemental enviar y recibir mensajes desde una secuencia de comandos en una página Active Server de Servicios de Internet Information Server, una aplicación basada en MTS o cualquier software que pueda utilizar COM.

• Integración con MTS. Las operaciones de MSMQ se pueden incluir automáticamente en transacciones MTS para conservar la integridad de los datos.

• Introducción automática en el diario de mensajes. Si así se solicita, MSMQ conservará copias de los mensajes enviados o recibidos por las aplicaciones. Los diarios proporcionan pistas de auditoria y pueden realizar más fácilmente la recuperación de ciertas clases de error.

• Notificación automática. Si así se solicita, MSMQ puede notificar a una aplicación de envío que los mensajes se recibieron y procesaron (o no) correctamente. Este servicio permite a las aplicaciones de envío saber cuándo pueden tratar los mensajes como entregados o, si se producen errores, cuándo deben realizar acciones correctivas.

• Servicios integrados de integridad de datos, privacidad de datos y firma digital. MSMQ puede firmar digitalmente y encriptar mensajes para su transferencia a través de la red. Esta capacidad protege los mensajes para que no se puedan ver o modificar durante la transmisión, incluso si se envían a través de redes públicas como Internet, y garantiza que los servidores no reciban mensajes de remitentes sin autorización.

• Capacidad para establecer la prioridad de los mensajes. MSMQ permite asignar prioridades a los mensajes y las colas de mensajes, y después se basa en dichas prioridades para enrutarlos y entregarlos. Las prioridades permiten a las aplicaciones ocuparse primero de los mensajes más importantes.

• Integración de aplicaciones simplificada. Las colas de mensajes reducen en gran medida los requisitos de sincronización entre aplicaciones, ya que es fácil traducir el contenido de los mensajes y las interfaces basadas en mensajes ocultan las diferencias existentes entre las diferentes arquitecturas de aplicaciones y tecnologías de bases de datos.



• Independencia de protocolos de red. Todas las funciones y características de las colas de mensajes funcionan independientemente de los protocolos de red. Cualquier aplicación que conozca el nombre de la cola de solicitudes de otra aplicación puede enviar solicitudes y recibir respuestas, cualquiera que sea el tipo de red.

Al ofrecer comunicaciones asincrónicas flexibles y confiables entre aplicaciones basadas en componentes, MSMQ desempeña un papel vital en los servicios de componentes de Microsoft para Windows NT 4.0. Con Windows 2000, los servicios de MSMQ están aún más estrechamente integrados con el modelo de programación COM, como se describe en la próxima sección. COM+ En Windows NT 4.0, COM y MTS simplificaron la programación de aplicaciones distribuidas. En Windows 2000, COM y MTS se combinan para crear COM+, que simplifica aún más la creación y el uso de componentes de software . COM+ proporciona servicios que pueden utilizarse desde cualquier lenguaje o herramienta de programación y permite una amplia interoperabilidad entre componentes, independientemente de cómo se implementen. Para conseguirlo, define un conjunto estándar de tipos de componentes y hace que todos los componentes se describan a sí mismos por completo. Esto garantiza que todos los componentes y servicios de sistemas compatibles con COM+ estarán accesibles para todos los lenguajes y herramientas compatibles con COM+, además de simplificar la distribución de componentes y aplicaciones que los utilizan. Las características suministradas con COM+ permiten que las aplicaciones se ejecuten más rápido y se escalen mejor, a la vez que facilitan a los programadores la integración de código con sistemas de varios proveedores. Los componentes escritos con el modelo COM funcionarán con COM+. COM+ amplía también la compatibilidad de la plataforma Windows con la programación basada en atributos, que permite utilizar los componentes de una manera más flexible. COM+ presenta varias capacidades nuevas, incluidas las siguientes: Integración completa de MTS en COM. Como se mencionó anteriormente, COM+ unifica los modelos de programación inherentes en los servicios COM y MTS. También combina el código de infraestructura para trabajar con compone ntes y el modelo de seguridad suministrado previamente por MTS. Esto facilita el desarrollo de aplicaciones distribuidas mediante la reducción del trabajo asociado con el desarrollo, la depuración, la distribución y el mantenimiento de una aplicación que anteriormente utilizaba COM para determinados servicios y MTS para otros.



Componentes en cola. Los componentes en cola son una característica de los Servicios de componentes que aprovecha las ventajas de MSMQ para permitir que los componentes de servidores participen de forma lógica en las transacciones mientras están fuera de línea o no disponibles. Considere los componentes en cola como la versión prefabricada de MSMQ (que sigue estando disponible por separado). Si bien los programadores pueden utilizar MSMQ para escribir aplicaciones que utilizan las capacidades suministradas por los componentes en cola, tal desarrollo supone bastante carga de trabajo. La programación con componentes en cola es mucho más rápida y no requiere el aprendizaje de técnicas nuevas por parte del programador. Los componentes en cola se utilizan habitualmente para las comunicaciones entre dos servidores. Las solicitudes que afectan a un componente en cola se registran, se ponen en cola y se reproducen de forma transparente más adelante, cuando el componente solicitado está disponible. Dicho modelo resulta especialmente útil en redes no confiables o en situaciones en las que uno de los servidores no está siempre conectado a la red. Los componentes en cola pueden ejecutarse inmediatamente si los servidores están conectados; de lo contrario, el componente no puede retener la ejecución hasta que se realiza una conexión. Eventos de COM+. También conocido como servicio de eventos de publicación y suscripción o Notificación de eventos, los eventos de COM+ constituyen una herramienta de programación que permite a los programadores de aplicaciones escribir código de aplicaciones (llamados publicadores) que pueden notificar código de aplicaciones del cliente (llamados suscriptores) cuando tiene lugar un evento concreto. Por ejemplo, los eventos de COM+ pueden ser útiles a los programadores que utilizan componentes en cola para garantizar la entrega de las tareas en cola. Los eventos de COM+ usan un mecanismo de eventos de publicación y suscripción por multidifusión que permite a diversos clientes suscribirse a eventos publicados por varios servidores. El sistema de eventos de COM+ mantiene una base de datos de eventos con información acerca de varios eventos, publicadores, suscriptores y suscripciones individuales. Para ver su funcionamiento, observe de nuevo la aplicación de entrada de pedidos descrita anteriormente. Mediante el uso de eventos de COM+, el servidor de inventario de productos puede publicar un aviso cuando los niveles de inventario de los elementos más populares descienden por debajo de un determinado nivel. Los programadores que escriben aplicaciones para el departamento de compras, o cualquier otra área de la organización que se vea afectada por las condiciones del inventario, pueden utilizar esta información en sus aplicaciones mediante la suscripción al servicio de notificación de eventos de software de inventario.



COM+

3.5.1.2. La arquitectura de tiempo de ejecución de COM+ Introducción

COM ofrece una solución para desarrollar aplicaciones basadas en componentes. Es bien sabido de todos que el trabajo que es necesario realizar para escribir componentes COM es arduo y repetitivo. COM+ es más que una nueva versión de COM: ofrece una completa infraestructura de servicios para componentes. Los componentes se crean y se instalan en aplicaciones de COM+ para poder generar aplicaciones escalables de servidor que permitan un alto rendimiento con una sencilla implementación. (Si un componente no precisa utilizar algún servicio, no se debe colocar en una aplicación de COM+.) La escalabilidad y el buen rendimiento se logran diseñando aplicaciones desde el exte rior para hacer uso de servicios como las transacciones, las agrupaciones de objetos y la semántica de actividades.

.NET Framework ofrece otra forma de escribir aplicaciones basadas en componentes y presenta ventajas sobre el modelo de programación de COM, mejor compatibilidad de herramientas, el tiempo de ejecución en lenguaje común



(CLR) y una sintaxis de codificación mucho más sencilla. Se puede tener acceso a la infraestructura de servicios de COM+ desde código administrado y no administrado. Los servicios en código no administrado se conocen como servicios de COM+. En .NET se hace referencia a estos servicios como Enterprise Services o servicios empresariales. Derivar una clase de ServicedComponent indica que los servicios los solicitará un componente. (Si un componente no necesitara los servicios, no debería derivar de ServicedComponent.) La compatibilidad de herramientas se ha mejorado para permitir a los programadores escribir aplicaciones basadas en el servidor, aunque la escalabilidad y el rendimiento aún pertenecen al campo de las prácticas de programación. La idea básica que subyace en los servicios es diseño para el rendimiento y la escalabilidad desde el exterior y aprovechamiento de los Enterprise Services para una fácil implementación de dichos patrones de diseño donde sea necesario. Componentes con servicio Un componente con servicio es una clase escrita en un lenguaje compatible con CLS (Common Language Specification) y derivada directa o indirectamente de la clase: System.EnterpriseServices.ServicedComponent Las clases configuradas de esta manera pueden estar alojadas en una aplicación COM+ y puede utilizar los servicios COM+ por medio del espacio de nombres EnterpriseServices. En la tabla siguiente se muestra un resumen de servicios COM+ disponibles.

Los servicios COM+, como las transacciones automáticas o los componentes en cola se pueden configurar de forma declarativa. Los atributos relacionados con el servicio se aplican en tiempo de diseño y se crean las instancias de clases



que utilizan esos servicios. Algunos servicios se configuran llamando a métodos en clases o interfaces relacionadas con el servicio. Ciertos servicios pueden pasar de un objeto a otro. Por ejemplo, un objeto configurado de manera que requiera una transacción puede extender esa transacción a un segundo objeto que también admita o requiera transacciones. El catálogo COM+ guarda la información de configuración que se aplica a la implementación de una clase. En tiempo de ejecución, en función de los atributos que aplique al código, COM+ crea una capa de servicio del contexto. La siguiente ilustración muestra una transacción automática que pasa entre dos objetos administrados alojados en COM+.

Aplicación COM+ con componentes con servicio alojados

Los servicios pueden fluir también entre objetos de COM+ y .NET Framework. Cada entorno controla la implementación y ejecución de su código nativo; COM+ proporciona siempre el contexto del objeto. Características de los servicios COM+ Una clase configurada posee un conjunto de COM+ estos son atributos declarativos que especifican los servicios requeridos. En tiempo de ejecución, COM+ se asegura que provee los servicios requeridos a los objetos. Estos servicios se proveen mediante “contextos” los cuales se implementan como objetos llamados “contexto del objeto”. Todas las clases son instanciadas en un contexto y cada objeto vive precisamente en uno. Las clases que no están configuradas ignoran sus contextos asociados. Se tienen dos tipos de aplicaciones COM+: • Aplicación de biblioteca, que es una colección de clases de componentes,

que cuando son instanciadas, son creadas dentro del proceso del cliente que llama.

• Aplicación de servidor, que es una colección de clases de componentes, que

cuando son instanciadas son creadas en un proceso subrogado separado del proceso del cliente que llama.



Una transacción es un conjunto de operaciones que son exitosas o fallidas como unidad. Si ésta falla se le hace “Rollback” y la data permanece en su estado original. De ser exitosa se hace un “Commit” y los cambios son tomados en cuenta. Así de esta manera se preserva la integridad de la información. Las transacciones en COM+ están a cargo del Coordinador de Transacciones Distribuidas (Distributed Transaction Coordinator, DTC) el cual es un componente del sistema operativo Windows. La activación justo-a-tiempo (JIT) es el mecanismo usado por COM+ para evitar el consumo de recursos por parte de los componentes mientras éstos están en estado “ocioso”, es decir, el desarrollador puede instanciar sus objetos COM+ al principio de su programa y dejarse de preocupar acerca del consumo de estos ya que solo son activados cuando alguno de los métodos es llamado. La seguridad es otro punto importante de las aplicaciones COM+. El primer aspecto es concerniente a la autenticación, lo cual permite establecer restricciones a quién tiene acceso a la aplicación y su funcionalidad. El otro aspecto es el modelo de impersonación, en el cual es objeto asume la información del cliente en el cual ha sido llamado. Los eventos, mejor conocidos como modelo “publicador-suscriptor”. En este enfoque se desarrolla una interfaz de eventos el cual se registra en COM+, luego se procede a registrar las clases que se desean estén en disposición de manipular los eventos definidos en la interfaz de eventos como suscriptores. Esta arquitectura es usualmente llamada como eventos débilmente acoplados “loosely-coupled”. Pool de objetos, es la característica que permite tener un conjunto de objetos disponibles para cualquier petición realizada del cliente sin incidir en costos de creación e instanciación. Una vez “liberado” el objeto por parte del cliente este vuelve al pool. Cola de mensajes, permite trabajar en situaciones desconectadas. Este servicio se encarga de registrar las llamadas a métodos de un cliente al servidor que es disponible de manera que pueden “volverse” a hacer la llamada cuando el servidor esté en línea nuevamente. El código del cliente permanece sin tener conocimiento de que el servidor fue desconectado y los servicios de COM+ están actuando como intermediarios. Carga balanceada del componente (CLB) es un equipo con Windows Advanced Server o Windows Data Server que sirve como administrador de otros servidores en la granja. El CLB se encarga de distribuir las solicitudes de los objetos entre los servidores disponibles.



Ejercicio Práctico: Componentes servidos con ensamblados Para hacer uso de los componentes servidos es necesario utilizar el espacio de nombres System.EnterpriseServices. Un componente servido de .NET es una clase diseñada para hacer uso de dicho espacio de nombre y un ensamblado servido es aquel que contiene al menos un componente servido. Para crear una clase como un componente servido esta debe derivar de la clase ServicedComponent y también debe definir un constructor público por defecto. public class PruebaDeComPlus: ServicedComponent { public PruebaDeComPlus() { } } Hágase saber que para usar el espacio de nombres System.EnterpriseServices es necesario agregar la referencia manualmente a System.EnterpriseServices.dll ya sea por agregar referencias en el Visual Studio o agregando /r:System.EnterpriseServices.dll si se compila desde la línea de comandos. Los atributos definidos en System.EnterpriseServices son:

• Transaction • ObjectPooling • JustInTimeActivation • EventClass • ApplicationActivation

Para demostrar los componentes servidos, crearemos una clase que encapsula la funcionalidad de la aplicación COM+ y crearemos un formulario para proveer una interfaz gráfica desde el cual se harán las llamadas. A diferencia de otro ensamblado de .NET estos requieren un tratamiento especial. A continuación se muestra el conjunto de atributos del archivo AssemblyInfo.cs que han de ser agregados para que nuestra aplicación pueda funcionar correctamente (AssemblyInfo.cs del proyecto clsPruebaDeComPlus) [assembly: ApplicationActivation(ActivationOption.Server)] [assembly: ApplicationAccessControl(false)] [assembly: ApplicationID("448934a3-324f-34d3-2343-129ab3c43b2c")] [assembly: ApplicationName("DemoComponenteServido")] [assembly: Description ("Demostración de COM+ en .NET")] El primer atributo especifica el tipo de aplicación que es (en este caso esta será de tipo biblioteca) esta información corresponde a la enumeración de ActivationOption. El segundo atributo es la manera como se accede al control de



la aplicación. El tercer atributo es el GUID de la aplicación. El cuarto es el nombre de la aplicación que será anfitrión de nuestro componente cuando este sea importado a servicios de COM+. El quinto es la descripción del componente. Hay dos maneras de implementar un ensamblado servido. La manera más simple es copiar el ensamblado en el directorio de la aplicación COM+ esta manera es conocida como “Registro dinámico” sin embargo hay un detalle, solo los administradores podrán hacer uso del mismo ya que el ensamblado no es colocado en el GAC (Global Assembly Cache). La otra manera es colocarlo en el GAC y se conoce como “Registro manual”, se requiere que el ensamblado posea un nombre fuerte (Strong name) y luego usemos el gacutil para introducirlo en el GAC. Gacutil -I ensamblado.dll El próximo paso es registrar explícitamente el ensamblado antes de utilizarlo, esto se hace mediante RegSvcs.exe. Cuando se ejecuta dicho utilitario contra un ensamblado de .NET este creará una aplicación COM+ con el nombre especificado en el atributo ApplicationName antes mencionado. RegSvcs Componente [COM+App] [TypeLibrary.tlb] Una vez hecho esto procedemos a probar nuestro aplicación COM+. Como se muestra a continuación el registro de la aplicación fue exitoso.

Al dirigirnos a la consola de servicios de componentes podemos apreciar que nuestra aplicación está ahí.



Al ejecutar la aplicación se registra en el visor de sucesos las acciones que se están llevando a cabo así también ha de suceder si se genera algún error. A continuación mostramos el visor de sucesos y los eventos generados desde nuestra aplicación.

Igualmente podemos apreciar los resultados de la consulta procesada por el componente.



En la consola de servicios de componentes se muestra la aplicación ejecutándose junto con la aplicación del sistema.

Una manera de comprobar como se esta comportando la aplicación es mediante las estadísticas de las transacciones. En la carpeta de Coordinador de transacciones distribuidas y el nodo de estadísticas de transacciones como se muestra a continuación.



Cada vez que se pulse el botón ejecutar query de nuestro formulario (cliente) se podrá apreciar como se activan las barras de transacciones activas y se incrementa la barra de transacciones ejecutadas. Aunque en este artículo solo recuperamos información la misma técnica aplica para operaciones que tengan que ver con manipulación (modificación) de la data. Cuestionario

1. Liste cinco beneficios de soluciones componente-basado.

2. ¿Qué es una aplicación COM+?

3. ¿Para qué se utiliza el catálogo COM+?

4. ¿Qué es el contexto?

5. ¿Qué es ServicedComponent?

3.5.2. Servicios de Transacción 3.5.2.1. Introducción al proceso de la transacción

¿Qué es una transacción? Una transacción es un conjunto de tareas relacionadas que se realizan de forma satisfactoria o incorrecta como una unidad. En términos de procesamiento, las transacciones se confirman o se anulan. Para que una transacción se confirme,



todos los participantes deben garantizar la permanencia de los cambios efectuados en los datos. Los cambios deben conservarse aunque el sistema se bloquee o tengan lugar otros eventos imprevistos. Basta con que un solo participante no pueda garantizar este punto para que la transacción falle en su totalidad. Todos los cambios efectuados en datos dentro del ámbito de la transacción se deshacen hasta un punto específico establecido. Propiedades ACID El término ACID expresa la función que las transacciones desarrollan en aplicaciones críticas para una misión. Acuñado por los pioneros en el procesamiento de transacciones, el acrónimo ACID responde a los términos atomicidad (atomicity), coherencia (consistency), aislamiento (isolation) y permanencia (durability). Estas propiedades garantizan un comportamiento predecible, reforzando la función de las transacciones como proposiciones de todo o nada diseñadas para reducir la carga de administración cuando hay muchas variables. Atomicidad Una transacción es una unidad de trabajo en la que se produce una serie de operaciones entre las instrucciones BEGIN TRANSACTION y END TRANSACTION de una aplicación. Una transacción se ejecuta exactamente una vez y tiene carácter "atómico" (de subdivisión), es decir, el trabajo se realiza en su totalidad o no se realiza en ningún caso. Las operaciones asociadas a una transacción comparten normalmente un objetivo común y son interdependientes. Si el sistema ejecutase únicamente una parte de las operaciones, podría poner en peligro el objetivo final de la transacción. La atomicidad elimina la posibilidad de procesar un subconjunto de operaciones. Coherencia Una transacción es una unidad de integridad porque mantiene la coherencia de los datos, transformando un estado coherente de datos en otro estado de datos igualmente coherente. La coherencia requiere que los datos enlazados mediante una transacción se mantengan en términos de semántica. Una parte de la responsabilidad para mantener la coherencia recae en el programador de la aplicación que debe asegurarse de que ésta exija todas las restricciones de integridad conocidas. Por ejemplo, en el desarrollo de una aplicación en la que se transfiere dinero, se



debe evitar el desplazamiento arbitrario de los puntos decimales durante la transferencia. Aislamiento Una transacción es una unidad de aislamiento, permitiendo que transacciones concurrentes se comporten como si cada una fuera la única transacción que se ejecuta en el sistema. El aislamiento requiere que parezca que cada transacción sea la única que manipula el almacén de datos, aunque se puedan estar ejecutando otras transacciones al mismo tiempo. Una transacción nunca debe ver las fases intermedias de otra transacción. Las transacciones alcanzan el nivel máximo de aislamiento cuando se pueden serializar. En este nivel, los resultados obtenidos de un conjunto de transacciones concurrentes son idénticos a los obtenidos mediante la ejecución en serie de las transacciones. Como un alto grado de aislamiento puede limitar el número de transacciones concurrentes, algunas aplicaciones reducen el nivel de aislamiento en el intercambio para mejorar el rendimiento. Permanencia Una transacción también es una unidad de recuperación. Si una transacción se realiza satisfactoriamente, el sistema garantiza que sus actualizaciones se mantienen aunque el equipo falle inmediatamente después de la confirmación. El registro especializado permite que el procedimiento de reinicio del sistema complete las operaciones no finalizadas, garantizando la permanencia de la transacción. Transacciones distribuidas Los sistemas de procesamiento de transacciones (TP) distribuidas se diseñan para facilitar las transacciones que abarcan recursos heterogéneos relacionados con transacciones en un entorno distribuido. Un sistema TP de transacciones distribuidas permite a la aplicación combinar en una unidad transaccional actividades tan diferentes como la recuperación de un mensaje de una cola de Message Queuing, el almacenamiento del mensaje en una base de datos de Microsoft SQL Server y la eliminación de todas las referencias existentes al mensaje en una base de datos de Oracle Server. Como abarcan varios recursos de datos, es importante que las transacciones distribuidas exijan las propiedades ACID para mantener la coherencia de los datos en todos los recursos. Un sistema TP de transacciones distribuidas está formado por varias entidades cooperadoras, como se describe en las secciones que figuran a continuación.



Estas entidades son lógicas y pueden residir en el mismo equipo o en equipos diferentes. Supervisores del procesamiento de transacciones (TP) Un supervisor TP consiste en software que se sitúa entre una aplicación relacionada con transacciones y una colección de recursos. Maximiza las actividades del sistema operativo, simplifica las comunicaciones de red y conecta varios clientes con varias aplicaciones que tienen acceso potencial a varios recursos de datos. En lugar de crear una aplicación que administre un entorno distribuido multiusuario, se crea una aplicación formada por solicitudes de transacciones únicas. El supervisor cambia el tamaño de la aplicación según proceda. El supervisor TP para Microsoft Windows 2000 es DTC (Coordinador de transacciones distribuidas). Administradores de transacciones En una transacción distribuida, cada recurso participante tiene un administrador de transacciones (TM) local para efectuar el seguimiento de las transacciones entrantes y salientes en el equipo. El supervisor TP asigna a un TM la tarea adicional de coordinar todas las actividades entre TM locales. El TM que coordina las actividades de transacción recibe el nombre de TM principal o coordinador. Un TM coordina y administra todas las funciones del procesamiento de transacciones, pero no está preparado para administrar datos directamente. Los administradores de recursos controlan las actividades relacionadas con datos. Administradores de recursos Un administrador de recursos es un servicio de sistema que administra datos persistentes o permanentes en bases de datos, colas de mensajes permanentes o sistemas de archivos transaccionales. El administrador de recursos almacena datos y realiza su recuperación ante un error del sistema. SQL Server y Message Queuing proporcionan administradores de recursos que participan en transacciones distribuidas. Oracle, Sybase, Informix, IBM (para IBM DB2) e Ingres también proporcionan administradores de recursos compatibles para los correspondientes productos de base de datos. Dispensadores de recursos Un dispensador de recursos administra los estados no permanentes que pueden aparecer en las transacciones. Por ejemplo, el dispensador de recursos de Open Database Connectivity (ODBC) administra grupos de conexiones de bases de datos, reclamando cada conexión cuando deja de ser necesaria.



3.5.2.2. Servicios de transacciones de .NET Una de las ventajas de utilizar COM+ para albergar componentes es la posibilidad de cambiar el comportamiento de dichos componentes sin tener que escribir nuevo código, por ejemplo para marcar la compatibilidad de transacciones de un componente como Requerida. Al definir un botón de opción en un componente COM+ dentro del complemento de servicios de componentes MMC cada vez que se crea el componente, el proceso tiene lugar en el contexto de una transacción COM+. Cuando un compone nte utiliza transacciones COM+, todas las transacciones de bases de datos están controladas por el Coordinador de transacciones distribuidas (DTC). La figura muestra un ejemplo de selección de la opción de transacción necesaria dentro de la interfaz de Servicios de componente.

Componente COM+ de ejemplo que requiere una transacción

Definir la seguridad para el componente resulta tan fácil como definir la compatibilidad de transacciones. Se puede decidir qué usuarios podrán ejecutar cada componente, e incluso cada método, sin necesidad de volver a compilar el código. Estas opciones se seleccionan mediante el complemento de servicios COM+.



Ejercicio Práctico: Creación de un componente de transacciones COM+ Hay una serie de pasos que se deben seguir para obtener un componente .NET que funcione con servicios COM+. Para empezar, debemos crear una clase que se derive de la clase System.EnterpriseServices.ServicedComponent. Esta clase de base proporciona todos las propiedades y los métodos necesarios para interactuar con los servicios COM+. Deberemos marcar la clase para que requiera una nueva transacción y los métodos creados para que puedan completar la transacción automáticamente si no se producen errores. Vamos a ponerlo en práctica: Abra Microsoft Visual Studio .NET y cree un nuevo proyecto ClassLibrary. Cambie el nombre del archivo Clase1.vb a COMPlusServices.vb. Abra el archivo COMPlusServices.vb y cambie el nombre de clase de Clase1 a COMPlusServices. Escriba el siguiente código en esta nueva clase: Imports System.EnterpriseServices Imports System.Reflection '******************************************** 'Detalles de registro de COM+ 'Nombre de la aplicación COM+ <Assembly: ApplicationNameAttribute("ComPlusExample")> 'Ensamblado de nombre seguro <Assembly: _ AssemblyKeyFileAttribute("bin/ComPlusExample.snk")> '******************************************** <TransactionAttribute(TransactionOption.Required)> _ Public Class COMPlusServices Inherits ServicedComponent Public Sub New() MyBase.New() End Sub <AutoComplete()> Public Function DoTransaction() _ As String Return "COM+ funciona correctamente" End Function End Class



Este código empieza importando un par de espacios de nombre para tener que escribir menos al declarar componentes.

5. A continuación tienen lugar los detalles de registro de COM+. Introduzca la siguiente línea de código:

'Proporcionar el nombre de aplicación COM+ <Assembly: ApplicationNameAttribute("ComPlusExample")> Esta línea asigna un valor de ComPlusExample a ApplicationNameAttribute. Este es el nombre de la aplicación COM+ una vez que se haya registrado en el catálogo COM+. Después de la primera vez que se llama a este componente, al abrir la carpeta de aplicaciones COM+ en el complemento MMC, lo verá como nombre de aplicación. La siguiente parte del código declara el atributo AssemblyKeyFileAttribute: <Assembly: _ AssemblyKeyFileAttribute("bin/ComPlusExample.snk")> Este código indica al catálogo COM+ la ubicación del nombre seguro. El archivo .SNK, que crearemos más tarde, es el que describe el componente para COM+. A continuación, crearemos por fin el nombre de clase, COMPlusServices, utilizando el código siguiente. <TransactionAttribute(TransactionOption.Required)> _ Public Public Class COMPlusServices El atributo junto a este nombre de clase indica a COM+ que desea definir el atributo de transacción como Necesario. Agregar esta línea de código es lo mismo que abrir el complemento de aplicaciones COM+ y definir este atributo de forma manual, como se muestra en la figura de la sección anterior. La siguiente línea de código en la clase hereda de ServicedComponent dentro del espacio de nombres System.EnterpriseServices. Inherits ServicedComponent Si no incluye esta línea, no podrá hacer que funcione este componente bajo COM+. Adición de un método de transacción Una vez que la configuración de esta clase se haya completado, puede crear un método que efectúe alguna acción. La función DoTransaction en el código



escrito devuelve un valor de cadena, pero mostrará la sintaxis que debe utilizarse para que este método participe en la transacción. <AutoComplete()> Public Function DoTransaction() As String Return "COM+ funciona correctamente" End Function Es importante anteponer este método con el atributo <AutoComplete()>. Esto significa que mientras no haya una excepción en este método, se llamará automáticamente a SetComplete cuando el método termine. Si se produjera una excepción en el método, el tiempo de ejecución de .NET llamaría al método SetAbort de forma automática. Creación de un nombre seguro Antes de compilar el componente, es necesario asignar un nombre seguro al ensamblado de dicho componente. De lo contrario, el catálogo COM+ no reconocerá al componente y no podrá registrarlo. En realidad, ya hemos hecho esto con el atributo AssemblyKeyFile que utilizamos anteriormente, pero ahora necesitamos crear el nombre seguro y asignarle un GUID con el ensamblado utilizando la Herramienta de nombre seguro (Sn.exe).

1. Abra una línea de comandos.

2. Para crear el nombre seguro, introduzca lo siguiente en la línea de comando y, a continuación, presione Intro.

sn -k ComPlusExample.snk

3. Copie el archivo ComPlusExample.snk del directorio raíz del disco duro (seguramente C:/) en el directorio bin dentro de la carpeta donde se encuentre el proyecto.

Ahora necesitará compilar este programa para generar los archivos necesarios y registrar este componente con COM+. En Visual Studio .NET, en el menú Generar, haga clic en Generar.

Generación de una aplicación cliente de ejemplo Una vez generado el componente, necesitará generar una aplicación cliente para llamar a este componente y comprobar su funcionamiento. Cree una aplicación de consola simple en la que el método Main del archivo de módulo cree una instancia del nuevo componente y llame al método DoTransaction(). Los principales pasos son los siguientes:

1. En Visual Basic .NET, cree un nuevo proyecto de aplicación de consola.



2. Agregue una referencia al componente que ha creado.

3. Escriba el siguiente código:

Module modMain Sub Main() Dim objCOMPlus As New _ COMPlusJumpStart.COMPlusServices() Console.WriteLine(objCOMPlus.DoTransaction) Console.ReadLine() End Sub End Module Prueba Por último estamos ya preparados para ejecutar esta aplicación y comprobar su funcionamiento.

1. Abra el complemento de servicios de componentes MMC y compruebe que su componente se registró dinámicamente en el catálogo COM+. Debería ver algo similar a la figura siguiente.

2. Compile y ejecute la aplicación de consola.

El nuevo componente atendido por .NET en el catálogo COM+



Cuestionario

1. Nombre las cuatro propiedades ACID de transacciones.

2. ¿Cuál es el servicio de transacciones distribuidas coordinadas para las aplicaciones COM+?

3. Liste las configuraciones de atributo de transacción que un componente COM+ puede tener.

4. ¿Qué pasa a un componente si una llamada a uno de sus métodos regresa y su bit dispuesto se ha establecido en True?

5. ¿Cómo puede crear un cliente que no hereda desde la clase ServicedComponent para los servicios de transacciones de .NET?

6. Nombre los cuatro niveles de aislamiento de transacción soportados para los componentes servidos.

3.5.3. Seguridad en Aplicaciones 3.5.3.1. Introducción a la seguridad de la aplicación Seguridad de acceso al código (CAS)

La seguridad de .NET Framework ofrece la posibilidad de que el código tenga acceso a los recursos únicamente si se le concede permiso para ello. .NET Framework emplea el concepto de permisos para expresar esta característica, que representa el derecho del código para utilizar recursos protegidos. El código, por su parte, solicita los permisos que le son necesarios. Y .NET Framework le concede las clases de permisos de acceso. Alternativamente, se pueden escribir las clases de permisos personalizadas. Los permisos se pueden emplear para indicar a .NET Framework exactamente para qué recursos y tareas necesita el código autorización. Cualquier ruta de código a través de System.EnterpriseServices solicita permisos de código no administrado.

La seguridad de acceso al código en .NET es muy útil en el caso de las aplicaciones en las que el código se descarga desde Internet y su autor no resulta de mucha confianza. Típicamente, las aplicaciones que utilizan componentes facilitados como servicio son de completa confianza, requieren que se dé el flujo de la seguridad entre múltiples procesos y permiten la configuración de las funciones durante la fase de implementación. Estas son las características expuestas por la seguridad basada en funciones de COM+.



Cualquier ruta de código a través de System.EnterpriseServices solicita permisos de código no administrado. Esto implica lo siguiente:

• Es necesario contar con permisos de código no administrado para poder

activar y realizar llamadas de contexto cruzado en los componentes facilitados como servicio.

• Si se pasa una referencia a un componente facilitado a un código que no resulta de confianza, no se puede llamar a los métodos definidos en ServicedComponent desde él. Sin embargo, sí que se puede llamar a los

métodos personalizados definidos en una clase derivada de ServicedComponent en ciertas circunstancias: las llamadas desde código que no es de confianza se pueden realizar en aquellos métodos personalizados que no requieren el cambio de contexto, servicios de

intercepción y si su implementación no realiza llamadas a los miembros de System.EnterpriseServices.

Asimismo, en la versión 1 de .NET, la pila de seguridad no se copia cuando tiene lugar un cambio de subproceso, por lo que los permisos de seguridad personalizados no se deben emplear con los componentes facilitados como servicio.

Seguridad basada en funciones (RBS) System.EnterpriseServices ofrece unos servicios de seguridad a los objetos de .NET que reflejan la funcionalidad de los mecanismos de seguridad de COM+. Cuando una aplicación de servidor de COM+ se emplea para alojar los componentes, las características de RBS requieren que el protocolo de transporte de DCOM se utilice para activar los componentes desde un cliente remoto. En la siguiente sección se proporciona más información sobre el acceso remoto. La identidad y el contexto de llamadas de seguridad de COM+ se encuentran por tanto disponibles en el código administrado. Además, CoImpersonateClient, CoInitializeSecurity y CoRevertClient son llamadas conocidas que se emplean por norma general en el lado del servidor, mientras que CoSetProxyBlanket sólo se utiliza con el cliente. Ciertas opciones de seguridad no se almacenan en los metadatos utilizando atributos, por ejemplo, agregando usuarios a funciones y estableciendo la identidad de la seguridad del proceso. Sin embargo, los atributos de nivel de ensamblado se pueden emplear para configurar lo que aparece en la ficha de seguridad del explorador de COM+ para una aplicación de servidor de COM+: Habilitar la autorización en la aplicación (ApplicationAccessControlAttribute(bool)). Se debe establecer como true para que ofrezca compatibilidad con RBS.



El nivel de seguridad (ApplicationAccessControlAttribute(AccessChecksLevelOption)). Si se establece en AccessChecksLevelOption.Application, los usuarios asignados a las funciones en la aplicación se agregan al descriptor de seguridad del proceso, y la comprobación detallada de las funciones en los niveles de componente, método e interfaz se desactiva. Las comprobaciones de la seguridad se llevan a cabo, por tanto, sólo a nivel de la aplicación y las aplicaciones de biblioteca confían exclusivamente en el proceso de host para la seguridad a nivel de proceso. Si el atributo se define en AccessChecksLevelOption.ApplicationComponent, entonces los usuarios asignados a las funciones en la aplicación se agregan al descriptor de la seguridad del proceso y las comprobaciones de la seguridad basada en funciones se realizan en la aplicación. Asimismo, estas comprobaciones se deben habilitar para cada componente que requiera RBS mediante la aplicación del atributo ComponentAccessControl en la clase. En una aplicación de biblioteca, las comprobaciones de la seguridad basada en funciones se realizan como si se tratara de una aplicación de servidor. La propiedad de seguridad se incluye en el contexto para todos los objetos de la aplicación y el contexto de la llamada de seguridad se encuentra disponible. Si un objeto cuenta con una configuración con el contexto de su creador, se activa en su propio contexto. La seguridad basada en funciones programática se basa en la disponibilidad del contexto de llamada de seguridad. Para que una comprobación de acceso significativa funcione en las aplicaciones de biblioteca de COM+, seleccione realizarlas a nivel de componente y proceso. Las selecciones de representación y autenticación corresponden a las propiedades ImpersonationLevel y Authentication del atributo ApplicationAccessControl. El atributo SecurityRole se puede aplicar al nivel de ensamblado, clase o método. Cuando se aplica a nivel de ensamblado, los usuarios de esa función pueden activar cualquier componente de la aplicación. Cuando se aplica a nivel de clase, los usuarios de esa función pueden, además, llamar a cualquier método del componente. Las funciones de nivel de clase y aplicación se pueden configurar en metadatos, o administrativamente, mediante el acceso al catálogo COM+. Configuración de RBS a nivel de ensamblado mediante metadatos: [assembly: ApplicationAccessControl(true, AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)] // agrega NTAuthority\everyone a esta función [assembly:SecurityRole("TestRole1",true)] // agrega usuarios a las funciones administrativamente [assembly:SecurityRole("TestRole2")] Configuración de RBS a nivel de clase en metadatos:



[assembly: ApplicationAccessControl(true, AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)] … [ComponentAccessControl()] [SecurityRole("TestRole2")] public class Foo : ServicedComponent { public void Method1() {} } RBS en los niveles de clase o ensamblado se puede configurar administrativamente puesto que dichas entidades existen en el catálogo COM+ después del registro del ensamblado. No obstante, como se mencionó anteriormente, los métodos de clase no aparecen en el catálogo COM+. Para configurar RBS en los métodos, la clase debe implementar los de una interfaz y emplear el atributo SecureMethod en el nivel de clase, o bien SecureMethod o SecurityRole en el nivel de método. Además, los atributos deben aparecer en la implementación de métodos de clase, no el método de interfaz en la definición de la misma. La forma más sencilla de utilizar RBS en los métodos es aplicar el atributo SecureMethod en el nivel de clase y, a continuación, configurar las funciones (ya sea administrativamente o colocando el atributo SecurityRole en los métodos). [assembly: ApplicationAccessControl(true, AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)] Interface IFoo { void Method1(); void Method2(); } [ComponentAccessControl()] [SecureMethod] public class Foo : ServicedComponent, IFoo { // Agregar funciones a este método administrativamente public void Method1() {} // "RoleX" se agrega al catálogo para este método SecurityRole("RoleX") public void Method2() {} } El uso de SecureMethod a nivel de clase permite configurar administrativamente todos los métodos de las interfaces con las funciones del catálogo COM+. Si la clase implementa dos interfaces, cada una de ellas con el mismo nombre de método, y las funciones se configuran administrativamente, será necesario establecerlas en ambos métodos como aparecen en el catálogo COM+ (a menos



que la clase implemente el método específico, por ejemplo, IFoo.Method1). Sin embargo, si se emplea el atributo SecurityRole en el método de clase, todos los métodos con el mismo nombre se configuran automáticamente con esa función cuando se registre el ensamblado. El atributo SecureMethod también se puede colocar en el nivel de método. [assembly: ApplicationAccessControl(true, AccessCheckLevel=AccessChecksLevelOption.ApplicationComponent)] Interface IFoo { void Method1(); void Method2(); } [ComponentAccessControl()] public class Foo : ServicedComponent, IFoo { // Agregar funciones a este método administrativamente [SecureMethod] // O utilizar SecurityRole (se traduce en SecureMethod++) public void Method1() {} public void Method2() {} } En el ejemplo, IFoo y ambos métodos aparecen en el catálogo COM+ y por tanto las funciones se pueden configurar administrativamente en cualquier método, si bien, el RBS de nivel de método sólo se fuerza en Method1. Utilice SecureMethod o SecurityRole en todos los métodos que se requerirán para participar en la seguridad RBS a nivel de método, o bien, coloque SecureMethod en el nivel de método como se señaló anteriormente. Siempre que se configura RBS a nivel de método, se solicita la función Marshaller: cuando se realizan llamadas a métodos y RBS no se ha configurado en éstos, la infraestructura de componentes facilitados como servicio realiza las llamadas en IRemoteDispatch. Cuando se realizan y RBS se ha configurado en los métodos (cuando el atributo SecureMethod está presente), la llamada tiene lugar utilizando DCOM con la interfaz asociada al método. Por consiguiente, DCOM garantiza que RBS se fuerza a nivel de método. No obstante, como se comentó en las secciones Activación e Intercepción, la interoperabilidad COM y RSCP realizarán las llamadas en IManagedObject (para poder permitir que los activadores remotos activen la referencia en su espacio) y en IServicedComponentInfo (para realizar consultas al objeto remoto). Estas interfaces se asocian a los componentes facilitados como servicio. Puesto que el componente se configura para que realice comprobaciones a nivel de método, es necesario asociar una función a estas interfaces si se desea que la infraestructura realice las llamadas correctamente. Por ello se agrega una función Marshaller a la aplicación cuando se registra el ensamblado; a continuación, se deberá agregar a los usuarios



administrativamente a la misma. En la mayoría de las ocasiones son todos los usuarios de la aplicación los que se incorporan a dicha función. Resulta algo distinto a lo que ocurría con COM+ no administrado, donde la configuración de RBS en los métodos no requería este pasó de configuración adicional. Incorporar automáticamente a todos los usuarios a esta función durante la fase de registro constituye un riesgo potencial, puesto que ahora cualquiera podría activar (pero no llamar) los componentes donde antes no tenía derechos. La función Marshaller también se agrega a la interfaz IDisposable para permitir a los clientes deshacerse del objeto. Una alternativa a esta función es que los usuarios agreguen las funciones relevantes a cada una de las tres interfaces mencionadas. 3.5.3.2. Implementación de seguridad basada en función de COM+ Cuando hay muchos usuarios enviando llamadas a componentes COM que funcionan bajo COM+, es necesario comprobar que sólo los usuarios especificados tienen acceso a ciertos componentes. COM+ permite definir funciones y asignarles usuarios de NT. Una vez que estas funciones se han definido, puede asignar las funciones que funcionarán con cada componente e incluso qué métodos de cada componente se pueden ejecutar.

Vamos a agregar un método a esta misma clase COMPlusServices para incorporar seguridad basada en funciones. Crearemos una función llamada Managers (Supervisores) y comprobaremos si el usuario que efectúa la llamada está en la función Managers en el nuevo método.

Pasos para agregar seguridad basada en funciones En lugar de modificar directamente la aplicación COM+ desde el complemento de servicios de componentes MMC para agregar la función de seguridad, agregaremos un nuevo atributo al proyecto. Utilizaremos la clase SecurityRoleAttribute para agregar la nueva función de Managers. El constructor para esta clase tiene dos argumentos: role (cadena) y everyone (booleano). El argumento role especifica la función que se creará y el argumento everyone especifica si el grupo integrado Everyone se agrega o no a los usuarios de la función. Agregue una nueva función de seguridad a la aplicación COM+ introduciendo el siguiente código justo debajo del comentario de detalles de registro de COM+. '******************************************** 'Detalles de registro de COM+ 'Atributo de seguridad basada en funciones <Assembly: SecurityRoleAttribute("Managers", False)>



1. Cambie el nivel de seguridad para realizar comprobaciones de acceso en los procesos y en los componentes. Esto permite a la aplicación COM+ tener un contexto de llamadas de seguridad.

2. Traiga a primer plano el complemento de servicios COM+.

3. Haga clic en la ficha Seguridad y cambie el nivel de seguridad, como se muestra en la figura.

Definir la propiedad de nivel de seguridad en el catálogo COM+ Como alternativa al proceso manual, se puede agregar un atributo al componente ordenándole que realice comprobaciones de acceso. El código siguiente debe agregarse en la sección de detalles de registro de COM+, en la parte superior de la clase COMPlusServices. <Assembly: ApplicationAccessCont rolAttribute (AccessChecksLevel:=AccessChecksLevelOption.ApplicationComponent)>



Comprobación de funciones de seguridad Ahora agregaremos un nuevo método a la clase denominado IsManager. Este método comprobará si el usuario es miembro de la función Managers. El método consiste en una función que devuelve un valor booleano que indica si el usuario que ejecuta la llamada forma parte o no de la función Managers. Para obtener acceso al contexto de seguridad del usuario que llame al método, es necesario utilizar la clase SecurityCallContext. Llamando al método CurrrentCall se obtiene el contexto del usuario actual. A continuación, llamaremos al método IsCallerInRole, pasando Managers como nombre de la función. Agregue el método indicado a continuación a la clase COMPlusServices. Public Function IsManager() As Boolean Dim objCallContext As SecurityCallContext = _SecurityCallContext.CurrentCall IsManager = _ objCallContext.IsCallerInRole("Managers") End Function A continuación, será necesario volver a generar el componente y probar este nuevo método. Desde el menú Generar de Visual Studio .NET, haga clic en Volver a generar solución. Prueba Modifique el código del método Sub Main() en la aplicación cliente de consola. El código debería ser similar a este: Sub Main() Dim objCOMPlus As New _ COMPlusJumpStart.COMPlusServices() Console.WriteLine(objCOMPlus.DoTransaction) Console.WriteLine(objCOMPlus.IsManager().ToString) Console.ReadLine() End Sub

1. Ejecute la aplicación de consola desde el símbolo de sistema introduciendo el nombre del archivo ejecutable que hemos compilado.

La primera vez que se ejecuta el código, se obtendrá una excepción que indica que se denegó el acceso porque no se ha agregado ningún usuario a la función Managers. Para resolver este problema, hay que agregar el usuario actual a Managers y volver a ejecutar la aplicación. Una vez hecho esto, no debería producirse la excepción. Es conveniente agregar código de control de excepciones. La aplicación cliente debería tener este aspecto con el código de control de excepciones:



Sub Main() Try Dim objCOMPlus As New _ COMPlusJumpStart.COMPlusServices() Console.WriteLine(objCOMPlus.DoTransaction) Console.WriteLine(objCOMPlus.IsManager().ToString) Console.ReadLine() Catch objException As Exception Console.WriteLine("Se produjo un error. " _ & "Detalles: " _&objException.Message) Console.ReadLine() End Try End Sub 3.5.3.3. Autenticación y personificación La seguridad se refiere al control del acceso a una variedad de recursos, como componentes de la aplicación, datos y hardware. La mayoría de las medidas de seguridad se basan en cuatro conceptos: Autenticación La autenticación es el proceso de confirmación de la identidad, que es la primera capa del control de seguridad. Antes de que una aplicación pueda autorizar el acceso a un recurso, debe confirmar la identidad del solicitante. El solicitante establece una identidad aportando algún tipo de credenciales, que sólo conocen el solicitante y el host que autentica. En algunos casos, puede que el solicitante desee verificar la identidad del host que autentica, lo que se denomina autenticación mutua. Autorización La autorización es el proceso que consiste en verificar si un usuario autenticado tiene permiso para obtener acceso a un recurso determinado, siendo ésta la siguiente capa de seguridad tras la autenticación. La confirmación de la identidad del solicitante por parte del host que autentica no implica necesariamente que el solicitante autenticado tenga los permisos necesarios para obtener acceso a un recurso determinado. Por ejemplo, suponga que un equipo ATM le autentica a través de una combinación de su tarjeta ATM y NIP. Aún así, sólo estará autorizado para obtener acceso a su cuenta bancaria. Para obtener más información. Protección de datos La protección de datos es el proceso que consiste en proporcionar confidencialidad, integridad y no repudio a los datos. Los datos requieren protección no sólo cuando están en tránsito sino también cuando están



almacenados. Independientemente de la forma que tengan los datos, una vez que entran en canales de comunicación no protegidos, se vuelven vulnerables a los ataques. El cifrado de los datos proporciona confidencialidad a éstos. El cifrado de datos utiliza un algoritmo de cifrado junto con una clave de cifrado con el fin de que los datos no tengan valor para las personas que no dispongan del algoritmo y de la clave correcta para descifrar los datos. La clave de cifrado es una variable adicional que se utiliza en el algoritmo. Una clave de cifrado contiene un valor numérico limitado por el número de bits que contiene la clave. Aunque una clave de 40 bits contiene 240 ó 1.099.511.627.776 valores de clave posibles, un equipo normal podría realizar una búsqueda exhaustiva de todos los valores de clave posibles en aproximadamente una semana. Sin embargo, si la clave de cifrado se compone de 128 bits, para que se produzca un ataque por fuerza bruta se tendrían que probar hasta 2128 o 3,4 x 1038 valores. Cada bit adicional duplica el número de valores posibles. Las claves de cifrado permiten que varios usuarios utilicen un algoritmo público sin que afecte a los datos cifrados con el algoritmo. Dado que la clave de cifrado determina el rigor del cifrado, todos los algoritmos de cifrado son vulnerables a los ataques por fuerza bruta. Estos ataques consisten en el intento sistemático de descifrar los datos utilizando todas las claves posibles. Por ejemplo, si la clave de cifrado utilizada para cifrar los datos sólo se compone de cuatro bits, para que se produzca un ataque por fuerza bruta que afecte a los datos sólo tienen que probarse hasta dieciséis valores de clave de cifrado. Para obtener más información, vea Criptografía. La integridad de los datos se obtiene mediante algoritmos hash, firmas digitales y códigos de autenticación de mensajes. Para garantizar la integridad de los datos, puede enviarse un hash de dichos datos para que los acompañe. El receptor podrá entonces comparar el hash que calcula en función de los datos recibidos con el hash que acompaña a los datos recibidos. Si ambos coinciden, los datos recibidos deberán ser los mismos que los datos a partir de los cuales se creó el hash recibido. Un hash es una cadena de números y caracteres que tiene una longitud fija. Se calcula utilizando un algoritmo hash, como MD5 (Message Digest 5) o SHA-1 (Secure Hash Algorithm). El cálculo del hash es una operación unidireccional que no se puede invertir para volver a crear los datos originales. La firma digital va un paso más allá del simple cálculo del hash y cifra el hash calculado utilizando una clave privada. Este paso adicional puede impedir que un atacante intercepte los datos y el hash que los acompaña, modifique los datos y, después, simplemente vuelva a calcular el nuevo hash de los datos modificados. Como una firma digital es un hash cifrado, el atacante necesitaría obtener acceso a la clave privada original utilizada para crear la firma digital original. Las firmas digitales pueden verificarse en el receptor final mediante la clave pública asociada. Las firmas digitales pueden utilizarse para exigir la no



repudiación de los datos, que puede utilizarse más adelante para comprobar el origen, contenido y marca de hora de los datos. Para obtener más información, vea Algoritmos hash y firmas digitales. Algunas tecnologías, como SSL/TLS, utilizan códigos de autenticación de mensajes (MAC) para verificar que no se han modificado los datos mientras estaban en tránsito. Sin embargo, como los códigos MAC utilizan una clave común para el cifrado y la verificación, no pueden utilizarse para exigir la no repudiación de los datos. Para obtener más información, vea Códigos de autenticación de mensajes de canal S. Auditoría La auditoría es el proceso que consiste en registrar y supervisar los eventos que se producen en un sistema y que son importantes para la seguridad. La auditoría constituye una fuente clave para el estudio de la seguridad. Para obtener más información, vea Registro de eventos. Lamentablemente, la auditoría es un proceso pasivo que sólo puede detectar problemas de seguridad una vez que la aplicación se vea afectada. Puede llevarse a cabo una supervisión activa mediante el Monitor de rendimiento de Windows para que se realicen comentarios en tiempo real. Para obtener más información, vea Supervisión del rendimiento. Cuestionario

1. ¿Si la seguridad se habilita para una aplicación COM+, cómo determina el COM SCM si un cliente particular es permitido para comenzar una aplicación servidor COM+?

2. ¿Cómo un objeto de Servicios .NET puede programáticamente tomar decisiones basadas en el rol de miembros solicitantes?

3. ¿Cómo un objeto de Servicios .NET puede obtener detalles relacionando el aumento de flujo de solicitantes?

4. ¿Qué configuraciones de seguridad de una biblioteca de aplicación hereda de su proceso huésped y cuál puede anularse específicamente?



3.5.4. Componentes en Cola 3.5.4.1. Introducción a la creación de colas El servicio de componentes en cola de COM+ proporciona una manera fácil de llamar y ejecutar componentes de manera asincrónica utilizando Microsoft Message Queuing. El procesamiento se puede producir independientemente de la disponibilidad o accesibilidad del remitente o el receptor. Para utilizar este servicio, la clase debe derivar directa o indirectamente de la clase System.EnterpriseServices.ServicedComponent. La propiedad MaxListenerThreads indica el número máximo de subprocesos simultáneos de agente de escucha de componentes en cola. El intervalo válido para este valor va de 0 a 1000. Para una aplicación recién creada, el valor deriva del algoritmo usado actualmente para determinar el número predeterminado de subprocesos de agente de escucha: 16 multiplicado por el número de unidades de procesamiento (CPU) del servidor. Este valor no impone el número de subprocesos que se ejecutan en todo momento, sólo el número máximo de subprocesos posibles. En un servidor inactivo sólo habría un subproceso en ejecución hasta que se encontraran más mensajes en la cola. Entonces, el servidor crearía más subprocesos según fuera necesario hasta llegar al valor de MaxListenerThreads. En el ejemplo siguiente se establece en 64 el número máximo de subprocesos de agente de escucha de componentes en cola. Nota La cadena proporcionada al método Marshal.BindToMoniker puede contener parámetros opcionales para especificar el nombre del equipo así como otro tipo de información. Vea la sección "Desarrollar componentes en cola" de Platform SDK si desea obtener más información. [Visual Basic] <ApplicationQueuingAttribute(QueueListenerEnabled := _ true, MaxListenerThreads := 64 )> [C#] [ApplicationQueuingAttribute(QueueListenerEnabled = true, MaxListenerThreads = 64 )] En el ejemplo siguiente que se compone de dos partes, se muestra cómo se implementa una clase QComponent en el servidor para mostrar un mensaje de manera asincrónica y se utiliza un cliente para llamar al método DisplayMessage en un componente en cola. Servidor [Visual Basic] Imports System.Reflection Imports System.EnterpriseServices Imports System



<assembly: ApplicationName("QCDemoSvr")> <assembly: ApplicationActivation(ActivationOption.Server)> <assembly: ApplicationQueuing(Enabled := True, _ QueueListenerEnabled := True)> <assembly: AssemblyKeyFile("QCDemoSvr.snk")> Namespace QCDemo Public Interface IQComponent Sub DisplayMessage(msg As String) End Interface <InterfaceQueuing(Interface := "IQComponent")> _ Public Class QComponent Inherits ServicedComponent Implements IQComponent Public Sub DisplayMessage(msg As String) implements _ IQComponent.DisplayMessage MessageBox.Show(msg, "Processing message") End Sub 'DisplayMessage End Class End Namespace [C#] using System.Reflection; using System.EnterpriseServices; [assembly: ApplicationName("QCDemoSvr")] [assembly: ApplicationActivation(ActivationOption.Server)] [assembly: ApplicationQueuing(Enabled=true, QueueListenerEnabled=true)] [assembly: AssemblyKeyFile("QCDemoSvr.snk")] namespace QCDemo { public interface IQComponent { void DisplayMessage(string msg); } [InterfaceQueuing(Interface = "IQComponent"] public class QComponent : ServicedComponent, IQComponent { public void DisplayMessage(string msg) { MessageBox.Show(msg, "Processing message"); } } }



Client [Visual Basic] Protected Sub Send_Click(sender As Object, e As System.EventArgs) _ Handles send.Click Dim iQc As IQComponent = Nothing Try iQc = CType(Marshal.BindToMoniker("que ue:/new:QCDemo.QComponent"), _ IQComponent) Catch l as Exception Console.Writeline("Caught Exception: " & l.Message) End Try iQc.DisplayMessage(messageToSend.Text) Marshal.ReleaseComObject(iQc) End Sub 'Send_Click [C#] protected void Send_Click (object sender, System.EventArgs e) { IQComponent iQc = null; try { iQc = (IQComponent) Marshal.BindToMoniker("queue:/new:QCDemo.QComponent"); } catch { MessageBox.Show("Cannot create Queued Component"); } iQc.DisplayMessage (messageToSend.Text); Marshal.ReleaseComObject(iQc); } 3.5.4.2. Desarrollo de componentes en cola Uso de los componentes en cola El proceso de agregar soporte para colas en aplicaciones COM+ resulta bastante sencillo. Sólo es necesario asegurarse de que la aplicación se está ejecutando como aplicación de servidor (fuera de proceso) y, a continuación, definir las propiedades Queued y Listen en la ficha Colas. Una vez definidos estos valores, la aplicación cliente puede llamar a componentes de forma sincrónica o asincrónica. Lo bueno de esta característica es que no hay que cambiar el código de un objeto COM; sólo es necesario cambiar sus propiedades en el catálogo de COM+.



La plataforma .NET admite componentes en cola y, como es de esperar, se puede aplicar dicho soporte para colas en componentes mediante atributos, en lugar de hacerlo de forma manual cambiando el catálogo de COM+. Vamos a agregar un método a la clase COMPlusServices y a llamarlo de forma asincrónica mediante los servicios de componentes en cola COM+ de una aplicación .NET cliente. Haga que su aplicación COM+ sea una aplicación de servidor (fuera de proceso). Esto es necesario para componentes en cola. Para hacerlo mediante atributos, agregue el siguiente código al proyecto: '******************************************** 'Detalles de registro de COM+ <Assembly: ApplicationActivationAttribute(ActivationOption.Server)> Agregue soporte para colas al componente. Hágalo accesible a colas MSMQ de manera que pueda considerar su propia cola para procesar mensajes. Este es el código para hacerlo mediante atributos: '******************************************** 'Detalles de registro de COM+ <Assembly: ApplicationQueuingAttribute(Enabled:=True, QueueListenerEnabled:=True)> Agregue un método llamado QueueTest a la clase. Asegúrese de que es una subrutina. No debe devolver ningún valor. Defínalo para que escriba un mensaje en el Registro de aplicaciones de Windows. El código debería ser similar a este: Public Sub QueueTest() System.Diagnostics.EventLog.WriteEntry(_ "COMPlusServces", "Prueba de cola", _ Diagnostics.EventLogEntryType.Error) End Sub Eso es todo. Al menos todo lo necesario para habilitar un componente y que funcione como componente COM+ en cola. Prueba Ahora deberemos probar este componente en cola creando otra aplicación de consola para llamarlo.

1. Cree una nueva aplicación de consola.

2. Agregue el siguiente código al procedimiento Sub Main de esta aplicación de consola.



Sub Main() Dim objTest As COMPlusJumpStart.COMPlusServices Dim strMoniker strMoniker = _ "queue:/new:COMPlusJumpStart.COMPlusServices" objTest = GetObject(strMoniker) objTest.QueueTest() End Sub

Este código llama al método QueueTest del componente de forma asincrónica. Para llamar al método de forma sincrónica, habría que llamarlo como al resto de los métodos del componente.

Ahora podemos ejecutar esta aplicación de consola para comprobar el funcionamiento de este componente en cola.

3.5.4.3. Componentes en cola y transacciones Cuestionario

1. Liste tres ventajas de usar la mensajería asincrónica en un entorno de los sistemas distribuidos.

2. Explique el propósito del grabador, oyente y componentes del jugador.

3. Liste dos factores que representen que una interfaz es impropia para la operación en cola.

4. Liste tres consideraciones generales del diseño de sistemas que utilizan componentes en cola.

5. ¿Cómo un cliente se instancia en componente en cola?

6. Liste dos maneras de devolver las contestaciones asincrónicas de un componente en cola a un cliente.

7. ¿Qué efecto realiza marcando una aplicación como en cola?

8. ¿Qué interfaces realiza un implemento de clase de excepción?



3.5.5. Despliegue y Administración de Aplicaciones 3.5.5.1. Despliegue de una aplicación COM+ construida usando los servicios .NET

Comenzaremos con la descripción de algunas de las principales diferencias entre MTS y COM+. A continuación trataremos la herramienta administrativa Servicios de componentes y su utilización en tres de las tareas administrativas más comunes del sistema:

• Distribución de las aplicaciones • Establecimiento de la seguridad basada en funciones y la identidad de

seguridad de una aplicación • Administración del agrupamiento de los objetos para conseguir un

rendimiento óptimo del sistema.

De MTS a COM+

Muchos usuarios de IIS ya conocen Microsoft Transaction Server (MTS) y su interfaz de usuario correspondiente, MTS Explorer. Se puede concebir COM+ como un conjunto de servicios que combinan el modelo de objetos componentes (COM) tradicional con MTS en los sistemas Windows 2000. Con la introducción de COM+, la funcionalidad de MTS se ha fundido con el sistema operativo. Como podrá comprobar, COM+ también amplía y mejora los servicios que se encuentran disponibles con MTS.

Si ha utilizado con anterioridad MTS y MTS Explorer, se encontrará con algunos cambios significativos cuando inicie la herramienta administrativa Servicios de componentes. De modo destacado, los paquetes MTS ahora reciben el nombre de aplicaciones COM+.

La idea de aplicación COM no es tan nueva. Sencillamente se trata del término que se emplea para referirse a los grupos de componentes COM desarrollados para trabajar conjuntamente. En las aplicaciones COM tradicionales, los componentes debían instalarse mediante la configuración de las entradas en el Registro antes de poder ejecutarse. Esta tarea normalmente se llevaba a cabo con la utilidad Regsvr32. En el caso de COM+, este paso se realiza automáticamente cuando configura los componentes como aplicación COM+. Los componentes COM todavía se pueden seguir registrando en Windows 2000 mediante la utilidad Regsvr32 y seguirán existiendo en el entorno COM+ como componentes sin configurar. Los componentes sin configurar no aparecen en pantalla dentro de la herramienta administrativa Servicios de componentes y no usan los nuevos servicios COM+. No obstante, cuando se ejecutan estos componentes, utilizan algunas partes de la infraestructura de COM+ para ejecutar aplicaciones COM+ distribuidas.



Las aplicaciones COM+ constan de uno o varios componentes COM. La clase COM es la implementación con nombre, concreta, de una o varias interfaces. La clase expone sus interfaces, que proporcionan un conjunto de funciones relacionadas entre sí denominadas métodos. El Objeto COM es un ejemplo de clase COM. Un componente COM es una unidad binaria de código que crea objetos COM (entre los que se incluyen el código de empaquetamiento y de registro).

La clase COM se identifica mediante un identificador de clase (CLSID) y a veces también con un identificador de programa (ProgID). Una interfaz es un grupo de funciones relacionadas entre sí que especifican un contrato. Éste incluye con el nombre, la firma y la semántica de la interfaz, y el formato de ordenación en búfer.

Cada interfaz se identifica con un identificador IID. La sintaxis de la interfaz se define en las bibliotecas de tipo e IDL. Las interfaces de la clase deberían dividirse en conjuntos de métodos manejables y coherentes. Recuerde que las interfaces son inmutables, el contrato COM establece que no se pueden modificar. Cualquier modificación (como agregar métodos) exige la definición de una interfaz nueva.

Distribuir aplicaciones COM+

Mientras que el programador de aplicaciones utiliza COM+ para escribir componentes e integrarlos como aplicaciones, la labor del administrador del sistema es, generalmente, instalar, distribuir y configurar las aplicaciones COM+ y sus componentes. Normalmente, el programador entregará una aplicación COM+ configurada en parte al administrador del sistema. O bien la aplicación puede provenir de una fuente externa, por ejemplo, de la adquisición de una aplicación COM+ a un proveedor de software independiente (ISV). El administrador puede entonces personalizar la aplicación para uno o varios entornos específicos (por ejemplo, mediante la incorporación de las cuentas de



usuario a las funciones y los nombres de usuario en un clúster de la aplicación). Entre las tareas típicamente administrativas se incluyen:

• Instalar una aplicación COM+ parcialmente configurada en un equipo administrativo.

• Proporcionar atributos específicos del entorno, como los miembros de función y el tamaño del grupo de objetos.

• Configurar la identidad (la cuenta de usuario de Windows 2000) con la que se va a ejecutar una aplicación COM+.

• Reexportar la aplicación COM+ totalmente configurada. • Crear un proxy de aplicación (cuando se vaya a tener acceso a la

aplicación de modo remoto).

Cuando la aplicación se ha configurado completamente para un entorno específico, el administrador puede entonces distribuirla entre los equipos de prueba o producción. Esto implica la instalación de la aplicación completa COM+ ya configurada en uno o varios equipos.

La herramienta administrativa Servicios de componentes facilita la distribución de las aplicaciones COM+ entre múltiples servidores con la ayuda del Asistente para exportación de las aplicaciones. Puede utilizar la herramienta administrativa Servicios de componentes para crear paquetes de instalación destinados a las aplicaciones COM+ y los proxy de la aplicación. COM+ genera paquetes de instalación admitidos por Windows Installer que, en un único archivo, contienen las piezas necesarias para instalar una aplicación COM+ en otro equipo.

El archivo .msi que contiene una aplicación COM+ sólo puede ser instalado en equipos que admitan Servicios COM+ 1.0 (en la actualidad, sólo Windows 2000). Como ventaja adicional, las aplicaciones COM+ que utilizan Windows Installer aparecen en el panel de contro l de Agregar o quitar programas, a menos que se modifique el archivo .msi mediante una herramienta de edición de Windows Installer.



El archivo .msi que genera la herramienta administrativa Servicios de componentes contiene:

• Tablas de Windows Installer con información de registro COM+. • Un archivo .apl que contiene los atributos de la aplicación. • Bibliotecas DLL y de tipos que describen las interfaces que se

implementan en las clases de la aplicación COM+.

Además, la herramienta administrativa Servicios de componentes genera un archivo contenedor (.cab). Este archivo engloba el archivo .msi, permitiendo así la distribución de la aplicación COM+ a través de Internet Explorer.

Instalar los proxy de al aplicación COM+

Para tener acceso a una aplicación de servidor COM+ remotamente desde otro equipo (cliente), el equipo cliente debe tener un subconjunto de atributos de la aplicación del servidor que se haya instalado, incluidas bibliotecas DLL de proxy o código auxiliar, y bibliotecas DLL y de tipos destinadas al uso remoto de la interfaz DCOM. Este subconjunto recibe el nombre de proxy de aplicación.

A través de la herramienta administrativa Servicios de componentes, puede exportar fácilmente una aplicación de servidor COM+ como si fuera un proxy de aplicación. Los proxy de aplicación que genera COM+ son paquetes estándar de instalación de Windows Installer. Tras la instalación, aparecen los proxy de aplicación en el panel de control de Agregar o quitar programas en el equipo cliente.

Cuando se genera un proxy de aplicación, COM+ proporciona automáticamente la siguiente información. Esta información es obligatoria para que el proxy de aplicación tenga acceso de forma remota a la aplicación COM+ de servidor.

• Información de la identidad de la clase (CLSID y ProgID); un proxy de aplicación admite hasta dos identificadores de programa (ProgID).

• La identidad de la aplicación y la relación de las clases hacia las aplicaciones (AppID).

• Información de ubicación por aplicación (nombre del servidor remoto). • Ordenación de la información para todas las interfaces expuestas por la

aplicación (por ejemplo, bibliotecas de tipo y proxy o código auxiliar). • Nombres de cola MSMQ e identificadores (si se ha habilitado el servicio

de componentes en cola en la aplicación). • Atributos de método, interfaz y clase, excepto la información de funciones. • Atributos de la aplicación.

Al contrario que las aplicaciones de servidor COM+, los proxies de aplicación se pueden instalar en cualquier sistema operativo que admita DCOM y Windows Installer. Los clientes de otras plataformas de Windows también pueden tener



acceso a las aplicaciones COM+ que se ejecutan en los servidores de Windows 2000. Respecto a los equipos en los que no se ejecuta Windows 2000 (y que, por consiguiente, carecen de COM+), sólo se instala el subconjunto de la información exigida para funcionar de modo remoto con DCOM. Esta información se instala en el Registro de Windows. Cuando se instala un proxy de aplicación (archivo .msi) en equipos donde no se ejecuta Windows 2000, debe ejecutarse Windows Installer. Windows Installer está disponible en formato redistribuible como parte del SDK de la plataforma.

Configurar la seguridad de COM+

Las funciones de seguridad modelan e imponen una directiva de control de acceso a la aplicación COM+. Las funciones son categorías de usuarios que se han definido para la aplicación con el propósito de determinar los permisos de acceso a los recursos de la aplicación. El programador asigna las funciones (como si se tratara de categorías simbólicas de usuario) a la aplicación y potencialmente a las estructuras más refinadas que incluya, como componentes, interfaces, métodos o recursos particulares de aplicación. Estas asignaciones de funciones se utilizan por tanto para determinar qué categorías de usuario tienen permiso para tener acceso a qué elementos dentro de la aplicación.

Cuando una aplicación emplea una seguridad basada en funciones, en cada llamada que se haga en la aplicación se comprueba la pertenencia como miembro de la función de llamada. Si quien realiza la llamada no pertenece a una función que tenga permiso de acceso al elemento que ha sido llamado, la llamada fracasará. Quienes realizan las llamadas tienen garantizado su acceso a la aplicación o a sus recursos estrictamente según las restricciones definidas en las funciones a las que pertenecen.

La labor del administrador del sistema es poblar las funciones que define la aplicación con los grupos y las cuentas de usuario de Windows 2000. Esta es una fase crucial en la aplicación de la directiva de seguridad de la aplicación. Se deben asignar los usuarios a las funciones que representan correctamente sus relaciones con los datos y recursos a los que podrían tener acceso a través de la aplicación.

La mejor forma de poblar estas funciones con usuarios es utilizar los grupos de Windows 2000. En primer lugar, se asigna una cuenta de usuario a los grupos en cuestión y, después, se asegura que a estos grupos se les asignan las funciones adecuadas. El uso de los grupos de Windows 2000 para poblar funciones le facilita la administración de grandes cantidades de usuarios.

En entornos informáticos de empresa, suele ser difícil hacer un seguimiento eficaz de cada usuario dentro de la organización y determinar la forma en que se asigna a la política de seguridad basada en las funciones particular de cada aplicación. A medida que aumenta el número de usuarios, administradores y



aplicaciones, esta tarea se vuelve cada vez más complicada. La solución más escalable es la de asignar grupos de usuarios a las funciones de la aplicación COM+.

Antes de asignar grupos a las funciones, es necesario que se asegure de haber comprendido la política de seguridad de la aplicación. Teóricamente, las funciones deberían llevar nombres que sugirieran quiénes deberían pertenecer a ellas, como "Jefes" y "Narradores". Además, hay descripciones para cada función a la que usted puede tener acceso mediante la herramienta administrativa Servicios de componentes, que pueden describir los tipos de usuario que deberían pertenecer a la función. Sin embargo, si no está seguro de qué grupos de usuarios pertenecen a qué funciones, consulte la documentación que acompaña a la aplicación o pregunte al programador.

Puede utilizar la herramienta administrativa Servicios de componentes tanto para realizar las asignaciones iniciales de las distintas funciones durante la instalación de la aplicación como para efectuar cualquier cambio necesario durante el tiempo de vida de la aplicación.

Agrupación de objetos

La agrupación de objetos es un servicio automático que ofrece COM+, que le permite configurar un componente para tener copias activas de éste en un grupo, listas para que cualquier cliente que solicite el componente pueda utilizarlas. Puede configurar administrativamente y controlar el grupo que se mantiene para un determinado componente, especificando las características que posee, como el tamaño del grupo y la solicitud de creación de valores de tiempo de espera. Cuando la aplicación se está ejecutando, COM+ le administra el grupo, controlando los detalles de la activación y reutilización de los objetos de acuerdo con los criterios que haya especificado.



Puede conseguir un rendimiento muy significativo y escalar las ventajas si reutiliza los objetos de este modo, particularmente cuando se han diseñado para sacar el máximo partido de la reutilización. Usted puede configurar administrativamente la agrupación de objetos para obtener el máximo partido de los recursos de hardware disponibles. La configuración del grupo puede variar a medida que cambien los recursos de hardware disponibles. También puede gobernar el uso de los recursos con la administración del grupo.

Cuando configure un componente que vaya a ser agrupado, COM+ mantendrá copias de éste en un grupo, listas para que cualquier cliente que solicite el componente las active. Cualquier solicitud de creación de objetos se tratará a través del administrador del grupo.

Al iniciarse la aplicación, el grupo se poblará hasta el nivel mínimo que usted haya especificado administrativamente, mientras prospera la creación de objetos. Cuando el cliente solicita la entrada del componente, el grupo satisfará su petición y servirá los componentes por orden de llegada. Si no hay ningún objeto del grupo disponible y el grupo no se encuentra aún en su máximo nivel especificado, se crea y activa un nuevo objeto para el cliente.

Cuando el grupo alcanza su nivel máximo, las solicitudes del cliente entran en la cola de trabajo. Cada solicitud recibe el primer objeto disponible del grupo. El número de objetos, tanto activados como desactivados, no sobrepasará nunca el valor máximo del grupo. El tiempo de espera de las solicitudes de creación de objetos se agotará después de un período especificado administrativamente, de modo que usted pueda controlar el tiempo que tienen que esperar los clientes para la creación de objetos. Siempre que sea posible, COM+ intentará reutilizar



un objeto una vez que el cliente lo libere, hasta que el grupo alcance su nivel máximo.

Puede utilizar el tamaño máximo de grupo para precisar con mucha exactitud el modo en que utiliza los recursos. Por ejemplo, si tiene licencia para un cierto número de conexiones de base de datos, puede controlar cuántas conexiones tiene abiertas en cualquier momento.

Al reflexionar acerca de los pa trones de uso de los clientes, las características de uso de los objetos y los recursos físicos como la memoria y las conexiones, es probable que descubra un equilibrio óptimo a la hora de ajustar el rendimiento. La agrupación de objetos irá menguando en su rendimiento tras alcanzar un cierto punto. Usted puede determinar el rendimiento que desea y equilibrarlo frente a los recursos que son necesarios para conseguirlo. Con el agrupamiento, tiene control sobre el uso de los recursos.

Cuestionario

1. Liste las limitaciones de usar el registro dinámico.

2. ¿Cuáles son los contenidos del archivo .msi que se crea cuándo exporta una aplicación COM+?

3. Liste las fases de repetición al usar la herramienta de COMREPL.

4. Liste los pasos para crear una aplicación COM+.





Estándar

Puntos de Atributo

Obtenidos (10-9) (8.5-7) (6.5-0)

Aplicación de la

Información









(10-9) (8.5-7) (6.5-0)



material elaborando








Los estudiantes no



del tema.


3.6. Web Services Escenario Web Services Sistemas de Objetos Distribuidos y Protocolos

• El paradigma de objetos distribuidos tiene amplia aceptación en aplicaciones distribuidas, por lo que un gran número de mecanismos basados sobre el paradigma están disponibles, entre ellos los que hemos tratado hasta el momento:

o Common Object Request Broker Architecture (CORBA).



o Java Remote Method Invocation (RMI). o Distributed Component Object Model (DCOM, COM+), o Mecanismos que soportan el Simple Object Access Protocol

(SOAP). • Este último es utilizado en los Web Services:

o Un servicio Web XML es un componente de software o una aplicación que expone sus funciones programáticamente a través de Internet o la intranet utilizando los protocolos estándar de Internet como son Simple Object Access Protocol (SOAP) para comunicación entre programas, y XML para representación de datos.

Estándares de Web Services Los servicios Web se registran y anuncian utilizando los siguientes servicios y protocolos:

• XML (extensible Markup Language), Estructura, describe e intercambia información. Independientemente de múltiples formas, todas las tecnologías de servicios Web se basan en XML. El diseño de XML se deriva de dos fuentes principales: SGML (Standard Generalizad Markup Language) y de HTML (Hipertexto Markup Language).

• UDDI (Universal Description, Discovery and Integration), es un protocolo para describir los componentes disponibles de servicios Web. Este estándar permite a las empresas registrarse en un tipo de directorio sección amarilla de Internet que les ayuda anunciar sus servicios, de tal forma que las compañías se puedan encontrarse unas a otras y realizar transacciones en el Web. El proceso de registro y consultas se realiza utilizando mecanismos basados en XML y HTTP. En el proyecto UDDI se trabaja para proveer un método de acceso común a los metadatos necesarios para determinar su un elemento de código previamente elaborado es suficiente, y si lo es, cómo accederlo.

• SOAP (Simple Object Access Protocol) es un protocolo para iniciar las conversaciones con un servicio UDDI. El SOAP simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar métodos objeto o funciones, que residen en sistemas remotos. Una aplicación SOAP crea una un petición bloque en XML. proporcionando los datos necesarios para el método remoto así como la ubicación misma del objeto remoto.

• WSDL (Web Service Description Language), es el estándar propuesto para la descripción de los servicios Web, el cual consiste en un lenguaje de definición de interfaz (IDL - Interface Definition Language) de servicio basado en XML, que define la interfaz de servicio y sus características de implementación. El WSDL es apuntado en los registros UDDI y describe los mensajes SOAP que definen un servicio Web en particular.

• ebXML (e-business XML) define componentes centrales, procesos, registros y almacenajes comerciales, servicios de mensajes, acuerdos de intercambio comercial, y seguridad.



Esquema de Implementación de un Servicio Web Un proveedor de servicio crea un servicio Web El proveedor de servicio utiliza WSDL para describir el servicio (a un registro UDDI) El proveedor de servicio registra el servicio (en un registro UDDI y/o a un registro/depósito ebXML ) Otro servicio o usuario localiza y solicita el servicio registrado al consultar los registros UDDI y/o ebXML El servicio o usuario solicitante escribe una aplicación que liga el servicio registrado utilizando SOAP (en el caso de UDDI) y/o ebXML Se intercambian datos y mensajes XML sobre HTTP

Ejercicio Práctico de Web Services Creación de una Aplicación Web Services en Visual Studio .Net Paso1: Un servicio Web desde un punto de vista del servidor IIS funciona exactamente igual que una aplicación Web. Se aloja en un directorio virtual y utiliza para su funcionamiento archivos .ASMX, en vez de las páginas .ASPX que utilizamos en ASP .NET.



• Crear un directorio físico donde almacenaremos los archivos necesarios para el funcionamiento de nuestro servicio Web. Suponiendo que su directorio raíz de su servidor Web IIS sea el directorio raíz por defecto (“c:\inetpub \wwwroot\”), crearemos un nuevo directorio llamado “WSDemo”.

• Ejecutar la consola de administración de IIS. Esta se encuentra en el Panel de Control, icono de Herramientas Administrativas e icono de Administrador de Servicios de Internet.

• Ejecutar la consola de administración de IIS. Esta se encuentra en el Panel de Control, icono de Herramientas Administrativas e icono de Administrador de Servicios de Internet.

• Seleccionamos y desplegamos la rama del Servidor Web Predeterminado, y veremos nuestra carpeta denominada “WSDemo”.

• Haremos clic con el botón derecho sobre esta carpeta, y elegiremos la opción Propiedades.

• En la pestaña Directorio, pulsaremos el botón de Crear. Esta operación lo que realiza es crear una nueva aplicación Web de IIS en este directorio físico. A partir de este momento, podremos acceder a la dirección “http://localhost/WSDemo”, e IIS nos la servirá dentro del marco que el define para las aplicaciones Web.

• Pulsamos Aceptar y salimos de todas las ventanas. Paso2: A continuación escribimos el código del servicio:

• Debemos indicar que vamos a utilizar elementos pertenecientes a la clase System.WebServices using System.Web.Services;

• Delante de los métodos que queramos que sean accesibles por la Web añadiremos la cláusula [WebMethod], indica al sistema en tiempo de ejecución que es un método llamado a través de HTTP.

• Todo Web Service debe ser identificado de forma única en Internet, la manera de hacer esto es suministrando una dirección URL. Esta URL debe ser declarada en un atributo antes de la declaración de la clase: [WebService(Namespace=“http://localhost/WSDemo”)]

Paso3: Solicitamos el Build (Generar) del proyecto e inmediatamente podemos acceder al servicio a través del navegador web. El código de nuestra página “wsdemo.asmx” es el siguiente: <%@ WebService Language="c#" Class="demo WS" %> using System; using System.Web; using System.Web.Services; namespace WS { [WebService(Namespace="http://localhost/WSDemo/")] public class wsdemo : System.Web.Services.WebService



{ public wsdemo() { } [WebMethod] Public Function LlamadaMetodoWSdemo() As String { return "Respuesta a wsdemo";

} } }

Actividad 3.6 Actividad Web Services Realizar el ejercicio práctico del Escenario Web Services, colocar informe en Tarea Individual 3.6





Estándar

Puntos de Atributo

Obtenidos

(10-9) (8.5-7) (6.5-0)

Aplicación de la

Información









(10-9) (8.5-7) (6.5-0)



material elaborando








Los estudiantes no



del tema.




4. Lenguajes de Programación

4.1. Lenguajes y Plataformas de Desarrollo Actividad 4.1 Actividad Lenguaje y Plataformas de Desarrollo Antes de iniciar o durante su proyecto final, revisar el Material de Apoyo 4.1 Nota: Esta actividad no tiene evaluación.

4.1.1 Antecedentes Inicialmente, los computadores eran grandes centros de computación con entidad propia en centros de investigación o gubernamentales y Universidades. Con la introducción de los PC en los 80, todos pudieron tener parte de esa capacidad de cómputo. Los PC, mucho más baratos que minis o mainframes, fueron una gran aportación para empresas y particulares. Aunque el computador personal estaba pensado para ser un elemento de computación autónomo y no formar redes de computadores, la posibilidad de compartir recursos gracias a la comunicación de varios PC, supone una ventaja que los fabricantes no pudieron ignorar, empezando así la carrera hacia los sistemas distribuidos, que tratan de sumar lo mejor de microcomputadores y supercomputadores a la vez creando un computador virtual a partir de varios PC. Orientado a Procedimiento La comunicación entre dos PC en sistemas UNIX, mejoró mucho cuando BSD introdujo el concepto de socket, que permitía que la comunicación entre procesos sitos en computadores distintos no fuera mucho más complicada que la de un programa que supiese leer y escribir archivos. Los programas que emplean sockets establecen un protocolo de comunicación para poder entenderse. El RPC, de Sun Microsystems, es el siguiente nivel de abstracción y permite realizar llamadas a procedimientos independientemente de su localización, buscando con ello la transparencia de acceso para el programador. Orientada a Objetos



Las tecnologías Orientadas a Objeto, hacen que estas abstracciones orientadas a procedimiento resulten inadecuadas, y propicia la aparición de sistemas como CORBA, RMI y COM/DCOM. El término sistema distribuido hace referencia al uso de objetos por parte de otros que pueden estar situados o no en la misma máquina, de forma casi transparente. Los objetos servidores que ofrecen servicios, y de objetos cliente, que los usan, aunque esta distinción carece de sentido en sistemas distribuidos, donde un objeto puede adoptar simultáneamente ambos roles.

4.1. 2 Java y las Redes SUN Java es un entorno de computación introducido al público en 1995 por Sun Microsystems. Considerado como lenguaje de programación, es simplemente un lenguaje cuya sintaxis recuerda la del C++, y tiene, respecto a este, ventajas, que el marketing de la compañía trata de resaltar, e inconvenientes, que trata de ocultar, sin embargo, las librerías de clases y el que todos sus programas se ejecuten en una máquina virtual lo convierten en un lenguaje altamente portátil, muy apto para una red con computadores y sistemas operativos tan heterogéneos como Internet. Máquinas Virtuales El secreto de la portabilidad binaria de los programas java reside en las máquinas virtuales. Los compiladores Java no generan binarios para una arquitectura real, sino para una inexistente máquina virtual Java, por lo que para usar los binarios, se necesita un emulador encargado de traducir instrucciones del programa a primitivas de la arquitectura anfitriona.

4.1.3 Sistemas Distribuidos en Java RMI RMI fue el primer framework para crear sistemas distribuidos que apareció para Java. Además, viene integrado en cualquier máquina virtual Java posterior a la 1.0 y está pensado para hacer fácil la creación de sistemas distribuidos a partir de una aplicación cuyas clases ya estén implementadas. CORBA: El estándar de sistemas distribuidos CORBA es el estándar para la creación de sistemas distribuidos creado por el Object Management Group (OMG). Pensado para ser independiente del



lenguaje, rápidamente aparecieron implementaciones en las que se podía usar casi cualquier lenguaje. DCOM: La alternativa de Microsoft. Aunque objeto y componente tienen significado distintos, el nombre utilizado en las tecnologías de Microsoft COM y DCOM, versión distribuida de COM es componente. COM/DCOM es un sistema de componentes implementado en todos los sistemas operativos que fabrica Microsoft. La tecnología para crear sistemas distribuidos proporcionada por Microsoft es una versión orientada a componentes del sistema RPC ya comentado.

4.1.4 CORBA. CORBA, Common Object Request Broker Architecture, es una tecnología para crear sistemas distribuidos, creada por un consorcio de fabricantes, agrupados bajo el OMG. El estándar CORBA define qué ha de incluir una implementación estándar, pero no cómo se han de hacer. Esta tarea se deja de la mano de los diferentes fabricantes. Esta es una de las principales características de CORBA: permite una total libertad a los implementadores siempre que estos respeten unos mínimos orientados a la interoperabilidad entre implementaciones. Ventajas Disponibilidad y Versatilidad Muchas arquitecturas y sistemas operativos cuentan con una implementación de CORBA, lo que hace suponer que se puede usar CORBA en virtualmente cualquier proyecto de sistemas distribuidos. Eficiencia La libertad de desarrollo ha favorecido la existencia de una pléyade de implementaciones del estándar que se adaptan a multitud de posibles necesidades de los usuarios, generando una competencia que favorece aquellas implementaciones de mayor calidad y con más características. Adaptación a Lenguajes de programación Además, es posible emplear los servicios de CORBA desde cualquier lenguaje de programación, desde C++, C ó Java, hasta COBOL ó Ada.



Inconvenientes

Complejidad Permitir la interoperabilidad de distintos lenguajes, arquitecturas y sistemas operativos hace que sea un estándar bastante complejo, y su uso no sea tan transparente al programador como sería deseable:

1. Hay que usar un compilador que traduce una serie de tipos de datos estándares a los tipos del lenguaje en el que se vaya a programar (IDL).

2. Hay que ser conscientes a la hora de diseñar qué objetos van a ser

remotos y cuáles no (los remotos sufren restricciones en cuanto a sus capacidades con respecto a un objeto normal).

3. Es necesario emplear tipos de datos que no son los que proporciona de

manera habitual el lenguaje de programación (muchas veces hay que emplear tipos de datos adaptados de IDL).

Incompatibilidad entre implementaciones Muchas empresas ofrecen implementaciones CORBA, si bien el grado de cumplimiento es diverso. Las divergencias entre ORBs radican en detalles que, aunque no hacen imposible aplicar en uno el mismo diseño de un programa pensado para otro, hacen cuela adaptación sea fastidiosa. Cuestiones como la colocación de librerías o las diferentes formas de implementar la gestión de la concurrencia, hacen difícil la portabilidad del código y obligan al programador a reciclarse cuando quiere cambiar de ORB. Además, donde el estándar no concreta, las implementaciones pueden variar entre sí, lo que da lugar a molestas incompatibilidades que complican la vida al usuario. Los ORBs. Los ORBs, Object Request Brokers, núcleo de cualquier implementación CORBA, transmiten los mensajes que se intercambian cliente y servidor, para lo que se ocupan de:

1. Canalizar las comunicaciones entre los objetos locales y los remotos.



2. Empaquetar los parámetros que el cliente pasa al método remoto y el resultado que el método devuelve al cliente.

3. Localizar al objeto remoto a partir de una referencia.

El IDL IDL (Interface Definition Language) es un lenguaje de programación pensado exclusivamente para especificar los interfaces de las clases cuyas instancias queremos hacer públicas a objetos remotos que las usaran como clientes. La necesidad de un IDL viene dada por la independencia de CORBA respecto a la arquitectura y al lenguaje de programación. Distintos lenguajes soportan diferentes tipos de datos y tienen distintas formas de especificar clases. Incluso limitándonos aun lenguaje, la ordenación y el tamaño de un tipo de datos determinado no tiene porqué ser el mismo entre arquitecturas diferentes (por ejemplo, no es lo mismo un entero en un 386 con MS-DOS que en un UltraSparc con Solaris 7). IDL pone de acuerdo a distintos lenguajes en el formato y tamaño de sus especificaciones. El compilador de IDL transforma una especificación neutral para la plataforma y el lenguaje en otra que puedan entender dicho lenguaje y plataforma. El IIOP: Interoperabilidad entre ORB. CORBA es neutral respecto al protocolo de red utilizado para comunicar cliente y servidor. Para ello especifica el GIOP (General Inter ORB Protocol) que define a muy alto nivel la comunicación entre ORBs diferentes. Para redes de tipo TCP/IP se emplea una instancia de GIOP conocida como IIOP (Internet InterORB Protocol). Gracias a IIOP, es posible que objetos que emplean ORBs de fabricantes distintos puedan interoperar en redes como Internet. Gestión de la concurrencia. El comportamiento de un objeto situado en un servidor cuando dos o más clientes quieren hacer uso de sus servicios viene determinado por la política de gestión de la concurrencia que se haya programado en el ORB. CORBA incluye varias políticas que definen cuándo y cómo activa el ORB los objetos en el servidor para atender peticiones. Desafortunadamente, si se utiliza un mismo proceso para atender todas las peticiones que se hagan, o si se crea uno nuevo para atender cada una de las



peticiones es algo de lo que se va a tener que ocupar el programador, aunque algunos ORBs pueden asistir al programador en esa tarea. Servicio de nombrado. En CORBA hay varias formas de que un objeto situado en una máquina pueda referirse a otro remoto. IOR Número de gran longitud, que permite identificar de manera única y global a un objeto que ofrece sus servicios en un entorno distribuido. Lo genera automáticamente el ORB de forma que no pueda haber dos objetos con el mismo identificador por muy grande que sea la red. Usa para ello datos aleatorios, y otros escogidos a partir del computador sobre el que se ejecuta, la implementación del ORB, etc. Asignación de Nombres Dándole previamente un nombre al objeto, otro que quiera usar sus servicios podría emplear una notación tipo URL como iiop://nombre_host:puerto/nombre_objeto6. Así, si en máquina.inf.uniovi.es, existe el objeto dns, cualquiera que quiera acceder a dns sólo tiene que solicitar a su ORB una referencia a iiop://máquina.inf.uniovi.es/dns. Esta forma de nombrado es más fácil de recordar para la mayor parte de los seres humanos, aunque seremos nosotros los que tendremos que asegurarnos de su unicidad (aunque solo dentro de los límites de la máquina en la que se registre). Ambos sistemas de nombrado tienen el inconveniente de no ser transparentes en cuanto a la localización ya que, si movemos los objetos servidores, tendremos que adecuar a los objetos clientes para que los busquen en otro lado. Servicios adicionales de CORBA. Las implementaciones CORBA pueden ofrecer servicios adicionales voluntariamente (aunque no es necesario para ser certificado de compatibilidad CORBA por el OMG). Un ejemplo de estas facilidades es el sistema de suscripción de eventos, que permite que un objeto se suscriba a eventos generados por otro. El propósito de este servicio es el de mejorar la eficiencia disminuyendo el tráfico de la red. Por ejemplo, si hay varios objetos clientes esperando a que suceda algo en el objeto que presta servicio en el servidor, en vez de hacer poleo (polling), podrían solicitarle a este que les envíe una notificación cuando eso ocurra. Seguridad.



El estándar CORBA no se preocupa de la seguridad implementada en el sistema distribuido. Si por alguna razón se requiere restringir el uso de los recursos controlados por un determinado objeto, debe hacerlo el usuario. Integración de CORBA en Java CORBA, como especificación, es absolutamente independiente de la plataforma o el lenguaje, por lo que no han tardado en aparecer implementaciones de CORBA con soporte de Java (como VisiBroker ó como ORBacus por ejemplo). Esto se traduce principalmente en un traductor IDL, tipos básicos de Java y en un framework, que permiten acceder a la librería de servicios del ORB. Algunas de estas librerías son nativas, en vez de emplear implementaciones 100% Java para soportar Java, lo que puede dar algunos problemas de portabilidad o imposibilitar la ejecución de aplicaciones dentro de los navegadores con soporte para Java. Pero la integración Java-CORBA incluirá interesantes mejoras cuando OMG introduzca la nueva versión del estándar, CORBA 3.0. De hecho, parte de la mejora en esta integración es justo lo inverso de lo que había hasta ahora: una correspondencia java-idl. Al contrario que el compilador de IDL a Java, que convierte una especificación en formato neutral en clases que puede usar un compilador java, el traductor java-idl extraerá la interfaz de las clases java y las traducirá a una especificación IDL, por lo que será más fácil emplear clases java por programas que usen CORBA y que estén implementados en otros lenguajes. Limitaciones e Inconvenientes CORBA. 1. El sistema no es transparente al programador. Las diferencias para el

programador que quiera usar un determinado objeto con respecto a las de emplear uno local, se reducen a la inicialización del mismo. En vez de inicializarlo normalmente, hay que pedir al ORB (vía IOR o usando un nombre más inteligible), una referencia al objeto remoto y luego convertirlo al tipo de objeto a manejar.

2. Los objetos remotos se pueden usar por referencia, pero no por valor. Así,

cuando se haga uso de los métodos de un objeto remoto (al que se accede por referencia), solo se le pueden pasar como parámetros (y el método solo podrá devolver como resultado) tipos de datos contemplados en el IDL. Afortunadamente, este problema queda resuelto con CORBA 3, que sí soporta el paso de parámetros por valor.



3. Múltiples implementaciones de CORBA dan lugar a múltiples incompatibilidades. El estándar CORBA define a alto nivel qué funciones debe proporcionar un ORB y cómo han de interoperar estos entre sí, lo que garantiza cierto grado de compatibilidad, pero el cómo se ofrezca esa funcionalidad al programador es algo que está al libre albedrío del fabricante del ORB. Es más, parte de la funcionalidad del estándar CORBA no es de obligado cumplimiento por parte de las compañías fabricantes para poder anunciarse como CORBA-compliant. En estas condiciones es muy difícil pensar que un programa que haya sido programado pensando en un ORB concreto, pueda funcionar bien con una simple recompilación.

4. El estándar CORBA está poco preparado para usarse en entornos

embebidos (electrónica de consumo, asistentes digitales) o que requieran soporte de tiempo real. Para el primer caso, se diseñó en CORBA 3 un subconjunto llamado Minumum CORBA que, al ser más ligero, encaja mejor en los sistemas embebidos, donde el control del consumo de recursos es vital. Para solucionar el segundo problema, CORBA 3introducirá Real -Time CORBA, que introducirá modelos de prioridad para conseguir un comportamiento predecible de los programas que lo usen.

4.1.5 RMI RMI (Remote Method Invocation) es parte de la librería de clases de Java que permite la creación de sistemas distribuidos en Java. Características particulares de RMI. Al contrario que otras tecnologías de sistemas distribuidos, RMI no busca la colaboración de objetos de distintas plataformas, programados indiferentes lenguajes, Java se encarga de solucionarlos problemas de heterogeneidad. Así, su API es más sencillo y natural al no contemplar que tipos de datos (y sus tamaños) existan o no en los lenguajes en los que se implementan cliente y servidor. Gestión de la concurrencia. La gestión de la concurrencia en RMI, como muchas de las cosas que lo diferencian de CORBA es extraordinariamente sencilla e inflexible. Para cada cliente que trate de acceder a un objeto remoto, el servidor creará un nuevo hilo que se encargará de darle servicio. Si varios hilos del mismo cliente realizan distintas peticiones al servidor, compartirán un mismo hilo en el servidor. Servicio de nombrado. El nombrado de objetos es sencillo pero dependiente del computador donde resida el objeto servidor en cada instante. Aún así, está pensado de tal forma



que difícilmente su uso creará problemas al usuario, ya que emplea la notación URL del tipo rmi://nombre_host:puerto/nombre_objeto. Un programa que acompaña a las implementaciones Java es el RMIRegistry. El registro rmi (rmiregistry) comunica objetos clientes con servidores. Conceptualmente, cuando un cliente quiere obtener una referencia a un objeto remoto, pregunta por él al rmiregistry donde resida dicho objeto. El registro lleva la cuenta de los objetos exportados que residen en esa máquina (ya que todos ellos han sido dados de alta en el registro por el programa que se haya encargado de crearlos e inicializarlos), por lo que comprueba que la solicitud del cliente puede ser atendida, y caso de ser así, devuelve la referencia esperada. El RMIRegistry puede ser ejecutado como servicio de Windows NT o como demonio en UNIX (y similares). Paso de parámetros por valor y serialización. RMI soporta que objetos clientes puedan emplear objetos remotos por valor y por referencia. El uso de un objeto remoto por referencia no es nada nuevo, cualquier objeto exportado ante el RMIRegistry se pasa automáticamente por referencia a cualquier cliente que quiera usarlo. La novedad es el paso de objetos por valor, para lo que se emplea la librería de serialización del API de Java. Para pasar un objeto por valor del servidor el cliente, debe implementar una clase abstracta que les obliga a definir cómo almacenar en un flujo de datos (como por ejemplo un archivo) los datos importantes del objeto serializable y cómo reconstruirlo a partir de esos mismos datos. Muchas de las clases del API de Java ya son serializables por lo que otras clases que las usen (por herencia o agregación) no tienen que ocuparse de serializarlas. Cuando se necesita llevar un objeto serializable de una máquina a otra (porque sea un parámetro de un método de un objeto remoto que empleamos por referencia, o porque sea el resultado que devuelve dicho método al cliente), se serializa, se lleva el flujo de una máquina a la otra, y una vez en el computador huésped, se reconstruye y se usa. La ventaja del paso por valor en un sistema distribuido radica en que se minimiza el tráfico en la red ya que, una vez recibido el objeto, todas las comunicaciones con él serán locales. Seguridad. Por defecto, RMI no incluye ninguna facilidad para restringir el uso de las clases desde clientes no autorizados, aunque el usuario siempre puede suplir parte de esta funcionalidad usando los servicios del sistema operativo, o haciendo ese



trabajo él mismo. Aún así, no se puede confiar en la seguridad de un sistema solo porque se haya autentificado al usuario al inicio de la conexión si es que el canal de comunicación no es seguro. La plataforma Java 2incluye el soporte de comunicaciones seguras en RMI usando el estándar SSL (Secure Sockets Layer). 4.1.6 DCOM/COM/COM+ COM se refiere tanto a especificación como aplicación, desarrollado por Microsoft que provee una infraestructura para integración de componentes. Soporta interoperabilidad y reutilidad de objetos distribuidos. COM define una interfaz de programación de aplicaciones (API) para permitir la creación de componentes para el uso integrando las aplicaciones personalizadas o permitir componentes diversos para interactuar. Sin embargo para interactuar, los componentes deben adherir a una estructura binaria especificada por Microsoft. Con tal de que los componentes adhieran a esta estructura binaria, los componentes escritos en lenguajes diferentes pueden interoperar. Distributed COM (DCOM) es una extensión a COM que permite interacción de componentes basados en red. Mientras los procesos de COM pueden ejecutar en la misma máquina pero la extensión de DCOM permite extender los procesos por una red en espacios direccionables diferentes. Con DCOM, componentes que operan en una variedad de plataformas pueden interactuar, con tal de que DCOM esté disponible dentro del entorno. Es mejor considerar COM y DCOM como una sola tecnología que provee un rango de servicios a la interacción del componente, de servicios que promueven la integración del componente en una sola plataforma, a la interacción del componente por las redes heterogéneas. De hecho, se unen COM y sus extensiones de DCOM en un solo tiempo de ejecución. Este solo tiempo de ejecución proporciona cercanía y acceso remoto. MTS extiende las capacidades del COM con servicios como transacción y seguridad. COM+ es la evolución de COM. COM+ integra servicios de MTS y mensaje en cola en COM y hace COM que se programa más fácil a través de una integración más íntima con lenguajes de Microsoft como Visual Basic, Visual C++ y J++. 4.1.7 Interoperabilidad de Plataformas Afortunadamente para los usuarios que necesitan crear un sistema distribuido, existen modos de poder utilizar un objeto cliente implementado según un



estándar de sistemas distribuidos, desde otro diferente. Un ejemplo es la integración entre COM y CORBA desarrollada por IONA Technologies. Asimismo, OMG y Sun están trabajando para hacer que CORBA y RMI sean interoperables de manera transparente al programador y al usuario. Además, la plataforma Java 2 viene con soporte de RMI y de CORBA simultáneamente. El rendimiento es menor, lo que se agrava especialmente si la comunicación entre dos objetos implementados en estándares distintos es intensa. Además, la interoperabilidad suele suponer tener que conformarse con el mínimo común denominador de las facilidades que incorporen los sistemas originales.

4.2. Desarrollo de un Sistema Distribuido

4.2.1 Caso de Estudio: IIOP.NET y un Servicio de Chat Introducción EJB (Enterprise Java Beans) es una tecnología establecida para implementar componentes de software en una plataforma Java. EBJ puede usarse para crear sistemas de objetos distribuidos y confía en Java RMI/IIOP para intercambiar los mensajes; EJB también puede exponerse como servicios Web. En la visión de Microsoft, la próxima generación de sistemas distribuidos es comunicar con Web Services. Web Services son mayores cuando integran sistemas heterogéneos flojamente acoplados, pero tiene sus limitaciones también: no tienen el apoyo por las referencias del objeto remotas. En la práctica, son sin estado y más cercano a una llamada del método remota que a un sistema del objeto distribuido. J2EE y .NET son dos mundos similares pero desarticulados: pueden actualmente interactuar sólo usando juntos Web Services. Ambas plataformas ofrecen grandes mecanismos por construir los sistemas de objeto distribuidos herméticamente acoplados: Remoting de .NET y RMI de Java, pero ambos confían en estándares incompatibles. Aunque, Remoting .NET es configurable: un formateador diferente para la serialización y deserialización de los objetos junto con un canal de transporte diferente puede proporcionarse fácilmente.



Vista general de un canal .NET

Es posible acceder a un componente .NET desde un Java mediante un canal remoto personalizado llamado IIOP.NET. Pero también en la dirección opuesta: cómo tener acceso a un Java EJB el servicio de un cliente de .NET también utilizando el canal remoto IIOP.NET, ninguna modificación en el sitio de EJB se requiere para este propósito. Esto último es el caso de estudio de esta sección. Alrededor de IIOP.NET IIOP.NET es un canal remoto de .NET basado en el protocolo de IIOP. IIOP es el protocolo definido por el estándar de CORBA, el mismo usado por Java RMI/IIOP. IIOP.NET actúa como un ORB (agente para peticiones de objetos de CORBA); él convierte el tipo de sistema .NET al tipo de sistema CORBA y viceversa, haciendo los objetos definidos en su aplicación accesible a otros ORBs. RMI/IIOP implementa un subconjunto de las funcionalidades del ORB (debido a algunas limitaciones en sistemas tipo Java) y proporciona las mismas características como IIOP.NET para el Plataforma de J2EE.

Vista general de un el sistema de objeto distribuido

Usando IIOP.NET casi es tan simple como usando el remoto .NET predefinido. La aplicación siguiente le mostrará cómo tener acceso a un Java EJB desde un servicio cliente de .NET, usando IIOP.NET. Se selecciono IIOP.NET porque es libre, actualmente disponible y tiene una herramienta para generar el IDL automáticamente.



Práctica: Un servicio de conversación (chat) usando IIOP.NET Escenario Para mostrar cómo tener acceso a un EJB desde .NET, usaremos un simple ejemplo pero no trivial: un servicio de charla. El servicio es un EJB que permite usuarios para registrar y eliminar un oyente por recibir los mensajes sometidos en la sala de conversación; el EJB gestiona la lista de clientes y despacha los mensajes a todos los clientes registrados. En seguida las interfaces y clases de Java se usan para comunicar con el servicio; ellas deben ser convertidas a los archivos de IDL para permitir el acceso de otros clientes de CORBA. Un Mensaje contiene el nombre del remitente y su mensaje. El mensaje es mapeado a un tipo de valor de CORBA, es decir un objeto que es serializado y enviado a una máquina remota, en lugar de ser remotamente accedido. public class Message implements Serializable { private String m_originator; private String m_msg; public Message() { ... } public Message(String msg, String originator) { ... } public String getMsg() { ... } public String getOriginator() { ... } } La interfaz MessageListener debe ser implementada por todos clientes de la sala de conversación que desean recibir los mensajes de conversación. La interfaz extiende java.rmi.Remote debido a que los clientes son remotos y la comunicación se realizará con RMI/IIOP. public interface MessageListener extends java.rmi.Remote { /* notify the listener, that a new message has arrived. */ public void notifyMessage(Message msg) throws java.rmi.RemoteException; } Finalmente, la interfaz de la sala de conversación define las características soportado por el bean sin estado, que permite enviar los mensajes y administrar la lista de oyentes. La interfaz de inicio contiene sólo la llamada para crear un nuevo componente y no se muestra aquí. public interface Chatroom extends EJBObject { /* post message in chat-room */ public void broadCast(Message msg) throws java.rmi.RemoteException;



/* register a client, interested in chatroom messages */ public void registerMe(MessageListener listener, String forUser) throws java.rmi.RemoteException, AlreadyRegisteredException; /* unregister the client with the name userName. */ public void unregisterMe(String userName) throws java.rmi.RemoteException, NotRegisteredException; } La sala de conversación funciona según el diagrama de secuencia de UML siguiente:

Diagrama de secuencia de la sala de conversación

Paso 1: Instale IIOP.NET Construir y ejecutar el ejercicio, necesita un Java SDK por lo menos 1.3, un servidor de la aplicación (suponemos IBM WebSphere 5.0), el Framework .NET SDK 1.0 o 1.1, el Microsoft J# SDK versión 1.0 o 1.1 e IIOP.NET (por lo menos 1.3.1). El IIOP.NET contiene los directorios:



• IIOPChannel contiene el código del canal • CLSToIDLGenerator contiene un generador para crear los archivos de

definición IDL desde un assembly de .NET. • IDLToCLSCompiler contiene un generador para crear archivos CLS

(.Asamblies multi-módulos de .NET) desde las definiciones de IDL. • Contienen ejemplos y tutoriales. Antes de construir IIOP.NET, copie los archivos lib\ir.idl y lib\orb.idl del directorio Java SDK en el directorio IDL IIOP.NET y establezca el entorno de variable WAS_HOME para el directorio de aplicación de servidor de WebSphere. Compile todo mediante nmake. Paso 2: Implementación del EJB Dado las definiciones anteriores, la aplicación del EJB realmente es clara . Creamos la clase Message, las interfaces MessageListener y Chatroom conteniendo las definiciones mostradas anteriormente. Para la implementación del bean, se proporcionan tres archivos: la interfaz de inicio del bean en la interfaz ChatroomHome, el propio bean en ChatroomBean, y la implementación clase administración en ChatroomServer. La administración es realizada en una clase separada única debido a que esta debe ser la misma para cada bean (considerando que cada cliente consigue una instancia del bean diferente) y el acceso a las estructuras deben sincronizarse. El bean remite las llamadas a la clase de administración del cliente: public void registerMe(MessageListener listener, String forUser) throws AlreadyRegisteredException { ChatroomServer server = ChatroomServer.getSingleton(); server.addClient(listener, forUser); } public void unregisterMe(String userName) throws NotRegisteredException { ChatroomServer server = ChatroomServer.getSingleton(); server.removeClient(userName); } public void broadCast(Message msg) { ChatroomServer server = ChatroomServer.getSingleton(); MessageListener[] listeners = server.getClients(); for (int i = 0; i < listeners.length; i++) { try {



listeners[i].notifyMessage(msg); } catch (Exception e) { System.err.println("error sending msg: " + e); System.err.println("--> removing listener"); server.removeListener(listeners[i]); } } } Difundiendo el mensaje se hace en el propio bean de Java para minimizar el gasto de tiempo en la sala de conversación (durante la cual la sala de conversación se bloquea). Enviando los mensajes puede tomar un tiempo largo, en particular cuando un cliente no esta disponible. La solución ideal aquí sería un CORBA unidireccional llamada asincrónica, pero esto no es posible en EJB; la manera propuesta de llevando a cabo esto requiere usando el Servicio de Java Mensaje (JMS); pero, por causa de simplicidad, se permitirá cada bean mandar los mensajes. La aplicación de ChatroomClient consiste en una instancia única que se ocupa de la lista de clientes: public class ChatroomServer { private static ChatroomServer s_chatroomServer = new ChatroomServer(); private Hashtable m_clients = new Hashtable(); private ChatroomServer() { super(); } public static ChatroomServer getSingleton() { return s_chatroomServer; } public synchronized void addClient(MessageListener ml, String forUser) throws AlreadyRegisteredException { if (!m_clients.containsKey(forUser)) { m_clients.put(forUser, ml); } else { throw new AlreadyRegisteredException( "a message listener is already registered for user: " + forUser); } } public synchronized void removeClient(String forUser) throws NotRegisteredException { if (m_clients.containsKey(forUser)) { m_clients.remove(forUser); } else { throw new NotRegisteredException( "no message listener registered for the user: " + forUser);



} } public synchronized void removeListener(MessageListener listener) { m_clients.values().remove(listener); } public synchronized MessageListener[] getClients() { MessageListener[] result = new MessageListener[m_clients.size()]; result = (MessageListener[])(m_clients.values().toArray(result)); return result; } } Note que el método de implementación getClients () devuelve una copia de la lista del oyente para evitar los problemas de la sincronización. Paso 3: Generación de los archivos de IDL Una vez que el servicio es implementado, el próximo paso es la generación de archivos de IDL que describen la interfaz de servicio mediante el modelo del CORBA. Cada servidor de la aplicación proporciona su propia manera de generar el IDL, porque cada servidor de la aplicación funciona con versiones diferentes de especificaciones del EJB que a su vez tienen las interfaces diferentes. Refiérase a la documentación de servidor de aplicación para el procedimiento exacto para generar los archivos de IDL. El paso 4: Generación de los módulos CLS desde los archivos de IDL De los archivos de IDL, la herramienta IDLToCLSCompiler genera un assembly multimódulo CLS que contiene las clases e interfaces requeridas para acceder al servicio basado en EJB. ¿Por qué el generador crea un netmodule en lugar de un stub de C#? Bien, hay unas razones, pero los más importantes son la simplicidad y portabilidad. Primero, los netmodules son bastante fáciles de generar usando la interfaz de reflexión emitada de .NET; el código fuente generador requeriría algún algoritmo pretty-printing. Segundo, los netmodules contienen las definiciones en la forma CLS, lo cual se entiende por todos los lenguajes conforme a .NET, así no le importa si su código está en C# o Visual Basic. Invoque el generador que especifica el directorio de salida (- o) y los archivos idl para usar.



IDLToCLSCompiler.exe -o ..\bin chatroom ch\elca\iiop\demo\ejbChatroom\Chatroom.idl ch\elca\iiop\demo\ejbChatroom\ChatroomHome.idl El generador le recordará que debe proporcionar la implementación para algunas clases: éstas son las clases que implementa el valuetypes del CORBA; en .NET estas clases están definidas con el atributo Serializable (no confunda el valuetypes de CORBA con clase de valuetype de .NET). El contenido de estas clases se duplica al sistema designado, así los métodos que proporciona también deben estar disponibles en el sistema remoto. Debido a que el IDL no contiene ningún código, tiene que proporcionar este código (este esfuerzo normalmente se limita al constructor de la clase). En nuestro caso, las clases a ser implementadas son la NotRegisteredException, AlreadyRegisteredException y Message definido por nuestro servicio; y Throwable, _Exception, CreateException, RemoveException (definido por Java, RMI o el EJB). Algún EJBs puede requerir la definición de adicional clases. Nuestra aplicación de esas clases esta en ExceptionImpl.cs y MessageImpl.cs. using System; namespace ch.elca.iiop.demo.ejbChatroom { ///<SUMMARY> /// Implementation of the CORBA value type Message /// </SUMMARY> [Serializable] public class MessageImpl : Message { public MessageImpl() { } public MessageImpl(string originator, string msg) { m_originator = originator; m_msg = msg; } public override string fromUser { get { return m_originator; } } public override string msg { get { return m_msg; } } } } Tenga presente que IIOP.NET buscará para la clase ClassImpl como implementación para la clase valuetype de CORBA. Así, las clases para proveer son nombradas NotRegisteredExceptionImpl, AlreadyRegisteredExceptionImpl, y así sucesivamente.



Paso 5: Implementación del cliente en C# El cliente proporciona una interfaz del usuario para coleccionar los mensajes del usuario, invoque el servicio y despliegue la información enviada por el servicio. Un simple GUI es utilizado; independientemente de la interfaz del usuario, hay unas cosas importantes para hacer. Primero, registre el canal IIOP.NET, conecte al EJB y consigue un caso del servicio. // register IIOP.NET channel IiopChannel channel = new IiopChannel(callbackPort); ChannelServices.RegisterChannel(channel); // get the naming service RmiIiopInit init = new RmiIiopInit(ejbNameServiceHost, ejbNameServicePort); NamingContext nameService = (NamingContext)init.GetService( "NameServiceServerRoot"); NameComponent[] name = new NameComponent[] { new NameComponent("demo", ""), new NameComponent("chatroomHome", "") }; // get the chatroom home interface ChatroomHome home = (ChatroomHome) nameService.resolve(name); Chatroom chatroom = home.create(); El ejbNameServiceHost y ejbNameServicePort, y el nombre del componente dependen sobre el servidor de la aplicación y la forma del servicio es configurada y registrada allí. Para poder recibir los mensajes, el cliente debe registrar a un oyente, es decir un objeto remoto que implementa la interfaz MessageListener. m_listener = new MessageListenerImpl(m_usernameTextbox.Text, this); m_chatroom.registerMe(m_listener, m_listener.userName); Ahora la sala de conversación está lista ser usado. Enviando un mensaje al cuarto es simple: MessageImpl msg = new MessageImpl(m_listener.userName, m_messageTextbox.Text); try { m_chatroom.broadCast(msg); } catch (Exception ex) { Console.WriteLine("exception encountered, while broadcasting: " + ex);



MessageBox.Show("an exception occured, while broadcasting!"); } Este código realiza una invocación del método sincrónico, es decir espera para el servidor para completar la difusión y retorno. Sin embargo, esto no es obligatorio, como los regresos de llamada no resultan y el cliente no tiene la necesidad de sincronizar con el servidor. Así, una invocación asincrónica también es posible: delegue BroadCastDelegate nulo (mensaje del Mensaje); delegate void BroadCastDelegate(Message msg); MessageImpl msg = new MessageImpl(m_listener.userName, m_messageTextbox.Text); try { BroadCastDelegate bcd = new BroadCastDelegate(m_chatroom.broadCast); // async call to broadcast bcd.BeginInvoke(msg, null, null); // do not wait for response } catch (Exception ex) { Console.WriteLine("exception encountered, while broadcasting: " + ex); MessageBox.Show("an exception occured, while broadcasting!"); } El método oyente notifyMessage() se llamará por los servicios EJB siempre que un nuevo mensaje esté disponible. Este método lleva a cabo el proceso de llamadas entrantes por el cliente.

Paso 6: Ejecución de la aplicación En el lado del servidor, el Makefile para el servicio EJB Websphere automáticamente registra al servidor de la aplicación, para que necesite arrancar el servidor (en caso de que ya no está corriendo). En el lado del cliente, lance la aplicación; entonces establezca su nombre, conecte al servidor y podrá enviar y recibir los mensajes.



La interfaz de usuario del cliente .NET

Acceso de un EJB desde .NET usando IIOP.NET 4.2 Desarrollo de un Sistema Distribuido Actividad 4.2 Desarrollo de un Proyecto Final Utilizar la técnica de Aprendizaje Orientado a Proyectos, descrito en el rubro de Panorama General del tema 3 de tecnologías de desarrollo, para desarrollar un sencillo proyecto de sistema distribuido, propuesto por ustedes.

Rúbrica para evaluación del proceso de AOP


Estándar

Puntos de Atributo

Obtenidos

(10-9) (8.5 -7) (6.5-0)

Colaboración

El producto final del equipo ha

sido compartido con todo el

equipo y representa algo que habría sido

Trabajo en equipo con asignación de roles y todos se

esfuerzan en llevar a cabo sus

responsabilidades.

La presentación es el resultado del esfuerzo de un

grupo, pero solamente han

contribuido



posible llevar a cabo

individualmente.

algunos miembros del

grupo. (10-9) (8.5 -7) (6.5-0)

Contenido

El proyecto presenta metas

claras relacionadas

con un tópico o asunto

importante. El proyecto es útil

más allá del curso.

El proyecto presenta

información de una manera

precisa y organizada. El proyecto es útil dentro del curso.

El proyecto se presenta de

cualquier manera, de

forma apresurada o todavía sin

finalizar. Presenta

errores o malas comprensiones.


5. Computación Móvil

Actividades Computación Móvil Revisar el Material de Apoyo 5 y realizar las tareas siguientes: 1. Realizar un mapa mental por cada uno de los rubros siguientes sobre computación móvil: 1.1 Antecedentes 1.2 Paradigmas 1.3 Lenguajes y Ambientes de Programación 2. Realizar el ejercicio sobre Aplicaciones Móviles. Nota: Si no cuenta con software para mapas mentales, puede realizarlos a mano y enviar escaneados.

5.1. Antecedentes en Computación Móvil.

5.1.1. Introducción a la comunicación inalámbrica.



El simple hecho de ser seres humanos nos hace desenvolvernos en medios donde tenemos que estar comunicados. Por eso la gran importancia de la transmisión y la recepción de información, y en la época actual donde los computadores hacen parte de la cotidianidad, es necesario establecer medios de comunicación eficaces entre ellos. Los sistemas distribuidos utilizan redes de área local, redes de área extendida e interredes para comunicarse. Los cambios en las necesidades de los usuarios han producido la irrupción de las redes inalámbricas. La tecnología inalámbrica es una de las más prometedoras y discutidas en esta década para poder comunicar computadoras. La conexión de computadoras mediante Ondas de Radio o Luz Infrarroja, actualmente está siendo ampliamente investigada. Las Redes Inalámbricas facilitan la operación en lugares donde la computadora no puede permanecer en un solo lugar, como en almacenes o en oficinas que se encuentren en varios pisos. Pero la realidad es que esta tecnología está todavía en pañales y se deben de resolver varios obstáculos técnicos y de regulación antes de que las redes inalámbricas sean utilizadas de una manera general en los sistemas de cómputo de la actualidad. No se espera que las redes inalámbricas lleguen a remplazar a las redes cableadas. Estas ofrecen velocidades de transmisión mayores que las logradas con la tecnología inalámbrica. Mientras que las redes inalámbricas actuales ofrecen velocidades de 2 Mbps, las redes cableadas ofrecen velocidades de 10 Mbps y se espera que alcancen velocidades de hasta 100 Mbps. Los sistemas de Cable de Fibra Óptica logran velocidades aún mayores, y pensando futuristamente se espera que las redes inalámbricas alcancen velocidades de solo 10 Mbps. Sin embargo se pueden mezclar las redes cableadas y las inalámbricas, y de esta manera generar una "Red Híbrida" y poder resolver los últimos metros hacia la estación. Se puede considerar que el sistema cableado sea la parte principal y la inalámbrica le proporcione movilidad adicional al equipo y el operador se pueda desplazar con facilidad dentro de un almacén o una oficina.

5.1.2 Conceptos de Comunicación Inalámbrica. 5.1.2.1. Propagación de señal. Las comunicaciones inalámbricas pueden, en un principio, desarrollarse en medios que soporten ondas sonoras, de radio o luminosas. Sin embargo nos concentraremos en la propagación de las ondas electromagnéticas de radio dentro del rango de frecuencias que va desde algunos cientos de MHz a unos pocos GHz.



El espectro electromagnético, el recurso natural de las comunicaciones por el espacio, se encuentra en su punto máximo de congestionamiento. Esto constituye evidencia de que a pesar del uso extenso de medios de transmisión como la fibra óptica; la transmisión de información por el aire continúa siendo el mecanismo más económico y versátil de cuantos existen para el transporte de información. Las ondas electromagnéticas viajan desde una antena transmisora hasta otra receptora. EL flujo de información que estamos proponiendo se realizara a través de dos dispositivos emisores – receptores (antenas) que obtendrán la señal análoga del medio físico en que se encuentren, posteriormente esta señal ha de ser sometida a un proceso de converso análogo – digital o viceversa según sea el caso, finalmente con la información digital se hace su captura a través del puerto paralelo y de esta manera los computadoras pueden trabajar con dicha información. 5.1.2.2 Desvanecimiento de la Señales El desvanecimiento de la señal es la perdida de información que se da por el medio de propagación de la información. En general, toda señal enviada esta sujeta a las variaciones naturales de las condiciones atmosféricas debidas a efectos climatológicos de origen local y también extraterrestre, como el caso de las manchas solares y la radiación cósmica las cuales ejercen un efecto muy marcado sobre la ionosfera. Sin embargo el estudio sistemático de los mecanismos y las condiciones que los favorecen, ha permitido el uso confiable de la propagación de ondas de radio en el espacio para comunicaciones de largo alcance. A pesar de las muchas variables y factores que tienden a degradar la calidad de las comunicaciones obtenidas, los ingenieros de comunicaciones han desarrollado técnicas tales como la diversidad espacial y de frecuencia, que mejoran considerablemente la confiabilidad y calidad de las transmisiones por ondas de radio. 5.1.2.3. Ancho de Banda El Ancho de Banda, es el espectro de frecuencia que soporta un medio de transmisión y su unidad de medida es el Hertz. El ancho de Banda es la región comprendida entre las frecuencias mínimas y máximas que puede transmitir el medio.



El ancho de banda es un componente muy importante en las comunicaciones de datos, ya que la capacidad (medida en bit por segundos) de un canal de comunicaciones, depende del ancho de banda del camino. Si en el canal de comunicaciones se incrementa el ancho de banda de 3 khz (300-3300 Hz) a 23 Khz, podría transmitirse todas las características de la voz. Esto también es válido para la transmisión de datos. Se consigue una tasa de transmisión de datos mejor cuando mayor sea el ancho de banda. El ancho de banda total de un sistema de una red es la medida de la productividad (throughput), del volumen del tráfico que puede ser transferido a través de la red en un intervalo de tiempo dado. En muchas tecnologías de red local, como Ethernet, se utiliza toda la capacidad de transmisión de la red en cada transmisión y el ancho de banda es igual a la tasa de transferencia de datos (es la velocidad a la cual se pueden transferir datos entre dos computadoras en una red). En cambio, la mayoría de las redes de área extensa los mensajes pueden ser transmitidos simultáneamente sobre varios canales diferentes, de modo que el ancho de banda no guarda una relación directa con la tasa de transferencia. Por lo que el ancho de banda dependerá esencialmente de la tecnología de la red utilizada. El ancho de banda se suele asimilar al diámetro de una tubería que sirviese para canalizar el flujo de datos. Pero esa simplificación es excesiva. De entrada el ancho de banda es la capacidad de una línea para transmitir información. Algunos sistemas de comunicación no utilizan la forma analógica (CA) de transmisión. Una forma más sencilla la constituye la transmisión por corriente continua (CC). Las señales CC se parecen a las ondas cuadradas simétricas que sólo pueden tomar los valores discretos de 1 y 0. Sin embargo, el transmisor CC no emplea la forma de onda oscilante, sino la existencia o no de pulsaciones de energía eléctrica. Además la señal CC se transmite tal como es, sin superponerla con ninguna otra señal o frecuencia. Si bien, tanto las señales CC como las CA se pueden emplear para transmitir flujos de información digital, el modo CA se utiliza para transmisión de larga distancia.



La Red Telefónica está diseñada para transmitir la voz, que es una señal con un ancho de banda pequeño. Para obtener suficiente fidelidad en la voz, se requiere un espectro de frecuencia de 300 Hz a 3,300 Hz. Este espectro de frecuencia de los circuitos limita el número de bits por segundo, alcanzable. Los factores que limitan la capacidad de transmisión son el ancho de banda, la potencia de la señal y el ruido en el conductor. La Tasa de Transferencia define la capacidad de bits trasmitidos por segundo, emite en BPS (Bits por Segundo). Es directamente proporcional al ancho de banda.

Modos de Transmisión El modo Banda Base utiliza todo el ancho de banda, por tanto en un instante dado sólo puede transmitir una señal. En este modo de transmisión, la señal no es modulada, no es adecuada para la transmisión a largas distancias, ni para instalaciones sometidas a nivel alto de ruidos e interferencias. El modo Banda Ancha modula la información sobre ondas portadoras analógicas, por lo que se requiere de equipos de transformación llamados Modem-Modulado/Demodulador- , es más inmune a los ruidos, pero más caro y difícil de instalar.



5.1.2.4. Modulación de señales Muchas señales de entrada no pueden ser enviadas directamente hacia el canal, como vienen del transductor. Para eso se modifica una onda portadora, cuyas propiedades se adaptan mejor al medio de comunicación en cuestión, para representar el mensaje. Aquí presentamos algunas definiciones: "La modulación es la alteración sistemática de una onda portadora de acuerdo con el mensaje (señal modulada) y puede ser también una codificación". "Las señales de banda base producidas por diferentes fuentes de información no son siempre adecuadas para la transmisión directa a través de un a canal dado. Estas señales son en ocasiones fuertemente modificadas para facilitar su transmisión." Una portadora es una señal senoidal de alta frecuencia, y uno de sus parámetros (tal como la amplitud, la frecuencia o la fase) se varía en proporción a la señal de banda base. Dependiendo del parámetro que se module, se obtiene la modulación en amplitud (AM), la modulación en frecuencia (FM), o la modulación en fase (PM).



Es interesante hacer hincapié en que muchas formas de comunicación no eléctricas también encierran un proceso de modulación, y la voz es un buen ejemplo. Cuando una persona habla, los movimientos de la boca ocurren de una manera más bien lenta, del orden de los 10 Hz, que realmente no pueden producir ondas acústicas que se propaguen. La transmisión de la voz se hace por medio de la generación de tonos portadores, de alta frecuencia, en las cuerdas vocales, tonos que son modulados por los músculos y órganos de la cavidad oral. Lo que el oído capta como voz, es una onda acústica modulada, muy similar a una onda eléctrica modulada. Razones Para Modular Existen varias razones para modular, entre ellas:

• Facilita la PROPAGACIÓN de la señal de información por cable o por el aire.



• Ordena el RADIOESPECTRO, distribuyendo canales a cada información distinta.

• Disminuye DIMENSIONES de antenas. • Optimiza el ancho de banda de cada canal • Evita INTERFERENCIA entre canales. • Protege a la Información de las degradaciones por RUIDO. • Define la CALIDAD de la información trasmitida.

Modulación para facilidad de radiación: Una radiación eficiente de energía electromagnética requiere de elementos radiadores (antenas) cuyas dimensiones físicas serán por lo menos de 1/10 de su longitud de onda. Pero muchas señales, especialmente de audio, tienen componentes de frecuencia del orden de los 100 Hz o menores, para lo cual necesitarían antenas de unos 300 km de longitud si se radiaran directamente. Utilizando la propiedad de traslación de frecuencias de la modulación, estas señales se pueden sobreponer sobre una portadora de alta frecuencia, con lo que se logra una reducción sustancial del tamaño de la antena. Por ejemplo, en la banda de radio de FM, donde las portadoras están en el intervalo de 88 a 108 MHz, las antenas no deben ser mayores de un metro.

donde ? es la longitud de onda en mts. c es la velocidad de la luz (3 x 10 8 m/s) f es la frecuencia en Hz

Modulación para reducir el ruido y la interferencia: Se ha dicho que es imposible eliminar totalmente el ruido del sistema. Y aunque es posible eliminar la interferencia, puede no ser práctico. Por fortuna, ciertos tipos de modulación tiene la útil propiedad de suprimir tanto el ruido como la interferencia. La supresión, sin embargo, ocurre a un cierto precio; generalmente requiere de un ancho de banda de transmisión mucho mayor que el de la señal original; de ahí la designación del ruido de banda ancha. Este convenio de ancho de banda para la reducción del ruido es uno de los intereses y a veces desventajosos aspectos del diseño de un sistema de comunicación. Modulación por asignación de frecuencia: El propietario de un aparato de radio o televisión puede seleccionar una de varias estaciones, aún cuando todas las estaciones estén transmitiendo material de un programa similar en el mismo medio de transmisión. Es posible seleccionar y separar cualquiera de las estaciones, dado que cada una tiene asignada una frecuencia portadora diferente. Si no fuera por la modulación, solo operaría una estación en un área dada. Dos o más estaciones que transmitan directamente en el mismo medio, sin modulación, producirán una mezcla inútil de señales interferentes.



Fuente: COFETEL

Modulación para multicanalización: A menudo se desea transmitir muchas señales en forma simultánea entre dos puntos. Las técnicas de multicanalización son formas intrínsecas de modulación, permiten la transmisión de múltiples señales sobre un canal, de tal manera que cada señal puede ser captada en el extremo receptor. Las aplicaciones de la multicanalización comprenden telemetría de datos, emisión de FM estereofónica y telefonía de larga distancia. Es muy común, por ejemplo, tener hasta 1,800 conversaciones telefónicas de ciudad a ciudad, multicanalizadas y transmitidas sobre un cable coaxial de un diámetro menor de un centímetro. Modulación para superar las limitaciones del equipo: El diseño de un sistema queda generalmente a la disponibilidad de equipo, el cual a menudo presenta inconvenientes en relación con las frecuencias involucradas. La modulación se puede usar para situar una señal en la parte del espectro de frecuencia donde las limitaciones del equipo sean mínimas o donde se encuentren más fácilmente los requisitos de diseño. Para este propósito, los dispositivos de modulación se encuentran también en los receptores, como ocurre en los transmisores.



Como Se Modula Frecuentemente se utilizan dispositivos electrónicos SEMICONDUCTORES con características no lineales (diodos, transistores, bulbos), resistencias, inductancias, capacitores y combinaciones entre ellos. Estos realizan procesos eléctricos cuyo funcionamiento es descrito de su representación matemática.

s(t) = A sen (wt + @ ) donde: A es la amplitud de la portadora (voltios) w es la frecuencia angular de la portadora (rad/seg) @ es el ángulo de fase de la portadora (rad) Tipos De Modulación Existen básicamente dos tipos de modulación:

• Modulación Analógica: Se realiza a partir de señales analógicas de información, por ejemplo la voz humana, audio y video en su forma eléctrica. Algunos ejemplos de Modulación Analógica son: AM, FM, PM.

• Modulación Digital: Se lleva a cabo a partir de señales generadas por fuentes digitales, por ejemplo una computadora. Algunos ejemplos de Modulación Digital son: ASK, FSK, PSK, QAM.

Relaciones Entre el Canal Y la Señal Depende del medio o canal, ya que hay unos mejores que otros, aunque también depende del tipo de modulación y aplicación. Los principales efectos que sufre la señal al propagarse son:

• Atenuación • Desvanecimiento • Ruido Blanco aditivo • Interferencia externa • Ruido de fase • Reflexión de señales • Refracción • Difracción • Dispersión

Relaciones Entre Modulación Y el Canal El canal influye fuertemente en la elección del tipo de modulación de un sistema de comunicaciones, principalmente debido al ruido.



El canal nos afecta negativamente en la comunicación ya que genera Distorsión, Interferencia y Atenuación. En cambio, la modulación nos da inmunidad al ruido, protección de la calidad de la información y nos ayuda a evitar la interferencia.

5.1.3. Localización en espectro de frecuencia En las siguientes tablas vemos los espectros de frecuencias que se tienen contemplados y los sistemas que utilizan cada una de ellas.

Banda Significado Rango de frecuencias Servicios VLF Very Low Frecuency 3 KHz-30 KHz Radio navegación de largo

alcance y comunicación submarina

LF Low Frecuency 30 KHz-300 KHz Navegación marítima, control de tráfico aéreo

MF Medium Frecuency 300 KHz-3 MHz Radio AM, radio marítima, buscadores autodireccionables

(RDF) HF High Frecuency 3 MHz-30 MHz Radioaficionados, comunicaciones

militares, larga distancia, aviones y barcos.

VHF Very High Frecuency 30 MHz-300 MHz Radio FM, TV, radio AM de aviones y ayuda a la navegación

aérea. UHF Ultra High Frecuency 300 MHz-3 GHz TV UHF, telefonía móvil, WLL

(Wireless Lo cal Loop), comunicaciones móviles,

comunicación microondas (a partir de 1 GHz)

SHF Super High Frecuency

3 GHz – 30 GHz Servicios por satélite y microondas, MMDS (Multichannel

Multipoint Distribution Service), LMDS (Local Multipoint

Distribution Service), Radar. EHF Extremely High

Frecuency 30 GHz en adelante Radar, satélite, LMDS

Infrarrojo 300 GHz-430 THz WPANs (Wireless Personal Area Networks)

Luz visible 430 THz-750 THz Fibras Ópticas



Esta tabla muestra las especificaciones de las normas de la IEEE en cuanto a comunicaciones inalámbricas se refiere, lo cuál está contemplado en el estándar IEEE 802.11 en sus diferentes versiones. Especificación Estatus Máxima tasa de

bits Frecuencia de operación

IEEE 802.11 Utilizado por la mayoría de fabricantes de WLANs

2 Mbps 2.4 GHz

IEEE 802.11b Especificación reciente 11 Mbps 2.4 GHz IEEE 802.11g En desarrollo 54 Mbps 5.0 GHz HiperLAN Desarrollado por ETSI 24 Mbps 5.0 GHz Bluetooh Promovido por 3Com,

Ericson, IBM, Intel Microsoft, Motorola, Nokia y Toshiba.

1 Mbps 2.4 GHz

IEEE: Institute of Electrical and Electronic Engineers ETSI: European Telecomunications Standards Institute

5.1.4. Diferencias entre sistemas alámbricos e inalámbricos.

• Los sistemas inalámbricos están reduciendo costos en cuanto al canal de transmisión.

• En cuanto a la tecnología utilizada el hardware de los sistemas inalámbricos es más costoso por el momento, aunque se piensa que en un futuro serán del mismo o similar valor.

• Con la tecnología se facilitan la operación en lugares donde la computadora no puede permanecer en un solo lugar o estemos en movimiento constante.

• Las redes cableadas ofrecen velocidades de transmisión mayores que las logradas con la tecnología inalámbrica.

• El hardware empleado para los sistemas inalámbricos es más pequeño que el que se utiliza en los sistemas alámbricos.

5.1.5. Sistemas Móviles Los avances tecnológicos en la miniaturización de dispositivos y en redes inalámbricas han llevado cada vez mas a la integración de dispositivos de computaciones pequeños y portátiles, estos dispositivos incluyen laptops, dispositivos de mano (handheld) entre los que se incluyen asistentes digitales personales (PDA), teléfonos móviles, videocámaras, cámaras digitales.



La facilidad de transporte de muchos de estos dispositivos, junto con su capacidad para conectarse adecuadamente en diferentes lugares, hacen posible los sistemas móviles. Sistemas Distribuidos: Marco conceptual y base algorítmica que sirve de base para abordar trabajos que involucran a dos o más computadoras conectados en red. En la década de los noventa surge el campo de la computación móvil, basada en los principios de los sistemas distribuidos y a partir de la necesidad de integrar, en este tipo de arquitectura de computadoras, clientes móviles. Conceptos asociados a este paradigma, actualmente un campo muy activo en investigación y desarrollo, son: Sistemas de redes móviles, acceso de información móvil, soporte para aplicaciones adaptativas, técnicas de ahorro de energía, sensibilidad respecto de la localización. Como una extensión de los sistemas distribuidos y de la computación móvil surge la computación ubicua. Examinando los requisitos impuestos al "hardware" de los dispositivos, se distinguen fundamentalmente tres:

• Miniaturización. La invisibilidad y dotar de capacidades de computación a todos dispositivos que nos rodean hacen de la miniaturización de los microprocesadores un requisito fundamental.

• Baja potencia . El desarrollo de los procesadores ha tenido siempre el objetivo de aumentar su rendimiento. Para estas aplicaciones, la necesidad de disponer de procesadores de baja potencia es prioritaria.

• Es necesario desarrollar microprocesadores que funcionen en un gran rango de voltajes y que estén provistos de mecanismos automáticos para el ahorro de energía.

• Conexión sin hilos. La interconexión de todos los elementos que constituyen un entorno perspicaz y la incorporación del paradigma de la computación móvil tienen como consecuencia la necesidad de establecer comunicaciones sin hilos. Aquí surge el desafío de desarrollar para las comunicaciones, el soporte físico, un gran ancho de banda. Este campo es muy activo en investigación y desarrollo ya que ésta tecnología permitirá el avance en otros campos en las telecomunicaciones y los sistemas de información.

5.2. Paradigmas de la computación móvil

5.2.1 Sistemas de comunicación inalámbrica. Para que esta comunicación inalámbrica entre diversos dispositivos sea posible, existen actualmente dos tipos de tecnologías: por infrarrojos y radiofrecuencia



5.2.1.1 Comunicación por radiofrecuencia (RF) La comunicación por radiofrecuencia tiene todas las cartas en la mano para ser el estándar de las comunicaciones futuras. Su principal base reside en la posibilidad de transmitir a mayor distancia, incluso a través de obstáculos entre el emisor y el receptor. Sin embargo, las ondas electromagnéticas tampoco están libres de inconvenientes, como el de las posibles interferencias con otros aparatos que emitan en el mismo rango. Esta es una cuestión que ya está siendo abordada por diversos organismos oficiales de todo el mundo con el objetivo de ampliar el espacio electromagnético y ofrecer a los fabricantes de este tipo de dispositivos otras posibilidades de frecuencia. 5.2.1.2 Comunicación por Infrarrojo (IR) A pesar de que el infrarrojo tiene mucho tiempo de vida y de la cantidad de soluciones que se comercializan basadas en esta comunicación, es muy probable que la tecnología por infrarrojos o IrDA tenga los días contados. Se basa en rayos luminosos que se mueven en el espectro infrarrojo y permite la comunicación bidireccional entre dos extremos a velocidades que oscilan entre los 9.600 bps y los 4 Mbps. Sus limitaciones se encuentran en su corto alcance y en la necesidad de mantener los dos extremos de la comunicación en línea y sin obstáculos para que sea realmente efectiva. Los sistemas de comunicación por infrarrojo utilizan muy altas frecuencias, justo abajo del espectro de la luz visible para transportar datos. Como la luz, el infrarrojo no puede penetrar objetos opacos, ya sea directamente (línea de vista) o indirectamente (tecnología difundida/reflectiva). El alto desempeño del infrarrojo directo es impráctico para usuarios móviles pero su uso es prácticamente para conectar dos redes fijas. La tecnología reflectiva no requiere línea de vista pero está limitada a cuartos individuales en zonas relativamente cercanas. 5.2.1.3 Sistemas Celulares La idea de un sistema celular consiste en un sistema basado en varios niveles de celdas: un transmisor de gran potencia (celda grande) con muchos transmisores de baja potencia (celdas pequeñas) cada una proporcionando cobertura a sólo una pequeña porción del área de servicio. A cada estación base se le asigna una porción del número total de canales disponibles en el sistema completo, y a las estaciones base cercanas se les asignan diferentes grupos de canales de forma que los canales disponibles son asignados en un número relativamente pequeño de estaciones base vecinas. A las estaciones base vecinas se les asigna diferentes grupos de canales de forma que las interferencias entre las estaciones base (y entre los usuarios móviles bajo su control) se reducen. Espaciando sistemáticamente las estaciones base y sus grupos de canales a través de un mercado, los canales disponibles se distribuyen a través de una región y pueden ser reutilizadas tantas veces como



sea necesario, siempre que la interferencia entre estaciones con el mismo canal se mantenga por debajo de unos niveles aceptables. 5.2.1.4 Comunicación Vía Satélite Los enlaces satelitales son comunicaciones por medio de microondas donde uno de los extremos de la conexión se encuentra en el espacio y el otro en la tierra, en forma de estación terrestre, que es la encargada de hacer la conexión entre el satélite y el usuario final. Un factor limitante para la comunicación microondas es que tiene que existir una línea recta entre los dos puntos pero como la tierra es esférica esta línea se ve limitada en tamaño entonces, colocando, ya sea el receptor o el transmisor, en el espacio se cubre un área más grande de superficie. Los sistemas de satélites y de microondas utilizan frecuencias que están en el rango de los MHz y GHz, usualmente utilizan diferentes frecuencias para evitar interferencias pero comparten algunas bandas de frecuencias. Elementos de un sistema satelital El siguiente gráfico muestra un diagrama sencillo de un enlace vía satélite, nótese que los términos UPLINK y DOWNLINK aparecen en la figura, el primero se refiere al enlace de la tierra al satélite y la segunda del satélite a la tierra.

Enlace Terrestre Enlace Terrestre

Estaciones Terrenas

Enlace de Subida(Uplink)

Enlace de Bajada(Downlink)

Las comunicaciones vía satélite poseen numerosas ventajas sobre las comunicaciones terrestres, la siguiente es una lista de algunas de estas ventajas:



• El costo de un satélite es independiente a la distancia que valla a cubrir. • La comunicación entre dos estaciones terrestres no necesita de un gran

número de repetidoras puesto que solo se utiliza un satélite. • Las poblaciones pueden ser cubiertas con una sola señal de satélite, sin

tener que preocuparse en gran medida del problema de los obstáculos. • Grandes cantidades de ancho de bandas están disponibles en los

circuitos satelitales generando mayores velocidades en la transmisión de voz, data y vídeo sin hacer uso de un costoso enlace telefónico.

Estas ventajas poseen sus contrapartes, alguna de ellas son:

• El retardo entre el UPLINK y el DOWNLINK esta alrededor de un cuarto de segundo, o de medio segundo para una señal de eco.

• La absorción por la lluvia es proporcional a la frecuencia de la onda • Conexiones satelitales multiplexadas imponen un retardo que afectan las

comunicaciones de voz, por lo cual son generalmente evitadas.

5.3. Lenguajes y Ambientes de Programación de Computación Móvil

5.3.1 Estándares y tecnologías de comunicación inalámbrica 5.3.1.1 Servicios de telecomunicaciones inalámbricas y terrestres En muy poco tiempo la información que sea consultada por una computadora personal se podrá hacer con un teléfono celular u algún otro dispositivo portátil. La globalización de las comunicaciones inalámbricas ha permitido el desarrollo de nuevos estándares y productos que muy pronto brindarán cambios en nuestras actividades. Los estándares inalámbricos tales como IEEE 802.11, IEEE 802.15, Bluetooth , HiperLAN/2, HomeRF en combinación con otras tecnologías no tan nuevas como la telefonía celular aunado con nuevos protocolos como el WAP permitirán la interconexión de las redes actuales e Internet a dispositivos móviles como teléfonos celulares, PDAs , radiolocalizadores (pagers) de dos vías y otros dispositivos portátiles. Estas tecnologías inalámbricas utilizan técnicas avanzadas de modulación que permiten un gran nivel de seguridad así como resistencia a la interferencia de dispositivos electrónicos y a otros usuarios. Además, la mayoría de los usuarios podrán compartir una banda de frecuencia sin interferencia. Más aún, estas nuevas tecnologías utilizan bandas de frecuencias sin licencia, que permiten el uso libre para el uso de la frecuencia.



Algunos de los servicios de telecomunicaciones terrestre e inalámbrica son MMDS, LMDS, WLL, GSM, IS-54, CDMA. 5.3.1.2. Fijos (MMDS, LMDS, WLL) Otras tecnologías WAN/MAN que permiten el acceso a Internet a altas velocidades son MMDS, LMDS, WLL, enlaces de microondas terrestres, vía láser infrarrojo y comunicaciones vía satélite. Estándar MMDS y LMDS Con MMDS es posible la provisión de Internet a altas velocidades en el rango de decenas de Mbps a distancias de más de 40 kilómetros, limitándola únicamente la curvatura de la tierra y la línea de vista. Con LMDS se puede transferir información hasta en el rango de Gbps, debido a que trabaja en una banda de frecuencia mayor [20-30 GHz] y con mas capacidad de canal, pero funciona en celdas con cobertura de 5 a 8 kilómetros. Por último en esta categoría el acceso a Internet vía satélite ha jugado un papel preponderante hoy en día. La ventaja más importante de las comunicaciones vía satélite en el acceso a Internet es la gran cobertura que tiene, alta capacidad en el orden de decenas de Mbps, provee accesos más directos a las dorsales satelitales, las comunicaciones vía satélite pueden penetrar áreas remotas donde otros medios de transmisión serían imposibles de llegar. En otras palabras la comunicación vía satélite es capaz de dar acceso a Internet hasta en una isla a miles de kilómetros de distancia. Quizá este sea el medio inalámbrico más caro al principio debido a que hay que comprar infraestructura costosa como las estaciones terrenas y pagar las altas mensualidades de ancho de banda a un proveedor satelital. Existen opciones satelitales mucho más económicas para usuarios residenciales o para pequeñas oficinas. Estos sistemas que operan de manera híbrida y asimétrica utilizan pequeños platos reflectores para la recepción de la información de Internet y empleando otro medio alternativo para el regreso de la información, ya sea mediante una línea privada de menos ancho de banda o mediante un módem casero. Este sistema permite la recepción de Internet a velocidades de hasta 400 Kbps, un ejemplo de este servicio es DirecPC. Existen también sistemas satelitales económicos pero que operan de manera bidireccional para pequeños negocios o para proveedores de Internet mediante pequeñas estaciones terrenas transmisoras/receptoras. Estándar WLL WLL (Wireless Local Loop) es una importante tecnología que permite servicios telefónicos que incrementan más el desarrollo de los diferentes países que los sistemas cableados. Las capacidades de un sistema WLL está basado en la aplicación TDMA (IS-54), el CDMA (IS-95A) y el ETSI GSM las cuales son



comparadas dependiendo de las necesidades e instalaciones existentes. Dentro de las ventajas de la tecnología WLL tenemos:

• Tiempo de implantación mucho más rápido que la convencional. • Potencial para un costo menor que el cable convencional; disminución de

costos en la electrónica versus costos de mano de obra en aumento. • Gastos menores de mantenimiento. Elimina las averías provocadas por

los instaladores tanto en las labores de reacomodos o instalación de nuevos usuarios, como también, en muchos tipos de daños físicos.

• Elimina las posibilidades de robos de cables. • Proporciona una cobertura económica para zonas suburbanas o rurales

de gran crecimiento y donde en la actualidad es muy costoso disponer de instalaciones de cables.

• Pueden también utilizarse en zonas urbanas en entornos competitivos o donde se requieren incorporar adiciones a la capacidad existente de la red convencional.

5.3.1.3. Móviles (GSM, IS-54, CDMA) Estándar GSM GSM (Global System for Mobile Communications) es una plataforma de red inteligente 100 % digital que ofrece capacidades y servicios que superan los sistemas celulares convencionales. GSM proporciona a sus usuarios las siguientes ventajas: Universalidad, inviolabilidad, p rivacidad. Un sistema GSM está basado, principalmente, en tres subsistemas: el Subsistema de Red y de Conmutación, el Subsistema de la Radio Base y el Subsistema de Soporte de Operación. Concepto De Red PLMN-GSM El estándar GSM define una red telefónica móvil terrestre (PLMN) completa, de naturaleza digital y de servicios integrados, que comprende el acceso radio con estructura celular, la transmisión, conmutación y señalización específicas para soportar las funciones de movilidad y los mecanismos de seguridad para el establecimiento de las llamadas y la protección de la información transmitida durante éstas. La red PLMN-GSM proporciona a usuarios fijos y móviles la intercomunicación con abonados o con recursos de otras redes fijas o móviles, incluidos los servicios asociados a ellas. Sin embargo tiene un grado de conectividad limitado. Estrictamente hablando, como red, sólo puede manejar internamente llamadas entre estaciones móviles que dependan de una misma central. Para todas las demás llamadas entre móviles que requieran la intervención de diferentes centrales y las llamadas en



que intervenga una terminal de red de telefónica convencional, se requiere el concurso de la PSTN (red telefónica básica). Por ello, en la PLMN-GSM no hay jerarquía de conmutación y la transmisión utiliza la norma PCM con canales de 64 kbit/s. Una de las características más importantes es la especificación de interfaces abiertas entre las distintas unidades funcionales de la red, en el marco del modelo OSI y siguiendo la normativa ISDN para la caracterización de la señalización y las funciones de red. Servicios Proporcionados Por La Red GSM Los servicios básicos ofrecidos son los de telefonía y datos, que comprenden transmisiones de textos, imágenes, fax, ficheros y mensajes. El servicio básico de telefonía es similar al que prestan las redes clásicas fijas. El usuario puede realizar y recibir llamadas hacia/desde cualquier red telefónica. Este servicio tiene asociado el de mensajería vocal que permite el almacenamiento de los mensajes para su posterior recuperación. Los servicios de datos utilizan la red GSM principalmente como red de acceso. Es posible entablar comunicación con diferentes redes destino a velocidades de datos comprendidas entre 300 y 9600 bit/s, en modo síncrono o asíncrono. Los servicios de datos en modo circuito pueden ser de tipo transparente o no transparente (con detección de errores y retransmisión). En el modo transparente la red usa el protocolo RLP (Radio Link Protocol), con un sistema de control de errores que realiza la detección de errores y la retransmisión consiguiente. El tipo de conexión y las características de los servicios de datos, dependen de la red destinataria. Para la PSTN, que es de naturaleza analógica, se requiere el uso de un módem en el punto de interconexión GSM-PSTN. En el caso de la ISDN hace falta disponer de un adaptador de velocidad de 9,6 kbit/s en GSM a 64 kbit/s en ISDN. Para las redes públicas de datos con conmutación de paquetes, PSPDN, la conexión depende de la norma usada en esa red: es directa en caso X25 y requiere la intervención de la PSTN o ISDN con la norma PAD – X.28 asíncrona, o con la norma X.32 síncrona. El servicio de mensajes cortos, SMS (Short Message Service) permite el intercambio de mensajes breves, de hasta 160 caracteres, que pueden leerse en la pantalla del equipo portátil o en la de un PC dotado de programas para la gestión del servicio. Los mensajes del servicio SMS llegan a sus destinatarios aunque éstos no estén disponibles (terminal apagado) o su línea esté ocupada. Una vez que el terminal



se encuentra en el estado activo desocupado, la red genera una llamada indicando al usuario que tiene uno o más mensajes depositados en su buzón. Este servicio es similar al de radiolocalización (paging) pero más completo ya que permite el intercambio bidireccional, el almacenamiento y envío y el acuse de recibo de los mensajes entregados. Otro servicio interesante es el de difusión celular, SMS-CB (Cell Broadcasting), mediante el cual pueden difundirse mensajes a grupos de usuarios situados en determinadas células. Los servicios suplementarios enriquecen las prestaciones de los teleservicios básicos. Brindan al usuario la posibilidad de elección del tratamiento de las llamadas entrantes o salientes: prohibiciones, desvíos, le facilitan información sobre la llamada: aviso de tasación, identificación de línea llamante, indicación de llamada en espera ole permiten ejercer ciertas funciones como retención, multiconferencia, etc. Estándar CDMA Uno de los puntos más importantes en un sistema móvil, como la telefonía celular, es la forma en como se accede al medio de comunicación. A estas técnicas se le conocen como "acceso múltiple". Múltiple significa que muchos usuarios pueden estar conversando simultáneamente. Es decir, una gran cantidad de subscriptores en un servicio móvil comparten un conjunto de canales de radio y cualquier usuario puede contender para acceder cualquiera de los canales disponibles. Un canal puede ser visto como una porción del espectro radioeléctrico, el cual es asignado temporalmente para un propósito especifico, tal como una llamada telefónica. Una técnica de acceso múltiple define como se divide el espectro de frecuencias en canales y como los canales son asignados a los múltiples usuarios en el sistema. Visto de otra manera, el seleccionar una técnica eficiente de acceso múltiple significa que los operadores telefónicos (carriers) obtendrán más ganancias al acomodar más usuarios en sus redes inalámbricas. Las técnicas de acceso múltiple son utilizadas en el ambiente de las comunicaciones para que varios dispositivos [computadoras, teléfonos, radios, etc.] puedan acceder al medio o canal de comunicación de manera ordenada. Sin las técnicas de acceso múltiple, las comunicaciones entre dispositivos sería un caos. Las técnicas de acceso múltiple nos permiten compartir un mismo canal de comunicación para varios usuarios. CDMA es un término genérico que define una interfa z de aire inalámbrica basada en la tecnología de espectro extendido (spread spectrum). Para telefonía celular, CDMA es una técnica de acceso múltiple especificada por la TIA (Telecommunications Industry Association - Asociación de Industriales de las Telecomunicaciones) como IS-95. En marzo de 1992, la TIA estableció



el subcomité TR 45.5 con la finalidad de desarrollar un estándar de telefonía celular digital con espectro extendido. En julio de 1993, la TIA dio su aprobación al estándar CDMA IS-95. Los sistemas IS-95 dividen el espectro en portadoras de 1.25 MHz. Unos de los aspectos únicos de CDMA es que a pesar de que existe un número fijo de llamadas telefónicas que pueden ser manipuladas por un proveedor de servicios de telefonía (carrier), éste no es un número fijo. La capacidad del sistema va a depender de muchos factores. Cada dispositivo que utiliza CDMA está programado con un pseudocódigo, el cual es usado para extender una señal de baja potencia sobre un espectro de frecuencia amplio. La estación base utiliza el mismo código en forma invertida (todos los ceros son unos y los unos ceros) para des-extender y reconstruir la señal original. Todos los otros códigos permanecen extendidos, indistinguibles del ruido de fondo. Hoy en día existen muchas variantes, pero el CDMA original es conocido como cdmaOne bajo una marca registrada de Qualcomm. A CDMA se le caracteriza por su alta capacidad y celdas de radio pequeño, que emplea espectro extendido y un esquema de codificación especial y lo mejor de todo es muy eficiente en potencia. Estándar AMPS (IS-54) AMPS (Advanced Mobile Phone Service) está definido no solo por un estándar, sino por muchos estándares. Todos los estándares son desarrollados por el comité TR-45 de la TIA. Aún las interfaces de radio son definidas por varias familias de estándares, una para cada tecnología (Análoga, NAMPS, TDMA y CDMA). El roaming automático es posible gracias al estándar TIA IS-41 que provee handoff entre sistemas, envío de llamadas, envío de corto-mensajes y validación y autenticación a través de un protocolo de paso de mensajes entre sistemas. El IS-41 fue desarrollado por el subcomité TIA TR-45.2. Uno de los estándares mas importantes de interfaz de radio para AMPS es: Estándar IS-54 TDMA Celular Digital Los sistemas digitales TDMA llevan su nombre de la sigla en Inglés Time Division Multiple Access, dividiendo un canal sencillo en un número de 'slots' de tiempo (timeslots), con cada usuario obteniendo uno de cada varios slots . Esto triplica la capacidad de las frecuencias celulares, dividiendo un canal celular de 30 Khz en 3 timeslots, los cuales soportan 3 usuarios en alternación estricta. Sistemas futuros posiblemente utilicen codificadores de voz de media rata, lo cual permitirá 6 usuarios en un canal de 30 Khz. La primera implementación de celular digital AMPS utilizaba TDMA, en el estándar IS -54 de la TIA (también conocido como D-AMPS). Este requiere la digitalización de la



voz, comprimirla y transmitirla en intervalos regulares. Siguiendo el IS-54, el cual proveía un canal de voz TDMA, el IS-136 es la siguiente generación la cual utiliza también TDMA en el canal de control. De esta manera TDMA, se puede definir como el IS-54 y el IS -136. Actualmente Hughes Network Systems está promocionando el concepto de E-TDMA, el cual utiliza asignación dinámica de timeslots , para evitar el desperdicio de timeslots cuando en un lado de la conversación está en silencio. Entre gente que no se habla simultáneamente en el teléfono, esta técnica puede casi doblar la eficiencia del espectro de TDMA una vez mas, a cerca de 10:1 sobre sistemas análogos. 5.3.1.4 Bluetooth y Servicios de Datos inalámbricos Bluetooth es una tecnología utilizada para conectividad inalámbrica de corto alcance entre dispositivos tales como PDAs (Personal Digital Assistance), teléfonos celulares, teclados, máquinas de fax, computadoras de escritorio y portátiles, módems, proyectores, impresoras, etc. El principal mercado es la transferencia de datos y voz entre dispositivos y computadoras personales. El enfoque de Bluetooth es similar a la tecnología de infrarrojo conocida como IrDA (Infrared Data Association). Sin embargo, Bluetooth, es una tecnología de radiofrecuencia (RF) que utiliza la banda de espectro disperso de 2.4 GHz. Muchas veces también se le confunde con el estándar IEEE 802.11, otra tecnología de RF de corto alcance. IEEE 802.11 ofrece más caudal eficaz pero necesita más potencia de transmisión y ofrece menos opciones de conectividad que Bluetooth para el caso de aplicaciones de voz. Debido a que Bluetooth funciona con RF no está sujeto a tales limitaciones. Las distancia de conexión en Bluetooth puede ser de hasta 10 metros o más dependiendo del incremento de la potencia del transmisor, pero los dispositivos no necesitan estar en línea de vista ya que las señales de RF pueden atravesar paredes y otros objetos no metálicos sin ningún problema. Bluetooth puede ser usado para aplicaciones en redes residenciales o en pequeñas oficinas, ambientes que son conocidos como WPANs (Wireless Personal Area Network). Una de las ventajas de las tecnologías inalámbricas es que evitan el problema de alambrar las paredes de las casas u oficinas. Bluetooth opera en la banda 2.4 GHz bajo la tecnología de radio conocida como espectro disperso. La banda de operación está dividida en canales de 1 MHz, a 1 megasímbolo por segundo puede obtenerse al ancho de banda máximo por canal. Con el esquema de modulación empleado, GFSK (Gaussian Frequency Shift Keying), esto equivale a 1 Mbps. Utilizando GFSK, un 1 binario representa una desviación positiva de la portadora nominal de la frecuencia, mientras que un 0 representa una desviación negativa. Después de cada paquete, ambos dispositivos re-sintonizan su radio transmisor a una frecuencia diferente, saltando de un canal a otro canal de radio; esta técnica se le conoce como



espectro disperso con salto en frecuencia (FHSS, Frequency Hopping Spread Spectrum). De esta manera, los dispositivos Bluetooth utilizan toda la banda de 2.4 GHz y si una transmisión se interfiere sobre un canal, una retransmisión siempre ocurrirá sobre un canal diferente con la esperanza de que este canal esté libre. Cada ranura de tiempo tiene una duración de 625 microsegundos y generalmente los dispositivos saltan una vez por paquete, o sea, saltan cada ranura, cada 3 ranuras o cada 5 ranuras. Como Bluetooth fue diseñado para aplicaciones móviles de poca potencia, la potencia del radio transmisor debe ser minimizada. Tres diferentes clases de niveles de potencias están definidas, las cuales proveen rangos de operación de aproximadamente 10, 20 y 100 metros: El más bajo nivel de potencia cubre 10 metros, el más alto nivel logra cubrir distancias de hasta 100 metros. Aunado a las distancias cortas de conexión de Bluetooth en materia de ancho de banda soporta hasta 780 Kbps, los cuales pueden ser utilizados para transferir unidireccionalmente 721 Kbps y 57.6 Kbps en la dirección de retorno o hasta 432.6 Kbps de manera simétrica en ambas direcciones. Aunque estas velocidades están limitadas para cierto tipo de aplicaciones como video, aplicaciones como transferencia de archivos e impresión caen perfectas en tal ancho de banda. Bluetooth permite manipular simultáneamente transmisiones de voz y datos. Es capaz de soportar un canal de datos asíncrono y hasta tres canales de voz asíncronos o un canal que soporte ambos, voz y datos. La capacidad combinada con los dispositivos del tipo "ad hoc" permite soluciones superiores para dispositivos móviles y aplicaciones de Internet. Esta combinación permite soluciones innovadoras como un dispositivo de manos libres para llamadas de voz, impresión a máquinas de fax y sincronización automática a PDAs, laptops y aplicaciones de libreta de direcciones de teléfonos celulares. La especificación Bluetooth La especificación de Bluetooth cubre desde el transceptor de radio hasta varias interfaces de protocolos basados tanto en hardware como en software. Algunos elementos clave y protocolos de la arquitectura de Bluetooth son descritos a continuación. Control de enlace: el hardware del control de enlace controla la transmisión y recepción de radio así como el procesamiento de la señal digital requerida para el protocolo de banda base. Sus funciones incluyen establecimientos de conexiones, soporte para enlaces asíncronos (datos) y síncronos (voz), corrección de error y autentificación. El microcódigo del administrador de enlaces desempeña funciones a bajo nivel para el establecimiento de enlaces, autentificación y configuración de los enlaces. Topología de la red: los dispositivos Bluetooth son generalmente organizados en grupos de 2 a 8 llamados picoceldas o picoredes, consistente de un



dispositivo maestro y uno o más dispositivos esclavos. Un dispositivo puede pertenecer a más de una picocelda y comportarse como un esclavo en ambas o un maestro en una picocelda y como esclavo en otra. Como Bluetooth opera en una banda de uso libre conocida como ISM (Industrial, Scientific, and Medical) donde otros dispositivos de uso común la utilizan como es el caso de puertas de cocheras, teléfonos inalámbricos, hornos de microondas, sólo por nombrar algunos. Para que los dispositivos Bluetooth puedan coexistir y operar confiablemente con los otros dispositivos, cada picocelda es sincronizada a una frecuencia específica del patrón de salto por frecuencia. Este patrón, que salta a 1,600 frecuencias diferentes por segundo, es único para una picocelda en particular. Cada "salto" de frecuencia es una ranura de tiempo durante la cual los paquetes de datos son transferidos. Un paquete puede abarcar hasta 5 ranuras de tiempo, en la cual la frecuencia permanece constante durante la duración de esa transferencia. Si los dispositivos van a saltar a las nuevas frecuencias después de cada paquete, ellos deben ponerse de acuerdo en la secuencia de las frecuencias que utilizarán. Como los dispositivos Bluetooth operan en 2 modos: como maestro y como esclavo. Si el maestro asigna la secuencia de salto de frecuencia. Los esclavos sincronizan al dispositivo maestro en tiempo y frecuencia seguido de la secuencia de salto del dispositivo maestro. Enlaces de banda base: La banda base de Bluetooth provee canales de transmisión para voz y datos y es capaz de soportar un enlace asíncrono de datos y hasta tres enlaces de voz asíncronos (o un enlace soportando ambos). Los enlaces orientados a conexión síncronos (SCO) son típicamente empleados para transmisiones de voz. Esos enlaces son conexiones simétricas punto a punto que reservan ranuras de tiempo para garantizar la transmisión a tiempo. Al dispositivo esclavo siempre se le permitirá responder durante la ranura de tiempo inmediatamente seguido de una transmisión tipo SCO del maestro. Un dispositivo maestro puede soportar hasta tres enlaces SCO a uno o varios esclavos, pero un solo esclavo puede soportar sólo enlaces SCO para diferentes dispositivos maestros. Los paquetes SCO nunca son retransmitidos. Los enlaces orientados a no-conexión (ACL, Asynchronous Connectionless) son típicamente empleados para transmisión de datos. Las transmisiones sobre estos enlaces son establecidas en base por ranura (en ranuras no reservadas para enlaces SCO). Los enlaces ACL soportan transferencias punto-multipunto de datos asíncronos como síncronos. Después de una transmisión ACL del maestro, sólo el dispositivo esclavo direccionado puede responder durante la siguiente ranura de tiempo o si el dispositivo no está direccionado, los paquetes son considerados como mensajes difundidos (broadcast). La mayoría de los enlaces ACL incluyen retransmisión de paquetes. Administrador de enlaces: La máquina de estado de banda base es controlada por el administrador de enlaces. Este microcódigo provee el control del enlace basado en hardware para



configuración, seguridad y control de enlaces. Sus capacidades incluyen autentificación y servicios de seguridad, monitoreo de calidad de servicio y control del estado de banda base. El administrador de enlaces se comunica con los demás utilizando el protocolo LMP (Link Management Protocol), el cual utiliza los servicios básicos de banda base. Los paquetes LMP, los cuales son enviados sobre los enlaces ACL, son diferenciados de los paquetes L2CAP (Logical Link Control and Adaptation Protocol) por un bit en el encabezado del ACL. Ellos son siempre enviados como paquetes de una ranura y una prioridad alta que los paquetes L2CAP. Esto ayuda el aseguramiento de la integridad del enlace bajo una alta demanda de tráfico. El Controlador de Interface del host (Host controller interface, HCI): Por encima del administrador de enlaces se encuentra el HCI. Este protocolo basado en hardware es usado para aislar la banda base de Bluetooth y el administrador de enlaces de un protocolo de transporte tal como el RS-232 o USB (Universal Serial Bus). Esto permite una interface estándar para el hardware de Bluetooth. Un manejador de dispositivos HCI en el host es usado para interactuar una aplicación Bluetooth con el protocolo de transporte. Actualmente existen tres mecanismos de transporte soportados: USB, RS-232 y el UART (Universal Asynchronous Receiver-Transmitter). Utilizando HCI, una aplicación Bluetooth puede acceder al hardware de Bluetooth sin el conocimiento de la capa de transporte o de otros detalles de implementación del hardware. Protocolos basados en software: el resto de los protocolos son implementados en software. La capa más baja de L2CAP provee la interface con el administrador de enlaces y permite la interoperabilidad entre dispositivos Bluetooth. Provee la multicanalización de protocolos, lo cual permite el soporte de otros protocolos de más alto nivel tales como TCP/IP. El L2CAP opera sobre un enlace del tipo ACL en banda base y provee enlaces punto-multipunto para transferencias síncronas como asíncronas. L2CAP provee servicios a los protocolos de los niveles superiores al transmitir paquetes de datos sobre los canales L2CAP. Existen tres tipos de canales L2CAP: canales bidireccionales que transportan comandos; canales orientados a conexión para conexiones punto-punto y bidireccionales; y canales unidireccionales orientados a no-conexión que soporten conexiones punto-multipunto, permitiendo que una entidad local L2CAP sea conectada a un grupo de dispositivos remotos. Varios protocolos interactúan con la capa de enlace L2CAP tales como SDP y RFCOMM. El protocolo SDP (Service Discovery Protocol) provee un medio para determinar que servicios Bluetooth están disponibles en un dispositivo particular. Un dispositivo Bluetooth puede actuar como un cliente SDP solicitando servicios o como un servidor SDP proveyendo servicios, o ambos. Un simple dispositivo Bluetooth tendrá no más de un servidor SDP, pero puede actuar como un cliente para más de un dispositivo remoto. El protocolo SDP provee acceso sólo a información acerca de servicios, la utilización de esos servicios



deberá ser proveído por otro protocolo. RFCOMM es un protocolo de transporte que provee transferencia de datos serial. Una entidad de emulación de puertos es usada para mapear la comunicación de la interface de la programación de aplicaciones (API, Applications Programming Interface) a los servicios de RFCOMM, permitiendo que el software legado opere en un dispositivo Bluetooth. TCS (Telephony Control Protocol Specification), un protocolo para aplicaciones de telefonía es proveído para control de llamadas de voz y datos a través de señalización. La señalización tanto para punto-punto y punto-multipunto son soportados utilizando los canales L2CAP, la voz o los datos son transferidos directamente desde la banda base sobre los enlaces SCO. Bluetooth también soporta el protocolo de sesión conocido como IrOBEX (IrDA Object Exchange Protocol), definido por IrDA. Este protocolo puede operar sobre las capas de transporte, incluyendo RFCOMM y TCP/IP. Para dispositivos Bluetooth, solo OBEX orientado a conexión es soportado. Tres perfiles de aplicación han sido desarrollados usando OBEX. Estos incluyen funcionalidades de sincronización para directorios telefónicos, calendarios, mensajes, etc.; funcionalidades de transferencia de archivos y Object Push para soporte de tarjetas de presentación. Las primeras tecnologías inalámbricas para equipos de computo utilizaban tecnología Spread Spectrum o infrarroja. Espectro Amplio (Spread Spectrum), fue desarrollado para fines militares y su funcionamiento consta en dividir las señales informativas en varias frecuencias, estas frecuencias comúnmente son las de 902-928 MHz y de 2.4 -2.484 GHz (también llamada ISM Industrial-Scientific and Medical radio frequency),este último rango de frecuencias es utilizado por teléfonos inalámbricos (NO celulares),controles de puertas eléctricas, entre otros; la ventaja de operación en esta frecuencia es que no requiere permiso gubernamental para ser utili zada a diferencia de otras frecuencias. Tecnología Infrarroja La Tecnología infrarroja opera en la banda de 300,000 GHz pero su uso es más limitado que Spread Spectrum, ya que una transmisión infrarroja requiere de una línea-visual directa entre los apara tos que están realizando la transmisión, este tipo de implementación es utilizada por controles de televisión y Vídeos. Es un estándar que utiliza FHSS, capaz de transmitir a velocidades de 1 Mbps y es apoyado por más de 2000 empresas de tecnología. Bluetooth ha surgido últimamente como un posible substituto a todo tipo de cable anexado a una computadora, debido a su costo y el apoyo de cientos de empresas. A su velocidad (1 Mbps) será capaz de sustituir las conexiones clásicas de cables paralelos y seriales, ya que es 3 y 6 veces más rápido (respectivamente) que estas conexiones en amplio uso en cualquier computadora.



Esto trae una cantidad interminable de posibilidades desde impresoras, monitores, conexiones de portátiles (Laptops), teclados, ratones y otros dispositivos. Esta tecnología es capaz de transmitir información efectivamente hasta una distancia de 10 metros entre aparatos que utilicen transmisores "Bluetooth", debido que se emplea FHSS el "Hopping Pattern" de Bluetooth es de 1600 veces por segundo, lo cual asegura que la transmisión de datos sea altamente segura. 5.3.1.5 Estándares de redes inalámbricas: IEEE 802.11 El estándar IEE 802.11 de LAN Inalámbrica esta diseñado para soportar comunicaciones a velocidades hasta de 11Mbps sobre una distancia de hasta 150 metro entre dispositivos equipados con transmisores/receptores inalámbricos simples. En este sentido la IEEE ha desarrollado varios estándares en que lo que LAN se refiere. La especificación IEEE 802.11 define redes locales inalámbricas que emplean ondas de radio en la banda de 2.4 GHz y 5 GHz conocido como espectro esparcido. Las velocidades típicas de esta tecnología son 11 Mbps en la especificación IEEE 802.11b y está en desarrollo la especificación IEEE 802.11a en la banda de 5 GHz que alcanzará velocidades de hasta 54 Mbps. El estándar IEEE 802.11 extiende el principio de sensible a la portadora (CSMA) utilizando la tecnología de Ethernet (IEEE 802.3) para adecuar las características de la comunicación sin hilos. Las estaciones IE EE 802.11 utilizan como medio de transmisión señales de radio (en la banda de los 2,4 Ghz.) o señales de infrarrojos. Utilizan técnicas de selección de frecuencia y de salto de frecuencia para evitar las interferencias externas y mutuas redes LAN inalámbricas independientes. Cuando se utiliza ondas de radio en lugar de cables como medio de transmisión surgen varios problemas, estos problemas se derivan del hecho de que los mecanismos de detección de portadora y de colisiones empleados por Ethernet son efectivos sólo cuando la potencia de la señal es aproximadamente la misma a lo largo de toda la red. Dado a que la potencia de la señal no es uniforme a lo largo del espacio en el que las redes LANs inalámbricas trabajan, la detección de la portadora y de las colisiones puede fallar de alguno de los siguientes modos:

• Estaciones ocultas, la detección de la portadora puede fallar en la detección de la transmisión de otra estación.

• Atenuación, debido a la ley del inverso del cuadrado de la propagación de las ondas electromagnéticas, la potencia de la señal de radio disminuye rápidamente con la distancia al transmisor.

• Enmascaramiento de colisiones, desgraciadamente la técnica de escuchar utilizada por Ethernet para detectar las colisiones no es muy efectiva en las redes vía radio.

• El aspecto de seguridad, el estándar IEEE 802.11, requiere de un intercambio de autentificación para cada estación que se conecte a la



red mediante el cual se demuestre el conocimiento de una clave compartida.

5.3.1.6 Sistemas de Comunicación por satélite Esencialmente, un satélite es un repetidor de radio en el cielo (transponder). Un sistema de satélite consiste de un transponder, una estación en tierra, para controlar el funcionamiento y una red de usuario, de las estaciones terrestres, que proporciona las facilidades para transmisión y recepción de tráfico de comunicaciones, a través del sistema de satélite. Las transmisiones de satélites se catalogan como bus o carga útil. La de bus incluye mecanismos de control que apoyan la operación de carga útil. La de carga útil es la información del usuario que será transportada a través del sistema. Aunque en los últimos años los nuevos servicios de datos y radioemisión de televisión son mas y más demandados, la transmisión de las señales de teléfono de voz convencional (en forma analógica o digital). Satélites Orbitales Los satélites mencionados, hasta el momento, son llamados satélites orbitales o no síncronos. Los satélites no síncronos giran alrededor de la Tierra en un patrón elíptico o circular de baja altitud. Si el satélite esta girando en la misma dirección de la rotación de la Tierra y a una velocidad angular superior que la de la Tierra, la órbita se llama órbita progrado. Si el satélite esta girando en la dirección opuesta a la rotación de la Tierra o en la misma dirección, pero a una velocidad angular menor a la de la Tierra, la órbita se llama órbita retrograda. Consecuentemente, los satélites no síncronos están alejándose continuamente o cayendo a tierra, y no permanecen estacionarios en relación a ningún punto particular de la tierra. Por lo tanto los satélites no síncronos se tienen que usar cuando están disponibles, lo cual puede ser un corto periodo de tiempo, como 15 minutos por órbita. Otra desventaja de los satélites orbitales es la necesidad de usar un equipo costoso y complicado para rastreo en las estaciones terrestres. Cada estación terrestre debe localizar el satélite conforme esta disponible en cada órbita, y después unir su antena al satélite y localizarlo cuando pasa por arriba. Una gran ventaja de los satélites orbitales es que los motores de propulsión no se requieren a bordo de los satélites para mantenerlos en sus órbitas respectivas.



Satélites Geoestacionarios Los satélites geoestacionarios o geosíncro nos son satélites que giran en un patrón circular, con una velocidad angular igual a la de la Tierra. Consecuentemente permanecen en una posición fija con respecto a un punto específico en la tierra. Una ventaja obvia es que están disponibles para todas las estaciones de la tierra, dentro de su sombra, 100% de las veces. La sombra de un satélite incluye todas las estaciones de la tierra que tienen un camino visible a él y están dentro del patrón de radiación de las antenas del satélite. Una desventaja obvia es que a bordo, se requieren de dispositivos de propulsión sofisticados y pesados para mantenerlos fijos en una órbita. El tiempo de órbita de un satélite geosíncrono es de 24 horas igual que la tierra. Clasificaciones Orbitales, Espaciamiento Y Asignaciones De Frecuencia Hay dos clasificaciones principales para los satélites de comunicaciones: hiladores (spinners) y satélites estabilizadores de tres ejes. Los satélites espinar, utilizan el movimiento angular de su cuerpo giratorio para proporcionar una estabilidad de giro. Con un estabilizador de tres ejes, el cuerpo permanece fijo en relación a la superficie de la Tierra, mientras que el subsistema interno proporciona una estabilización de giro. Los satélites geosíncronos deben compartir espacio y espectro de frecuencia limitados, dentro de un arco específico, en una órbita geoestacionaria, aproximadamente a 22,300 millas, arriba del Ecuador. La posición en la ranura depende de la banda de frecuencia de comunicación utilizada. Los satélites trabajando, casi o en la misma frecuencia, deben estar lo suficientemente separados en el espacio para evitar interferir uno con otro. Hay un límite realista del número de estructuras satelitales que pueden estar estacionadas, en un área específica en el espacio. La separación espacial requerida depende de las siguientes variables:

• Ancho del haz y radiación del lóbulo lateral de la estación terrena y antenas del satélite.

• Frecuencia de la portadora de RF. • Técnica de codificación o de modulación usada. • Límites aceptables de interferencia. • Potencia de la portadora de transmisión.

Generalmente, se requieren de 3 a 6º de separación espacial dependiendo de las variables establecidas anteriormente. Las frecuencias de la portadora, más comunes, usadas para las comunicaciones por satélite, son las bandas 6/4 y 14/12 GHz. El primer número es la frecuencia de subida (ascendente) (estación terrena a transponder) y el segundo número



es la frecuencia de bajada (descendente) (transponder a estación terrena). Diferentes frecuencias de subida y de bajada se usan para prevenir que ocurra repetición. Entre mas alta sea la frecuencia de la portadora, más pequeño es el diámetro requerido de la antena para una ganancia específica. La mayoría de los satélites domésticos utilizan la banda 6/4 GHz. Desafortunadamente, esta banda también se usa extensamente para los sistemas de microondas terrestres. Se debe tener cuidado cuando se diseña una red satelital para evitar interferencia de, o interferencia con enlaces de microondas establecidas. Modelos De Enlace Del Sistema Satelital Esencialmente, un sistema satelital consiste de tres secciones básicas: una subida, un transponder satelital y una bajada. Modelo de subida El principal componente dentro de la sección de subida satelital, es el transmisor de estación terrena. Un típico transmisor de la estación terrena consiste de un modulador de IF, un convertidor de microondas de IF a RF, un amplificador de alta potencia (HPA) y algún medio para limitar la banda del último espectro de salida (por ejemplo, un filtro pasa-bandas de salida). El modulador de IF se convierte la IF convierte las señales de banda base de entrada a una frecuencia intermedia modulada en FM, en PSK o en QAM. El convertidor (mezclador y filtro pasa-bandas) convierte la IF a una frecuencia de portadora de RF apropiada. El HPA proporciona una sensibilidad de entrada adecuada y potencia de salida para propagar la señal al transponder del satélite. Los HPA comúnmente usados son klystons y tubos de onda progresiva. Transponder Un típico transponder satelital consta de un dispositivo para limitar la banda de entrada (BPF), un amplificador de bajo ruido de entrada (LNA), un sistema que traslada frecuencias, un amplificador de potencia de bajo nivel y un filtro pasa-bandas de salida. Este transponder es un repetidor de RF a RF. Otras configuraciones de transponder son los repetidores de IF, y de banda base, semejantes a los que se usan en los repetidores de microondas. Modelo de bajada Un receptor de estación terrena incluye un BPF de entrada, un LNA y un convertidor de RF a IF. Nuevamente, el BPF limita la potencia del ruido de entrada al LNA. El LNA es un dispositivo altamente sensible, con poco ruido, tal como un amplificador de diodo túnel o un amplificador paramétrico. El



convertidor de RF a IF es una combinación de filtro mezclador /pasa-bandas que convierte la señal de RF recibida a una frecuencia de IF. Enlaces cruzados Ocasionalmente, hay aplicaciones en donde es necesario comunicarse entre satélites. Esto se realiza usando enlaces cruzados entre satélites o enlaces intersatelitales (ISL). Una desventaja de usar un ISL es que el transmisor y receptor son enviados ambos al espacio. Consecuentemente la potencia de salida del transmisor y la sensibilidad de entrada del receptor se limitan. 5.3.1.6.1 Elementos de un Sistema Satelital Su objetivo es el establecimiento de comunicaciones móviles, mediante satélites en órbita, entre estaciones terrenas fijas y estaciones terrenas móviles. Comunicación Vía Microondas Antes de comenzar a describir los componentes de un sistema satelital, debemos comprender la comunicación vía microondas, ya que la comunicación satelital se basa en los principios de dicha comunicación. Básicamente un enlace vía microondas consiste en tres componentes fundamentales: El Transmisor, El receptor y El Canal Aéreo. El Transmisor es el responsable de modular una señal digital a la frecuencia utilizada para transmitir, El Canal Aéreo representa un camino abierto entre el transmisor y el receptor, y como es de esperarse el receptor es el encargado de capturar la señal transmitida y llevarla de nuevo a señal digital. El factor limitante de la propagación de la señal en enlaces microondas es la distancia que se debe cubrir entre el transmisor y el receptor, además esta distancia debe ser libre de obstáculos. Otro aspecto que se debe señalar es que en estos enlaces, el camino entre el receptor y el transmisor debe tener una altura mínima sobre los obstáculos en la vía, para compensar este efecto se utilizan torres para ajustar dichas alturas. Antenas y Torres De Microondas La distancia cubierta por enlaces microondas puede ser incrementada por el uso de repetidoras, las cuales amplifican y redireccionan la señal, es importante destacar que los obstáculos de la señal pueden ser salvados a través de reflectores pasivos. Las siguientes figuras muestran como trabaja un repetidor y como se ven los reflectores pasivos.



AntenaRecepción

Amplificadorde RuidoBajo

Convertidorde Frecuencia

Controlador(Driver)

Amplificadorde Salida

AntenaTransmisión

Terminal A Terminal B

Terminal C

Repetidor Repetidor

Repetidor

Principalo Repetidor de Canal

96 Canales VF

48 Canales VF

48 Canales VF

La señal de microondas transmitidas es distorsionada y atenuada mientras viaja desde el transmisor hasta el receptor, estas atenuaciones y distorsiones son causadas por una perdida de poder dependiente a la distancia, reflexión y refracción debido a obstáculos y superficies reflectoras, y a pérdidas atmosféricas. La siguiente es una lista de frecuencias utilizadas por los sistemas de microondas:

Common Carrier Operational Fixed 2.110 2.130 GHz 1.850 1.990 GHz 2.160 2.180 GHz 2.130 2.150 GHz 3.700 4.200 GHz 2.180 2.200 GHz 5.925 6.425 GHz 2.500 2.690 GHz 10.700 11.700 GHz 6.575 6.875 GHz 12.200 12.700 GHz



Debido al uso de las frecuencias antes mencionadas algunas de las ventajas son:

• Antenas relativamente pequeñas son efectivas. • A estas frecuencias las ondas de radio se comportan como ondas de luz,

por ello la señal puede ser enfocada utilizando antenas parabólicas y antenas de embudo, además pueden ser reflejadas con reflectores pasivos.

• Otra ventaja es el ancho de banda, que va de 2 a 24 GHz. El uso de estas frecuencias también posee desventajas:

• Las frecuencias son susceptibles a un fenómeno llamado Disminución de Multicamino (Multipath Fafing), lo que causa profundas disminuciones en el poder de las señales recibidas.

• A estas frecuencias las pérdidas ambientales se transforman en un factor importante, la absorción de poder causada por la lluvia puede afectar dramáticamente el rendimiento del canal.

Componentes de un Sistema Satelital Básicamente, los enlaces satelitales son iguales a los de microondas excepto que uno de los extremos de la conexión se encuentra en el espacio, como se había mencionado un factor limitante para la comunicación microondas es que tiene que existir una línea recta entre los dos puntos pero como la tierra es esférica esta línea se ve limitada en tamaño entonces, colocando sea el receptor o el transmisor en el espacio se cubre un área más grande de superficie. Los componentes principales de un sistema satelital son:

• Estación Terrena transmisora • Transponder satelital [Satélite] • Estación terrena receptora • Espacio (atmósfera)

El siguiente gráfico muestra un diagrama sencillo de un enlace vía satélite, nótese que los términos UPLINK y DOWNLINK aparecen en la figura, el primero se refiere al enlace de la tierra al satélite y la segunda del satélite a la tierra.



Enlace Terrestre Enlace Terrestre

Estaciones Terrenas

Enlace de Subida(Uplink)

Enlace de Bajada(Downlink)

Los satélites de comunicación están frecuentemente ubicados en lo que llamamos Orbitas Geosincronizadas, lo que significa que el satélite circulará la tierra a la misma velocidad en que esta rota lo que lo hace parecer inmóvil desde la tierra. Una ventaja de esto es que el satélite siempre esta a la disposición para su uso. Un satélite para estar en este tipo de órbitas debe ser posicionado a 13.937,5 Kms. de altura, con lo que es posible cubrir a toda la tierra utilizando solo tres satélites como lo muestra la figura.

Tierra

Un satélite no puede retransmitir una señal a la misma frecuencia a la que es recibida, si esto ocurriese el satélite interferiría con la señal de la estación terrestre, por esto el satélite tiene que convertir la señal recibida de una frecuencia a otra antes de retransmitirla, para hacer esto lo hacemos con algo llamado "Transponders". Otro punto que cabe destacar es que existen satélites que se encargan de regenerar la señal recibida antes de retransmitirla, pero estos solo pueden ser utili zados para señales digitales, mientras que los satélites que no lo hacen pueden trabajar con ambos tipos de señales (Análogas y Digitales).



La estación terrena transmisora se caracteriza por el P.I.R.E (Potencia Isotrópica Radiada Efectiva). Esto de hecho esta relacionado a la potencia del transmisor y la ganancia de la antena en la frecuencia de transmisión. La estación terrena receptora se caracteriza por una figura de mérito (G/T) y la Frecuencia Intermedia (IF) de banda ancha. Una estación terrena satelital es un conjunto de equipo de comunicaciones y de cómputo que puede ser terrestre (fijo y móvil), marítimo o aeronáutico. Las estaciones terrenas pueden ser usadas en forma general para transmitir y recibir del satélite. Pero en aplicaciones especiales solo pueden recibir o solo pueden transmitir. A continuación se enumeran cada uno de los subsistemas básicos que integran una estación terrena satelital.

• Plato Reflector (antena): Es el punto por el cuál el la estación terrestre puede enviar información hacia el satélite o puede recibir una señal, con información, proveniente del satélite.

• Amplificador de Potencia [HPA, High Power Amplifier]: Al Amplificador de Alta Potencia [HPA] también se le conoce como Transmisor o Transceptor [Transceiver] ya que está en la parte Transmisora. Existen varias versiones de HPAs, dependiendo de la potencia radiada y de otros factores. Los hay de estado sólido, los SSPA (Solid State Power Amplifier) o SSHPA, los hay analógicos de de Tubos de Vacío, los TWTs (Travelling Wave Tube), los KPA (Klystron Power Amplifiers). Los SSPAs generalmente se usan para potencias bajas, los TWTs y los Klystron se utilizan para potencias muy altas.

• Amplificador de Bajo Ruido (Receptor), LNA: (Low Noise Amplifier): • Conversor de subida/bajada (Up/down converter): Un conversor de

subida y bajada, se puede conseguir a parte, y generalmente convierten frecuencias de IF (Frecuencia Intermedia) a RF (Radio Frecuencia) cuando es UpConverter y de RF a IF cuando es DownConverter. La frecuencias de IF son generalmente de 70 MHz, 140 MHz y la mas común es la banda L (950-1550 MHz aprox). La RF puede ser Banda C, Ku, Ka, etc. El conversor de subida/bajada también puede estar integrado junto con el LNA. Cuando es así, se le conoce como LNB (Low Noise Block): entonces un LNB = LNA + Up/Down Converter

• Modem satelital (modulador, demodulador): Se encarga de modular las señales que provienen de los equipos que están conectados a través del MUX y de demodular las señales que vienen del Satélite hacia dichos equipos, podríamos decir que es el traductor de señales de los sistemas hacia el satélite y viceversa.

• MUX: El MUX es el encargado de multiplexar, que es dar varias salidas a la línea que viene del MODEM Satelital, dichas salidas van a dar a



diferentes dispositivos, los cuáles aprovechan la señal de entrada del MODEM Satelital y además pueden enviar información hacia él.

Diagrama genérico de una estación terrena transmisora/receptora

Cada elemento en la cadena de recepción puede ser asignada a una temperatura de ruido, la cual es una medida de potencia de ruido contribuida por el elemento por unidad de ancho de banda. Esas contribuciones son combinadas para reflejar la potencia de ruido por la distribución de la ganancia a través de la cadena. En general, la temperatura de ruido de el sistema es determinado primariamente por la antena, al amplificador de bajo ruido (LNA) y los componentes de acople de esos elementos. La suma de pequeñas pérdidas, tales como la atenuación en el cable, entre el LNA y la antena puede resultar en degradación significante de la figura de mérito G/T. El transponder también juega un papel bien importante en un enlace satelital, éste se encuentra dentro del satélite y cuyas funciones básicas son las siguientes:

• Amplificación de la señal • Aislamiento de canales adyacentes • Traslación de frecuencias

Por último, también el ambiente determina en gran medida el éxito o el fracaso de un enlace satelital y es aquí donde se generan las mayores pérdidas, ocasionadas por el largo trayecto de la señal propagada desde un satélite en el caso más extremo 36,000 Kms. de distancia. Los principales factores que ocasionan la degradación de la señal se encuentran la lluvia, la nieve, la absorción atmosférica, las pérdidas por el espacio libre, entre otras.



5.3.2 Redes inalámbricas Al igual que las redes tradicionales alámbricas vamos a clasificar a las redes inalámbricas en:

• WWAN / WMAN (Wireless Wide Area Network/ Wireless Metropolitan Area Network)

• WLAN (Wireless Local Area Network) 5.3.2.1 IP Móvil Una máquina en la red tiene siempre tiene una dirección IP, la cuál se conforma con una parte fijada por la subred en que se encuentra (prefijo de red) y otra parte pertenece directamente a la dirección de la máquina. Esta dirección IP le sirve al router para que pueda hacer llegar los paquetes o datagramas que un usuario en la red le envía a otro, ya sea dentro de la misma red o en una red diferente, o incluso en subredes diferentes. Si un máquina cambia de red, tiene que cambiar su dirección IP, esto hará que las conexiones (TCP) que tuviera abiertas se terminan., además todos los paquetes que eran enviados hacia ella, no podrán ser entregados porque se encuentra en una red diferente y como ya lo mencionamos su dirección IP habrá cambiado. Aun más complicado es el hecho de que aun si no cambiáramos su dirección IP, la máquina continuaría sin recibir los paquetes e incluso dejaría de comunicarse con cualquier máquina, ya que ni siquiera tendría forma de comunicarse con las máquinas dentro de su red, precisamente porque no cambiamos la dirección IP. El IP móvil es una tecnología que permite que un nodo de red ("nodo móvil") emigre de su "casa" red a otras redes, o dentro del mismo dominio de la administración, o a otros dominios administrativos. El IP móvil puede seguir una computadora principal móvil sin necesitar cambiar la dirección IP del móvil a lo largo de sus pasos por diferentes redes. Este móvil se puede pensar como la cooperación de tres subsistemas importantes. Primero, hay un mecanismo del descubrimiento definido de modo que las computadoras móviles puedan determinar sus nuevas puntas de conexión (dirección de su nueva red) conforme se mueven de lugar al lugar dentro del Internet. En segundo lugar, una vez que la computadora móvil sepa la dirección IP en su nueva punta de conexión, se coloca con un agente que lo representa en su red casera.



Sin el IP móvil, uno de los dos mecanismos siguientes se debe emplear para que un nodo cambie su punta de la conexión sin perder su capacidad de comunicarse:

• El nodo debe cambiar su dirección IP siempre que cambie su punta de la conexión.

• Las rutas a la máquina específica en cuestión se deben propagar a través de la porción relevante de la infraestructura del enrutamiento de Internet. Esto es que alguien tendría que recordar las redes por donde va cambiando la dirección IP de la maquina.

Ambas alternativas son inaceptables en nuestro caso. El primer caso hace imposible que un nodo mantenga comunicación con otros nodos cuando el nodo cambia de localización (cambia su dirección IP). El segundo tiene problemas severos de escalamiento considerando el crecimiento explosivo en ventas de computadoras portátiles, ya que entre más computadoras portátiles tendríamos que recordar más direcciones y además las direcciones de todas las redes por donde se está moviendo el nodo. El IP móvil fue ideado para resolver las metas siguientes para los nodos móviles que no se mueven con más frecuencia que una vez por segundo. Permite a los nodos moverse a partir de una subred a otra. Es conveniente para la movilidad a través de medios heterogéneos como para la movilidad a través de medios homogéneos. Fundamentos de IP Móvil El terminal móvil tiene dos direcciones IP:

• Dirección Local (Home Address): Es fija, es con la que el terminal mantiene las conexiones con otras máquinas y corresponde con su red local.

• Dirección de Auxilio (Care-of Address): Es cambiante, es la que corresponde a la red en que se encuentre el móvil en un momento dado.

En la red local, un Agente Local (Home Agent) sabe qué Dirección de Auxilio tiene en cada momento el terminal móvil:

• Recoge los datagramas destinados a la Dirección Local del terminal móvil

• Los reenvía dentro de un nuevo datagrama dirigido a la Dirección de Auxilio (túnel).

Como podemos ver el Agente Local funciona como un intermediario entre las máquinas que se quieren comunicar con la terminal móvil, ya que recibe los mensajes que van hacia a ella y después los reenvía, por lo tanto, este Agente



conoce la dirección actual de la terminal móvil. Esto lo logra sabiendo la dirección local, que es fija, y además él sabe la dirección de auxilio que en el instante preciso de la comunicación tiene, porque sabemos que en el siguiente instante esta dirección puede cambiar. Fases del IP Móvil Las Fases que comprenden al direccionamiento móvil de IP son las siguientes:

• Descubrimiento de la Dirección de Auxilio por parte de la terminal móvil en cada paso por diferentes redes.

• Registro de la Dirección de Auxilio en el Agente Local para que él pueda hacer la conexión o tuneleo de los datagramas.

• Túnel desde el Agente Local a la Dirección de Auxilio para que la información sea entregada a la terminal móvil.

Problemas de IP Móvil Algunos problemas que conlleva el uso de IP Móvil son los siguientes:

• El encaminamiento en triángulo es ineficiente: esto es porque, dependemos de la velocidad de la máquina que esta funcionando como agente y si esta falla toda la comunicación se pierde.

• La creación de túneles nos genera costos extras en nuestras conexiones. • Cuello de botella en el Agente Local: esto es debido a la carga de

registros que tiene que manejar. • Implicaciones de seguridad en cortafuegos: esto es porque el Agente

Local es el que esta dando salida a todos los paquetes, si no se protege dicha máquina, entonces todos los paquetes que son enviados y recibidos pueden ser tomados.

5.3.2.2 LANs inalámbricas WLAN son las siglas en inglés de Wireless Local Area Network. Es un sistema de comunicación de datos flexible muy utilizado como alternativa a la LAN cableada o como una extensión de ésta. Las WLAN han adquirido importancia en muchos campos incluido el de la medicina.



Una WLAN transmite y recibe datos utilizando ondas electromagnéticas, en lugar del par trenzado, coaxial o fibra óptica utilizado en las LAN convencionales, y que proporciona conectividad inalámbrica de igual a igual (peer to peer), dentro de un edificio, de una pequeña área residencial/urbana o de un campus universitario. En EEUU proliferan estas redes para acceso a Internet, en donde hay más de 4.000 zonas de acceso, y en Europa es previsible que pronto se extiendan. Las WLAN se encuadran dentro de los estándares desarrollados por el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) para redes locales inalámbricas. Otras tecnologías como HyperLAN apoyada por el ETSI, y el nuevo estándar HomeRF para el hogar, también pretenden acercarnos a un mundo sin cables y, en algunos casos, son capaces de operar en conjunción y sin interferirse entre sí. Otro aspecto a destacar es la integración de las WLAN en entornos de redes móviles de 3G (UMTS) para cubrir las zonas de alta concentración de usuarios (los denominados hot spots), como solución de acceso público a la red de comunicaciones móviles. Como todos los estándares 802 para redes locales del IEEE, en el caso de las WLAN, también se centran en los dos niveles inferiores del modelo OSI, el físico y el de enlace, por lo que es posible correr por encima cualquier protocolo (TCP/IP o cualquier otro) o aplicación, soportando los sistemas operativos de red habituales, lo que supone una gran ventaja para los usuarios que pueden seguir utilizando sus aplicaciones habituales, con independencia del medio empleado, sea por red de cable o por radio. La especificación IEEE 802.11 define redes locales inalámbricas que emplean ondas de radio en la banda de 2.4 GHz y 5 GHz conocido como espectro esparcido. Las velocidades típicas de esta tecnología son 11 Mbps en la especificación IEEE 802.11b y está en desarrollo la especificación IEEE 802.11a en la banda de 5 GHz que alcanzará velocidades de hasta 54 Mbps. Las redes locales inalámbricas se han vuelto muy populares hoy en día, éstas pueden proveer acceso a Internet por ejemplo a estudiantes alrededor de un



campus universitario utilizando una computadora portátil provista con una tarjeta con acceso inalámbrico. Una de las áreas de mayor potencial en la evolución futura de las telecomunicaciones es la transmisión inalámbrica digital de banda ancha. Idealmente, un sistema inalámbrico de banda ancha permitiría la transmisión de cualquier tipo de información digitalizada (audio, vídeo, datos) desde cualquier lugar y en cualquier momento, con posibilidad de transmitir en tiempo real de ser necesario. Entre las ventajas de un sistema inalámbrico sobre uno cableado podemos mencionar: Movilidad: la cual apoya la productividad y la efectividad con que se presta el servicio. Aunque los costos iniciales son mayores que los que supondría un sistema cableado, a lo largo del tiempo los gastos de operación pueden ser significativamente menores. Menor tiempo de instalación y puesta en marcha del sistema. La instalación es más sencilla. Existe completa flexibilidad en cuanto a la configuración del sistema. Se pueden tener diversas topologías para satisfacer los requerimientos de aplicaciones e instalaciones específicas. La aparición de un sistema de esta naturaleza requiere la conjunción de varios factores, entre las que podemos mencionar:

• Utilización de técnicas de espectro esparcido, que en combinación con esquemas de sectorización y/o celularización permitirán un uso más eficiente del cada vez más congestionado (y costoso) espectro radioeléctrico.

• Desarrollo de sistemas de microondas económicos y compactos que operen a frecuencias cada vez más altas.

• Nuevos y mejores modelos de propagación que permitan una mejor predicción de los factores que afectan la calidad del servicio, tales como los efectos de trayectorias múltiples, pérdidas por ocultamiento y atenuación por lluvia, entre otros.

• Desarrollo de "antenas inteligentes" que compensen las variaciones en el canal de transmisión y que minimicen los efectos de la interferencia co-canal.

• Técnicas de modulación robustas que permitan altas velocidades de transmisión con bajo BER en presencia de condiciones adversas.

• Esquemas de enrutamiento apropiados que garanticen cobertura adecuada y al mismo tiempo calidad de servicio.

• Nueva legislación conducente a una mejor administración y control del espectro radioeléctrico.

Aunque no todos los factores mencionados existen en la actualidad, un sistema inalámbrico es en muchos casos es la alternativa más atractiva en aplicaciones tales como telefonía, interconexión de redes, acceso a Internet de alta velocidad, teleconferencia, etc.



Ejemplos de uso: ventas al pormenor, almacenes, manufacturación, etc., de modo que se transmite la información en tiempo real a un procesador central. Cada día se reconocen más este tipo de redes es un amplio número de negocios y se augura una gran extensión de las mismas y altas ganancias. Es clara la alta dependencia en los negocios de las redes de comunicación. Por ello la posibilidad de compartir información sin que sea necesario buscar una conexión física permite mayor movilidad y comodidad. Así mismo la red puede ser más extensa sin tener que mover o instalar cables. Respecto a la red tradicional la red sin cable ofrece las siguientes ventajas:

• Movilidad: Información en tiempo real en cualquier lugar de la organización o empresa para todo usuario de la red. El que se obtenga en tiempo real supone mayor productividad y posibilidades de servicio.

• Facilidad de instalación: Evita obras para tirar cable por muros y techos. • Flexibilidad: Permite llegar donde el cable no puede. • Reducción de costos: Cuando se dan cambios frecuentes o el entorno es

muy dinámico el costo inicialmente más alto de la red sin cable es significativamente más bajo, además de tener mayor tiempo de vida y menor gasto de instalación.

• Escalabilidad: El cambio de topología de red es sencillo y trata igual a las redes grandes o pequeñas.

Cómo trabajan las WLAN Se utilizan ondas de radio o infrarrojos para llevar la información de un punto a otro sin necesidad de un medio físico. Las ondas de radio son normalmente referidas a portadoras de radio ya que éstas únicamente realizan la función de llevar la energía a un receptor remoto. Los datos a transmitir se superponer a la portadora de radio y de este modo pueden ser extraídos exactamente en el receptor final. Esto es llamado modulación de la portadora por la información que está siendo transmitida. De este modo la señal ocupa más ancho de banda que una sola frecuencia. Varias portadoras pueden existir en igual tiempo y espacio sin interferir entre ellas, si las ondas son transmitidas a distintas frecuencias de radio. Para extraer los datos el receptor se sitúa en una determinada frecuencia ignorando el resto. En una configuración típica de LAN sin cable los puntos de acceso (transceiver) conectan la red cableada de un lugar fijo mediante cableado normalizado. EL punto de acceso recibe la información, la almacena y transmite entre la WLAN y la LAN cableada. Un único punto de acceso puede soportar un pequeño grupo de usuarios y puede funcionar en un rango de al menos treinta metros y hasta varios cientos. El punto de acceso (o la antena conectada al punto de acceso) es normalmente colocado en alto pero podría colocarse en cualquier lugar en que se obtenga la cobertura de radio deseada.



El usuario final accede a la red WLAN a través de adaptadores. Estos proporcionan una interfaz entre el sistema de operación de red del cliente (NOS: Network Operating System) y las ondas, vía una antena. La naturaleza de la conexión sin cable es transparente al sistema del cliente. Configuraciones de la WLAN Pueden ser simples o complejas. La más básica se da entre dos computadoras equipados con tarjetas adaptadoras para WLAN, de modo que pueden poner en funcionamiento una red independiente siempre que estén dentro del área que cubre cada uno. Esto es llamado red de igual a igual. Cada cliente tendría únicamente acceso a los recursos de otro cliente pero no a un servidor central. Este tipo de redes no requiere administración o preconfiguración. Red Peer to Peer Instalando un Punto de Acceso (APs) se puede doblar el rango al cuál los dispositivos pueden comunicarse, pues actúan como repetidores. Desde que el punto de acceso se conecta a la red cableada cualquier cliente tiene acceso a los recursos del servidor y además actúan como mediadores en el tráfico de la red en la vecindad más inmediata. Cada punto de acceso puede servir a varios clientes, según la naturaleza y número de transmisiones que tienen lugar. Existen muchas aplicaciones en el mundo real con entre 15 y 50 dispositivos cliente en un solo punto de acceso. Cliente y punto de acceso Los puntos de acceso tienen un rango finito, del orden de 150m en lugares cerrados y 300m en zonas abiertas. En zonas grandes como por ejemplo un campus universitario o un edificio es probablemente necesario más de un punto de acceso. La meta es cubrir el área con células que solapen sus áreas de modo que los clientes puedan moverse sin cortes entre un grupo de puntos de acceso. Esto es llamado "roaming". Múltiples puntos de acceso y "roaming" Para resolver problemas particulares de topología, el diseñador de la red puede elegir usar un Punto de Extensión (EPs) para aumentar el número de puntos de acceso a la red, de modo que funcionan como tales pero no están enganchados a la red cableada como los puntos de acceso. Los puntos de extensión funcionan como su nombre indica: extienden el rango de la red retransmitiendo las señales de un cliente a un punto de acceso o a otro punto de extensión. Los puntos de extensión pueden encadenarse para pasar mensajes entre un punto de acceso y clientes lejanos de modo que se construye un "puente" entre ambos.



Uso de un punto de extensión Uno de los últimos componentes a considerar en el equipo de una WLAN es la antena direccional. Por ejemplo: se quiere una Lan sin cable a otro edificio a 1Km de distancia. Una solución puede ser instalar una antena en cada edificio con línea de visión directa. La antena del primer edificio está conectada a la red cableada mediante un punto de acceso. Igualmente en el segundo edificio se conecta un punto de acceso, lo cuál permite una conexión sin cable en esta aplicación. 5.3.2.3 WANs inalámbricas WWAN (Wireless Wide Area Networks) son redes extensas sin cables. Ejemplos de este tipo de redes son las redes de telefonía móvil: GSM, GPRS, TDMA, etc. El alcance de una WWAN puede llegar hasta 30 km, lo que ofrece a los usuarios un modo de seguir conectados mientras se desplazan o están alejados de otra infraestructura de red.

Las redes de área amplia inalámbricas transmiten los datos mediante señales de telefonía móvil, a través de un proveedor de servicios de telefonía móvil, con velocidades de conexión similares a las de acceso telefónico de 56K. Las velocidades de descarga están limitadas a 53 Kbps. Las velocidades de carga son inferiores (unos 30 Kbps). Las velocidades pueden variar según el estado de la línea y el fabricante del módem. Es necesario disponer de una línea telefónica analógica y del servicio. (El alcance y la velocidad varían según el entorno y otros factores.) Su alcance ofrece a los usuarios un modo de conectarse mientras se desplazan o están alejados de otra infraestructura de red. Redes inalámbricas tipo WAN/MAN :



• Telefonía celular analógica y celular • Radiolocalización de dos vías (pagers) • Radio enlaces terrestres de microondas • Láser/infrarrojo • WLL (Wireless Local Loop) • LMDS/MMDS • Comunicaciones por satélite

En la categoría MAN/WAN tenemos primeramente al acceso a Internet por medio de telefonía celular. Aunque originalmente la telefonía celular fue utilizada para la transferencia de voz, muy pronto se desarrollaron protocolos para poder transferir datos a través de esta tecnología inalámbrica. La primera de ellas fue CDPD (Celullar Digital Packet Data), desarrollada a mediados de los 90s por AT&T. CDPD provee la transmisión inalámbrica de datos digitales como Internet a través de la telefonía celular. Actualmente provee transferencias hasta 14.4 Kbps si se emplea la técnica de acceso múltiple CDMA (Code Division Multiple Access), mientras que en TDMA (Time Division Multiple Access) está limitada a 9.6 Kbps. CDPD se utiliza actualmente para transmitir mensajes breves a PDAs y correo electrónico a teléfonos celulares. Es posible el acceso limitado a Internet debido a que CDPD está basado en el protocolo de Internet TCP/IP. Con CDPD es posible transferir datos a través de redes públicas basadas en circuitos como en paquetes. En un futuro cercano aparecerán nuevos servicios con más alta velocidad basados en CDPD a través de redes basadas en paquetes. Otro protocolo que provee acceso a Internet es WAP (Wireless Access Protocol). Con WAP son posibles las comunicaciones de datos entre redes inalámbricas a celulares y otros dispositivos portátiles como PDAs, radiolocalizadores, teléfonos inteligentes, etc. Las especificaciones de WAP soportan la mayoría de los servicios y protocolos de las redes celulares de hoy en día tales como GSM, PDC, TDMA, CDMA y CDPD. Uno de los principales objetivos de la especificación WAP es permitir que dispositivos portátiles se interconecten con las redes inalámbricas independientemente de sistemas operativos y protocolos. Es por eso que WAP utiliza un lenguaje conocido como WML (Wireless Markup Language) que permite la conexión entre las redes y los dispositivos portátiles. Otras tecnologías WAN/MAN que permiten el acceso a Internet a altas velocidades son MMDS, LMDS, WLL, enlaces de microondas terrestres, vía láser infrarrojo y comunicaciones vía satélite.



5.4. Aplicaciones Móviles Las aplicaciones para dispositivos móviles básicamente son programas capaces de ejecutarse en ambientes operativos reducidos. Tales ambientes o sistemas operativos reducidos o compactos se instalan en dispositivos móviles como PDA (Personal Digital Assistant), como por ejemplo, Pocket PC, Palm, Smart Phone, etc. Los dos tipos de aplicaciones típicas para dispositivos móviles son:

1. Aplicaciones “Stand-Alone”: Son aplicaciones que directamente se instalan sobre el dispositivo móvil.

2. Aplicaciones Web: El dispositivo móvil únicamente utiliza un navegador para Internet y se conecta por red (alámbrica o inalámbrica) al servidor Web que hospeda la aplicación.

A continuación se ejemplifica la creación de aplicaciones sencillas correspondientes a estos dos tipos de programas.

EJERCICIO Creación de una Aplicación Windows para una Pocket PC. En el siguiente ejemplo, vamos a crear una aplicación Windows para una Pocket PC y una Aplicación Web, la cuál vamos a acceder desde la Pocket PC. Primero veremos la creación de la Aplicación para SmartDevice en C#, la cuál después se va a correr en el emulador de una Pocket PC.

1. Damos clic en Visual Studio .NET 2003



2. Seleccionamos Archivo -> Nuevo -> Proyecto

3. Nos va a aparecer la siguiente ventana, dentro de la cuál haremos clic

en Proyectos de Visual C# y después en Aplicación para SmartDevice.

4. Damos un Nombre y una Ubicación para nuestro Proyecto.

5. En la siguiente pantalla, seleccionamos Pocket PC y Aplicación para Windows.



6. Esta es la ventana de desarrollo de nuestra Aplicación para

SmartDevice.

7. Del cuadro de herramientas arrastre dos Botones y una Etiqueta .



8. Dentro de las propiedades del button1, ajustamos el campo Text a “SI”.

9. Hacemos lo mismo para el button2, solo que Text lo ajustamos a “NO”.

10. Dentro de las propiedades del label1, ajustamos Text a vacío, sin texto.

11. Damos doble clic en el campo de button1 y veremos el código para

dicho botón.



12. Dentro del método button1_Clic colocamos la siguiente línea

label1.Text = "Diste clic en " + button1.Text;

13. Hacemos lo mismo pero con el button2 y colocamos la siguiente línea label1.Text = "Diste clic en " + button2.Text;

14. Los métodos deben quedar como se ve en la siguiente figura.



15. Seleccione Generar -> Generar Solución. El programa debe generarse sin problemas.

16. Seleccione Depurar -> Iniciar.

17. En el cuadro de texto seleccione Emulador de Pocket PC 2002 y de clic en Implementar.

18. Se abre el emulador del Pocket PC y la Aplicación que generamos.



19. Corra la Aplicación. De clic en alguno de los botones. Vea las salidas

que genera el programa.



Creación de una Aplicación Web ASP.NET para Pocket PC En el siguiente ejemplo, vamos a crear una aplicación Web ASP.NET para que sea accedido desde una Pocket PC. La aplicación se creará primero en el IIS de una máquina, para posteriormente acceder a dicha WebForm por medio de la Pocket PC. Primero crearemos la Aplicación ASP.NET.

1. Damos clic en Visual Studio .NET 2003

2. Seleccionamos Archivo -> Nuevo -> Proyecto

3. Nos va a aparecer la siguiente ventana, dentro de la cuál haremos clic en Proyectos de Visual C# y después en Aplicación para SmartDevice.



4. Damos un Nombre y una Ubicación para nuestro Proyecto.

5. Esta es la ventana de desarrollo de la Aplicación Web ASP.NET



6. Seleccionamos dos botones y una etiqueta, del cuadro de controles y los colocamos en la WebForm

7. Dentro de las propiedades del Button1, ajustamos la propiedad Text a “SI”.



8. Dentro de las propiedades del Button2, ajustamos la propiedad Text a

“NO”.

9. Dentro de las propiedades del Label1, ajustamos la propiedad Text a vacío.

10. Seleccione Generar -> Generar Solución. El programa debe generarse sin

errores.



11. Seleccione Depurar -> Iniciar 12. Se abre una nueva ventana del Browser con la dirección donde se genero

su Aplicación Web ASP.NET



13. Ahora vuelva a abrir la Aplicación que generó anteriormente para SmartDevice y corra de nuevo el emulador.

14. Para abrir de nuevo la Aplicación anterior seleccione la Pestaña Página

de Inicio dentro de Visual Studio .NET.

15. Seleccione el Proyecto de SmartDevice con el nombre que le haya puesto.

16. Seleccione Depurar -> Iniciar. En el cuadro de Texto seleccione Emulador

de Pocket PC 2002 y de clic en Implementar.



17. Una vez abierto el emulador de clic en el Icono de Windows y seleccione Explorer.

18. En la ventana del Explorador seleccione Ver -> Barra de Direcciones



19. En la Barra de Direcciones copie la dirección de la Aplicación Web que generó, solo que en vez de poner local, coloque la dirección IP de la máquina de donde desea correr la Aplicación Web. La dirección debe ser del tipo: http://XXX.XXX.XXX.XXX/WebApplication1/WebForm1.aspx

20. Pruebe la Aplicación. Los resultados deben ser los siguientes





Estándar

Puntos de Atributo

Obtenidos (10-9) (8.5-7) (6.5-0)

Aplicación de la

Información









(10-9) (8.5-7) (6.5-0)



material elaborando








Los estudiantes no



del tema.


CURSO INTRODUCCI“N A LOS SISTEMAS DISTRIBUIDOS - Inicio

Documents

Transcript of CURSO INTRODUCCI“N A LOS SISTEMAS DISTRIBUIDOS - Inicio