h1

Los acordeones para el examen de certificación (Parte 2: Arquitecturas Comunes)

10/11/2007

Wizdoc [Icon By Buuf]

 Tips & Tricks: Acordeon SCEA: Seccion 2: Arquitecturas Comunes

Sección 2: Arquitecturas Comunes

  • Reconocer el efecto de cada una de las siguientes características sobre arquitecturas de dos capas, tres capas y multi-capa (two tier, three tier and multi-tier architectures): escalabilidad, mantenibilidad, confiabilidad, disponibilidad, extensibilidad, desempeño, administrabilidad y seguridad.
  • Reconocer el efecto de cada una de las siguientes características sobre la tecnología J2EE: escalabilidad, mantenibilidad, confiabilidad, disponibilidad, extensibilidad, desempeño, administrabilidad y seguridad.
  • De acuerdo a una arquitectura dada descrita en términos de su disposición de red, listar los beneficios y potenciales debilidades asociados a ésta.
  • Dos capas: Cliente-Servidor bajo en todos los aspectos.
  • Tres capas: Capa de Presentación, Capa de Negocio y Capa de Persistencia mejora en todas sus características – la mayoría de las aplicaciones J2EE en web utilizan este modelo.
  • N-capas / multi-capa: Tres capas con capa de middleware y configuración de alta disponibilidad – un sistema distribuido – Sube en todo excepto en mantenibilidad y administrabilidad.
    Característica

    Descripción

    Escalabilidad

    • Conforme aumenta la carga, se requiere de mayor soporte para mantener la calidad del servicio (Quality of Service – QoS).
    • Mientras más escalable es un sistema, mayor es la capacidad de carga que puede soportar.
    • Escalamiento Vertical: añadir más capacidad al hardware (memoria, espacio en disco, procesadores, etc.)
      • Para J2EE esto implica poder administrar más componentes (business components, web components) debido al incremento de recursos.
      • Pros: Es relativamente barato y fácil de administrar, pocos o ningún cambio al código fuente (Nota: en todo caso deberían cambiar sólo los parámetros de despliegue o de configuración de los contenedores).
      • Cons: Al escalar verticalmente una de las capas, sigue teniendo un sólo punto de falla (point of failure) por lo que tiene poca confiabilidad y disponibilidad.
    • Escalamiento Horizontal: añadir componentes de hardware (más servidores, configuraciones en clúster)
      • Para J2EE se requerirá soporte a distribución (como mínimo implementar java.io.Serializable), clusterización y balanceo de cargas.
      • Pros: Confiable, disponible y mejora la capacidad de soportar mayor carga; aumenta el desempeño de la aplicación.
      • Cons: Es caro (se requieren como mínimo dos servidores, pueden requerirse balanceadores y hardware de red adicional), más difícil de administrar que el escalamiento vertical (es necesario replicar las configuraciones o los cambios en ésta), es más complejo (como mínimo una falla requiere más tiempo para su diagnóstico).
    Disponibilidad

    • El servicio o recurso siempre es accesible.
    • Se obtiene mediante el escalamiento horizontal o vertical.
    • Se mitiga el riesgo de falla al incrementar redundancia de componentes (por ejemplo, se utiliza mucho el concepto de configuración en failover).
    • Para el caso de J2EE esto implica utilizar los beneficios de la especificación y sus implementaciones (pools de conexiones a base de datos, threads y componentes web y de negocio).
    Confiabilidad

    • Integridad y consistencia de la aplicación y sus transacciones.
    • Conforme aumenta la carga, el sistema debe procesar cualquier petición sin ningún problema.
    • Poca confiabilidad implica poca escalabilidad.
    • Para J2EE indica en cuanto a código el buen uso de técnicas de configuración transaccional (por ejemplo, EJB-BMP) aunque también recae en el contenedor este punto (por ejemplo, EJB-CMP)
    Mantenibilidad

    • Corrección o modificación de la funcionalidad de servicios existentes sin impactar otros componentes del sistema.
    • Para mejorar la mantenibilidad de un sistema es necesario tener poco acoplamiento, modularidad y haber generado una buena documentación. Esto se logra mediante la implementación de las mejores técnicas de desarrollo (usar metodologías de administración y desarrollo, patrones, POCs, etc.)
    • Para el caso especifico de la modularidad ésta se logra mediante
      • Arquitecturas multi-capa
      • Implementación de patrones como el MVC.
    Flexibilidad

    • Habilidad del sistema de adaptarse a nuevos requerimientos de forma efectiva en tiempos y costos.
    • Mejora la disponibilidad, confiabilidad y escalabilidad.
    • Reduce el desempeño (por ejemplo, al utilizar patrones de diseño puede volverse una pesadilla de mantenimiento a menos que el desarrollador sea experto en dichos patrones) y la administrabilidad (como ejemplo, encontrar un bug en Struts – un framework con alta flexibilidad – puede volverse un dolor en la muela).
    Extensibilidad

    • Habilidad del sistema para agregar y modificar funcionalidad sin afectar a los servicios ya existentes.
    • Es más fácil de alcanzar cuando existe poco acoplamiento y se implementa el encapsulamiento (vía interfaces y el uso de éstas como parte de los patrones de diseño).
    • J2EE está hecho tomando en cuenta este tipo de característica (todos los patrones de diseño originales – consolidados por Erich Gamma, et al – así como los Sun Blueprints).
    Desempeño

    • Alta velocidad de respuesta del sistema, falta de cuellos de botella.
    • Logrado a través de la buena implementación de J2EE y sus implementaciones (pools de conexiones a base de datos, threads y componentes web y de negocio); tuning del contenedor, la JVM y el sistema operativo y en el caso de arquitecturas multi-capa, de los servicios de red y hardware relacionado.
    • Se mide por
      • Número de transacciones por unidad de tiempo (Transaction throughput)
      • Tiempo de respuesta hacia una petición (Response time)
    Administrabilidad

    • Capacidad de monitoreo y administración de la salud del sistema.
    • Monitoreo del QoS y modificar dinámicamente propiedades del sistema para mejorarlo.
    • Se le reduce al incrementar el escalamiento horizontal o la seguridad del sistema.
    Seguridad

    • La habilidad del sistema de asegurar que sólo se podrá acceder y/o modificar la información a través de las políticas de seguridad establecidas.
    • A mayor seguridad, mayores costos y complejidad pero con menor desempeño.
    • Puntos principales de la seguridad:
      • Identificar – autenticación.
      • Autorizar – autorización.
      • Integridad – manipular información sólo mediante los procedimientos permitidos.
      • Privacidad – Compartir la información sólo con los actores autorizados.
      • Auditabilidad – Registro de bitácoras.
    • Se logra mediante la implementación de VPNs, Firewalls y aspectos de seguridad/encripción como SSL, HTTPS, Applets firmados.

    Notas adicionales

    • De acuerdo al examen, se busca que el arquitecto en potencia pueda describir y/o diseñar arquitecturas consolidadas (software principalmente, con algunas trazas de integración con sistemas heredados), aunque por lo que estoy viendo en el día a día en mi trabajo, es recomendable no sólo limitarse a Java/JEE como solución, pues aunque es una muy buena plataforma, no es la panacea.
    • Otro aspecto bastante limitativo a la hora de diseñar arquitecturas es que la seguridad puede darte en la torre a la hora de revisar el desempeño, especialmente cuando se trata de conceptos como encripción que requiere mucho poder de cómputo.
    • Algo que me saca mucho de onda es que incluso Sun no implementa EJBs… por ello el cambio tan radical entre JEE 5 y las anteriores implementaciones.
    • No se si estoy poniéndome melodramático, pero creo que para JEE5 tendré que soplarme la especificación tal cual, pues muchos conceptos cambian de forma considerable (para la nueva especificación ya no hay "Entity Beans") o se agregan nuevas tecnologías ("Web Services", "Java Server Faces"). Ahhh… y algo que me mueve mucho el tapete son las mentadas anotaciones. Si mejora la calidad de vida del programador, pues ya se ahorra uno muchísimo código pero los inner-workings se vuelven algo más esotérico.
    • Finalmente, como tarea es indispensable revisar el framework de definición de arquitecturas de Sun (SunTone™), pues me suena mucho a que el exámen tiene a final de cuentas el objetivo de que el arquitecto esté moldeado de acuerdo a lo que se define ahí:


    Modelo de diseño arquitectónico SunTone™
  • Responder

    Introduce tus datos o haz clic en un icono para iniciar sesión:

    Logo de WordPress.com

    Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

    Imagen de Twitter

    Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

    Foto de Facebook

    Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

    Google+ photo

    Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

    Conectando a %s

    A %d blogueros les gusta esto: