Capitulo 3 arquitecturas_de_desarrollo_web

Capitulo 2
Arquitecturas de Desarrollo de
Software
Miguel Ángel Niño Zambrano

Motivación
• Discurso Académico vs. Discurso de la
industria.
• Calidad del Software.
• Diseño de software y desarrollo basado
en la arquitectura.
• ¿Cómo diseñar: Orientado a Objetos,
componentes, servicios, Patrones de
software?

Agenda
• Historia del la Arquitectura de Desarrollo
de Software.
• Introducción a la Arquitectura de Software
• Tipos de Arquitecturas.
• Paradigmas de Desarrollo de software.
• Aplicación de Arquitectura en el Desarrollo
de Software Web.

Historia del la Arquitectura de
Desarrollo de Software.

Historia de la Arquitectura de DS
1968: Edsger Dijkstra
1970: Diseño Estructurado
1969: P.I. Sharp formula
1972 - 1976: David Parnas
1975: Brooks
•Estructura antes de programar.
•Niveles de Abstracción.
•Diseño Conceptual – Niklaus Wirth
•Arquitectura del Software.
•Especificaciones: Funcionales +
Diseño + Forma.
•Modelos de desarrollo de software.
•Salen de cascada a modelos
Orgánicos, Evolutivos y Cíclicos.
•Módulos y Ocultamiento de
Información.
•Estructuras de software y Familias
de Programas.
•Búsqueda de Calidad del Software.
•Decisiones de Diseño Tempranas.
•Arquitectura como la
especificación completa de la IU.
•Arquitectura (¿Qué?) vs.
Implementación (¿Cómo?)

Historia de la Arquitectura de DS
1980s: POO
1990s: Apogeo de la AS
1992: Perry & Wolf
2000: Roy Fielding
•1960 (Simula) TADs y Clases, Smalltalk
•Teoría: Modelar el Dominio del problema e
implementarlo en un lenguaje POO.
•Arquitectura del Software análogo a la
construcción de edificios. Bases de la
AS (Elementos, Forma, Razón).
•Herramientas CASE.
•1996 - Paul Clements: Componentes.
•1995 – Patrones de Diseño. B4.
•Estilos arquitectónicos (ADLs)
•Vistas Arquitectónicas. Modelo
propuestos:
•4+1.
•TOGAF.
•RM/ODP.
•IEEE.
•Modelo REST: Tecnologías Web
y Modelo Orientado a Servicios.
•IEEE Std 1471.
2000s: Líneas de Productos y
Metodologías de DS basada en
La Arquitectura.

Introducción a la Arquitectura
de Software

Introducción a la AS
• Definición: (Clements 1996): La AS es, a grandes
rasgos, una vista del sistema que incluye los
componentes principales del mismo, la conducta de
esos componentes según se la percibe desde el resto
del sistema y las formas en que los componentes
interactúan y se coordinan para alcanzar la misión del
sistema. La vista arquitectónica es una vista abstracta,
aportando el más alto nivel de comprensión y la
supresión o diferimiento del detalle inherente a la mayor
parte de las abstracciones.
• Definición: (IEEE Std 1471): La Arquitectura de
Software es la organización fundamental de un sistema
encarnada en sus componentes, las relaciones entre
ellos y el ambiente y los principios que orientan su
diseño y evolución

Puntos de vista de la AS
• Modelos estructurales: componentes, conexiones
entre ellos , la configuración, estilo, restricciones,
semántica, análisis, propiedades, racionalizaciones,
requerimientos, necesidades de los participantes,
(ADLs).
• Modelos de framework: refieren a dominios o clases
de problemas específicos.
• Modelos dinámicos: Enfatizan la cualidad conductual
de los sistemas.
• Modelos de proceso: programación de procesos para
derivar arquitecturas.
• Modelos funcionales: conjunto de componentes
funcionales, organizados en capas que proporcionan
servicios hacia arriba
Según: Shaw y David Garlan [SG95]

Conceptos de AS
• Estilos: Concepto descriptivo, define una
forma de organización. Ej. flujo de datos, las peer-
to-peer, las de invocación implícita, las jerárquicas, las centradas en
datos o las de intérprete-máquina virtual.
• Lenguajes de Descripción
Arquitectónica – ADLs.
• Frameworks y Vistas: Es una estructura
de soporte definida en la cual otro
proyecto de software puede ser
organizado y desarrollado.

Conceptos de AS
• Principales Frameworks y Vistas
Zachman
(Niveles)
TOGAF
(Arquitecturas)
4+1
(Vistas)
[BRJ99]
(Vistas)
POSA
(Vistas)
Microsoft
(Vistas)
Scope Negocios [Text] Lógica Diseño Lógica
Empresa Datos Proceso Proceso Proceso Conceptual
Sistema lógico Aplicación Física Impleme
ntación
Física Física
Tecnología Tecnología Desarrollo Despliegu
e
Desarroll
o
.
Representación . Casos de
uso
Casos de
uso
.
Funcionamiento . . . . .

Conceptos de AS – Clasificación de Vistas según
Jamers Rumbaugh, Ivar Jacobson, Grady Booch
Área Vista Diagramas Conceptos principales
Estructural Vista estática
Vista de casos de
uso
Vista de
implementación
Vista de despliegue
Diagrama de clases
Diagramas de casos de
uso
Diagrama de
componentes
Diagrama de
despliegue
Clase, asociación, generalización,
dependencia, realización, interfaz
Caso de uso, actor, asociación,
extensión, inclusión, generalización
de casos de uso
Componente, interfaz, dependencia,
realización
Nodo, componente, dependencia,
localización
Dinámica Vista de máquinas
de estados
Vista de actividad
Vista de interacción
Diagrama de estados
Diagrama de actividad
Diagrama de secuencia
Diagrama de
colaboración
Estado, evento, transición, acción
Estado, actividad, transición de
terminación, división, unión
Interacción, objeto, mensaje, activación
Colaboración, interacción, rol de
colaboración, mensaje
Gestión del
modelo
Vista de gestión del
modelo
Diagrama de clases Paquete, subsistema, modelo

Conceptos de AS
• Procesos y Metodologías: Relacionadas a las
vistas dinámicas. Métodos Pesados (CMM) vs.
Métodos Ágiles (XP,FDD,etc.).
• Abstracción: consiste en extraer las
propiedades esenciales, o identificar los
aspectos importantes, o examinar
selectivamente ciertos aspectos de un
problema, posponiendo o ignorando los detalles
menos sustanciales, distractivos o irrelevantes.
• Escenarios (Guión o Libreto): casos de uso
(secuencias de responsabilidades) y casos de
cambio (modificaciones propuestas al sistema)..

Investigación y Evolución en AS
• David Garlan y Dewayne Perry : en su
introducción al volumen de abril de 1995 de IEEE
Transactions on Software Engineering dedicado a la AS
– Lenguajes de descripción de arquitecturas.
– Fundamentos formales de la AS (bases matemáticas,
caracterizaciones formales de propiedades extra-funcionales
tales como mantenibilidad, teorías de la interconexión, etcétera).
– Técnicas de análisis arquitectónicas.
– Métodos de desarrollo basados en arquitectura.
– Recuperación y reutilización de arquitectura.
– Codificación y guía arquitectónica.
– Herramientas y ambientes de diseño arquitectónico.
– Estudios de casos

Investigación y Evolución en AS
• Paul Clements [Cle96b] (Reusabilidad): define cinco temas
fundamentales en torno de los cuales se agrupa la disciplina.
1. Diseño o selección de la arquitectura: Cómo crear o seleccionar una
arquitectura en base de requerimientos funcionales, de rendimiento o de
calidad.
2. Representación de la arquitectura: Cómo comunicar una arquitectura.
Este problema se ha manifestado como el problema de la representación de
arquitecturas utilizando recursos lingüísticos, pero el problema también
incluye la selección del conjunto de información a ser comunicada.
3. Evaluación y análisis de la arquitectura: Cómo analizar una arquitectura
para predecir cualidades del sistema en que se manifiesta. Un problema
semejante es cómo comparar y escoger entre diversas arquitecturas en
competencia.
4. Desarrollo y evolución basados en arquitectura: Cómo construir y
mantener un sistema dada una representación de la cual se cree que es la
arquitectura que resolverá el problema correspondiente.
5. Recuperación de la arquitectura: Cómo hacer que un sistema legacy
evolucione cuando los cambios afectan su estructura; para los sistemas de
los que se carezca de documentación confiable, esto involucra primero una
“arqueología arquitectónica” que extraiga su arquitectura.

