Documente Academic
Documente Profesional
Documente Cultură
INTEGRANTES:
PRESENTADO A:
1. ¿SERVICIOS DE NOMBRES?
2. ¿COMUNICACIÓN DE MENSAJES?
Esta información está disponible para que los usuarios puedan iniciar una sesión en su host,
tener acceso a los recursos y se les concedan los permisos. La información del servicio de
nombres se puede almacenar en archivos, mapas o diferentes formatos de archivos de base de
datos. Estos repositorios de información pueden ser locales en el sistema o estar alojados en
una base de datos o un repositorio basado en red de manera central.
Sin un servicio de nombres central, cada host tendría que conservar su propia copia de esta
información. Si centraliza todos los datos, la administración resulta más fácil.
Los servicios de nombres son fundamentales para cualquier red informática. Entre otras
funciones, los servicios de nombres proporcionan una funcionalidad que realiza lo siguiente.
2. Comunicación de mensajes
Comunicación de mensajes RPC
Las RPC son muy utilizadas dentro de la comunicación cliente-servidor. Siendo el cliente el que
inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando
este de vuelta el resultado de dicha operación al cliente.
El modelo RCP implica un nivel de transparencia de ubicación, a saber, que la llamada a
procedimiento es en gran parte la misma tanto si es local como remota, pero usualmente estas
no son idénticas, entonces las llamadas locales pueden ser distinguidas de las llamadas
remotas. Las llamadas remotas son usualmente más lentas y menos confiables que las llamadas
locales, por lo tanto, distinguirlas es útil.
Existen diversas tecnologías para implementar RPC que no son compatibles entre sí, como ser
el RFC 1057 (RPC de Sun), DCOM (de Microsoft), etc.
R/ RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un
método de manera remota. Forma parte del entorno estándar de ejecución de Java y
proporciona un mecanismo simple para la comunicación de servidores en aplicaciones
distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras
tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará
accesible a través de la red y el programa permanece a la espera de peticiones en un puerto
TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos
proporcionados por el objeto.
Arquitectura
Elementos
Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos
accesibles, y espera a que el cliente los invoque.
Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.
Comunicación de mensajes Corba
R/ Common Object Request Broker Architecture (CORBA) es un estándar definido por Object
Management Group (OMG) que permite que diversos componentes de software escritos en
múltiples lenguajes de programación y que corren en diferentes computadoras, puedan
trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos
heterogéneos.
Su objetivo es ayudar a reducir la complejidad, disminuir los costes y acelerar la introducción de
nuevas aplicaciones informáticas, promoviendo la teoría y la práctica de la tecnología de
objetos en los sistemas distribuidos.
Es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas. No
obstante, también brinda al programador una tecnología orientada a objetos; las funciones
objetos y estos objetos pueden estar en diferentes máquinas, pero el programador accederá a
ellos a través de funciones normales dentro de su programa.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente
necesarios como seguridad y transacciones. Y así este no es un sistema operativo en sí, en
realidad es un middleware.
Características
Para que esto sea posible, es necesario asegurar que los datos son correctamente
intercambiados entre dos lenguajes distintos, para lo cual IDL define los tipos de datos de una
forma independiente del lenguaje con las correspondencias necesarias. Por ejemplo, un tipo
long en C++ de 32 bits puede corresponderse con un int de Java. OMG ha definido bastantes
correspondencias con lenguajes de programación populares, como: C, C++, COBOL, Java,
Smalltalk o Ada.
Tendremos principalmente dos tipos diferentes de IDL en CORBA:
Stub IDL: es la interfaz estática a los servicios declarados en las interfaces IDL, para el
cliente todas las llamadas parecen locales. Actuará como proxy del objeto remoto,
realizando la invocación de métodos remotos, incluyendo la serialización, la recepción
de respuestas y la deserialización. El cliente puede tener tantos stubs como interfaces
IDL existan. Es generado a partir del IDL en el lenguaje de programación del cliente (C,
C++ Java, Smalltalk, Ada,… ) por un compilador IDL.
Skeleton IDL: es el representante estático del cliente en el servidor. Para el servidor
todas las llamadas parecen locales. Es generado a partir del IDL por un compilador IDL y
realiza la deserialización de las invocaciones del cliente.
Características
Modelo de procesado
El modelo de procesado de SOAP está definido como un sistema distribuido, en el que
intervienen diferentes nodos. En un escenario básico, los nodos SOAP se comunican uno
asumiendo el rol de SOAP Sender y SOAP Receiver. Aun así, la especificación define diferentes
tipos de nodos en función del rol que asumen en el envío del mensaje:
Debido al uso de XML para el paso de mensajes, SOAP es considerablemente más lento
que otros middleware como CORBA ya que los datos binarios se codifican como texto.
Para contrarrestar este punto débil en el caso de XML con código binario incrustado se
desarrolló un método optimizado de transmisión de mensajes.
Depende del WSDL (Web Services Description Language).
Al contrario que Java, PHP o Python ciertos lenguajes no ofrecen un apoyo adecuado
para su uso ya sea a nivel de integración o de soporte IDE.