• Author / Uploaded
• Pablo Bautista

Citation preview

Tecnológico Nacional de México Campus Pachuca “El Hombre Alimenta el Ingenio en Contacto con la Ciencia.”

Sistemas Distribuidos 1 Materia

Lic. Gutiérrez Madrigal José Luis Docente

Comunicación Unidad 3

ALUMNO

NO. CONTROL

Bautista Hernández Pablo

12200594

Ingeniería en Sistemas Computacionales Enero - Julio 2017

3 COMUNICACIÓN La comunicación entre procesos en sistemas con un único procesador se lleva a cabo mediante el uso de memoria compartida entre los procesos. En los sistemas distribuidos, al no haber conexión física entre las distintas memorias de los equipos, la comunicación se realiza mediante la transferencia de mensajes.

Comunicación Cliente-Servidor Sockets Es un mecanismo de comunicación, Permite a los sistemas cliente/servidor ser desarrollados Localmente en una sola máquina A través de redes. Funciones tales como impresión, utilerías de red, tales como login y ftp, usualmente usan sockets para comunicarse. Socket designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiarse cualquier flujo de datos, generalmente de manera fiable y ordenada. Un socket queda definido por una dirección IP, un protocolo y un número de puerto.

Explicación detallada Para que dos programas puedan comunicarse entre sí es necesario que se cumplan ciertos requisitos:  

Que un programa sea capaz de localizar al otro. Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad.

Para ello son necesarios los tres recursos que originan el concepto de socket: 

Un protocolo de comunicaciones, que permite el intercambio de octetos.

 

Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora. Un número de puerto, que identifica a un programa dentro de una computadora.

Los sockets permiten implementar una arquitectura cliente-servidor. La comunicación ha de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicación, por este motivo se denomina programa servidor. Un socket es un fichero existente en la máquina cliente y en la máquina servidora, que sirve en última instancia para que el programa servidor y el cliente lean y escriban la información. Esta información será la transmitida por las diferentes capas de red.

Comunicación RPC Otro paso en el diseño de un sistema operativo distribuido plantea las llamadas a procedimientos remotos o RPCs. Los RPC amplían la llamada local a procedimientos, y los generalizan a una llamada a un procedimiento localizado en cualquier lugar de todo el sistema distribuido. En un sistema distribuido no se debería distinguir entre llamadas locales y RPCs, lo que favorece en gran medida la transparencia del sistema. Una de las dificultades más evidentes a las que se enfrenta el RPC es el formato de los parámetros de los procedimientos. Un ejemplo es la posibilidad de que, en un sistema distribuido formado por diferentes tipos de ordenadores, un ordenador con formato little endian llamara a un procedimiento de otro ordenador con formato big endian, etc. Este problema se podría solucionar si tenemos en cuenta que ambos programas conocen el tipo de datos de los parámetros, o estableciendo un estándar en el formato de los parámetros, de forma que sea usado de forma única. Por último, queda por solucionar la tolerancia a fallos. Una llamada a un procedimiento remoto puede fallar por motivos que antes no existían, como la pérdida de mensajes o el fallo del cliente o del servidor durante la ejecución del procedimiento.

La limitación del RPC más clara en los sistemas distribuidos es que no permite enviar una solicitud y recibir respuesta de varias fuentes a la vez, sino que la comunicación se realiza únicamente entre dos procesos. Por motivos de tolerancia a fallos, bloqueos, u otros, sería interesante poder tratar la comunicación en grupo.

Comunicación en grupo La comunicación en grupo tiene que permitir la definición de grupos, así como características propias de los grupos, como la distinción entre grupos abiertos o que permiten el acceso y cerrados que lo limitan, o como la distinción del tipo de jerarquía dentro del grupo. Igualmente, los grupos han de tener operaciones relacionadas con su manejo, como la creación o modificación. Tolerancia a fallos Que el sistema de archivos sea tolerante a fallos implica que el sistema debe guardar varias copias del mismo archivo en distintos ordenadores para garantizar la disponibilidad en caso de fallo del servidor original. Además, se ha de aplicar un algoritmo que nos permita mantener todas las copias actualizadas de forma consistente, o un método alternativo que sólo nos permita acceder al archivo actualizado, como invalidar el resto de copias cuando en cualquiera de ellas se vaya a realizar una operación de escritura. El uso de memorias cache para agilizar el acceso a los archivos también es recomendable, pero este caso requiere analizar con especial atención la consistencia del sistema.

3.1 Paso de mensajes La aproximación más básica a la comunicación entre procesos es el paso de mensajes. En este paradigma, los datos que representan mensajes se intercambian entre dos procesos, un emisor y un receptor. El paso de mensajes es el paradigma fundamental para aplicaciones distribuidas. Un proceso envía un mensaje que representa una petición. El mensaje se entrega a un receptor, que procesa la petición y envía un mensaje como respuesta. En secuencia, la réplica puede disparar

posteriores peticiones, que lleven a sucesivas respuestas, y así en adelante.