Arquitectura vs. Diseño
• Taylor y Medvidovic [TM00]: señalan que la literatura
actual mantiene en un estado ambiguo la relación entre
ambos campos, albergando diferentes interpretaciones
y posturas:
1. Una postura afirma que arquitectura y diseño son lo mismo.
2. Otra, en cambio, alega que la arquitectura se encuentra en un
nivel de abstracción por encima del diseño, o es simplemente
otro paso (un artefacto) en el proceso de desarrollo de
software.
3. Una tercera establece que la arquitectura es algo nuevo y en
alguna medida diferente del diseño (pero de qué manera y en
qué medida se dejan sin especificar).
• La arquitectura y el diseño sirven al mismo propósito.
Sin embargo, el foco de la AS en la estructura del
sistema y en las interconexiones la distingue del diseño
de software tradicional

Tipos de Arquitecturas
Estilos más relevantes de
desarrollo de software

Estilos de Flujo de datos (EFD)
• Esta familia de estilos enfatiza
la reutilización y la
modificabilidad. Es apropiada
para sistemas que
implementan
transformaciones de datos en
pasos sucesivos. Ejemplares
de la misma serían las
arquitecturas de tubería-
filtros y las de proceso
secuencial en lote.
Ej. Unix, Compiladores, XML
Ráfaga SAX, SGBD, Workflow.

Características del Estilo EFD
• El estilo se debe usar cuando:
– Se puede especificar la secuencia de un número conocido de
pasos.
– No se requiere esperar la respuesta asincrónica de cada paso.
– Se busca que todos los componentes situados corriente abajo
sean capaces de inspeccionar y actuar sobre los datos que
vienen de corriente arriba (pero no viceversa).
• Ventajas:
– Es simple de entender e implementar. Es posible implementar
procesos complejos con editores gráficos de líneas de tuberías
o con comandos de línea.
– Fuerza un procesamiento secuencial.
– Es fácil de envolver (wrap) en una transacción atómica.
– Los filtros se pueden empaquetar, y hacer paralelos o
distribuidos.

Características del Estilo EFD
• Desventajas:
– El patrón puede resultar demasiado simplista, especialmente
para orquestación de servicios que podrían ramificar la
ejecución de la lógica de negocios de formas complicadas.
– No maneja con demasiada eficiencia construcciones
condicionales, bucles y otras lógicas de control de flujo.
Agregar un paso suplementario afecta la performance de cada
ejecución de la tubería.
– Una desventaja adicional referida en la literatura sobre estilos
concierne a que eventualmente pueden llegar a requerirse
buffers de tamaño indefinido, por ejemplo en las tuberías de
clasificación de datos.
– El estilo no es apto para manejar situaciones interactivas,
sobre todo cuando se requieren actualizaciones incrementales
de la representación en pantalla.
– La independencia de los filtros implica que es muy posible la
duplicación de funciones de preparación que son efectuadas
por otros filtros (por ejemplo, el control de corrección de un
objeto de fecha).

Ejemplo del Estilo Tubería- Filtro
en una Aplicación Web
• La aplicación típica del estilo es un procesamiento
clásico de datos: el cliente hace un requerimiento; el
requerimiento se valida; un Web Service toma el objeto
de la base de datos; se lo convierte a HTML; se efectúa
la representación en pantalla.
• Order Processing Pipeline proporciona la secuencia de
pasos necesaria para procesar las compras en un sitio
de Web. En la primera etapa, se obtiene la información
del producto de la base de datos de catálogo; en la
siguiente, se procesa la dirección del comprador; otra
etapa resuelve la modalidad de pago; una etapa ulterior
confecciona la factura y otra más realiza el envío del
pedido. Cada etapa de la tarea representa una categoría
de trabajo.

Estilos Centrados en Datos (ECD)
• Esta familia de estilos enfatiza la
integrabilidad de los datos. Se estima
apropiada para sistemas que se
fundan en acceso y actualización de
datos en estructuras de
almacenamiento. Sub-estilos
característicos de la familia serían los
repositorios, las bases de datos, las
arquitecturas basadas en hipertextos
y las arquitecturas de pizarra.

