Topología de redArquitecturas de red

La arquitectura o topología de red es la disposición física en la que se conectan los nodos de una red de ordenadores o servidores, mediante la combinación de estándares y protocolos.

Define las reglas de una red y cómo interactúan sus componentes. Estos equipos de red pueden conectarse de muchas y muy variadas maneras. La conexión más simple es un enlace unidireccional entre dos nodos. Se puede añadir un enlace de retorno para la comunicación en ambos sentidos. Los cables de comunicación modernos normalmente incluyen más de un cable para facilitar esto, aunque redes muy simples basadas en buses tienen comunicación bidireccional en un solo cable.

En casos mixtos se puede usar la palabra arquitectura en un sentido relajado para hablar a la vez de la disposición física del cableado y de como el protocolo considera dicho cableado. Así, en un anillo con una MAU podemos decir que tenemos una topología en anillo, o de que se trata de un anillo con topología en estrella.

La topología de red la determina únicamente la configuración de las conexiones entre nodos. La distancia entre los nodos, las interconexiones físicas, las tasas de transmisión y/o los tipos de señales no pertenecen a la topología de la red, aunque pueden verse afectados por la misma.

Componentes 1. Hardware. 2. Software. 3. Operatividad. 4. Escenarios. 5. Interconexión. 6. Compatibilidad. 7. Análisis y diseño.

Al principio, la transmisión de datos era un gran problema, que fue resuelto dividiéndolo los procesos en capas, ordenadas de forma piramidal. Mientras más inferior sea una capa, se tratará de un proceso más físico, y mientras más se ascienda, se tratará de un proceso más lógico.

La principal arquitectura de capas es el Modelo OSI.

Componentes En una arquitectura de capas, cada capa realiza funciones y ofrece

servicios.

1. Una capa N ofrece sus servicios a la capa superior N+1. Una capa N+1 solo "ve" los servicios de la capa N.

2. Las capas de un componente se comunican entre si usando interfaces (que no pertenecen a la arquitectura).

3. Una capa de un componente se comunica con su homóloga de otro componente mediante un protocolo.

4. En cada capa existen entidades (generalmente procesos) que realizan las funciones de esa capa. Janun predeterminada

Topología en estrella En su forma más simple, una topología en estrella consta de un switch central,

o hub que actúa como un router para retransmitir los mensajes. Cuando se aplica a redes basadas en bus, este hub central retransmite todas las

transmisiones recibidas desde cualquier nodo periférico a todos los nodos periféricos de la red, a veces incluso al nodo original.

Todos los nodos periféricos se pueden comunicar con los demás transmitiendo o recibiendo del nodo central solamente. Un fallo en la línea de conexión de cualquier nodo con el nodo central provocaría el aislamiento de ese nodo respecto a los demás, pero el resto de sistemas permanecería intacto.

Si el nodo central es pasivo, el nodo origen debe ser capaz de tolerar un eco de su transmisión. Una red en estrella activa tiene un nodo central activo que normalmente tiene los medios para prevenir problemas relacionados con el eco.

Se utiliza sobre todo para redes locales. La mayoría de las redes de área local que tienen un router, un switch o un hub siguen esta topología. El nodo central en estas sería el hub, el router o el switch, por el que pasan todos los paquetes

Topología en Árbol Topología de red en la que los nodos están colocados en forma de árbol. Desde una visión topológica, la conexión en árbol es parecida a una serie de

redes en estrella interconectadas salvo en que no tiene un nodo central. En cambio, tiene un nodo de enlace troncal, generalmente ocupado por un

hub o switch, desde el que se ramifican los demás nodos. Es una variación de la red en bus, la falla de un nodo no implica interrupción

en las comunicaciones. Se comparte el mismo canal de comunicaciones. El enlace troncal es un cable con varias capas de ramificaciones, y el flujo de

información es jerárquico. Conectado en el otro extremo al enlace troncal generalmente se encuentra un host servidor.

La topología en árbol puede verse como una combinación de varias topologías en estrella. Tanto la de árbol como la de estrella son similares a la de bus cuando el nodo de interconexión trabaja en modo difusión, pues la información se propaga hacia todas las estaciones, solo que en esta topología las ramificaciones se extienden a partir de un punto raíz (estrella), a tantas ramificaciones como sean posibles, según las características del árbol.

Topología en Malla El establecimiento de una red de malla es una manera de encaminar datos, voz e

instrucciones entre los nodos. Las redes de malla se diferencian de otras redes en que las piezas de la red (nodo) están conectadas unas con otras por uno u otro camino, mediante cables separados. Esta configuración ofrece caminos redundantes por toda la red, de modo que si falla un cable, otro se hará cargo del tráfico.

Esta topología, a diferencia de otras (como topología en árbol y topología en estrella), no requiere de un servidor o nodo central, con lo que se reduce el mantenimiento (un error en un nodo, sea importante o no, no implica la caída de toda la red).

Las redes de malla son autoregenerables: la red puede funcionar incluso cuando un nodo desaparece o la conexión falla, ya que el resto de nodos evitan el paso por ese punto. Consecuentemente, se forma una red muy confiable, es una opción aplicable a las redes sin hilos (wireless), a las redes con cable (Wired), y a la interacción del software.