Las operaciones básicas necesarias para dar soporte al paradigma de paso de mensajes son enviar y recibir. Para comunicaciones orientadas a conexión, también se necesitan las operaciones conectar y desconectar. (Los detalles sobre las operaciones, tales como argumentos o valores de retorno, se darán junto a las respectivas herramientas y funcionalidades en los capítulos posteriores.) Por medio del grado de abstracción proporcionado por este modelo, los procesos interconectados realizan la entrada y la salida hacia el otro proceso, de una forma similar a la utilizada en la entrada/salida (E/S) de ficheros. Como en el caso de la E/S de ficheros, las operaciones sirven para encapsular el detalle de la comunicación a nivel del sistema operativo, de forma que el programador puede hacer uso de operaciones para enviar y recibir mensajes sin preocuparse por el detalle subyacente. La interfaz de programación de aplicaciones de sockets (que se estudiará en el Capítulo 4) se basa en este paradigma. Usando un socket, una construcción lógica, dos procesos pueden intercambiarse datos de la siguiente forma: Un emisor escribe o inserta un mensaje en el socket; en el otro extremo, un receptor lee o extrae un mensaje del socket. La implementación de nuestro sistema de subastas usando paso de mensajes y el paradigma cliente-servidor se describirá en la próxima sección. Los procesos de un S.O. pueden comunicarse entre sí al compartir espacios de memoria, ya sean variables compartidas o buffers, o a través de las herramientas provistas por las rutinas de comunicación de interprocesos.

Para comunicar procesos en un ambiente distribuido, además del uso de un sistema de nombres de recursos, se necesita un esquema de comunicación lógico que dé sentido a estas transacciones. El sistema operativo provee mínimamente dos primitivas, enviar y recibir, normalmente llamadas send y receive, pero tendrá que implementar un enlace de comunicación entre los procesos. Este enlace puede ser unidireccional o multidireccional según permita la comunicación en solo uno o en varios sentidos, y dependiendo de la forma en que se dispara la comunicación.

Comunicación Síncrona. Quien envía permanece bloqueado esperando a que llegue una respuesta del receptor antes de realizar cualquier otro ejercicio.

Comunicación Asíncrona. Quien envía continúa con su ejecución inmediatamente después de enviar el mensaje al receptor.

Comunicación Persistente. El receptor no tiene que estar operativo al mismo tiempo que se realiza la comunicación, el mensaje se almacena tanto tiempo como sea necesario para poder ser entregado.

Comunicación Transitoria. El mensaje se descarta si el receptor no está operativo al tiempo que se realiza la comunicación. Por lo tanto, no será entregado.

Comunicación Directa. Las primitivas enviar y recibir usan directamente el nombre del proceso con el que se comunican. Por ejemplo:

“enviar (mensaje, A) envía un mensaje al proceso A. Obsérvese que la primitiva sólo debe especificar cuál va a ser el proceso Destino, ya que el proceso fuente viene direccionado en la comunicación.” Las operaciones básicas Send y Receive se definen de la siguiente manera: Send (P, mensaje); envía un mensaje al proceso P. Receive (Q, mensaje); espera la recepción de un mensaje por parte del proceso Q.

Comunicación Indirecta. Es aquella donde la comunicación está basada en un gateway, enrutador, puente o switch, ya que el emisor y el receptor están a distancia.

Comunicación Simétrica. Todos los procesos pueden enviar o recibir. También establece una llamada bidireccional para el caso de dos procesos.

Comunicación Asimétrica. Un proceso puede enviar, los demás procesos solo reciben. También llamada unidireccional o no interactiva. Es el esquema típico de algunos servidores de Internet.

Comunicación con uso de buffers automático. El transmisor se bloquea hasta que el receptor recibe el mensaje completo, pero éste tiene capacidad para recibirlo, aunque no esté listo para procesarlo. La comunicación y sincronización en S.O.D. es más compleja y se establece en canales lentos y menos confiables que los buses internos de una computadora, lo que incorpora problemas como la pérdida de mensajes, la llegada de datagramas desordenados, la heterogeneidad de los nodos y su diferente rendimiento, etc. La forma natural de comunicar y sincronizar procesos en los sistemas distribuidos es mediante paso de mensajes; los procesos intercambian

mensajes mediante las primitivas que además establecen una extensión de los semáforos en la que se transmite más información en un contexto sincronizado. Una de las ventajas de emplear mecanismos de comunicación y sincronización basados en paso de mensaje es la portabilidad de las soluciones programadas para diferentes arquitecturas de computadoras, incluidos los sistemas con memoria compartida, otra ventaja es que no existe el problema del acceso en exclusión mutua a datos compartidos, ya que no hay contienda por el acceso al recurso, sino una fila en espera. Un sistema operativo o lenguaje de programación podría ofrecer herramientas, algunas basadas en memoria compartida y otras basadas en la comunicación mediante paso de mensajes, por lo que podríamos llegar a tener un mismo proceso o hilo que empleara las dos posibilidades. Los siguientes son aspectos relevantes en el diseño de los sistemas de paso de mensajes:   

Identificación en el proceso de comunicación. Sincronización. Características del canal (capacidad, flujo de datos, etc).

3.2 Objetos distribuidos Habitualmente, los sistemas distribuidos se han venido construyendo utilizando conceptos utilizados en los sistemas operativos tradicionales. El concepto de proceso y los mecanismos de comunicación entre procesos son los más destacables. En los últimos tiempos, el auge de las tecnologías orientadas a objetos ha llevado a los diseñadores a plantearse la forma en que pueden aplicarlas para la construcción de sistemas distribuidos. La aplicación de dichas tecnologías no se ha detenido en la construcción en sí del sistema distribuido, sino en la forma que éste proporciona sus servicios y en la manera en que se construyen las aplicaciones de usuario. El problema que surge inmediatamente es cómo construir el sistema distribuido para que cubra dichas expectativas. La construcción se

deberá realizar basándose en uno de los dos modelos siguientes: el modelo de procesos (o cliente/servidor) o el modelo de objetos.