ECD – Pizarra o Repositorio
• En esta arquitectura hay dos componentes principales:
una estructura de datos que representa el estado actual
y una colección de componentes independientes que
operan sobre él [SG96]. En base a esta distinción se
han definidos dos subcategorías principales del estilo:
– Si los tipos de transacciones en el flujo de entrada definen los
procesos a ejecutar, el repositorio puede ser una base de datos
tradicional (implícitamente no cliente-servidor).
– Si el estado actual de la estructura de datos dispara los
procesos a ejecutar, el repositorio es lo que se llama una pizarra
pura o un tablero de control.
Ej. reconocimiento de patrones,
reconocimiento de habla, Algunos
Compiladores que usan TS, AST .
Programación genética, evolutiva.

Uso del ECD en aplicaciones Web
• No existe literatura profusa al respecto.
• Se espera que con los Agentes Inteligentes se
obtengan resultados al respecto. Ej. STI
• Se puede entender hacia una aplicación que
necesite hacer los siguiente:
– Fuentes de conocimiento, necesarias para resolver el
problema.
– Una pizarra que representa el estado actual de la
resolución del problema.
– Una estrategia, que regula el orden en que operan las
fuentes.

Estilos de Llamada y Retorno ELR
modificabilidad y la escalabilidad. Son los
estilos más generalizados en sistemas en
gran escala. Miembros de la familia son
las arquitecturas de programa principal y
subrutina, los sistemas basados en
llamadas a procedimientos remotos, los
sistemas orientados a objeto y los
sistemas jerárquicos en capas.

ELR- Modelo Vista – Controlador
MVC
• Paradigma Interfaz – Base de
Datos.
• Problemas:
– La interfaz suele cambiar, o
acostumbra depender de distintas
clases de dispositivos (clientes
ricos, browsers, PDAs);
– La programación de interfaces de
HTML, además, requiere
habilidades muy distintas de la
programación de lógica de
negocios.
– Otro problema es que las
aplicaciones tienden a incorporar
lógica de negocios que van más
allá de la transmisión de datos.
El patrón conocido como
Modelo-Vista-Controlador (MVC)
separa el modelado del:
- Dominio,
- La presentación y
- Las acciones basadas en datos
ingresados por el usuario en tres
clases diferentes

Características del MVC
• Modelo. El modelo administra el
comportamiento y los datos del dominio de
aplicación, responde a requerimientos de
información sobre su estado (usualmente
formulados desde la vista) y responde a
instrucciones de cambiar el estado
(habitualmente desde el controlador).
• Vista. Maneja la visualización de la información.
• Controlador. Interpreta las acciones del ratón y
el teclado, informando al modelo y/o a la vista
para que cambien según resulte apropiado.

Ventajas y desventajas del MVC
• Ventajas:
– Soporte de vistas múltiples. Dado que la vista se halla
separada del modelo y no hay dependencia directa del modelo
con respecto a la vista.
– Adaptación al cambio. Los requerimientos de interfaz de
usuario tienden a cambiar con mayor rapidez que las reglas de
negocios.
• Desventajas:
– Complejidad. El patrón introduce nuevos niveles de indirección
y por lo tanto aumenta ligeramente la complejidad de la
solución. También se profundiza la orientación a eventos del
código de la interfaz de usuario, que puede llegar a ser difícil de
depurar.
– Costo de actualizaciones frecuentes. Desacoplar el modelo
de la vista no significa que los desarrolladores del modelo
puedan ignorar la naturaleza de las vistas.

Uso del MVC en una Aplicación
Web
• En aplicaciones de Web, por otra parte, la
separación entre la vista (el browser) y el
controlador (los componentes del lado del
servidor que manejan los requerimientos
de HTTP) está mucho más taxativamente
definida.
• Ejemplo Carrito de Compras.

Estilos de Orientación a Objetos
• Los componentes de este
estilo arquitectónico son los
objetos – también
considerados originalmente
como instancias de tipos
abstractos de datos,
aunque ahora diríamos
clases.
• Los objetos son ejemplos
de un tipo de componentes
que algunos llaman gestor
porque es responsable de
preservar la integridad de
un recurso, es decir la
representación. Los objetos
interactúan a través de
invocaciones de funciones y
procedimientos.

ECR – Arquitectura Orientadas a
Objetos
• Hay dos aspectos importantes en
relación con este estilo:
1. un objeto es responsable de preservar la
integridad de su representación
(normalmente, manteniendo algún
invariante de la misma) y
2. la representación permanece oculta
respecto de los demás objetos

