El desarrollo de aplicaciones distribuidas requirió de nuevas técnicas de diseño y de generación de modelos. También trajo nuevos problemas. Existen 2 tipos distintos de arquitecturas que se utilizaron antes de .NET para hacer aplicaciones distribuidas: Llamadas a Procedimiento Remoto (RPC) Arquitecturas basadas en mensajes
Se verán los problemas técnicos que este tipo de arquitecturas tiene y finalmente como los Estándares Web son utilizados para hacer la nueva generación de aplicaciones distribuidas
Hay una serie de problemas comunes en el diseño de las aplicaciones distribuidas:
La compatibilidad de los Tipos de Datos: Distintos sistemas operativos tienen diferentes tipos de datos que no son siempre compatibles entre sí.
Fallas del Servidor: Debido a que los componentes pueden ser remotos, una falla de cualquiera de ellos puede hacer que toda la aplicación falle .
Fallas del Cliente: El servidor debe saber como responder a las fallas del cliente.
Reintento de llamadas: Si por ejemplo, se hace una llamada a un método en un servidor para generar una orden de compra muy grande, y el servidor responde pero se pierde la respuesta por fallas de red, no es muy eficiente volver a enviar la orden de compra.
Seguridad: En aplicaciones distribuidas los problemas de seguridad se multiplican. Por ejemplo, se debe considerar como: Autenticar a los usuarios Autorizarlos a acceder a los recursos Encriptar la información que viaja por la red Evitar ataques de denegación de servicio
Sincronización de la hora: Hay operaciones que dependen de la fecha y la hora. Por ejemplo, no es lógico en una aplicación procesar un envío de mercadería antes de haber recibido la orden de compra. Si el cliente y el servidor tienen fechas distintas, se debe generar un mecanismo de sincronización de hora para evitar este problema.
La arquitectura basada en RPC Qué es RPC: RPC son llamadas a procedimientos o funciones en sistemas remotos, es decir en máquinas distintas a la máquina local. Transparencia de localización: El desarrollador utiliza los componentes sin necesidad de saber su ubicación física. Con RPC tanto en el cliente como en la máquina donde reside el componente hay subsistemas que se ocupan de la comunicación y el intercambio de datos.
Llamadas Sincrónicas: En RPC las llamadas a los procedimientos son sincrónicas. Esto quiere decir que cuando una aplicación hace una llamada a un procedimiento RPC debe esperar que el servidor le responda para poder continuar con el procesamiento. Esto presenta problemas en un entorno distribuido, mucho más si pensamos en distribuir los componentes en Internet.
Las llamadas sincrónicas con RPC tienen desventajas: Uso de múltiples componentes: Si su aplicación distribuida depende de muchos componentes que se llaman entre sí, esto hace que la aplicación sea más susceptible a fallas. Balanceo de Carga y Tolerancia a fallos: Es el problema de como las aplicaciones descubren la información necesaria para poder conectarse otros servidores en el caso de que el que esta utilizando falle. O de como balancean el procesamiento entre varios servidores Esto no es posible con RPC.
Priorización: Con RPC es muy difícil detectar que servidores están con mucha carga de trabajo y derivar la llamada RPC a otro servidor menos ocupado.
Picos de carga de Trabajo: RPC no puede manejar los picos de carga de trabajo que puede tener un servidor si tiene llamadas RPC de muchos clientes.
La arquitectura basada en Mensajes Otra arquitectura para desarrollar aplicaciones distribuidas es la basada en mensajes.
Esta tecnología es asincrónica. Lo que significa que el cliente puede seguir con el procesamiento mientras espera la respuesta del servidor. Utiliza mensajes en vez de llamadas a funciones.
Tiene desventajas:
Se verán los problemas técnicos que este tipo de arquitecturas tiene y finalmente como los Estándares Web son utilizados para hacer la nueva generación de aplicaciones distribuidas
Hay una serie de problemas comunes en el diseño de las aplicaciones distribuidas:
La compatibilidad de los Tipos de Datos: Distintos sistemas operativos tienen diferentes tipos de datos que no son siempre compatibles entre sí.
Fallas del Servidor: Debido a que los componentes pueden ser remotos, una falla de cualquiera de ellos puede hacer que toda la aplicación falle .
Fallas del Cliente: El servidor debe saber como responder a las fallas del cliente.
Reintento de llamadas: Si por ejemplo, se hace una llamada a un método en un servidor para generar una orden de compra muy grande, y el servidor responde pero se pierde la respuesta por fallas de red, no es muy eficiente volver a enviar la orden de compra.
Seguridad: En aplicaciones distribuidas los problemas de seguridad se multiplican. Por ejemplo, se debe considerar como: Autenticar a los usuarios Autorizarlos a acceder a los recursos Encriptar la información que viaja por la red Evitar ataques de denegación de servicio
Sincronización de la hora: Hay operaciones que dependen de la fecha y la hora. Por ejemplo, no es lógico en una aplicación procesar un envío de mercadería antes de haber recibido la orden de compra. Si el cliente y el servidor tienen fechas distintas, se debe generar un mecanismo de sincronización de hora para evitar este problema.
La arquitectura basada en RPC Qué es RPC: RPC son llamadas a procedimientos o funciones en sistemas remotos, es decir en máquinas distintas a la máquina local. Transparencia de localización: El desarrollador utiliza los componentes sin necesidad de saber su ubicación física. Con RPC tanto en el cliente como en la máquina donde reside el componente hay subsistemas que se ocupan de la comunicación y el intercambio de datos.
Llamadas Sincrónicas: En RPC las llamadas a los procedimientos son sincrónicas. Esto quiere decir que cuando una aplicación hace una llamada a un procedimiento RPC debe esperar que el servidor le responda para poder continuar con el procesamiento. Esto presenta problemas en un entorno distribuido, mucho más si pensamos en distribuir los componentes en Internet.
Las llamadas sincrónicas con RPC tienen desventajas: Uso de múltiples componentes: Si su aplicación distribuida depende de muchos componentes que se llaman entre sí, esto hace que la aplicación sea más susceptible a fallas. Balanceo de Carga y Tolerancia a fallos: Es el problema de como las aplicaciones descubren la información necesaria para poder conectarse otros servidores en el caso de que el que esta utilizando falle. O de como balancean el procesamiento entre varios servidores Esto no es posible con RPC.
Priorización: Con RPC es muy difícil detectar que servidores están con mucha carga de trabajo y derivar la llamada RPC a otro servidor menos ocupado.
Picos de carga de Trabajo: RPC no puede manejar los picos de carga de trabajo que puede tener un servidor si tiene llamadas RPC de muchos clientes.
La arquitectura basada en Mensajes Otra arquitectura para desarrollar aplicaciones distribuidas es la basada en mensajes.
Esta tecnología es asincrónica. Lo que significa que el cliente puede seguir con el procesamiento mientras espera la respuesta del servidor. Utiliza mensajes en vez de llamadas a funciones.
Tiene desventajas:
Procesamiento del Mensaje: El programador debe manejar en el código el empaquetamiento y des empaquetamiento de los mensajes. Además debe controlar su validez Interoperabilidad: Los sistemas de mensajería utilizan tecnología propietaria. Se necesita software para permitir el envío de mensajes y la comunicación los distintos sistemas.
Flujo de Carga y secuenciamiento de los mensajes: Se necesita de algún mecanismo para coordinar el flujo y la secuencia de los mensajes. Por ejemplo, no se puede procesar una orden de envío de un producto antes de que se procesa la orden de pedido del producto.
Los estándares Web Tanto RPC como la arquitectura basada en mensajes han sido implementados en forma exitosa por muchas organizaciones. Sin embargo su uso tiene dificultades que se resuelven con la utilización de los protocolos Web estándares.
Problemas con los Protocolos Binarios: Existen varias tecnologías RPC, ninguna estándar, por ejemplo. COM de Microsoft, CORBA y RMI. Todas estas tecnologías utilizan protocolos binarios.
Los estándares Web Tanto RPC como la arquitectura basada en mensajes han sido implementados en forma exitosa por muchas organizaciones. Sin embargo su uso tiene dificultades que se resuelven con la utilización de los protocolos Web estándares.
Problemas con los Protocolos Binarios: Existen varias tecnologías RPC, ninguna estándar, por ejemplo. COM de Microsoft, CORBA y RMI. Todas estas tecnologías utilizan protocolos binarios.
Los protocolos binarios tienen desventajas:
Firewall: Para permitir la comunicación entre un cliente y un servidor que se encuentra detrás de un firewall los administradores deben dejar un rango variable de puertos abiertos. Esto es un riesgo de seguridad muy alto.
Interoperatividad: Las distintas tecnologías RPC implican protocolos binarios de comunicación distintos. Para que interoperen entre sí se deben traducir los paquetes de red lo que puede significar pérdida de información. Para evitar este problema las organizaciones utilizan un solo modelo RPC.
Formato de los Datos: Cada protocolo RPC utiliza un formato de datos distintos. La traducción de un formato a otro presenta dificultades.
La nueva arquitectura: Los protocolos que utiliza Internet resuelven muchos de los problemas anteriormente mencionados. Internet y la Web: Los protocolos TCP e IP fueron desarrollados originalmente para conectar redes distintas y crear una red de redes. Esta red de redes terminó convirtiéndose en el Internet que conocemos hoy. A finales de 1990, Tim Berners-Lee inventó WWW (World Wide Web).
WWW es lo que hoy conocemos como la Web. La Web es una red globalmente interconectada de documentos hipertexto. Utiliza 2 tecnologías principales: El lenguaje HTML y el protocolo HTTP para la comunicación. HTML: Es un lenguaje de marcas (Tags). Las marcas definen como el Explorador de Internet presenta la información. Los documentos que tienen estas marcas son llamados documentos hipertexto.
Ventajas de HTTP:
Interoperatividad: Las distintas tecnologías RPC implican protocolos binarios de comunicación distintos. Para que interoperen entre sí se deben traducir los paquetes de red lo que puede significar pérdida de información. Para evitar este problema las organizaciones utilizan un solo modelo RPC.
Formato de los Datos: Cada protocolo RPC utiliza un formato de datos distintos. La traducción de un formato a otro presenta dificultades.
La nueva arquitectura: Los protocolos que utiliza Internet resuelven muchos de los problemas anteriormente mencionados. Internet y la Web: Los protocolos TCP e IP fueron desarrollados originalmente para conectar redes distintas y crear una red de redes. Esta red de redes terminó convirtiéndose en el Internet que conocemos hoy. A finales de 1990, Tim Berners-Lee inventó WWW (World Wide Web).
WWW es lo que hoy conocemos como la Web. La Web es una red globalmente interconectada de documentos hipertexto. Utiliza 2 tecnologías principales: El lenguaje HTML y el protocolo HTTP para la comunicación. HTML: Es un lenguaje de marcas (Tags). Las marcas definen como el Explorador de Internet presenta la información. Los documentos que tienen estas marcas son llamados documentos hipertexto.
Ventajas de HTTP:
Es el protocolo utilizado para pedir y recibir documentos. El formato de estos documentos puede ser HTML pero también muchos otros más como por ejemplo XML. Los Servicios Web y los clientes pueden intercambiar documentos XML utilizando el protocolo HTTP. HTTP es un Standard usado universalmente
XML- Un formato de datos universal: A pesar de que HTML permite presentar datos, HTML no permite comunicar la estructura de los datos y su relación. XML nació en 1996 para permitir describir la estructura de los datos en un documento. Firewall: Los servidores Web son los responsables de administrar los documentos, que pueden ser accedidos desde Internet pasando por el firewall de la organización y utilizando el protocolo HTTP.
Problemas con la Web:
XML- Un formato de datos universal: A pesar de que HTML permite presentar datos, HTML no permite comunicar la estructura de los datos y su relación. XML nació en 1996 para permitir describir la estructura de los datos en un documento. Firewall: Los servidores Web son los responsables de administrar los documentos, que pueden ser accedidos desde Internet pasando por el firewall de la organización y utilizando el protocolo HTTP.
Problemas con la Web:
Como la Web es una red pública se presentan algunos problemas.
Seguridad: Entre otros problemas se encuentran: el robo de información o la modificación de los datos
Performance: Algunos clientes acceden con conexiones telefónicas lo que puede limitar por su baja velocidad la complejidad de las aplicaciones.
Por lo tanto algunas aplicaciones se deben limitar a la Intranet.
Seguridad: Entre otros problemas se encuentran: el robo de información o la modificación de los datos
Performance: Algunos clientes acceden con conexiones telefónicas lo que puede limitar por su baja velocidad la complejidad de las aplicaciones.
Por lo tanto algunas aplicaciones se deben limitar a la Intranet.
No hay comentarios:
Publicar un comentario