Una red con topología en malla ofrece una redundancia y fiabilidad superiores. En una topología en malla, cada equipo está conectado a todos los demás equipos. Aunque la facilidad de solución de problemas y el aumento de la fiabilidad son ventajas muy interesantes, estas redes resultan caras de instalar, ya que utilizan mucho cableado. Por ello cobran mayor importancia el uso de Wireless, ya que no hay necesidad de cableado(a pesar de los inconvenientes del (Wireless). En muchas ocasiones, la topología en malla se utiliza junto con otras topologías para formar una topología híbrida.

Una red de malla extiende con eficacia una red compartiendo el acceso a una infraestructura de red con mayor coste.

Topología en BUS Topología de red en la que todas las estaciones están conectadas a un único

canal de comunicaciones por medio de unidades interfaz y derivadores. Las estaciones utilizan este canal para comunicarse con el resto. Es la más sencilla por el momento.

La topología de bus tiene todos sus nodos conectados directamente a un enlace y no tiene ninguna otra conexión entre nodos. Físicamente cada host está conectado a un cable común, por lo que se pueden comunicar directamente, aunque la ruptura del cable hace que los hosts queden desconectados.

La topología de bus permite que todos los dispositivos de la red puedan ver todas las señales de todos los demás dispositivos, lo que puede ser ventajoso si desea que todos los dispositivos obtengan esta información. Sin embargo, puede representar una desventaja, ya que es común que se produzcan problemas de tráfico y colisiones, que se pueden paliar segmentando la red en varias partes. Es la topología más común en pequeñas LAN, con hub o switch final en uno de los extremos, también representa una desventaja ya que si el cable se rompe, ninguno de los servidores siguientes tendrá acceso a la red

Versiones de Software En la ingeniería del software el término fases de desarrollo expresa cómo ha

progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión importante de un producto pasa generalmente a través de una

etapa en la que se agregan las nuevas características (etapa alfa), después una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los bugs importantes (etapa estable).

Las etapas intermedias pueden también ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los términos se utilizan a veces de manera informal para describir el estado de un producto.

Pre-alfa La fase conocida como pre-alfa se publica a veces antes del lanzamiento de

una versión alfa o beta. En contraste con la versión alfa y las versiones beta, la pre-alfa no tiene sus características completas. Los diseñadores todavía están determinando en esta etapa exactamente qué funcionalidades debe tener el producto. Tales etapas se pueden llamar también development releases o nightly builds.

Versiones de Software Alfa La versión alfa de un producto es la primera para la que el equipo de desarrollo

decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versión del programa que se envía a los verificadores para probarla.

Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.

Beta Una versión beta o lanzamiento beta representa generalmente la primera

versión completa , que es probable que sea inestable pero útil para que las demostraciones internas y las inspecciones previas seleccionen a clientes.

Algunos desarrolladores se refieren a esta etapa como inspección previa (preview) o como una inspección previa técnica (technical preview [TP]).

Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores.

Versiones de Software Las versiones beta están en un paso intermedio en el ciclo de desarrollo

completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario.

Cuando una versión beta llega a estar disponible para el público en general que a menudo es utilizada extensamente por los tecnológicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado.

Generalmente los desarrolladores de las versiones betas del software gratuito o de código abierto los lanzan al público en general, mientras que las versiones beta propietarias van a un grupo relativamente pequeño de probadores..

Versiones de Software Versión candidata a definitiva El término candidata a definitiva o candidata para el lanzamiento se

refiere a un producto final, preparado para lanzarse como versión definitiva a menos que aparezcan errores que lo impidan.

En esta fase el producto implementa todas las funciones del diseño y se encuentra libre de cualquier error que suponga un punto muerto en el desarrollo.

Versión de disponibilidad general La versión de disponibilidad general de un producto es su versión final.

Normalmente es casi idéntica a la versión candidata final, con sólo correcciones de último momento. Esta versión es considerada muy estable y relativamente libre de errores con una calidad adecuada para una distribución amplia y usada por usuarios finales. Microsoft y otros usan el término "release to manufacturing" (RTM) para referirse a esta versión (para productos comerciales como Windows XP, tal como "Build 2600 is the Windows XP RTM release"), y "release to Web" (RTW) para productos libremente descargables.

El Proceso Unificado El Proceso Unificado "es un proceso de desarrollo de software configurable

que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational",

El Proceso Unificado guía a los equipos de proyecto en cómo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto.

El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura.

El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones.

El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas.

El Proceso Unificado El Proceso Unificado se enfoca en la arquitectura como el centro del

desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reuso.

Se considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa

Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios.

Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor.

Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios y como poner esa información eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes.

Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.

Diseño Conceptual Diseño Conceptual

El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas:

Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa Una forma de obtener estos requerimientos es construir una matriz

usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución.

Diseño Lógico Diseño Lógico El diseño lógico traduce los escenarios de uso creados en el diseño

conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se

usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define

formalmente las reglas y políticas específicas de negocios. Un objeto de negocios es la encapsulación de un servicio que abstrae las

cualidades esenciales de algo de interés. Un servicio es una unidad con capacidad de cómputo. Un servicio debe

satisfacer lo siguiente: Ser seguro, lo que equivale a un uso correcto y con autorización Ser válido, qué tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catálogo de servicios que constituye un repositorio de servicios.

Diseño Lógico Los objetos de negocio deben verificarse y probarse de tal manera que

asegure que los módulos operen como unidades completas de trabajo. Las tareas de verificación incluyen:

Una verificación independiente: Pre y post condiciones Lógica y funcionalidad individual

Una verificación dependiente: Verificación de dependencias Que operan como una unidad específica de trabajo

El diseño lógico comprende las siguientes tareas: Identificar y definir los objetos de negocio y sus servicios Definir las interfases Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario

Diseño Lógico Una interfase tiene las siguientes partes:

Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final Capacidad o funcionalidad (SQL, pseudocódigo, función matemática) Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:

Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulación de tiempo crítica Considerar algún problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a través de la ubicación Determinar cuando el servicio que controla la transacción es dependiente de los servicios

contenidos en otros objetos de negocio

Diseño Lógico La validación del modelo lógico debe ser tal que éste sea:

Completo – debe representar todos los escenarios de uso, Correcto – el comportamiento lógico debe corresponder con el comportamiento conceptual, y Claro – los objetos de negocio y servicios no deben ser ambiguos

En el diseño lógico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos.

Los servicios de usuario (user services) controlan la interacción. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinación de éstos. Generalmente involucra una interfase gráfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interacción con la aplicación. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Un servicio de usuario incluye un contenido (qué se necesita comunicar al usuario) y una forma (cómo se comunica el contenido) cuando es necesaria la comunicación.

Diseño Lógico Los servicios de negocio convierten datos recibidos de los servicios de

datos y de usuario en información (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea.

Las tareas de los servicios de negocio son: Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en información Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la

transacción.

Diseño Lógico Los servicios de datos son los servicios de bajo nivel que apoyan los

servicios de negocio y son de una amplia gama de categorías como las siguientes:

Declaración del esquema y su evolución (estructuras de datos, tipos, acceso indexado, SQL, APIs)

Respaldo y recuperación (recuperación de datos si un evento falla) Búsqueda y Lectura (búsquedas, compilación, optimización y ejecución de solicitudes,

formación de un conjunto de resultados) Inserción, actualización y borrado (procesar modificaciones consistentemente transaccional).

Una transacción es atómica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o después) y durable (una vez completada, ésta sobrevive).

Bloqueo (permite al acceso concurrente a los datos) Validación de datos (verifica la integridad del dominio, triggers y gateways para verificar el

estado de los datos antes de aceptarlos, manejo de errores) Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) Administración de la conexión (mecanismos básicos para establecer una sesión de los servicios

de datos). Establecer una conexión involucra: una identificación, la colocación y provisión de datos, tiempo de sesión, el tipo de interacción (conversacional, transaccional, multiusuario, monousuario).

