Sistemas distribuidos (página 2)

Partes: 1, 2

Ejemplos

Ejemplos

Ejemplos

Aspectos a tener en cuenta en el proceso de ingeniería
Protocolos de comunicaciones:
Son más importantes que la propia arquitectura distribuida o centralizada. Un buen protocolo permite que se pueda pasar, sin un coste adicional de rediseño o codificación, de una arquitectura centralizada a una distribuida, y viceversa:
Pipes
RPC
SQL Remoto
HTTP
X11
Otros

Aspectos a tener en cuenta
Middleware. Es la herramienta o conjunto de herramientas que nos permitiran gestionar y coordinar los mecanismos de comunicación.
Independiza el servicio y su implementación, del S.O. y protocolos de comunicaciones
Permite la convivencia de distintos servicios en una misma máquina
Modelo tradicional: Monitor de teleproceso
CICS, Tuxedo, Encina
Modelo OO: CORBA

Aspectos a tener en cuenta
Fase de análisis:
Prácticamente no hay diferencias respecto a un S.I. tradicional
Se debe definir la política de empresa: fat client o fat server.
Se debe definir el coste en comunicaciones que puede asumir la organización.

Aspectos a tener en cuenta
Fase de diseño
El diseño de entidades, en raras ocasiones se verán éstas afectadas
Aparecerán nuevos conjuntos de datos en los DFDs. No se trata de nuevas entidades, sino de información que debe viajar entre nodos
Respecto al diseño de tablas, se debe especificar su implementación:
Desde qué nodos debe ser accesible
Qué nivel de acceso se precisa desde cada uno de ellos
Cómo implementarlo

Aspectos a tener en cuenta
Implementación BB.DD. Distribuidas
No hay entornos puramente distribuidos. Debe analizarse, tabla a tabla, qué distribuir, qué centralizar y cómo hacerlo:
Tabla única
Tablas con réplica simétrica on-line
Tablas con réplica simétrica off-line **
Tabla maestra más copias instantáneas
Tabla maestra más copias instantáneas actualizables **
Especial atención a las secuencias !!
Especial atencíón a los conflictos de réplica (**)

Aspectos a tener en cuenta
Diseño de procesos
Se deberán tener en cuenta, no tan sólo los procesos de réplica y su periodicidad, sino el ancho de banda que consuman, máxime si implican tarificación por paquetes trasnmitidos:
Pipes y sockets -> Aproximación analítica
Middleware -> Información a transmitir + Sobrecoste en ancho de banda + Sobrecoste en tiempo de proceso
Protocolos propietarios (SQL) -> Recurrir a benchmarks o referencias del fabricante
Analizados los consumos de ancho de banda y tiempo estimado de proceso, se deberá replantear la idoneidad de ubicación de cada proceso
Extremar las pruebas cuando se requiera diseñar e implementar protocolos de comunicación

Aspectos a tener en cuenta
Fase de pruebas. Debido a la complejidad del sistema, serán necesarias varias fases:
Pruebas de funcionalidad de la aplicación. Se puede llevar a cabo sobre máquinas de desarrollo y estaciones de trabajo de forma paralela
Pruebas de carga del servidor
Pruebas de integridad de datos. Son especialmente importantes en el caso de bases de datos distribuidas
Pruebas transaccionales
Pruebas de red

Desarrollos Web
Caso particular de desarrollo cliente servidor con representación remota, en la cual disponemos de un protocolo standard: HTTP y un middleware denominado WebServer.
Cada página puede desencadenar la solicitud de numerosos peticiones adicionales para finalizar el proceso de representación remota.
Se dispone de un lenguaje standard de definición y formateo de páginas: HTML

Desarrollos Web
Incrustación de la lógica de aplicación en el servidor Web:
CGI: Common Gateware Interface
Cada petición HTTP genera un nuevo proceso, el cual analiza la solicitud y genera un resultado. Cada proceso corresponde a una transacción.
Es flexible, ideal para pequeñas aplicaciones de uso reducido
No escala adecuadamente
Plug-ins
Cada petición HTTP es resuelta por el componente adecuada, dentro del mismo proceso del Web-Server.
Mejor rendimiento
Compromete la seguridad y fiabilidad del servidor Web
Servidor especializado
Facilidad de desarrollo
Buen rendimiento
Rigidez de configuración

Desarrollos Web
Tipos de plug-ins
HTML incrustado en código
Se centran en la lógica
Son fácilmente de optimizables
Ejemplos: servlets, Perl, Python
Código incrustado en HTML
Se centran en el interface de usuario
Son fáciles de crear y modificar
No requieren grandes formalismos
No necesitan una gran formación
Ejemplos: ASP, JSP, PHP