Características de la Arquitectura OO
• Los componentes del estilo se basan en principios OO:
encapsulamiento, herencia y polimorfismo. Son asimismo las
unidades de modelado, diseño e implementación, y los objetos y
sus interacciones son el centro de las incumbencias en el diseño de
la arquitectura y en la estructura de la aplicación.
• Las interfaces están separadas de las implementaciones. En
general la distribución de objetos es transparente, y en el estado de
arte de la tecnología apenas importa si los objetos son locales o
remotos. El mejor ejemplo de OO para sistemas distribuidos es
Common Object Request Broker Architecture (CORBA), en la cual
las interfaces se definen mediante Interface Description Language
(IDL); un Object Request Broker media las interacciones entre
objetos clientes y objetos servidores en ambientes distribuidos.
• En cuanto a las restricciones, puede admitirse o no que una
interfaz pueda ser implementada por múltiples clases.
En tanto componentes, los objetos interactúan a través de
invocaciones de funciones y procedimientos. Hay muchas variantes
del estilo; algunos sistemas, por ejemplo, admiten que los objetos
sean tareas concurrentes; otros permiten que los objetos posean
múltiples interfaces.

Ventajas y Desventajas de A00
• Sólo se señalan las más obvias. Entre las cualidades:
– Se puede modificar la implementación de un objeto sin afectar a
sus clientes.
– Es posible descomponer problemas en colecciones de agentes
en interacción.
– Un objeto es ante todo una entidad reutilizable en el entorno de
desarrollo.
• Entre las limitaciones, el principal problema del estilo
– Para poder interactuar con otro objeto a través de una
invocación de procedimiento, se debe conocer su identidad.. La
consecuencia inmediata de esta característica es que cuando se
modifica un objeto (por ejemplo, se cambia el nombre de un
método, o el tipo de dato de algún argumento de invocación) se
deben modificar también todos los objetos que lo invocan.
– También se presentan problemas de efectos colaterales en
cascada: si A usa B y C también lo usa, el efecto de C sobre B
puede afectar a A.

Uso de AOO en una aplicación
Web
• Ejemplo de Creación de Clases y Objetos
en la aplicación de ejemplo del curso.

Estilos en Capas EC
• Los sistemas o arquitecturas en capas
constituyen uno de los estilos que aparecen con
mayor frecuencia mencionados como categorías
mayores del catálogo, o, por el contrario, como
una de las posibles encarnaciones de algún
estilo más envolvente.
• En [GS94] Garlan y Shaw definen el estilo en
capas como una organización jerárquica tal que
cada capa proporciona servicios a la capa
inmediatamente superior y se sirve de las
prestaciones que le brinda la inmediatamente
inferior. (más de 100 patrones o variantes de
este estilo).

EC – Arquitectura Cliente / Servidor
• Un componente
servidor, que ofrece
ciertos servicios,
escucha que algún otro
componente requiera
uno; un componente
cliente solicita ese
servicio al servidor a
través de un conector.
El servidor ejecuta el
requerimiento (o lo
rechaza) y devuelve
una respuesta.
Modelo de Tres capas Microsoft DNA

Ventajas de los Modelos en Capas
• El estilo soporta un diseño basado en niveles de
abstracción crecientes, lo cual a su vez permite a los
implementadores la partición de un problema complejo
en una secuencia de pasos incrementales.
• El estilo admite muy naturalmente optimizaciones y
refinamientos.
• Proporciona amplia reutilización. Al igual que los tipos de
datos abstractos, se pueden utilizar diferentes
implementaciones o versiones de una misma capa en la
medida que soporten las mismas interfaces de cara a
las capas adyacentes. Esto conduce a la posibilidad de
definir interfaces de capa estándar, a partir de las cuales
se pueden construir extensiones o prestaciones
específicas.

Desventajas de los Modelos en
Capas
• Muchos problemas no admiten un buen mapeo en una
estructura jerárquica. Incluso cuando un sistema se
puede establecer lógicamente en capas,
consideraciones de performance pueden requerir
acoplamientos específicos entre capas de alto y bajo
nivel.
• A veces es también extremadamente difícil encontrar el
nivel de abstracción correcto; por ejemplo, la
comunidad de comunicación ha encontrado complejo
mapear los protocolos existentes en el framework ISO.
• Los cambios en las capas de bajo nivel tienden a
filtrarse hacia las de alto nivel, en especial si se utiliza
una modalidad relajada; también se admite que la
arquitectura en capas ayuda a controlar y encapsular
aplicaciones complejas, pero complica no siempre
razonablemente las aplicaciones simples