Modelo basado en objetos El modelo basado en objetos afronta la construcción del sistema identificando las abstracciones clave del dominio del problema. Dichas entidades son vistas como agentes autónomos que colaboran para llevar a cabo un comportamiento de nivel superior. El modelo basado en objetos pone énfasis en la identificación y caracterización de los componentes del sistema, que serán modelados con objetos. Informalmente, se puede definir un objeto como una colección formada por una serie de datos y un conjunto de operaciones definidas sobre ellos, de tal manera que se garantiza la ocultación de los detalles internos. Para alterar el estado de un objeto, se tendrá que invocar la operación apropiada, de tal forma que el conjunto de las operaciones definidas para un objeto definirá colectivamente su comportamiento. El mecanismo de encapsulación de los objetos se encarga de que esto sea así. También se pueden utilizar los mecanismos de herencia y polimorfismo como herramientas adicionales de estructuración para el diseño y construcción de sistemas distribuidos. La aplicación de conceptos de orientación a objetos tal cual para la construcción de sistemas distribuidos es denominada en [BG96] aproximación aplicativa. Un ejemplo clásico del uso de estos mecanismos es el sistema operativo Choices [CIR+93]. El modelo basado en objetos no difiere del tradicional paradigma de OO en el que cada entidad es un objeto con una interfaz de mensajes que proporcionan sus operaciones. En el modelo basado en objetos para los sistemas distribuidos, cada recurso compartido se representa como un objeto. Los objetos son identificados de forma unívoca y se pueden mover por la red sin cambiar su identidad. Cuando un proceso requiere el acceso a un recurso, envía un mensaje al objeto correspondiente. Este mensaje es despachado al método adecuado que resuelve la petición y envía un mensaje de respuesta al proceso adecuado.

El modelo basado en objetos es simple y flexible. Ofrece una visión uniforme de todos los recursos. Como en los modelos descritos anteriormente, los objetos pueden actuar como clientes y servidores. Sin embargo, en el modelo cliente/servidor, el esquema de nombrado de los recursos dependía del gestor mientras que aquí todos los recursos se referencian de manera uniforme.

3.2.1 RMI RMI (Remote Method Invocation) [Sun98] fue diseñado para permitir la invocación de métodos remotos de objetos entre distintas máquinas Java (ubicadas en el mismo o en distintos computadores) de manera transparente. Integra directamente un modelo de objetos distribuidos en el lenguaje Java a través de un conjunto de clases e interfaces. Un objeto RMI es un objeto cuyos métodos pueden ser invocados desde otra máquina Java, incluso a través de una red. Cada objeto remoto implementa una o más interfaces remotas que especifican qué operaciones pueden ser invocadas por los clientes. Cualquier otra operación pública que tenga el objeto pero que no aparezca en la interfaz remota no podrá ser utilizada por los clientes remotos. Los clientes invocan dichos métodos exactamente igual que si fueran métodos locales, quedando ocultos los detalles de la comunicación. Se utilizan los denominados sustitutos (stub) y esqueletos (skeleton), que actúan de intermediarios entre los objetos local y remoto. Los sustitutos y los esqueletos son generados de manera automática por el compilador rmic. Desde el punto de vista del programador, los objetos remotos se manipulan de la misma manera que los locales, a través de referencias. Realmente, una referencia a un objeto remoto apunta a una referencia a un sustituto local que lo representa, y que es el encargado de transmitir los parámetros de la invocación al computador remoto y recibir de él el valor de retorno. La manipulación de objetos remotos tiene que tener en cuenta: Cómo obtener una referencia a un objeto remoto. Gestión de excepciones específicas de la invocación de métodos remotos.

Por su parte, un esqueleto es el encargado de recoger los parámetros que recibe del sustituto a través de la red, invocar de manera local al objeto remoto y devolver el resultado de nuevo a través de la red al sustituto del objeto que realizó la invocación. A diferencia de una invocación local, una invocación RMI pasa los objetos locales que forman parte de la lista de parámetros por copia (por valor), dado que una referencia a un objeto local sólo sería útil en una máquina virtual única. RMI utiliza el servicio de serialización de objetos para aplanar el estado de un objeto local y colocarlo en el mensaje a enviar a la máquina virtual remota. Si el objeto es no-serializable, no se puede usar como parámetro. También son pasados por valor los parámetros de tipos primitivos. Por otro lado, RMI pasa los objetos remotos (objetos que implementan una interfaz remota) por referencia. RMI proporciona interfaces y clases para buscar objetos remotos, cargarlos y ejecutarlos de manera segura. Adicionalmente, proporciona un servicio de nombrado un tanto primitivo (servicio de nombrado no persistente y espacio de nombres plano) que permite localizar objetos remotos y obtener referencias a ellos, de manera que se puedan invocar sus métodos. La utilización de objetos remotos lleva consigo la aparición de nuevas situaciones de error, de tal forma que el programador deberá manejar el conjunto de nuevas excepciones que pueden ocurrir durante una invocación remota. RMI incluye una característica de recolección de basura distribuida, que recolecta aquellos objetos servidores que no son referenciados por ningún cliente de la red.

3.2.2 CORBA CORBA (Common Object Request Broker Architecture) [OMG99] es una especificación definida por el OMG (Object Management Group) para la creación y uso de objetos remotos, cuyo objetivo en proporcionar interoperabilidad entre aplicaciones en un entorno distribuido y heterogéneo. OMG es el mayor consorcio mundial de compañías de software (alrededor de 800) entre las que destaca la ausencia de Microsoft, que tiene su propia plataforma de objetos distribuidos: DCOM (Distributed Component Object Model, Modelo de Objetos Componentes Distribuido).

Es conocido como un tipo de “middleware”, ya que no realiza las funciones de bajo nivel necesarias para ser considerado un sistema operativo. A pesar de que debe funcionar sobre sistemas operativos tradicionales, realiza muchas de las operaciones que tradicionalmente se han considerado del dominio de los sistemas operativos para entornos distribuidos. Los objetos CORBA se diferencian de los objetos de los lenguajes habituales de programación en que: 

pueden estar localizados en cualquier lugar de la red,



pueden ejecutarse en cualquier plataforma (hardware + sistema operativo), y



pueden estar escritos en cualquier lenguaje.

Un cliente puede utilizar un objeto CORBA sin saber dónde está ni en qué lenguaje ha sido implementado; lo único que tiene que conocer es la interfaz que publica dicho objeto. El corazón de CORBA es su ORB (Object Request Broker). El ORB es el responsable de: 

Buscar la implementación del objeto servidor.



Prepararlo para recibir la petición.



Poner en contacto el cliente con el servidor.



Transportar los datos (parámetros y valores de retorno) entre uno y otro, transformándolos adecuadamente.

En definitiva, es el responsable de que ni cliente ni servidor necesiten conocer ni la localización ni el lenguaje de implementación del otro. Los objetos CORBA se tienen que definir con el lenguaje de definición de interfaces IDL (Interface Definition Language) que, como su propio nombre indica, se limita a definir la interfaz del objeto y no su implementación. La definición del objeto incluye la definición de sus atributos, sus métodos (denominados operaciones) y las excepciones que eleva. La implementación del objeto se tiene que realizar con algún lenguaje de programación que tenga enlaces con IDL (en la actualidad existen enlaces con lenguajes como C, C++, Java, Smalltalk, Ada, etc.).

IDL proporciona herencia múltiple de interfaces, de manera que las interfaces derivadas heredan las operaciones y los tipos definidos en las interfaces base. Todas las interfaces derivan de una interfaz raíz, denominada Object, la cual proporciona servicios que son comunes a todos los objetos CORBA, como duplicación y liberación de referencias a objetos, etc. La compilación de una definición de objetos en IDL genera, entre otras cosas, un sustituto (stub) y un esqueleto (skeleton), para el cliente y servidor, respectivamente. El sustituto crea una petición de servicio al ORB a instancias del cliente y representa al objeto servidor. El esqueleto, por su parte, entrega las peticiones a la implementación del objeto CORBA. Es posible utilizar para la definición de los objetos una serie de tipos basicos y construidos que no tienen la categoría de objetos y que son similares a otros tipos encontrados en la mayoría de los lenguajes de programación: char, boolean, array, struct, etc. Las interfaces de objetos se almacenan en un repositorio de interfaces (IR, Interface Repository), que proporciona un almacenamiento persistente de las declaraciones de interfaces realizadas en IDL. Los servicios proporcionados por un IR permiten la navegación por la jerarquía de herencia de un objeto y proporcionan la descripción de todas las operaciones soportadas por un objeto. La función principal del IR es proporcionar la información de tipos necesaria para realizar peticiones utilizando la Interfaz de Invocación Dinámica, aunque puede tener otros propósitos, como servir de almacenamiento de componentes reutilizables para los desarrolladores de aplicaciones. La compilación de las declaraciones IDL en algún lenguaje de programación permite a los clientes invocar operaciones en objetos conocidos, pero algunas aplicaciones necesitan poder realizar llamadas a objetos sin tener conocimiento de sus interfaces en tiempo de compilación. En esencia, la Interfaz de Invocación Dinámica (DII, Dynamic Invocation Interface) es un stub genérico de clientes capaz de enviar cualquier petición a cualquier objeto, interpretando en tiempo de ejecución los parámetros de la petición y los identificadores de la operación. CORBA permite que la implementación de los objetos sea todo lo variada que se quiera. En unos casos, varias interfaces IDL pueden estar implementadas por un solo programa, y, en otros casos, una interfaz IDL

puede estar implementada por una serie de programas, uno para cada operación. Un Adaptador de Objetos (OA, Object Adapter) proporciona los medios por los que varios tipos de implementaciones de objetos utilizan los servicios del ORB, como por ejemplo: 

generación de referencias de objetos.



invocación de métodos de objetos.



seguridad.



activación y desactivación de objetos e implementaciones.

Dependiendo del ORB subyacente, un OA puede elegir entre proporcionar estos servicios delegando en el ORB o realizando el trabajo él mismo. En cualquier caso, las implementaciones de los objetos no van a estar al tanto de la diferencia, ya que únicamente usan la interfaz proporcionada por el OA. Para que un cliente pueda realizar una petición a un objeto servidor, deberá utilizar una referencia al objeto. Una referencia siempre refiere el mismo objeto para la que fue creada, durante tanto tiempo como exista el objeto. Las referencias son tanto inmutables como opacas, de manera que un cliente no puede “entrar” en una referencia y modificarla. Sólo el ORB sabe que es lo que hay “dentro” de la referencia. Cuando se pasan objetos como parámetros en invocaciones a métodos, lo que realmente se pasan son referencias a dichos objetos. El paso de objetos como parámetro es, por tanto, por referencia. En la última revisión importante de CORBA (revisión 2.3, de Junio de 1999) se introdujo la propuesta de objetos-por-valor (objects-by-value), que extienden el modelo de objetos de CORBA tradicional para permitir el paso de objetos por valor dentro de los parámetros de los métodos. Para conseguirlo se introduce un nuevo tipo IDL denominado el tipo valor (value). Cuando un ORB encuentra un objeto de tipo valor dentro de un parámetro, automáticamente pasa una copia del estado del objeto al receptor. En contraste, el ORB pasará por referencia cualquier objeto declarado vía una interfaz IDL.

