Quizás soy un nostálgico, quizás no he evolucionado lo suficiente con los tiempos pero aún a día de hoy, más de 10 años después de conocer la metodología de Sun (SunTone AM) para definir Arquitecturas me sigue pareciendo uno de los mejores modelos.

Este modelo se representa en un cubo:

Una aproximación efectiva para conseguir integración y habilitar el desarrollo rápido de nuevos recursos basados en Web es interponer una “capa de servicios” entre los dispositivos cliente y los recursos de back-end.

Mediante esta aproximación, la funcionalidad de back-end se pone disponible a través de componentes bien definidos e invocables a través de la red.

Estos componentes pueden poner disponible la funcionalidad de back-end a clientes web, facilitando bloques para combinar servicios simples en servicios de valor añadido completos que se hacen disponibles a través de la Web.

La aproximación “dirigida por servicios” se construye sobre la aproximación multi-capa estableciendo una plataforma de capa intermedia que permite el descubrimiento e integración de componentes de capa intermedia.

Esta arquitectura implica la estandarización de la tecnología de la interfaz de la capa intermedia de forma que una vez implementada, un componente de la capa intermedia está disponible para ser utilizado por otros componentes de capa intermedia sin complejos reformateos de mensajes ni conversiones de protocolos. Esta estandarización transforma la capa intermedia en una capa de servicios flexible.

De esta forma, el sistema podrá soportar navegadores Web y una variedad de dispositivos clientes tales como tablets y smartphones. El particionamiento de la arquitectura en múltiples niveles (‘layers’) permite el procesamiento de servicios de negocio con un cualquier número de accesos diferentes y tecnologías de recursos de back-end.

Para llevar a cabo esta arquitectura “dirigida por servicios”, representaremos la arquitectura en cinco capas de servicios. Estas capas son:

· “Cliente” (Client),

· “Presentación” (Presentation),

· ”Negocio” (Business),

· “Integración” (Integration) y

· “Recurso” (Resource)

y representan el particionamiento “front-to-back” (desde lo que se ve hacia lo más interno que no se ve) de una aplicación o sistema.

La “Capa Cliente” incluye el procesamiento que ocurre en el punto de acceso del cliente, y frecuentemente está fuera del control de la organización.

La “Capa de Presentación” incluye el procesamiento que adapta la visualización e interacción de forma adecuada al dispositivo cliente que está accediendo, ya sea un PC, un Smartphone ó cualquier otro dispositivo.

La “Capa de Negocio” contiene la lógica propia de la organización, independientemente del dispositivo que acceda o de la implementación en recursos.

La “Capa de Integración” es la que da formato y convierte protocolos necesarios para comunicar con los recursos de la organización.

La “Capa de Recursos” contiene sistemas, data-warehouses, o cualquier otro sistema de back-end ó de procesamiento externo.

La implementación de las capas puede requerir una combinación de hardware tradicional y especializado, de software y de tecnologías de networking.

Los requisitos de plataforma tales como velocidad del procesador, ancho de banda de red, entorno de sistema operativo, y middleware pueden variar considerablemente dependiendo del servicio que esté siendo implementado, y puede cambiar significativamente según evoluciona la tecnología, los servicios son más sofisticados y los volúmenes de transacciones crecen.

El desarrollo rápido y la mejora de redes dirigidas por los servicios dependen de la creación de un entorno de plataforma flexible que pueda ser adaptado rápidamente en respuesta a requisitos de plataforma.

Para conseguir estos niveles de flexibilidad, la plataforma de aplicación se puede dividir en cinco niveles principales.

Estos son

· “Hardware”,

· “Plataforma Inferior”,

· “Plataforma Superior”,

· “Plataforma Virtual” y

· “Nivel de Aplicación”.

Ahora se entiende el cubo, verdad? 🙂

La descripción del sistema está además organizada en un grupo de vistas, cada una de ellas ilustrando un sub-grupo de características del sistema desde un perspectiva diferente. Los niveles del sistema agrupan varias vistas.

La definición de cada nivel (“layer”) con las vistas asociadas es como sigue:

1.Nivel de Aplicación (“Application Layer”) comprende los componentes específicos de la aplicación, incluyendo sobre todo lo relativo al código propietario y en menor medida los COTS.

· “Structure View”, describe los componentes software y sus dependencias desde un punto de vista interno.

· “Configuration View”, describe configuraciones como componentes desde el punto de vista operativo, instalación o configuración del sistema.

· “Behavior View”, presenta descripciones funcionales detalladas de los use cases o escenarios.

· “Process View”, resume el comportamiento síncrono del sistema entre diferentes capas y componentes del sistema.

2.Nivel de Plataforma Virtual (“Virtual Platform Layer”) aísla a la aplicación de las diferentes implementaciones de productos de la “Upper Platform Layer” mediante la definición de API, facilitando la elección de fabricante de plataforma. J2EE es el ejemplo más claro de Plataforma Virtual. No hay Vistas en esta capa.

3. Nivel de Plataforma Superior (“Upper Platform Layer”) consiste en productos tales como Web Servers, Servidores de aplicaciones o diferentes tipos de Middleware.

· “Incorporated Mechanisms”, describe mecanismos requeridos y como se utilizan.

· “Custom Mechanisms”, describe los mecanismos propios que se deben construir en el sistema.

4.Nivel de Plataforma Inferior (“Lower Platform Layer”), trata lo relativo a sistema operativo y servicios asociados de bajo nivel.

· “Configurations View”, describe la configuración del sistema a nivel de sistema operativo.

5.Nivel de Plataforma Hardware (“Hardware Platform Layer”), abarca los nodos físicos que intervienen en el sistema y las interconexiones de red.

· “Configurations View”, describe la configuración del hardware, es decir, servidores, almacenamiento, electrónica de red, routers, periféricos, etc.

Finalmente “SunTone AM” presenta una vista de todas las cualidades sistémicas uniendo todas la propiedades del sistema. Consiste en una descripción de la cualidad requerida con el nivel de servicio que se desea. Por cada cualidad se ha de describir además como la arquitectura resuelve el problema, referenciando las vistas necesarias.

Implementación de la Matriz de Capas de Servicio y la Plataforma en Niveles

Para definir nuestra Arquitectura conforme al modelo SunTone AM los 3 conceptos: Capas de servicio y Niveles de plataforma pueden ser visualizados como una matriz bi-dimensional con una dimensión que representa los niveles del stack hardware/software, y el otro representando las capas de una aplicación particionada.

En las capas de servicio, como es el caso de la capa de integración, todos las aplicaciones o módulos desarrollados no requieren de todos los niveles inferiores. Es decir si se desarrolla un módulo de comunicaciones en Java, este ha de

	Cliente	Presentación	Negocio	Integración	Recurso
Aplicación
Plataforma Virtual
Plataforma Superior
Plataforma Inferior
Hardware