Uso Arquitectura en Capas en una
Aplicación Web.
• Ejemplo de tres capas (Ej. e-Commerce):
– Interfaz: Corresponde a las páginas Web que
presentan la información a los usuarios. Envía los
requerimientos a la lógica para obtener una
respuesta.
– Lógica: Representa los componentes del negocio
(clases y objetos) que resuelven el tratamiento de la
información.
– Física: Acceden a las diferentes fuentes de datos
consultando y modificando, dependiendo de los
requerimientos de la lógica.

Estilo CBSE (Ingeniería del
Software Basado en Componentes)
• Arquitecturas Basadas en Componentes:
• un componente de software, es una unidad de
composición con interfaces especificadas
contractualmente y dependencias del contexto
explícitas.
• Que sea una unidad de composición y no de
construcción quiere decir que no es preciso
confeccionarla: se puede comprar hecha, o se puede
producir en casa para que otras aplicaciones de la
empresa la utilicen en sus propias composiciones.
• Ejemplos: CORBA Component Model (CCM),
JavaBeans y Enterprise JavaBeans en J2EE y lo que
alternativamente se llamó OLE, COM, ActiveX y COM+,
y luego .NET.

Uso de AOC en una aplicación
Web
• El framework de .NET permite construir
componentes avanzados e interoperar
componentes y servicios a nivel de la
tecnología COM+ 1.5, no como prestación
legacy, sino en el contexto mayor
(estilísticamente mixto) de servicios de
componentes.
• Ejemplo: Controles de Usuario.
Componentes del S.O.

Estilo de Código Móvil ECM
portabilidad. Ejemplos de la misma son
los intérpretes, los sistemas basados en
reglas y los procesadores de lenguaje de
comando. Fuera de las máquinas virtuales
y los intérpretes, los otros miembros del
conjunto han sido rara vez estudiados
desde el punto de vista estilístico

ECM – Arquitectura de Máquina Virtual
• La arquitectura de máquinas virtuales se ha llamado
también intérpretes basados en tablas. De hecho,
todo intérprete involucra una máquina virtual
implementada en software. Se puede decir que un
intérprete incluye un seudo-programa a interpretar y
una máquina de interpretación. El seudo-programa a
su vez incluye el programa mismo y el análogo que
hace el intérprete de su estado de ejecución (o registro
de activación). La máquina de interpretación incluye
tanto la definición del intérprete como el estado actual
de su ejecución. De este modo, un intérprete posee por
lo general cuatro componentes:
1. Una máquina de interpretación que lleva a cabo la tarea,
2. Una memoria que contiene el seudo-código a interpretar,
3. Una representación del estado de control de la máquina de
interpretación, y
4. Una representación del estado actual del programa que se
simula.