Un tipo valor se puede entender a medio camino entre una interfaz IDL y una estructura (del estilo de las del lenguaje C). La sintaxis del valor permite especificar algunos detalles de implementación (por ejemplo, su estado), que no forman parte de una interfaz IDL. Además, se pueden especificar métodos locales para operar con dicho estado. A diferencia de las interfaces, los métodos de los tipos valor no pueden ser invocados remotamente. Los CORBAservices son un conjunto de servicios que aumentan y complementan los servicios proporcionados por el ORB. Todos ellos son accesibles a través de un conjunto de interfaces especificadas en IDL. Se relacionan, a continuación, los servicios incluidos en el estándar: Life Cycle Service: define las operaciones para crear, copiar, mover y eliminar objetos. Persistence Service: proporciona una interfaz para almacenar objetos de manera persistente en una amplia variedad de servidores de almacenamiento: bases de datos orientadas a objetos (ODBMSs), bases de datos relacionales (RDBMSs) y ficheros tradicionales. Naming Service: permite a los objetos localizar otros objetos, incluso utilizando servicios de directorio como X.500, NIS+, NDS, LDAP, etc. Event Service: permite a los objetos registrar dinámicamente su interés por eventos específicos. Este servicio define el objeto denominado event channel, que recolecta y distribuye eventos entre los objetos, que no necesitarán conocerse entre sí. Concurrency Control Service: proporciona un gestor de cerraduras (lock, en inglés). Transaction Service: proporciona una coordinación de dos fases (two-phase commit) utilizando transacciones planas o anidadas. Relationship Service: proporciona una forma de crear asociaciones dinámicas entre objetos que no se conocen entre sí. Externalization Service: proporciona una manera estándar de introducir/enviar al exterior datos de un objeto utilizando un mecanismo de tipo flujo de bytes (stream). Query Service: proporciona operaciones de consulta sobre objetos. Es un superconjunto de SQL.

Licensing Service: proporciona operaciones para medir la utilización de objetos para asegurar una compensación justa por su uso. Permite controlar el coste por sesión, por nodo, por creación de instancia, etc. Properties Service: proporciona operaciones que permiten asociar valores con nombre (propiedades) a cualquier objeto. Time Service: proporciona interfaces para sincronizar relojes en un entorno de objetos distribuidos. También proporciona operaciones para definir y gestionar eventos dependientes del tiempo. Security Service: proporciona seguridad en el entorno de objetos distribuidos, soportando autenticación, listas de control de acceso, confidencialidad, etc. Trader Service: proporciona “páginas amarillas” para los objetos. Permite a los objetos publicitar sus servicios y pujar por la realización de trabajos. Collection Service: proporciona interfaces para crear y manipular las collecciones más comunes.

3.2.3 COM COM (Component Object Model) [Mic95] es la tecnología de definición y manipulación de componentes de Microsoft que proporciona un modelo de programación y un estándar binario para los mismos. DCOM [Mic98] (de Distributed COM) es la tecnología que extiende COM para permitir a los objetos componentes residir en máquinas remotas y está disponible desde la aparición de Windows NT 4.0. A partir de ahora se utilizarán los términos COM y DCOM indistintamente. Un objeto COM se define en términos de las interfaces individuales que soporta (una o más) y que están definidas en la clase (objeto clase) a la que pertenece. Cada interfaz está identificada por un identificador único (IID, Interface Identifier), que es un caso particular de identificador global y único (GUID, Global Unique Identifier). Los GUID son valores de 128 bits que se garantizan únicos estadísticamente en el espacio y en el tiempo. Las interfaces son el único medio de interactuar con un objeto COM. Un cliente que desea utilizar los servicios de un objeto habrá de obtener primero un puntero a una de sus interfaces.

Los objetos clase implementan una o más interfaces y se identifican por un identificador de clase (CLSID, Class Identifier). Los CLSID son también un caso particular de GUID. Con el fin de que un cliente pueda crear un objeto COM, es necesario describir su clase utilizando el lenguaje de definición de interfaces (IDL, Interface Definition Language). La compilación de dicha descripción genera un representante (proxy) para los clientes y un sustituto (stub) para el servidor. COM no proporciona la herencia como instrumento para lograr la reutilización. En su lugar proporciona los mecanismos de contención y agregación. El polimorfismo es conseguido cuando diferentes clases soportan la misma interfaz, permitiendo a una aplicación utilizar el mismo código para comunicarse con cualquiera de ellas. El objetivo principal de COM es proporcionar un medio por el que los clientes pueden hacer uso de los objetos servidores, sin tener en cuenta que pueden haber sido desarrollados por diferentes compañías utilizando diferentes lenguajes de programación. Con el fin de lograr este nivel de interoperabilidad, COM define un estándar binario, que especifica cómo se dispone un objeto en memoria principal en tiempo de ejecución. Cualquier lenguaje que pueda reproducir dicha disposición en memoria podrá crear objetos COM. Además del objetivo de la interoperabilidad, COM tiene otros objetivos: 

Proporcionar una solución para los problemas de versiones y evolución.



Proporcionar una visión del sistema de los objetos.



Proporcionar un modelo de programación singular.



Proporcionar soporte para capacidades de distribución.

En el modelo de programación COM, los clientes COM se conectan a uno o más objetos COM. Cada objeto COM expone sus servicios a través de una o más interfaces, que no son más que agrupaciones de funciones relacionadas semánticamente. La implementación compilada de cada objeto COM está contenida en un módulo binario (exe o dll) denominado servidor COM. Un único servidor COM es capaz de contener la implementación compilada de varios objetos COM.