Distribución de datos (Distribuye información, a múltiples unidades de recuperación, bases de datos heterogéneas, según la topologías de la red).

Diseño Físico El diseño físico traduce el diseño lógico en una solución implementable y

costo-efectiva o económica. El componente es la unidad de construcción elemental del diseño físico.

Las características de un componente son: Se define según cómo interactúa con otros Encapsula sus funciones y sus datos Es reusable a través de las aplicaciones Puede verse como una caja negra Puede contener otros componentes

En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico) y la agregación y contención (un componente puede reusar utilizando técnicas de agregación y contención, sin duplicar código).

Diseño Físico El diseño físico debe involucrar:

El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red.

El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso)

El diseño para uso concurrente – el desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.

El diseño con el manejo de errores y prueba de eventos: Validando los parámetros- a la entrada antes de continuar con cualquier proceso. Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin

cerrar archivos, liberar objetos sincronizados o memoria. Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las

bases de datos. Debugging – crear una versión para limpiar errores. Protección integral de transacciones de negocios – los errores deben regresarse al

componente que llama.

Diseño Físico El diseño físico comprende las siguientes tareas:

Definir los componentes Refinar el empaquetamiento y distribución de componentes Especificar las interfases de los componentes Distribuir los componentes en la red Distribuir los repositorios físicos de datos Examinar la tolerancia a fallas y la recuperación de errores Validar el diseño físico

De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados, una partición, un extracto o una réplica.

Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos.

Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposición entre particiones. En una partición horizontal cada hilera existe en una sola base de datos. En una partición vertical cada columna es contenida en una y solo una base de datos.

Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa un timestamp o etiqueta de tiempo para indicar qué tan viejos son los datos.

Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe de haber sincronización entre ambas.

Diseño Físico El diseño físico está íntimamente ligado a una alternativa tecnológica. Ante

la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias ya que una mala decisión implicará un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta.

La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicándose entre sí en una plataforma internet con protocolos estándar en redes heterogéneas.

Diseño Físico