Ejemplos de Implementaciones de
Máquinas Virtuales
• Numerosos lenguajes y ambientes de scripting utilizan máquinas
virtuales: Perl, Javascript, Windows Script Host (WSH), Python,
PHP, Pascal. WSH, por ejemplo, tolera programación en casi
cualquier lenguaje de scripting que se atenga a ciertas
especificaciones simples.
• En la nueva estrategia arquitectónica de Microsoft la máquina virtual
por excelencia guarda relación con el Common Language Runtime,
acaso unas de las dos piezas esenciales del framework .NET (la
otra es la biblioteca de clases). El CLR admite, en efecto, diversos
paradigmas puros y templados: programación funcional (Lisp,
Scheme, F#, Haskell), programación imperativa orientada a objetos
(C#, J#, C++, Python) y estructurada en bloques (Oberon),
ambientes de objetos puros (Smallscript / Smalltalk), programación
lógica declarativa (Prolog, P#), diseño basado en contratos (Eiffel),
modelado matemático (Fortran), scripting interpretado (Perl), meta-
programación (SML, Mondrian), programación cercana a la
semántica de negocios (Cobol), programación centrada en reportes
(Visual ASNA RPG), además de todos los matices y composiciones
heterogéneas a que haya lugar

Estilos Heterogéneos - EH
• Se incluye en este grupo formas compuestas o
indóciles a la clasificación en las categorías
habituales. Tipos:
– Sistemas de Control de Procesos: . El objetivo de
un sistema de esta clase es mantener ciertos valores
dentro de ciertos rangos especificados, llamados
puntos fijos o valores de calibración.
– Arquitecturas Basadas en Atributos: Los estilos
basados en atributos incluyen atributos de calidad
específicos que declaran el comportamiento de los
componentes en interacción.
– Estilos Peer to Peer: Consiste por lo general en
procesos independientes o entidades que se
comunican a través de mensajes.
– Arquitecturas Basadas en Recursos:
Representational State Transfer o REST.

EH – Arquitecturas Basadas en
Eventos
• Las arquitecturas basadas en eventos se han llamado
también de invocación implícita. Otros nombres
propuestos para el mismo estilo han sido integración
reactiva o difusión (broadcast) selectiva. Por supuesto
que existen estrategias de programación basadas en
eventos, sobre todo referidas a interfaces de usuario, y
hay además eventos en los modelos de objetos y
componentes, pero no es a eso a lo que se refiere
primariamente el estilo, aunque esa variedad no está del
todo excluida. Es implementado con el patrón
Observer, un término que se hizo popular en Smalltalk a
principios de los ochenta; en el mundo de Java se le
conoce como modelo de delegación de eventos.

EH – Arquitectura Orientadas a Servicios
• Sólo recientemente estas arquitecturas que los
conocedores llaman SOA han recibido tratamiento
intensivo en el campo de exploración de los estilos. Al
mismo tiempo se percibe una tendencia a promoverlas
de un sub-estilo propio de las configuraciones
distribuidas que antes eran a un estilo en plenitud.
• Este predominio no se funda en la idea de servicios en
general, comunicados de cualquier manera, sino que
más específicamente va de la mano de la expansión de
los Web services basados en XML, en los cuales los
formatos de intercambio se basan en XML 1.0
Namespaces y el protocolo de elección es SOAP.
• SOAP significa un formato de mensajes que es XML,
comunicado sobre un transporte que por defecto es
HTTP, pero que puede ser también HTTPs, SMTP, FTP,
IIOP, MQ o casi cualquier otro, o puede incluir
prestaciones sofisticadas de última generación como
WS-Routing, WS-Attachment, WS-Referral, etcétera.

Web Services como tendencia de
programación Web
• Un Web service es un sistema de software
diseñado para soportar interacción máquina-a-
máquina sobre una red. Posee una interfaz
descripta en un formato procesable por máquina
(específicamente WSDL). Otros sistemas
interactúan con el Web service de una manera
prescripta por su descripción utilizando
mensajes SOAP, típicamente transportados
usando HTTP con una serialización en XML en
conjunción con otros estándares relacionados a
la Web. (Parte del Modelo C/S)

Características de las arquitecturas
orientadas a servicios
• Un servicio es una entidad de software que encapsula
funcionalidad de negocios y proporciona dicha
funcionalidad a otras entidades a través de interfaces
públicas bien definidas.
• Los componentes del estilo (o sea los servicios) están
débilmente acoplados. El servicio puede recibir
requerimientos de cualquier origen. La funcionalidad del
servicio se puede ampliar o modificar sin rendir cuentas
a quienes lo requieran. Los servicios son las unidades
de implementación, diseño e implementación.
• Los componentes que requieran un servicio pueden
descubrirlo y utilizarlo dinámicamente mediante UDDI y
sus estándares sucesores. En general (aunque hay
alternativas) no se mantiene persistencia de estado y
tampoco se pretende que un servicio recuerde nada
entre un requerimiento y el siguiente.

Bibliografía
• Introducción a la Arquitectura de Software. Carlos
Billy Reynoso. Universidad de Buenos aires.
• Estilos y Patrones en la Estrategia de Arquitectura
de Microsoft. Versión 1.0 – Marzo de 2004. Carlos
Reynoso – Nicolás Kicillof. Universidad de Buenos aires.
• Blog de Arquitecturas,
http://homepage.mac.com/imaz/iblog/C612772037/index.html
.
• Video MVC VsNET.
http://www.hanselman.com/silverlight/ScottHaAtAltNetConf/
.

Capitulo 3 arquitecturas_de_desarrollo_web

Más contenido relacionado

La actualidad más candente (20)

Similar a Capitulo 3 arquitecturas_de_desarrollo_web (20)

Último (20)

Capitulo 3 arquitecturas_de_desarrollo_web

Notas del editor