Un servidor COM puede estar enlazado al proceso cliente (in-process server), puede ejecutarse en un proceso distinto del cliente pero en la misma máquina (local server) o bien, puede ejecutarse en un proceso separado en una máquina distinta, incluso en un sistema operativo distinto (remote server). Para la comunicación con objetos situados en espacios de direcciones distintos del espacio de direcciones del cliente, se utilizan intermediarios en la forma de representantes y sustitutos. El modelo de programación COM define que un servidor COM debe exponer objetos COM, un objeto COM debe exponer sus servicios y un cliente COM debe usar los servicios de objetos COM. Para comunicarse con un objeto que no es local, COM emplea un mecanismo de comunicación entre procesos que es transparente a la aplicación, incluso en lo relativo a la localización del objeto. Todos los objetos COM tienen que implementar una interfaz particular, denominada IUnknown. Esta interfaz es el corazón de COM y es utilizada para negociación de interfaces en tiempo de ejecución (preguntar al objeto qué interfaces soporta y obtener punteros a las mismas), gestión del ciclo de vida del objeto y agregación. Cada objeto mantiene una cuenta de referencia que es incrementada cada vez que un cliente solicita un puntero para una interfaz o pasa una referencia al mismo. Cuando la interfaz deja de ser utilizada por el cliente, la cuenta de referencia se decrementa. Las operaciones de incremento y decremento son realizadas de manera explícita por el cliente invocando funciones pertenecientes a la interfaz.

3.3 Síncrona y asíncrona Síncrona La transmisión síncrona es una técnica que consiste en el enviar una trama de datos (conjunto de caracteres) que configura un bloque de información comenzando con un conjunto de bits de sincronismo (SYN) y terminando con otro conjunto de bits de final de bloque (ETB). En este caso, los bits de sincronismo tienen la función de sincronizar los relojes existentes tanto en el emisor como en el receptor, de tal forma que estos controlan la duración de cada bit y carácter.

Dicha transmisión se realiza con un ritmo que se genera centralizadamente en la red y es el mismo para el emisor como para el receptor. La información se transmite entre dos grupos, denominados delimitadores (8 bits). Características Los bloques a ser transmitidos tienen un tamaño que oscila entre 128 y 1,024 bytes. La señal de sincronismo en el extremo fuente, puede ser generada por el equipo terminal de datos o por el módem. Cuando se transmiten bloques de 1,024 bytes y se usan no más de 10 bytes de cabecera y terminación, el rendimiento de transmisión supera el 99 por 100. Ventajas   

Posee un alto rendimiento en la transmisión Son aptos para transmisiones de altas velocidades (iguales o mayores a 1,200 baudios de velocidad de modulación) El flujo de datos es más regular.

También llamada Transmisión Sincrónica. A todo el conjunto de bits y de datos se le denomina TRAMA. Desventaja 

Los equipamientos son de tecnología más completa y de costos más altos

Asíncrona La transmisión asíncrona tiene lugar cuando el proceso de sincronización entre emisor y receptor se realiza en cada palabra de código transmitido. Esta sincronización se lleva a cabo a través de unos bits especiales que definen el entorno de cada código. También se dice que se establece una relación asíncrona cuando no hay ninguna relación temporal entre la estación que transmite y la que recibe. Es decir, el ritmo de presentación de la información al destino no tiene por qué coincidir con el ritmo de presentación de la información por la fuente. En estas situaciones tampoco se necesita garantizar un ancho de banda determinado, suministrando solamente el que esté en ese momento disponible. Es un tipo de relación típica para la transmisión de datos. En este tipo de red el receptor no sabe con precisión cuando recibirá un mensaje. Cada carácter a ser transmitido es delimitado por un bit de información denominado de cabecera o de arranque, y uno o dos bits denominados de terminación o de parada. El bit de arranque tiene dos funciones de sincronización de reloj del transmisor y del receptor. El bit o bits de parada, se usan para separar un carácter del siguiente.

Después de la transmisión de los bits de información se suele agregar un bit de paridad (par o impar). Dicho Bit sirve para comprobar que los datos se transfieran sin interrupción. El receptor revisa la paridad de cada unidad de entrada de datos. Partiendo desde la línea de transmisión en reposo, cuando tiene el nivel lógico 1, el emisor informa al receptor de que va a llegar un carácter, para ello antepone un bit de arranque (Start) con el valor lógico 0. Una vez que el bit Start llega al receptor este disparará un reloj interno y se quedará esperando por los sucesivos bits que contendrá la información del carácter transmitido por el emisor. Una vez que el receptor recibe todos los bits de información se añadirá al menos un bit de parada (Stop) de nivel lógico 1, que repondrán en su estado inicial a la línea de datos, dejándola así preparada para la siguiente transmisión del siguiente carácter. Es usada en velocidades de modulación de hasta 1,200 baudios. El rendimiento se basa en el uso de un bit de arranque y dos de parada, en una señal que use código de 7 bits más uno de paridad (8 bits sobre 11 transmitidos) es del 72 por 100. Ventajas y desventajas del modo asíncrono: 

   

En caso de errores se pierde siempre una cantidad pequeña de caracteres, pues éstos se sincronizan y se transmiten de uno en uno. Bajo rendimiento de transmisión, dada la proporción de bits útiles y de bits de sincronismo, que hay que transmitir por cada carácter. Es un procedimiento que permite el uso de equipamiento más económico y de tecnología menos sofisticada. Se adecua más fácilmente en aplicaciones, donde el flujo transmitido es más irregular. Son especialmente aptos, cuando no se necesitan lograr altas velocidades.