Desarrollo Web
Esquema aplicado a Apache y PHP
Navegador
Apache
Plug-in PHP
Programa
ejecutable
HTTP
Parámetros
proceso
Base de
datos
Página PHP

Nuevos tipos de dispositivos
Dispositivos que acceden hoy a internet:
Internet Explorer, Netscape, Set Top Box, Móviles WAP, PDAs Palm Pilot, Windows CE, …
Previsiones para los próximos años:
2.002 el 50% de las transacciones habituales se podrán realizar desde dispositivos móviles
2.003 el 80% de los usuarios realizarán algún tipo de transacción desde dispositivos móviles
2.004 los se querrán realizar el 100% de las transacciones desde dispositivos móviles
2.005 Se esperan más de 1.000 millones de usuarios móviles de internet

Nuevos tipos de dispositivos
Problema a resolver:
Necesidad de adaptar el interface de usuario a cada tipo de dispositivo
Medidas a tomar:
Separar la lógica de aplicación del interface de usuario
Utilizar métodos estándar de comunicación entre la lógica de aplicación y el interface de usuario
Uso de herramientas que permitan adaptar rápidamente las aplicaciones a los nuevos tipos de dispositivos que irán apareciendo

Nuevos tipos de dispositivos
Tendencia actual
Navegador
Web Server
Páginas HTML
Servidor Aplicaciones
Lógica de negocio
Datos
(Gp:) Base de datos

Interface de usuario
Gestor comunicaciones
Usuario
Móvil
WAP Server
Páginas WML
SQL
XML
–
–
Wml binario
http

Nuevos tipos de dispositivos
Variante de los fabricantes BBDD
Navegador
Web Server
Páginas HTML
Lógica de negocio
Datos
(Gp:) Base de datos

Interface de usuario
Gestor comunicaciones
Usuario
Móvil
WAP Server
Páginas WML
XML
–
–
Wml binario
http

Nuevos tipos de dispositivos
Variante de los fabricantes pasarelas
Navegador
Web Server
Páginas HTML
Lógica de negocio
Datos
(Gp:) Base de datos

Interface de usuario
Gestor comunicaciones
Usuario
Móvil
WAP Server
Reglas de
traducción WML
SQL
–
–
Wml binario
http
Interface de usuario

Estándares de mercado
Estrategia Java
Navegador
Web Server
Lógica de negocio
Datos
Gestor comunicaciones
Usuario
Móvil
WAP Server
Wml binario
http
Interface de usuario
Páginas JSP / Servlets / Java Beans
Enterprise Java Beans
(Gp:) Base de datos

SQL
RMI
–
–

Estándares de mercado
Estrategia .NET
Navegador
Web Server
Lógica de negocio
Datos
Gestor comunicaciones
Usuario
Móvil
WAP Server
Wml binario
http
Interface de usuario
Páginas ASP
OBJECTO COM +
(Gp:) Base de datos

SQL
XML
–
–
Visual Basic

Problemas no resueltos
La gestión de la sesión de usuario es todavía hoy deficiente, debido en parte a la naturaleza del protocolo http
La maleabilidad del interface de usuario es muy limitada si no se quiere sacrificar la portabilidad
La encadenación entre pantallas se realiza de forma artesana. Las herramientas no permiten implementar pantallas recursivas ni fácilmente reutilizables

Estrategia a seguir
Valorar la durabilidad temporal de las tecnologías a aplicar
Separar, en el diseño e implentación de la aplicación, las capas de lógica de aplicación e interface de usuario
Prestar mucha atención a los nuevos tipos de dispositivos
Examinar con lupa los "atajos" ofrecidos por los fabricantes

Costes sistema distribuido
Elementos a valorar:
Coste de las comunicaciones: Valorar alternativas presentadas por los nuevos proveedores de telecomunicaciones. No descartar el tirar líneas propias
Evaluar el coste adicional en hardware, software y gestión que implica una arquitectura distribuida. Si las comunicaciones lo permiten, saldrá más rentable una arquitectura centralizada
El impacto de los protocolos de comunicaciones será vital en el desglose posterior de costes. Se deben dedicar todos los esfuerzos necesarios para evaluar cuál es el protocolo óptimo.

Costes sistema distribuido
Elementos a valorar:
Se ha de tener en cuenta que plantear un sistema distribuido implica la aparición de numerosos problemas que antes no estaban presentes. Estos problemas se deben resolver mediante tecnología, productos, organización y método.
Un sistema bien distribuido puede suponer un pequeño ahorro de costes de gestión y mantenimiento
Un sistema mal distribuido puede comprometer la validez de la información del sistema