3.4 Consideraciones de seguridad Debido a ellas surge la necesidad de proteger la integridad y la privacidad de la información, y otros recursos que pertenecen a individuos y organizaciones, se conjuga ambos mundos: el físico y el digital. Nace, como es lógico, de la necesidad de compartir recursos. En el mundo físico, las organizaciones adoptan políticas de seguridad para poder compartir recursos dentro de unos límites especificados. Las políticas de seguridad se hacen cumplir con la ayuda de los mecanismos de seguridad. En el mundo electrónico, la distinción entre políticas de seguridad y los mecanismos también es importante: sin ella, sería difícil determinar si un sistema particular es seguro. Las políticas de seguridad son independientes de la tecnología empleada, así como el instalar una cerradura en una puerta no garantiza la seguridad del edificio a menos que haya una política de uso (por ejemplo. que la puerta esté cerrada cuando no esté vigilada). Los mecanismos de seguridad que describiré no garantizan, por sí mismos, la seguridad de un

sistema.

Evolución de las Necesidades de Seguridad

A continuación describiremos los mecanismos que permiten hacer cumplir las políticas de seguridad en los sistemas distribuidos. La distinción entre políticas de seguridad y mecanismos de seguridad es de utilidad cuando se diseñan sistemas seguros, pero no es fácil estar seguro de que cierto conjunto de mecanismos de seguridad implementan completamente las políticas de seguridad deseadas. Este es un modelo de seguridad diseñado para ayudar en el análisis de las amenazas de seguridad potenciales en un sistema distribuido. Resumiendo el modelo de seguridad como sigue: • Los procesos encapsulan recursos y acceden a comunicarse con los clientes a través de sus interfaces. Los usuarios u otros procesos pueden estar autorizados para operar sobre los recursos y estos deben estar protegidos contra accesos no autorizados.

• Los procesos interactúan en la red, que es compartida. Los enemigos o atacantes pueden acceder a la red y podrán copiar, leer o introducir mensajes arbitrarios, dirigidos hacia cualquier destino y simular que provienen de cualquier otro. Este modelo de seguridad identifica las características de los sistemas de seguridad expuestos a ataques. La Emergencia de la Criptografía en el Dominio Público La criptografía proporciona la base para la mayoría de los sistemas de seguridad de los computadores. La criptografía tiene una larga y fascinante historia. La necesidad de comunicaciones militares seguras y la correspondiente necesidad del enemigo de interceptarlas y desencriptarlas ha fomentado la inversión de mucho esfuerzo intelectual, por parte de los mejores cerebros matemáticos de cada época. Pero sólo en tiempos recientes la criptografía emerge de la trastienda en la que fue puesta por la clase dirigente de políticos y militares que solían controlar su desarrollo y su aplicación. Hoy en día es un tema de investigación abierta y con una comunidad de investigadores amplia y muy activa. La reciente apertura es, en su mayor medida, resultado del importante crecimiento del interés en las aplicaciones no militares de la criptografía y los requisitos de seguridad de los sistemas de computadores distribuidos. Esto desembocó en la existencia, por primera vez, de una comunidad autosuficiente de criptógrafos aparte del entorno militar. Irónicamente, esta apertura al público de la criptografía ha traído consigo un mayor avance de las técnicas criptográficas, su resistencia a los ataques criptoanalíticos y la comodidad con la que se despliegan las medidas criptográficas. La criptografía de clave pública es fruto de esta apertura. Un ejemplo más, el algoritmo de encriptación estándar DES fue inicialmente un secreto militar. Su eventual publicación y los esfuerzos exitosos para romperlo

han traído consigo el desarrollo de algoritmos de encriptación de clave secreta mucho más resistentes. Otro producto secundario útil ha sido el desarrollo de una terminología y aproximación común. Un ejemplo de esto último es la adopción de un conjunto de nombres familiares para los protagonistas (principales) involucrados en las transacciones que hay que asegurar. El uso de nombres familiares para los principales y los atacantes ayuda a aclarar y acercar al mundo las descripciones de los protocolos de seguridad y los potenciales ataques sobre ellos, lo que supone un paso importante hacia la identificación de sus debilidades. Alice Bob Carol Dave Eve Mallory Sara

Primer participante. Segundo participante. Otro participante en los protocolos a tres o cuatro bandas. Participante en protocolos a cuatro bandas. Fisgón. Atacante malevolente. Un servidor.

3.5 Opciones tecnológicas (ASMX, WCF, RMI, etc.) Un desarrollador puede incluir en sus sitios soluciones sentencias, es decir, instrucciones que consuman Web Services de terceros o propios como por ejemplo aquellos que proporcionan los datos meteorológicos para una localidad determinada, las cotizaciones de determinadas monedas, la cartelera de películas, el calendario o agenda de un especialista médico, etc. Pensando un poco más en forma comercial, ¿Qué pasaría si por ejemplo estuvieras trabajando en tu procesador de texto en un idioma para el cual no tienes un corrector ortográfico ni sintáctico instalado (quizás no exista para instalar), pero deseas realizar la revisión del documento a toda costa? Bien, perfectamente podría haber una opción en el menú de este procesador que de alguna forma localice un Web Service en Internet que brinde esta funcionalidad, y lo más interesante aún para quien lo haya desarrollado es que puede solicitar al usuario que se subscriba para su uso. Como ves, todos ganan en esta transacción. El ejemplo anterior muestra una realidad a la que no podemos estar ajenos. Es un replanteo de la estrategia utilizada por los desarrolladores quienes ahora, al realizar una aplicación, no deben pensar únicamente en el lugar físico donde la misma va a

ejecutarse sino en que esa aplicación deberá estar interconectada con otras computadoras, corriendo otras aplicaciones quizás en otras plataformas y lenguajes, pero usando protocolos y estándares universales. El intercambio se intensificará muchísimo más y quizás existan por ejemplo “proveedores de dominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugar de crear toda la lógica para manejar las tablas y el cargado de los datos para el concepto PAIS, se limite a consumir un Web Service que me tome esta información de algún lugar en Internet. Imagino una reutilización aún mayor de funcionalidades y una colaboración e intercambio de lógica a nivel mundial. Quizás sea muy ambicioso en este planteo. Pasando al terreno más técnico y práctico de este artículo, existen algunas consideraciones y conceptos que es necesario mencionar para comenzar a entender el tema:  Un Web Service puede ser registrado para poder dejarlo a disposición de otros usuarios y para que los mismos puedan localizarlo. Un mecanismo para registrar estos servicios es por medio de UDDI, sigla que corresponde a Universal Description , Discovery and Integration, un “repositorio de Web Services”. Para registrar un servicio tendrás que tener en cuenta que debes suministrar la información de tu empresa, en qué categorías ubicarías tu servicio y la interfaz a utilizar para consumir este servicio.  El mecanismo utilizado por un Web Service para especificar de qué forma hay que proporcionarle los datos, de manera tal que cualquiera pueda interaccionar con el mismo, es por medio de lenguaje XML. Esta información se almacena en un archivo llamado WSDL (Web Services Description Language), el cual contiene un documento XML junto con la descripción de ciertos mensajes SOAP y cómo deben intercambiarse, así como también dónde está el recurso del servicio y con qué protocolo debe dialogar quien lo consume.  El protocolo de comunicación utilizado es el SOAP generalmente, el cual es relativamente sencillo de utilizar.  Los Web Services utilizan protocolos comúnmente conocidos y difundidos tales como el formato XML, TCP/IP como protocolo de transporte y HTTP como protocolo de transferencia de hipertexto.

¿Qué es SOAP? SOAP es un protocolo que define el formato XML para los mensajes de intercambio en el uso de un Web Service. Para aquellos programadores que solían utilizar llamadas del tipo RPC, SOAP también las soporta. Adicionalmente, es posible mediante SOAP definir un mensaje HTTP y este punto es de especial interés puesto que el protocolo imprescindible para Internet es HTTP.

Un servicio Web o WebService es un servicio ofrecido por una aplicación que expone su lógica a clientes de cualquier plataforma mediante una interfaz accesible a través de la red utilizando tecnologías (protocolos) estándar de Internet.

Por ejemplo, una aplicación como Access está formada por un conjunto de componentes que ofrecen una serie de servicios, como el acceso a datos, la impresión de informes, el diseño de tablas... La idea de los servicios es la misma, aunque éstos no tienen por qué estar en el mismo ordenador que el cliente y además son accedidos a través de un servidor Web y de un modo independiente de la plataforma, utilizando protocolos estándar (HTTP, SOAP, WSDL, UDDI).

Para crear un servicio puede utilizarse cualquiera de los lenguajes disponibles en la plataforma .NET. Una vez creado el servicio, para conseguir que sea accesible por los consumidores, es necesario describirlo utilizando un lenguaje estándar llamado WSDL (Web Service Description Language). Los clientes del servicio podrán estar creados en cualquier lenguaje y ejecutarse sobre cualquier sistema operativo y hardware, lo único necesario es que sean capaces de obtener y entender la descripción WSDL de un servicio. Un archivo WSDL es, en realidad, un archivo XML en el que se identifica el servicio y se indica el esquema para poder utilizarlo, así como el protocolo o protocolos que es posible utilizar.

Una vez dispone de esta información, el cliente puede comunicarse con el servicio utilizando protocolos como HTTP o SOAP (SOAP añade invocación de métodos a HTTP, aunque es posible hacerlo con peticiones HTTP-GET y/o HTTP-POST en lugar de SOAP). Además de describir un servicio para que pueda ser utilizado por los clientes es importante publicar el servicio de modo que pueda ser encontrado por clientes que no conozcan necesariamente el componente que ofrece el servicio, pero que busquen un servicio de sus características. Esto se logra mediante el estándar UDDI (Universal Description, Discovery and Integration Registry). Realmente se trata de un servicio mundial en el que los proveedores de servicios pueden registrarlos de modo gratuito. Un Servicio Web es una entidad programable, proporcionado un elemento particular de funcionalidades, como Lógica de aplicación. Puede ser usado internamente por cualquier aplicación o externamente, a través de la internet por cualquier número de aplicaciones usando estándares como XML (Lenguaje de Marca Extensible) y HTTP (Protocolo de Transferencia de Hipertexto). Algunos Especificaciones Núcleos de un servicio Web son: 

SOAP: Es un Protocolo basado en XML.



WSDL: Es un formato XML describe la interfaz pública a los servicios Web



UDDI: Es un protocolo para publicar y descubrir Metadatos.

Existe dos vía primaria para crea Servicios en ASP.NET: 1. Servicios Web basado en el Modelo ASP.NET (.asmx). 2. Servicios Web basado en Microsoft Windows Communication Foundation (WCF). La diferencia fundamental entre ellos es: Los Servicios Web de ASP.NET se hospedan directamente en Microsoft Internet Information Service IIS, cuales son procesados y ejecutados a través de protocolo de transferencia de Hipertexto (HTTP). Ahora Los Servicios Web de Windows Communication Foundation (WCF) pueden trabajar con una variedad de Hosts, Protocolos y Clientes. Hosts: IIS, Aplicaciones Consola residente, Servicio de Windows, etc.

Protocolos: HTTP, TCP, MSMQ, Binary HTTP, etc. Clientes: Windows, Web, Mobile, etc.