Captulo 14

Estilos arquitectnicos
Un patrn es una solucin reutilizable a un problema recurrente (Gamma et al., 1995). Los patrones pueden ser de bajo nivel y de detalle, tales como la programacin de lenguajes lenguaje, en un moderado nivel, como los patrones de diseo que expresan objeto comn y los patrones de clase, o en un nivel an ms alto. Un estilo arquitectnico es un tipo de patrn que se produce en un nivel de arquitectura y se aplica a elementos arquitectnicos como componentes y mdulos. Una arquitectura define un lenguaje que consiste en elementos y limitaciones. Un estilo arquitectnico, a menudo abreviado como acaba de estilo, define un conjunto de tipos de elementos (tales como mdulos, componentes, conectores y puertos) que se pueden utilizar. Un sistema que se ajuste a ese estilo debe utilizar ese tipo (ya veces slo los tipos), lo que limita el espacio de diseo. Un estilo define adems un conjunto de restricciones que restringen cmo se pueden utilizar los tipos, tales como la topologa del sistema de tiempo de ejecucin, las dependencias entre los mdulos, direccin del flujo de datos a travs de conectores, y la visibilidad de los componentes. Un estilo puede tambin definir las responsabilidades de los elementos. Algunos estndares de la industria pueden ser considerados como los estilos arquitectnicos. Empresa Java Beans (EJB), por ejemplo, consiste en una especificacin y varias implementaciones de proveedores. Se define un conjunto de elementos, como los frijoles y el contenedor de aplicaciones, y las relaciones entre ellos. Los estilos arquitectnicos fueron reconocidos por primera vez en la ViewType tiempo de ejecucin, que todava tiene la mayor variedad de estilos reconocidos, pero el concepto de estilo se ha ampliado para cubrir el mdulo y viewtypes asignacin tambin. Este captulo proporciona un modesto catlogo de estilos arquitectnicos, la mayora de los que aparecen en los catlogos publicados en otros lugares. Las descripciones aqu hincapi en la conexin entre las limitaciones que te impones y las propiedades del sistema que usted logre como resultado. Antes de saltar en el catlogo, sin embargo, este captulo cubre las ventajas de estilos arquitectnicos, la diferencia entre los estilos que se ven en la prctica (estilos incorporados) y aquellos en los catlogos (estilos platnicos), la conexin entre los estilos de la arquitectura y el diseo centrado en y la distincin entre los patrones arquitectnicos y estilos arquitectnicos. Las restricciones pueden actuar como gua de carriles (recurdese la seccin 2.2) que sealan un sistema en el que desea que vaya. Por ejemplo, para mejorar la seguridad en un sistema de Internet, puede imponer la restriccin de que todas las entradas deben ser desinfectados. Trabajar dentro de las limitaciones de un estilo puede ser difcil. Las limitaciones que usted (o alguien ms) impuso ayer pueden ser inapropiados hoy. Una vez que el sistema est construido dentro de un estilo, puede requerir un esfuerzo considerable para cambiar a un estilo diferente. Eso podra estar bien si pudieran decidir con facilidad, de antemano, que el estilo era la mejor opcin, pero eso es difcil de hacer. Una vez que imponen restricciones, mantenimiento de un sistema puede ser ms difcil porque es posible que tenga que buscar diseos no evidentes slo para mantenerse dentro de los lmites del estilo. As que por qu debera considerar la imposicin de restricciones o usando un estilo? Prefabricados conjunto de restricciones. Usted puede pensar en un estilo como un conjunto prefabricado de las limitaciones con las ventajas y los inconvenientes conocidos. Como cualquier cosa prefabricada, usted se ahorrar el trabajo de diseo y depurarlo. No puede ser perfectamente adaptada a sus necesidades, pero tiene la ventaja de que ya existe y que tiene propiedades conocidas. La coherencia y la comprensibilidad. La consistencia provocada por las limitaciones del estilo puede alentar la evolucin limpia del sistema, lo que puede facilitar el mantenimiento. En lugar de un montn de diferentes arbitrariamente buenas ideas se estn aplicando, se obtiene una buena idea, aplicado de manera coherente. Comunicacin. La comunicacin entre los desarrolladores se mejora porque el simple nombre de un estilo, como la publicacin-suscripcin, expresa concisamente la intencin del diseo a otros desarrolladores. Al igual que con

14.1 Ventajas

los patrones de diseo con nombre (por ejemplo, Factory, Observador y Estrategia), los desarrolladores que conocen los nombres pueden comunicarse de manera ms eficiente Reutilizacin del diseo. Cuando se utiliza un estilo, vuelve a utilizar un conjunto prefabricado de restricciones. Como resultado, cualquier ingeniero de escribir en ese estilo tiene la ventaja de la reutilizacin de los conocimientos de diseo de ingenieros de alto nivel, que sea inventado o seleccionadas ella. Usted puede ir ms all e impulsar estas limitaciones de estilo en la ejecucin de cdigo, llamado Arquitectura de elevacin. Por ejemplo, el proyecto del sistema de datos de la Misin de NASA / JPL (MDS) dise un conjunto de componentes y las relaciones que ha funcionado bien para salvar su ingeniera de sistemas con la ingeniera de software. A continuacin, se izan este estilo en una aplicacin que hace cumplir las limitaciones de estilo (Barrett et al., 2004). Como resultado, cualquier ingeniero en el proyecto fue capaz de volver a utilizar el conocimiento de los ingenieros de diseo de alto nivel. Asegrese de atributos de calidad. Uno de los problemas con, cdigo de su eleccin sin restricciones es que puede hacer cualquier cosa. Si usted necesita el cdigo para tener una cierta calidad, tales como el mantenimiento, la escalabilidad o seguridad, debe restringirlo. Por ejemplo, una pieza de software que utilizo regularmente tiene la capacidad de ser ampliado con plugins escritos por el usuario escritas en un lenguaje de programacin. Aunque puedo descargar muchos de estos plugins, rara vez funcionan. Por qu? Debido a que el software se ejecuta en varias plataformas, y sin embargo, los plugins no estn obligados a utilizar una biblioteca multiplataforma. Los plugins sin restricciones siempre hacen una referencia especfica de la plataforma, como C: \ TEMP, lo que hace que se rompan en otras plataformas. En resumen, si el software quiere plugins para ejecutar mltiples plataformas, debe limitar lo que el cdigo del plugin puede hacer. Los anlisis. El otro problema, cdigo de su eleccin sin restricciones es que no se puede analizar. Si se le pide para decidir si un sistema COTS se integrar con la suya, y que el sistema no tiene limitaciones, entonces usted tendr que poner las botas de vadeo profundo y cavar a travs del cdigo. Por otro lado, si usted sabe que se utiliza el mismo estilo arquitectnico que el sistema (tal vez cliente y servidor) y sus mensajes se formatean utilizando la misma norma que el suyo, usted debe tener un tiempo ms fcil la decisin (es decir, el anlisis). En resumen, no hay restricciones significa ningn anlisis.

14.2 platnica vs estilos consagrados

Si usted ha ledo el libro de patrones de diseo (Gamma et al., 1995), se habr dado cuenta que el cdigo real puede variar de la versin ideal del patrn en el libro. No debe ser ninguna sorpresa, entonces, que los estilos arquitectnicos y los patrones difieren del ideal tambin, y la diferencia puede ser muy grande. Patrones y estilos sirven para varios propsitos. Uno de los propsitos es explicativa, en que el nombre del patrn comunica el diseo general. Otro propsito es proporcionar cualidades de diseo, tales como el estilo tubo con filtro que permite la reconfiguracin de los filtros. Un cambio en el patrn o estilo an podra comunicar el diseo en general, mientras que la disminucin de su influencia en la calidad del diseo. Con esto en mente, aqu hay dos formas polarizadas para pensar acerca de los estilos arquitectnicos o patrones. Estilos platnicos. El estilo arquitectnico es una idealizacin platnica, llamado as por los ideales platnicos como crculos perfectos. Estas son las clases de estilos y modelos que encontrar en los libros y slo rara vez en el cdigo fuente. Estilos encarnada. Un estilo arquitectnico plasmado se observa en los sistemas reales. A menudo viola las estrictas limitaciones encontradas en los estilos platnicos. Esa violacin implica a menudo una gran desventaja: ya no se puede confiar en las propiedades de estilo ms, ya que esas propiedades se derivan de las restricciones. Estilos veces encarnados son tambin platnica, como fue el sistema de datos de la Misin de NASA / JPL (MDS) de estilo. Un par de ejemplos debe reforzar la diferencia entre los dos y poner de relieve las ventajas y desventajas. El estilo arquitectnico tubo con filtro impone la restriccin de que slo filtra comunicarse a travs de las tuberas y son de otra manera independiente. Sin embargo, en la prctica, a menudo se encontrar con cadenas de tuberas y filtros en la primera y / o el ltimo filtro viola la restriccin. A veces, el primer filtro lee datos de un lugar que no sea un tubo, ya veces el ltimo ejerce control de filtro de toda la cadena. Estas violacines afectan la propiedad del estilo, reconfiguracin de los mismos? Probablemente, pero slo el primero o el ltimo filtro, y otros filtros pueden ser reconfigurados. Estas violacines impacto en el valor explicativo del nombre del estilo? Probablemente no.

Un segundo ejemplo es el estilo cliente-servidor. El estilo platnico requiere que los servidores sean conscientes de los clientes, ya que esto produce acoplamiento beneficios: los cambios en el cliente no tendr un impacto en el servidor. Sin embargo, puede encontrar versiones consagradas del estilo en servidores a veces empujan a los datos, no solicitados por el consumidor. Dependiendo de cmo se implementa, puede resultar en un servidor que depende de los clientes.

14.3 Limitaciones y diseo de arquitectura orientada

Platnicos estilos arquitectnicos y la arquitectura centrada en el diseo (vase la seccin 2.7) estn conceptualmente relacionadas. Recordemos que la arquitectura centrada en el diseo significa que usted est confiando en su arquitectura para reducir los riesgos, lograr caractersticas o cualidades garantizar: usted est en funcin conscientemente en la arquitectura para lograr un objetivo. Cuando despus de la arquitectura centrada en el diseo, se puede inventar una nueva arquitectura para lograr su objetivo, o se puede emplear un estilo arquitectnico existente con sus conocidos efectos sobre la calidad del sistema. Basndose en la arquitectura para garantizar calidades del sistema se relaciona con la platnica y estilos incorporados. Siguiendo estrictamente las restricciones de un estilo arquitectnico platnica produce propiedades conocidas, que usted es ms probable que lo haga con el diseo de la arquitectura orientada. Usted puede incluso elegir para izar (ver seccin 2.8) partes del estilo para hacer cumplir su uso. Por el contrario, si usted est siguiendo el diseo de arquitectura indiferente (ver seccin 2.6), puede utilizar estilos incorporados, donde no se siguen estrictamente las restricciones de estilo. A pesar de las desviaciones, el sistema puede obtener algunas de las cualidades deseadas. El estilo llamado todava servir como una inspiracin o gua. No es incorrecto utilizar un estilo consagrado como esto, pero debe hacerlo a sabiendas, ya que sera imprudente para violar las restricciones de un estilo an as esperan sus beneficios.

14.4 Patrones vs estilos

Puede ser til para distinguir los patrones arquitectnicos de estilos arquitectnicos, donde los patrones estn en una escala ms pequea que los estilos. Los patrones pueden aparecer en cualquier parte de su diseo, y mltiples patrones podran aparecer en el mismo diseo. En contraste, un sistema por lo general tiene un nico estilo arquitectnico dominante. Por ejemplo, si un sistema tiene una arquitectura de estilo cliente-servidor, que se puede esperar para ver los componentes de cliente y servidor en los puntos de vista de diseo de alto nivel. El sistema tambin podra emplear patrones de arquitectura, como la transferencia de estado representacional (REST) patrn para limitar el tamao de los mensajes intercambiados por los clientes y los servidores, o el patrn de directorio, por lo que los clientes pueden buscar las direcciones de los servidores. La distincin entre los estilos arquitectnicos y diseos arquitectnicos no es claro y, sin duda, usted encontrar ejemplos en los que es difcil diferenciarlos. Como los sistemas se hacen ms grandes, es ms comn ver sistemas-de-sistemas, donde un sistema que fue Independientes se ha incorporado en un sistema ms grande. Si el sistema autnomo original tena un estilo arquitectnico, pero ahora est subordinada al estilo del sistema mayor, eso degradarlo a un patrn arquitectnico? Probablemente. As que en lugar de preocuparse por la categorizacin de algo como un lenguaje, un patrn de diseo, un patrn arquitectnico, o un estilo arquitectnico, se les puede llamar a todos los patrones de seguridad, y, probablemente, utilizar los trminos patrn arquitectnico y el estilo arquitectnico como sinnimos.

14.5 Un catlogo de estilos

Las siguientes secciones describen algunos de los estilos arquitectnicos ms comunes. Estos estilos abarcan el mdulo de tiempo de ejecucin, y viewtypes asignacin. Los estilos arquitectnicos se aplican a su diseo y modelos de implementacin, pero no sus modelos de dominio (patrones de anlisis (Fowler, 1996) se aplican a los modelos de dominio). La mayora de estos estilos arquitectnicos se han descrito antes y que aqu se describen, por dos razones. La primera es para proporcionarle una cobertura completa de los temas arquitectnicos, ya que de otro modo se pregunta cules son esos estilos ms comunes son. La segunda razn es para reforzar la conexin entre las limitaciones y los atributos de calidad resultantes. La figura 14.1 proporciona un resumen rpido de los estilos. En l se describe que ViewType cada estilo se aplica a, sus elementos y relaciones, sus limitaciones y los atributos de calidad que promueve. Las descripciones detalladas de textos en las siguientes secciones entrar en ms profundidad y describen variantes y ejemplos de estilo.

14.6 Estilo en capas

La arquitectura en capas es tal vez la ms comn - tan comn que muchos desarrolladores asumen que todos los sistemas son, o deberan ser, en capas. Es posible que encuentre

c o t S q Cor reo!

ViewType Capas Gran bola de barro Pipe-y-Filter Batch-secuencial Modelo Centrado (datos compartidos) Publicacin-suscri pcin Cliente-Servidor y N-Tier Peer-to-Peer
Runtime Mdulo

Elementos y Relaciones
Capas, relacin usos, canales de devolucin de llamada

Restricciones / carriles de gua

Slo se puede utilizar capas inferiores adyacentes Ninguno

Cualidades Promovido
Modifiabilty, portabilidad, reusabilidad Ninguno, pero muchos inhibida

Mdulo

Ninguno

0 e S
r-i

Conectores de tubos, componentes de filtro, leer y escribir puertos

Filtros independientes, proceso gradual Etapas independientes, el procesamiento no incremental

Reconfigurabilidad (modificabilidad), la reutilizacin Reutilizacin, modificabilidad

Runtime

Etapas (pasos), trabajos (lotes)

Runtime

Modelo, Vista y Controlador componentes, actualizar y notificar a los puertos

Vistas y controladores interactan slo a travs del modelo Los productores del evento y los consumidores son ajenos Relacin asimtrica, la independencia del servidor Relacin entre pares igualitaria, todos los nodos de los clientes y los servidores

Modifiability, extensibilidad, concurrencia

Runtime

Publicar y suscribirse puertos, conector de bus de eventos

Mantenibilidad, evolvability

A y

Runtime

Componentes cliente y servidor, conectores de solicitud-respuesta

Capacidad de mantenimiento, capacidad de evolucin, integracin legacy Disponibilidad, flexibilidad, escalabilidad, extensibilidad

Runtime

Componentes, conectores pares solicitud-respuesta

Map-Reduce

Tiempo de asignacin

Maestro,

mapa,

reducir

los Divisible funciones, asignacin Vara

conjunto topologa

de

datos de la

Escalabilidad, el rendimiento, la disponibilidad

ejecucin y trabajadores; conectores del sistema susceptibles de mapear y reducir de archivos local y mundial Vara

Espejo, Granja, y Bastidor

Asignacin

Vara: Actuacin, disponibilidad

oo C N

Figura 14.1: Un resumen condensado de los estilos arquitectnicos de este captulo. Consulte el texto para una lista completa de elementos, relaciones, restricciones y atributos de calidad.

7 14.6. Estilo en capas

Figura 14.2: Un ejemplo de la arquitectura en capas, parte de la ViewType mdulo. Se compone de una pila ordenada de capas que slo puede utilizar la capa adyacente inferior (s). Aqu, la capa 3 podra usar Capa 2 o Capa 1. Las capas inferiores no pueden utilizar las capas superiores, excepto a travs de devoluciones de llamada.

los sistemas que han sido documentados como capas, pero las capas han sido la fuerza de ajuste. Se aplica a los elementos de cdigo fuente, por lo que es parte de la ViewType mdulo. Elementos y limitaciones. El elemento esencial del estilo en capas es una capa y la relacin es esencial una relacin de usos, una especializacin de una relacin de dependencia. El estilo en capas consiste en una pila de capas, donde cada capa acta como una mquina virtual para las capas por encima de ella (vase la figura 14.2) y sus formularios de pedidos, un grfico acclico dirigido. En un estilo de capa simple, una capa slo puede utilizar la capa directamente debajo de ella. Esta limitacin significa que las capas inferiores posteriores estn ocultos, por lo que la interfaz de una capa define una mquina virtual para la capa superior. Considere la Mquina Virtual Java (JVM): programas que se ejecutan en l no pueden usar capas inferiores posteriores y por lo tanto son independientes del sistema operativo y el hardware. Resultando cualidades. Restriccin del estilo de capas lleva directamente a los atributos de calidad que promueve: modificabilidad, portabilidad y reutilizacin. Dado que una capa depende solamente de la capa directamente debajo de ella, las capas posteriores se pueden intercambiar o emulados. Pilas Taller de capas dan ms oportunidades de sustitucin en el posible costo de la ejecucin eficiente (rendimiento). Por ejemplo, la interconexin de sistemas abiertos (OSI) modelo de referencia define una pila de capas de red del ordenador, pero una aplicacin en capas ingenua puede ser sustancialmente ms lenta que una no-capas. Variantes. Las variantes del estilo en capas doblan la restriccin de tal manera que una capa puede ser capaz de saltar hacia abajo a las capas inferiores. Por ejemplo, el bus de mensajes HornetQ ejecuta en la JVM y utiliza la biblioteca de entrada / salida no bloqueante (NIO) Sin embargo, cuando se detecta que se est ejecutando en Linux, se utiliza la biblioteca de entrada / salida asncrona Kernel (AIO), que mejora el rendimiento. Ntese que en este caso se supera el pasivo rendimiento an mantiene modificabilidad, portabilidad y reutilizacin, ya que puede recurrir a la biblioteca NIO estndar de la JVM. Otra variante que se ve es capas compartidas, donde cada capa puede utilizar estas compartidos, o vertical, capas. Estas cepas uso de la definicin de una capa al punto de ruptura, de cmo puede una capa compartida difieren de un ensamblado, mdulo sin restricciones arbitrarias?

Si interpretas estas capas compartidas como la conveniencia visual para mostrar la dependencia de un mdulo comn, en lugar de como un tipo diferente de la capa, esta variante tiene ms sentido. Por ejemplo, si todas las capas en el sistema depende de la biblioteca estndar de C (libc), y que pensaba que era importante mostrar en un diagrama, puede mostrarlo como una capa compartida. Notas. El estilo de capas puede variar en gran medida de su forma platnica a su forma encarnada. La forma platnica, descrito anteriormente, se beneficia de los atributos de calidad claros de su limitacin. Sin embargo, en la prctica, un estilo en capas puede violar su restriccin, y usted puede ver saltando de capas o capas inferiores utilizando capas superiores, lo cual tiene el efecto de anular los beneficios de atributos de calidad. Sin embargo, incluso en esta forma relajada, las capas pueden proporcionar beneficios cognitivos a los desarrolladores debido a que el grupo de capas de mdulos en funcionalidad coherente. Las capas inferiores se pueden comunicar de forma segura con capas ms altas si se utilizan un mecanismo de devolucin de llamada. Consideremos el caso comn de una capa de interfaz de usuario y una capa de funcionalidad bsica. La interfaz de usuario puede ser necesario para actualizar su pantalla basada en lo que el ncleo est haciendo, quiz la actualizacin de una barra de progreso basada en la realizacin de una tarea familiar. El mdulo principal puede definir una interfaz de devolucin de llamada que informa del estado de la tarea. Para mantener la capa de ordenar intacta, la capa de interfaz de usuario debe iniciar la devolucin de llamada, tal vez haciendo el ncleo para informar sobre su estado y pasa a la capa de interfaz de usuario como un parmetro. La capa de ncleo no sabe nada, o depende de la capa de interfaz de usuario en s, ya que la capa de interfaz de usuario implementa una interfaz de devolucin de llamada definido por la capa central. El estilo en capas se describe en (Clements et al., 2010), (Buschmann et al., 1996), y (Shaw y Garlan, 1996).

14.7 Gran bola de estilo barro

Si el estilo de capas es el estilo ms comn objetivo, la gran bola de estilo barro es quizs el ms a menudo realmente logra (Foote y Yoder, 2000). Se caracteriza por la ausencia de cualquier estructura evidente, o tal vez vestigios de la estructura ahora-erosionado. Tambin es tpico intercambio promiscua de la informacin, a veces, en la medida en que las estructuras de datos se convierten efectivamente en mundial. Aunque el mdulo de tiempo de ejecucin, o la asignacin de organizacin puede ser un desastre, a menudo comienza en la ViewType mdulo y se propaga en otras partes. Las reparaciones y el mantenimiento son convenientes y se asemejan a los parches de crudo en lugar de elegantes refactorizaciones. No se hace ningn esfuerzo para hacer cumplir cualquiera integridad conceptual o consistencia. La deuda tcnica es astronmicamente alto. Grandes bolas de barro pueden ocurrir como resultado de cdigo de usar y tirar que persiste durante ms tiempo de lo esperado, a menudo debido a que era til y por lo tanto mantiene. Otro factor es las compensaciones entre los beneficios a corto plazo ya largo plazo. Puede ser de su inters a corto plazo para hacer parches convenientes en lugar de refactorizaciones ms caros.

Figura 14.3: Un ejemplo del estilo arquitectnico tubo con filtro, parte de la ViewType tiempo de ejecucin, que muestra cinco filtros y cinco tubos. Cada filtro incremental debe procesar su entrada y escribir su salida. Por consiguiente, varios filtros y tuberas pueden estar ejecutando simultneamente.

Como era de esperar, estos sistemas tienen una pobre capacidad de mantenimiento y extensibilidad. Es tentador descartar el estilo como un anti-patrn puro, pero Brian Foote y Joseph Yo-der hacer el argumento convincente de que el estilo describe una buena estrategia bastante de ingeniera (Bach, 1997), en la tradicin de Richard Gabriel es peor se mejor argumento (Gabriel, 1994). Los autores sealan que "No todo el shack de almacenamiento patio trasero tiene columnas de mrmol." (Foote y Yoder, 2000) Las fuerzas que impulsan los sistemas para convertirse en grandes bolas de barro tienen una estabilidad peculiar en que una vez que un sistema se convierte en una bola de barro, algunos desarrolladores de encontrar seguridad y el prestigio de ser los pocos que pueden entender y evolucionar, mientras que los que detestan el barro (y, presumiblemente, podra limpiarlo) huir. El resultado es que la bola de barro es rara vez limpiado.

14,8 estilo tubo con filtro

En el estilo arquitectnico tubo con filtro, los datos fluyen a travs de tuberas a los filtros que trabajan en los datos, de manera similar a la forma en que el fluido puede fluir a travs de las tuberas en una planta de procesamiento qumico. Una caracterstica clave del estilo es que toda la red de tuberas-y-filtro es continuamente datos y de procesamiento de forma incremental. Esto lo distingue de la arquitectura por lotes secuenciales (vase la Seccin 14.9), en el que cada etapa de los procesos plenamente sus datos antes de entregrselo a la siguiente. Un ejemplo de un sistema de tuberas con filtro fue visto en el sistema de procesamiento lingstico en la figura 10.7 y otro ejemplo se ve en la figura 14.3. El estilo tubo con filtro se aplica a los elementos de tiempo de ejecucin, por lo que es parte de la ViewType tiempo de ejecucin. Elementos y limitaciones. El estilo pipe-and-filter consta de cuatro elementos: tuberas, filtros, leen los puertos, y escribir puertos. Cuando se opera, un filtro lee algunos de entrada a partir de uno o ms puertos de entrada, que hace algn tipo de procesamiento, y escribe el resultado a uno o ms puertos de salida. Repite esto hasta que es hora de parar. Los filtros pueden enriquecer, refinar o transformar los datos, pero las tuberas slo deben transportar los datos en una direccin, sin cambios, y el fin (Garlan, 2003). Usted puede pensar en cada filtro que se aplica una funcin a su entrada. fuente

10

Ntese, sin embargo, que por medio de tuberas a travs de la salida del filtro de tipo rompe la restriccin de estilo para el clculo incrementales, debido especie debe ver todo el flujo de entrada antes de que pueda escribir su salida.

CAPTULO 14. ESTILOS ARQUITECTNICOS

a travs de los tubos y los filtros hasta que se alcanza un fregadero. Las fuentes y los sumideros son a menudo archivos, pero tambin pueden ser otras fuentes o destinos de transmisin. Al tener ms de una entrada o puerto de salida, una red puede ser ms complicado que simplemente una lnea recta, pero los datos todava fluye en una direccin de la fuente (s) a la pileta (s). Los bucles en la red son raros y, a menudo prohibida. El estilo pipe-and-filter requiere filtros independientes. Los filtros no pueden interactuar unos con otros, incluso indirectamente, excepto a travs de las tuberas, y no pueden compartir el estado entre s. Un filtro no puede hacer suposiciones sobre lo que ocurre aguas arriba o aguas abajo. Para reforzar la idea de la independencia de filtro, se puede pensar en un filtro como oficinista simple en una habitacin cerrada con llave que recibe sobres mensaje pas por debajo de una puerta, los procesa sin hacer referencia a nada ni a nadie fuera de la habitacin, luego se desliza otro mensaje sobre el marco de otro puerta. Un filtro debe leer incrementalmente la entrada que recibe y, a medida que procesa esa entrada, incrementalmente escribir su salida. La intencin de esta restriccin es mantener toda la red de tuberas con filtro de trabajo en todo momento con los datos que fluye a travs de l, en lugar de que los datos se acumulan en un filtro, hambrientos filtros aguas abajo. Es difcil ser preciso sobre esta restriccin, sin embargo. Por ejemplo, est bien para un filtro de leer dos fichas de entrada y escribir el ms grande de los dos para su produccin? Probablemente, ya que no permite que muchos datos que se acumulan antes de escribir una salida gradual. Sin embargo, esta excepcin permite algo que no es, sin duda muy elemental: anlisis. Qu pasa con un filtro que lee tokens hasta que reconozca una expresin? Eso podra permitir que un poco de los datos, tal vez todo eso, a acumularse antes de escribir cualquier salida. Usted debe evaluar esta limitacin en cuanto a sus intenciones con la red de tuberas con filtro, ya que podra ser muy importante o una regla que se puede doblar o romper. La correccin de la red de tuberas con filtro debe ser determinista con respecto a la concurrencia. Independientemente de si su aplicacin se lleva a cabo con la concurrencia, una entrada dada siempre debe dar el mismo resultado. Resultando cualidades. El estilo tubo con filtro permite composicin finales de (re-) de una red. Por ejemplo, en Linux, puede construir una red1 tubera con filtro en la lnea de comandos, as: cat "expenses.txt" | grep "^ ordenador" | cut-f 2 Esto agarrar todas las lneas del archivo que comienzan con "equipo" y salida de las columnas restantes. Hay muchos filtros existentes para elegir (como grep y cortar visto aqu), por lo que los usuarios pueden crear una red sobre la marcha para calcular los resultados que desean. Este es un ejemplo de la modificabilidad o reconfiguracin. Ni siquiera se puede ofrecer una red, slo una coleccin de filtros pre-hechos para que otros puedan montar. Estos

filtros se pueden volver a utilizar por los usuarios. Al trabajar dentro de este estilo, las oportunidades de concurrencia se han mejorado ya que cada filtro puede ejecutarse en su propio subproceso o proceso. En general, las redes de tuberas y filtros no son apropiados para aplicaciones interactivas. Variantes. A veces, la red est limitado a ser lineal. Las redes estn generalmente dirigidos acclicos grficos, pero con cuidado de que es posible introducir bucles. Los filtros pueden ni tirar o empujar a los datos de sus puertos de entrada. Notas. Al implementar una red de tuberas con filtro tendr que prestar atencin a la forma en que debe detenerse. Usted puede terminar la red eternamente, tal vez matando a los procesos, pero cmo saber que se hace el procesamiento? A veces la respuesta viene del dominio, por ejemplo, cuando los datos de entrada (por ejemplo, un archivo) ha llegado al final. Otra alternativa es enviar un token en banda, a lo largo de la tubera, que indica el final de la secuencia. Otra opcin es cerrar las tuberas de manera explcita, y dejar que los filtros de prueba para ver si el tubo todava est abierta. En el resumen, las tuberas son infinitamente rpido y grande. Pero en la prctica, las tuberas se implementan normalmente con un tampn de tamao limitado que se puede llenar, lo que puede afectar al rendimiento del sistema. Tambin habr diferencias de rendimiento si los filtros estn todos en el mismo espacio de memoria o si estn en mquinas separadas. Redes vinculados a la CPU pueden funcionar mejor si se ejecuta en mquinas separadas, pero las redes de ancho de banda con destino pueden correr ms rpido en una sola mquina. Cabe distinguir dos funciones, posiblemente desempean mismo desarrollador, con el fin de aclarar el significado de la independencia filtro. Una de las funciones es la de un desarrollo de filtros. En el desarrollo de un filtro, el desarrollador puede hacer suposiciones sobre el papel del filtro de aguas arriba y aguas abajo, o incluso en el panorama general, al igual que el empleado de la habitacin cerrada con llave. La segunda funcin es la de una red de tuberas de desarrollador-y-filtro. Este desarrollador es responsable del montaje de los filtros existentes en una red que cumple con el objetivo general del sistema, y tiene el conocimiento global acerca de lo que est aguas arriba y aguas abajo de cada filtro. El estilo tubera-y-filtro se describe en (Clements et al., 2010), (Taylor, Medvi-dovic y Dashofy, 2009), (Buschmann et al., 1996), (Garlan, 2003), y (Shaw y Garlan, 1996).

14,9 estilo lotes secuenciales

En la arquitectura de lotes secuenciales, los flujos de datos de etapa en etapa y se procesa incrementalmente. Sin embargo, en contraste con el estilo tubera-y-filtro, cada etapa se completa la totalidad de su procesamiento antes de que escribe su salida. Los datos pueden fluir entre las fases de una corriente, pero es ms a menudo escrito en un archivo en el disco. Un ejemplo de sistema por lotes secuencial se ve en la figura 14.4. El estilo por lotes secuencial se aplica a los elementos de tiempo de ejecucin, por lo que es parte de la ViewType tiempo de ejecucin.

Figura 14.4: Un ejemplo del estilo arquitectnico de lotes secuenciales, parte de la ViewType tiempo de ejecucin, que muestra tres etapas. Cada etapa lee la totalidad de su entrada y escribe su salida completa de una sola vez, no incremental. Por lo tanto, cada etapa se ejecuta en secuencia.

Elementos y limitaciones. Los componentes de procesamiento en una arquitectura de lotes secuencial se denominan una variedad de diferentes nombres, a veces llamado etapas o pasos. No parece haber ningn nombre estndar para los conectores entre etapas, probablemente porque es un acto de abstraccin para ver un archivo en el disco como un conector. Una nica tarea que fluye a travs del sistema de lotes secuencial se llama un lote o un trabajo. Una etapa tiene uno o ms puertos de lectura y escritura puertos. El estilo lotes secuencial tiene limitaciones similares al estilo pipe-and-filter. En particular, cada etapa es similar independiente. Una etapa depende de los datos que se tarda en, pero no en las etapas que vienen antes de que. Etapas no interactan entre s, sino por la entrada y flujos de salida o archivos. Etapas del proceso plenamente su entrada a continuacin, terminar, despus de lo cual la etapa siguiente hace lo mismo.

Un sistema de lotes secuencial es ms a menudo una serie lineal de etapas. No se trabaja en los conectores, que simplemente pasan de datos inalterados desde los puertos de escritura de la etapa anterior a los puertos de lectura de la siguiente etapa. Un sistema discontinuo secuencial se estructura con menos frecuencia como un grfico acclico dirigido, pero al hacerlo crea oportunidades para que las etapas a ejecutar en paralelo.

Resultando cualidades. Sistemas por lotes secuenciales promover los mismos atributos de calidad como el estilo tubera-y-filtro, especialmente desde modificabilidad etapas son independientes el uno del otro. Una diferencia es que, cuando un sistema de tuberas con filtro produce su salida de forma incremental, de salida final de un sistema por lotes secuencial ser ausentes o totalmente disponible, que tendr un impacto facilidad de uso de un sistema. Otra diferencia es que tiene menos oportunidades de concurrencia ya que los estadios no se pueden ejecutar en paralelo a menos que varios trabajos estn fluyendo a travs del sistema. Sistemas por lotes son conceptualmente ms simple ya que slo una etapa se est ejecutando en un momento dado. Tambin pueden tener un mayor rendimiento. Notas. El estilo por lotes secuencial se describe en (Taylor, Medvidovic y Dashofy, 2009), (Garlan, 2003), y (Shaw y Garlan, 1996).

Figura 14.5: Un ejemplo del modelo de centrado estilo arquitectnico, parte de la ViewType tiempo de ejecucin, que muestra el modelo, un componente que recibe actualizaciones sobre el modelo (la Vista), un componente que actualiza el modelo (el controlador), y un componente que hace ambas cosas (la Vista / Controlador). Las vistas y los controladores no interactan entre s, sino por el modelo.

14.10 estilo Modelo centrado en

En el estilo arquitectnico modelo de centrado, componentes independientes interactan con un modelo central (tambin llamado un almacn de datos o repositorio) en lugar de uno con el otro. Tambin se conoce como el estilo repositorio, estilo compartido-datos, o estilo de datos-centrado, se cambia aqu debido a que los nombres de los otros han causado desarrolladores para inferir incorrectamente que se requiere una base de datos relacional, o similares. Este estilo se puede utilizar una base de datos relacional, pero se utiliza ms a menudo en memoria. Un ejemplo se ve en la figura 14.5. Este estilo se aplica a los elementos de tiempo de ejecucin, por lo que es parte de la ViewType tiempo de ejecucin. Por ejemplo, en un entorno de desarrollo moderno e integrado (IDE), un nico modelo central representa el estado del programa de edicin, incluyendo el cdigo fuente y la representacin analizada. Este modelo se presenta al usuario con muchos puntos de vista y controles. Los componentes de la vista y de control son independientes el uno del otro, pero todos dependen de la componente de modelo central. Si el usuario modifica el cdigo fuente, esto cambia el modelo central. El modelo central notifica al componente de elaboracin de la modificacin del cdigo fuente, lo que provoc que volver a compilar y actualizar el modelo central del cdigo analizado. Ese cambio en el modelo central se enva a la vista que muestra las listas de los nombres de los mtodos. Este estilo arquitectnico se relaciona con varios patrones de diseo, incluyendo el Documento-View, Modelo-Vista-Controlador (MVC), y los patrones de Observadores (Gamma et al, 1995;. Schmidt y Buschmann, 2003). Elementos y limitaciones. Cada sistema de modelo de centrado tiene un componente de modelo y una o ms vista, controlador, o los componentes de vista-controlador. Los nombres de estos componentes pueden variar dependiendo de la variedad de estilo modelo centrado se utiliza. Los tipos de conectores pueden variar de manera similar. Si el modelo que implementa el patrn Observer luego los conectores se notificar a los puntos de vista de los cambios, pero las vistas tambin podran sondear el modelo. Si se utiliza una base de datos relacional, los disparadores se pueden utilizar para causar notificaciones de actualizacin. Vistas y controladores dependen nicamente en el modelo, no en la otra. No hay un nico modelo compartido y muchas vistas y controladores. Como en el Modelo-Vista-Controlador, vistas y controladores especiales puede

causar un corto circuito y se comunican directamente, sin pasar por el modelo, pero esto empaa su independencia con el beneficio de un mejor rendimiento. Resultando cualidades. Sistemas en modelos centrados son altamente modificable por la independencia de vista y los componentes del controlador del componente de modelo y las dependencias mnimas. Modifiability tambin se ha mejorado debido a que el productor y el consumidor de informacin se desacoplan. El sistema es extensible desde puntos de vista inesperados y controladores son fciles de agregar ms tarde. Puede ser ms fcil de manejar y conservar el estado ya que se centraliza en el componente del modelo. Concurrencia puede ser promovido desde puntos de vista y los controladores se pueden ejecutar en sus propios hilos o procesos, o incluso en hardware diferente. Notas. Algunos ejemplos de variantes de este estilo son las pizarras, los espacios de tuplas, y consultar bases de datos continuos. Un punto importante variacin es si el modelo est estructurado de antemano. Algunas variantes de poner a disposicin un montn de datos no estructurados que se limpian gradualmente por las vistas y controladores. Otras variantes hacen que los datos estructurados disponibles, pero no saben que los datos sern utilizados por las vistas y controladores. Debido a su modificabilidad y extensibilidad, este estilo es til cuando usted no sabe la futura configuracin del sistema. El estilo modelo centrado se describe en (Taylor, Medvidovic y Dashofy, 2009), (Schmidt y Buschmann, 2003), (Clements et al., 2010), y (Shaw y Garlan, 1996).

14.11 publicacin-suscripcin estilo

En el estilo arquitectnico de publicacin-suscripcin, tambin conocido como pub-sub o basada en eventos, componentes independientes publican eventos y suscribirse a ellos. Un componente de la publicacin ignora la razn del grande-cuadro por qu se publica un evento, ni sabe un componente suscribirse por qu o quien public el evento. Sin duda, el desarrollador que disea el sistema coloca editores y suscriptores de forma deliberada, por ejemplo, un componente publica un "Nuevo Empleado" evento y otro componente se adhiere a ella y rdenes que el nuevo empleado un ordenador. Un ejemplo de un sistema de publicacin-suscripcin se ve en la figura 14.6. El estilo de publicacin-suscripcin se aplica a los elementos de tiempo de ejecucin, por lo que es parte de la ViewType tiempo de ejecucin. Elementos y limitaciones. El estilo de publicacin-suscripcin define dos tipos de puertos, puertos de publicar y suscribir los puertos, y un conector, un bus de eventos (es decir, la publicacin-suscripcin) del conector. Cualquier tipo de componente puede publicar eventos (o suscribirse a

Figura 14.6: Un ejemplo del estilo arquitectnico de publicacin-suscripcin, parte de la ViewType tiempo de ejecucin, que muestra cinco componentes conectados a un (pub-sub) conector de publicacin-suscripcin con puertos publicar y suscribirse puertos. Los suscriptores slo dependen del evento, no en el editor del evento, y los editores de "dispara y olvida", el evento, que no depende de la respuesta de los otros componentes.

ellos) con tal de que utiliza un publish (o suscripcin) puerto. El bus de eventos es un conector de la N-manera en que muchos puertos pueden adherirse a ella, en lugar de la habitual binario conector que conecta exactamente dos puertos. Por lo tanto, un componente puede publicar un evento y muchos de los componentes puede suscribirse a l. Ntese que en este estilo del conector es la estrella de rock, no los componentes, y que el conector es responsable de un poco de trabajo. El conector de bus de eventos es responsable de la entrega de eventos. Los componentes que se publican actos confianza que los eventos se entregan a los suscriptores y suscriptores de confianza que reciben los eventos que estn suscritas. Los suscriptores slo dependen del evento, no en el editor del evento. Los suscriptores no se ven afectados si el desarrollador sistema sustituye un editor evento con una compatible, o divide sus responsabilidades a travs de dos editores, tanto tiempo como se publican los mismos eventos.

Del mismo modo, los editores son ajenos al consumo de evento. Ellos deben trabajar igualmente bien si se reciben sus eventos o si hay otro componente se suscribe a ellos. Se puede imaginar el uso de un bus de eventos para simular una llamada de procedimiento: un componente publica un evento que se recibe por otro y que la respuesta vuelve a travs de un segundo evento. Esto viola la restriccin olvido desde el primer componente est esperando una respuesta. Resultando cualidades. El mayor beneficio de el estilo de publicacin-suscripcin es que desacopla los productores y consumidores de eventos. Como consecuencia, el sistema es ms fcil de mantener y capaces de evolucionar. Tenga en cuenta la situacin en la que un nuevo componente tiene que hacer el trabajo en base a un evento. Simplemente puede suscribirse a ese evento y el sistema no ha tenido cambios. Especficamente, el editor evento es sin cambios. Del mismo modo, un nuevo publicador de eventos se puede aadir sin afectar el sistema, y ms tarde un componente (nueva o existente) puede iniciar la suscripcin a esos eventos. El bus de eventos agrega una capa de direccionamiento indirecto entre productores y consumidores. Por lo tanto, puede afectar al rendimiento del sistema. Sin embargo, los recursos reutilizables pueden tener una mejor ingeniera (y ajustar el rendimiento) detrs de ellos de especial, pero los recursos a medida: considerar la ingeniera detrs de una base de datos relacional COTS contra un repositorio basado en archivos a medida. Una implementacin bus evento es algo que se puede comprar y existen varias implementaciones de cdigo abierto, por lo que el rendimiento de discapacidad desde el estilo puede ser compensado por la madurez comparativa del cdigo bus evento. Variantes. Algunas variantes de estilo de publicacin-suscripcin requieren los suscriptores registrarse y darse de baja de los acontecimientos. Otros utilizan un modelo declarativo en que el abonado simplemente afirma que debe recibir un evento, por ejemplo, usando un lenguaje de programacin o anotacin en un archivo de configuracin. Esto se relaciona con otro punto de variacin: la creacin dinmica de tipos de eventos, editores, o suscriptores. Cuando la variante de estilo permite que tales cambios de tiempo de ejecucin, es un ejemplo de una arquitectura dinmica (vase la Seccin 9.7). Buses eventos varan en lo que las propiedades que soportan. Algunos son duraderos ya que garantizan cualquier mensaje que aceptan no se perdern durante una falla (por ejemplo, corte de energa). Por lo general, garantizan durabilidad, escribiendo todos los eventos de almacenamiento fiable, al menos temporalmente, pero esto viene con una compensacin de latencia. Tambin pueden garantizar la entrega de la orden o la entrega priorizada de los acontecimientos. Algunos pueden permitir que los acontecimientos que se procesan por lotes juntos para evitar tormentas de eventos similares. Los editores y suscriptores definen el vocabulario de los acontecimientos. Por lo tanto, si un editor pone a cabo el evento A y un abonado escucha para el evento B, el vocabulario del sistema consta de los eventos A y B. El sistema puede permitir la administracin de este vocabulario, por ejemplo, la traduccin de un evento en el evento B. Notas. Desde un punto de vista de mantenimiento de software y capacidad de evolucin, la publicacin-suscripcin estilo desacopla editores de eventos de los consumidores, pero no hay que confundir esto con el conocimiento y las intenciones del desarrollador del sistema. Si est diseando un sistema de pub-sub, usted deliberadamente introducir, por ejemplo, un editor del "nuevo empleado" evento y un consumidor de la misma. Tenga cuidado de que este conocimiento y la intencin no se pierde en los diagramas. Es tentador para mostrar simplemente un bus de eventos con todos los componentes conectados a l. En este diagrama, cmo puede saber quin habla a quin? Slo demuestra que cualquiera puede hablar con nadie. El estilo de publicacin-suscripcin se describe en (Clements et al., 2010) y (Shaw y Garlan, 1996). Tambin se describe en (Taylor, Medvidovic y Dashofy, 2009) como el estilo basado en eventos, pero tenga cuidado de tener en cuenta que se utiliza el nombre de publicacin-suscripcin para describir un estilo diferente, lo que este libro llama el estilo modelo centrado.

14.12 estilo cliente-servidor y N-tier

En la arquitectura cliente-servidor, los clientes solicitan los servicios de los servidores. La solicitud es por lo general sincrnica y a travs de un conector de peticin-respuesta, pero puede variar. Existe una asimetra entre el cliente y el servidor en el que el cliente puede solicitar que el servidor

Figura 14.7: Un ejemplo del estilo de arquitectura cliente-servidor, parte de la ViewType tiempo de ejecucin, que muestra un solo servidor conectado a dos clientes. Los clientes pueden iniciar la comunicacin, pero el servidor no puede. El servidor no conoce la identidad de los clientes hasta que se pone en contacto.

no trabajar, pero no a la inversa. Un ejemplo de un sistema cliente-servidor se ve en la figura 14.7. Este estilo se aplica a los elementos de tiempo de ejecucin, por lo que es parte de la ViewType tiempo de ejecucin. Elementos y limitaciones. El estilo cliente-servidor contiene componentes de cliente y servidor y, por lo general, un conector de peticin-respuesta y puertos. Los clientes pueden iniciar la comunicacin, pero el servidor no puede. El servidor no conoce la identidad del cliente hasta que se pone en contacto, pero los clientes deben o bien conocer la identidad del servidor o no saben cmo buscar el servidor. Variantes. El estilo cliente-servidor tiene varios puntos de variacin. Los conectores pueden ser sncrona o asncrona, es posible que haya lmites en la cantidad de clientes o servidores, conexiones quiz con o sin estado (es decir, las sesiones) y la topologa del sistema puede ser esttica o dinmica. Una variante del estilo permite al servidor, despus de su primer contacto con el cliente, para enviar las actualizaciones posteriores del cliente. Un ejemplo de esto es el protocolo de correo IMAP, donde los clientes pueden ponerse en contacto con el servidor y dejar abierto un conector que les proporciona actualizaciones como mensajes de correo electrnico llegan al servidor. Incluso en esta variante, el servidor no puede ponerse en contacto con el cliente sin haber sido solicitados, y la naturaleza de la comunicacin de servidor a cliente est limitado. Otra variante del estilo cliente-servidor es el estilo de N-capas. Este estilo utiliza dos o ms instancias del estilo cliente-servidor para formar una serie de niveles, como se ve en la figura 14.8. Las peticiones deben fluir en una sola direccin a travs del sistema. Un caso comn es un sistema de 3 niveles en una interfaz de usuario acta como un cliente de primer nivel para la lgica de servidor de nivel empresarial, que a su vez acta como un cliente para el servidor de nivel de persistencia. En este estilo, los niveles tienen responsabilidades funcionales exclusivos, por lo que por ejemplo, el nivel de interfaz de usuario es el nico responsable de la interaccin del usuario y el nivel de persistencia guarda exclusivamente los datos persistentes. El estilo de N-capas ha sido descrito como un hbrido entre el tiempo de ejecucin y viewtypes asignacin, ya que los niveles son a menudo (pero no siempre) asociado con hardware diferente. Sin embargo, el hardware podra alojar dos o ms niveles. Las definiciones de los niveles varan, pero la mayora estn de acuerdo en que son agrupaciones lgicas de funciones (como componentes) que se pueden asignar al hardware.

16

CAPTULO 14. ESTILOS ARQUITECTNICOS

Figura 14.8: Un ejemplo de los tipos de arco estilo tectnico, parte del tiempo de ejecucin y asignacin de responsabilidades como el primer N-Tier, que muestranvista-nidas, tres niveles. Cada nivel nivel de interaccin manejo del usuario, el segundo nivel de la lgica tiene def de negocio de manipulacin, y el tercero, la persistencia de manipulacin nivel. Tiers suelen asignarse a hardware especfico, pero el hardware puede alojar mltiples niveles.

Resultando cualidades. El estilo cliente-servidor establece una relacin de poder asimtrica entre el cliente y el servidor en cuanto a quin puede iniciar el proceso. Sin embargo, el resultado suele ser que el servidor termina con ms influencia, ya que se presta el servicio. Una organizacin puede cambiar de un proceso de negocio o la regla cambiando su aplicacin en un solo lugar, el servidor, en lugar de a travs de los muchos clientes, por lo que se mejora la mantenibilidad. Esta central de control tambin ayuda a la capacidad de evolucin del sistema. El estilo cliente-servidor tambin se puede utilizar para integrar los sistemas existentes mediante la creacin de una fachada en todo el sistema existente y tratndolo como un servidor. Notas. El estilo cliente-servidor es similar al estilo modelo centrado, pero el estilo modelo de centrado tiene la restriccin adicional de que los componentes de la vista y el controlador no interactan. En la prctica, los clientes en un sistema cliente-servidor raramente interactan, pero el estilo no lo prohben. El estilo de peer-to-peer es similar, excepto que no ha asimetra entre clientes y servidores - cada par puede ser.

14.13 estilo de Peer-to-peer

En la arquitectura peer-to-peer, los nodos se comunican entre s como iguales y las relaciones jerrquicas estn prohibidos. Cada nodo tiene la capacidad, pero no la obligacin, de actuar como cliente y como servidor. El resultado es una red de nodos que funcionan como pares, donde cada nodo puede solicitar o prestar servicios a cualquier otro nodo. El estilo de peer-to-peer se aplica a los elementos de tiempo de ejecucin, por lo que es parte de la ViewType tiempo de ejecucin. Elementos y limitaciones. Los elementos del estilo peer-to-peer son similares a los del estilo cliente-servidor. Sin embargo, cuando el conector de cliente-servidor (normalmente un conector de peticin-respuesta) hace cumplir un papel de cliente y una funcin de servidor, un conector de peer-to-peer tiene funciones idnticas en cada extremo que permiten a ambas peticiones y respuestas.

Un sistema de peer-to-peer es igualitaria, donde el estilo cliente-servidor es jerrquica. Se requiere la capacidad de actuar como un servidor para cualquier otro nodo y hacer peticiones de cualquier otro nodo, pero esto no significa que cada nodo debe estar totalmente conectado a todos los dems nodos. En cualquier momento dado, un nodo est generalmente conectado a un subconjunto de los nodos, y las conexiones se puede aadir y quitar que el sistema funciona. Es importante reconocer que el estilo de peer-to-peer no es simplemente una relajacin del cliente-servidor asimetra de fuerza, sino de una prohibicin especfica de esa limitacin, ya que las cualidades del estilo de peer-to-peer se derivan de la falta de asimetra Resultando cualidades. Redes Peer-to-peer se utilizan a menudo para proporcionar acceso a los recursos, como los archivos en una red BitTorrent, con copias redundantes de los archivos almacenados en varios nodos. Un nodo podra solicitar el archivo, o partes de l, a partir de cualquiera de los nodos. Por consiguiente, la disponibilidad es promovido, puesto que el archivo est todava disponible, incluso si uno de los nodos se queda sin conexin. Tambin promueve la capacidad de recuperacin, dado que los fallos de nodos individuales son menos propensos a poner en peligro el sistema. A diferencia de los estilos de cliente-servidor, una red peer-to-peer verdad no tiene ningn punto nico de fallo y no se necesita ninguna infraestructura central. La red es altamente escalable y extensible, ya que hay ejemplos1 de las redes peer-to-peer que han crecido a millones de nodos, como BitTorrent y Skype. Estos sistemas pueden crecer en tamao despus de que se despliegan sin cambiar el cdigo y sin la accin promotora. Notas. Algunos de los puntos fuertes de las redes peer-to-peer se derivan de la interconexin-Edness de los nodos, pero esto puede ser subvertido si una pandilla de nodos es disjunta de la red principal: una isla. Evitar islas puede suponer la violacin de la interpretacin estricta de las directrices, tales como la designacin de algunos nodos maestros bien conocidos que se pueden conectar nuevos nodos a la red principal.

14.14 Mapa-reducir estilo

El estilo arquitectnico de mapas reducir es adecuado para el procesamiento de grandes conjuntos de datos, tales como las que se encuentran en los sistemas de escala de Internet, como los motores de bsqueda o en los sitios de redes sociales (Dean y Ghemawat, 2004; Oreizy, Medvidovic y Taylor, 2008). Programas conceptualmente simples, tales como la ordenacin o la bsqueda, se ejecuta lentamente en grandes conjuntos de datos si se utiliza un solo equipo. Este estilo permite el clculo que se extendi a travs de mltiples ordenadores. A medida que el nmero de equipos que se utilizan aumenta, la probabilidad de que uno de ellos falle tambin aumenta, por lo que este estilo permite la recuperacin de tales fracasos. La disposicin general de los elementos en un sistema de mapa reducir-se ve en la figura 14.9. El estilo de mapa-reducir aplica a los elementos de tiempo de ejecucin, pero tambin es dependiente

1 Note that these specific examples are not pure peer-to-peer in that BitTorrent has trackers than facilitate peer exchanges and Skype has supernodes and other non-peer mechanisms to prevent islands in the network.

18 CAPTULO 14. ESTILOS ARQUITECTNICOS

Figura 14.9: Un ejemplo de la cartografa reducir estilo arquitectnico, parte del tiempo de ejecucin y viewtypes asignacin, con tres trabajadores del mapa y dos reducen los trabajadores. Un maestro coordina y distribuye el trabajo a los trabajadores del mapa, que procesan una parte del conjunto de datos de entrada que se leen desde el sistema de archivos global (FS) y escribir en su FS local. Reducir los trabajadores leen los resultados y los combinan, escribiendo su produccin al FS global.

en una configuracin particular de elementos de asignacin para lograr su escalabilidad, lo que es parte tanto del tiempo de ejecucin y viewtypes asignacin. El gran conjunto de datos se divide en conjuntos de datos ms pequeos (llamados divisiones) y se almacena en un sistema de archivos global. Uno o ms de estos conjuntos de datos se procesa (es decir, asignada) por un componente de correlacin de los trabajadores y los resultados intermedios se escriben en su sistema de archivos local. Los resultados intermedios y trabajadores del mapa son independientes, por lo que ningn mapa trabajador puede leer la salida de otro. Un componente trabajador reducir lee los resultados locales de mltiples sistemas de ficheros y cosechadoras locales (es decir, reduce) los resultados para producir un resultado final completo, que se almacena en el sistema de archivos global. Al igual que con los trabajadores del mapa, reducir los trabajadores son independientes. Mapa de los trabajadores y reducir los trabajadores ejecutan en un conjunto de equipos, cada uno con su propio sistema de archivos local. El obrero maestro es responsable de crear instancias de los otros trabajadores y para la asignacin de las divisiones de los trabajadores del mapa. Tambin supervisa la salud de los obreros y reprograma trabajo cuando los trabajadores fallan. Los desarrolladores que trabajan en este estilo slo tienen que razonar sobre la correccin de la forma en que una sola mquina est procesando un solo fragmento de datos. Un montn de computacin paralela que est pasando, pero los desarrolladores pueden ignorarlo, sino que simplemente asegurarse de que cualquier mapa o reducir trabajador implementa su funcin correctamente

Elementos y limitaciones. Un mapa-reducir el sistema tiene un solo obrero maestro y mltiples trabajador mapa y reducir los componentes de los trabajadores. El obrero maestro se comunica con los otros con un conector del controlador trabajador. Mapa trabajadores pueden escribir datos en su sistema de archivos local utilizando un conector de sistema de ficheros local, y reducir los trabajadores leen los datos de manera similar tanto tambin utilizar un conector de sistema de archivos global. Gran parte de este estilo es izada en una biblioteca de la aplicacin estndar (o marco), por lo que los programadores son ambos protegidos de su complejidad y debe respetar sus limitaciones. Para escribir un programa, un desarrollador debe proporcionar una funcin de mapa y una funcin Reducir. Si la funcin que divide el conjunto de entrada original es ineficaz igualmente la creacin de trozos duros (por ejemplo, tamao o complejidad), algunos trabajadores del mapa se toman ms tiempo para ejecutar que otros, ralentizar el sistema global. Cuando se utilizan mapa determinista y reducir funciones, el clculo paralelizado, incluso cuando en la recuperacin de fallos, es lo mismo que un secuencial. Resultando cualidades. El principal atributo de calidad que en mapas reduzca mejora es la escalabilidad. Tareas que eran poco prctico para calcular con un nico equipo se pueden dividir a travs de muchas mquinas, la mejora del rendimiento. Una vez que el programa est escrito para usar el estilo de mapa reducir, podra ejecutarse en un clster de uno, o de mil mquinas. Map-Reduce tambin promueve la disponibilidad, ya que se recupera de fallas de la mquina con la reprogramacin de la obra en otra mquina. Notas. El rendimiento de este estilo est muy influenciado por localidad datos. Los resultados intermedios deben mantenerse cerca del mapa y reducir los componentes de los trabajadores para evitar el uso de ancho de banda de red. El sistema de ficheros global es a menudo un distribuido, sistema de archivos redundantes. Map-Reduce a menudo se combina con el estilo batch secuencial, donde la produccin de un mapa-reducir trabajo proporciona la entrada para el siguiente. Cada trabajo-mapa reducir es una etapa en la red por lotes secuencial. La combinacin de estos dos estilos arquitectnicos (o patrones) puede transformar un problema que no era adecuado para reducir mapa-en uno que es. Map-Reduce se describe como un estilo arquitectnico en (Oreizy, Medvidovic y Taylor, 2008), pero el trabajo seminal es (Dean y Ghemawat, 2004). Hadoop, una implementacin de cdigo abierto de mapas reducir se describe en (Hoff, 2008b) y (Apache Software Foundation, 2010).

14.15 espejo, estante, y estilos de granja

Hasta el momento, los estilos arquitectnicos que han sido desde el mdulo de tiempo de ejecucin y viewtypes. Los estilos de la ViewType asignacin son ms propensos a ser discutido por los ingenieros de la red (o arquitectos) que los arquitectos de software. Estos son algunos breves ejemplos para darle una idea de qu estilos de asignacin parecen. Mirrored. En el estilo de espejo, hardware idntico se duplica y se ejecuta en paralelo. El gobierno ha regulado histricamente el negocio de telefona fija e impone requisitos de tiempo de actividad. Es difcil hacer una sola computadora (un conmutador telefnico es un equipo con una gran cantidad de "perifricos" conectados) suficientemente fiable, adems de que puede tener que ser desconectado para actualizar el software. En consecuencia, conmutadores telefnicos a menudo se construyen con dos equipos de imagen de espejo en el interior. En general, funcionan de bloqueo de paso, duplicar el esfuerzo, pero si uno falla, entonces el otro contina en su propia. Software de arriba puede actualizar en un medio separado de la otra. Dado que cada ordenador es igualmente fiable, la fiabilidad conmutador telefnico va hacia abajo, ya que hay el doble de equipos que ahora pueden fallar, pero su disponibilidad sube, ya que la probabilidad de que ambas fallen simultneamente se baja. Rack. En el estilo de rack, servidores de las materias primas se apilan verticalmente para ocupar un espacio relativamente pequeo piso. Todos los equipos de la parrilla estn conectados a la misma red. Esa red a su vez tiene uno o ms enlaces ascendentes a la Internet. La conexin de red para el bastidor es a menudo ms rpido, o menos ancho de banda limitado, que la red de enlace ascendente, por lo que es ms rpido para dos ordenadores en el mismo bastidor para comunicarse de dos no en el mismo bastidor. Google tiene algunos de sus bastidores de equipo original en exhibicin en el vestbulo y la cremallera es notable por su densidad: hay casos, slo placas madre para computadoras y discos duros separados por cartn. Incluso cuando se utiliza casos, el estilo de bastidor es eficaz en el aumento de la densidad de los ordenadores en una sala de servidores y proporcionando un grupo de equipos con gran ancho de banda entre ellos.

La granja de servidores. En el estilo de servidores, muchos ordenadores (generalmente idnticas) se encuentran en la misma habitacin. La interconexin de los equipos puede variar y la granja puede estar compuesto de muchos bastidores. Farms se entienden mejor en comparacin con su alternativa: ordenadores dedicados, especialmente-configurados atadas a las aplicaciones. Farms, en contraste, son considerados como un recurso de masa que puede alojar cualquier aplicacin. Tenga en cuenta que las aplicaciones pueden tener restricciones en ellos as que son aptos para funcionar en una granja, tales como aptridas. Una granja es fcilmente escalable mediante la adicin de ms de lo mismo tipo de hardware. Los usos ms comunes de las fincas son para la interfaz de usuario y los niveles medios de los sistemas de 3 niveles, en una granja de servidores web se encarga de la interfaz de usuario y otra finca ocupa el nivel medio.

14.16 Conclusin
Un estilo arquitectnico es un tipo de patrn que se produce en un nivel de arquitectura y se aplica a elementos arquitectnicos como componentes y mdulos. Los patrones varan en alcance de idiomas a nivel del lenguaje de programacin de estilos a nivel de arquitectura. Los estilos arquitectnicos son patrones que dominan la arquitectura. Proporcionan un conjunto conocido de elementos, relaciones y restricciones. Las limitaciones que restringen cmo se pueden utilizar los elementos, como la topologa de tiempo de ejecucin del sistema, las dependencias entre los mdulos, la direccin del flujo de datos a travs de sus conectores, y la visibilidad de sus componentes. El uso de estilos alienta la coherencia y la comprensibilidad de su arquitectura, mejora la densidad y la precisin de la comunicacin entre los desarrolladores, y promueve la reutilizacin del diseo. Tal vez lo ms importante, a travs de sus limitaciones, permiten a la arquitectura para promover o garantizar los atributos de calidad, y promover su capacidad para analizarla. Los estilos que usted ha ledo aqu son mejor considerados como ideales platnicos. Cuando nos fijamos en los sistemas reales, es ms probable que encuentre consagrados estilos, los que doblan limitaciones estrictas del estilo. Si las restricciones se doblan demasiado, el estilo puede perder su capacidad para proporcionar cualidades deseables. Estilos tienen una fuerte conexin con diseo de la arquitectura centrada. Arquitectura-centrado de diseo significa que usted est en funcin conscientemente en la arquitectura para lograr un objetivo. Una forma de hacerlo es disear una arquitectura personalizada atento a las cualidades que usted desea. Otra forma es usar un estilo arquitectnico off-the-shelf que promueve esas mismas cualidades. Cuando usted est siguiendo la arquitectura centrada en el diseo, usted gravitar hacia estilos platnicos, porque doblar las limitaciones pone las cualidades deseadas en riesgo. Este captulo analiza los estilos arquitectnicos desde el mdulo de tiempo de ejecucin, y viewtypes asignacin. Los estilos ViewType mdulo eran capas y la gran bola de barro. Los estilos de ejecucin eran pipe-and-filter, lotes secuencial, el modelo centrado en publicacin-suscripcin, cliente-servidor y peer-to-peer. El mapa-reducir y estilos de N-Capas extendi el tiempo de ejecucin y viewtypes asignacin. Y el espejo, conjunto de servidores y estilos de rack eran todos de la ViewType asignacin.

14.17 Otras lecturas

Escritura temprana en los estilos arquitectnicos incluye Perry y Wolf (1992) y la perfeccin titulado "Una gua del campo a Boxology" de Shaw y Clements (1997). Shaw y Garlan (1996) alcanza tambin a los estilos arquitectnicos, incluyendo la mayor parte de los incluidos en este captulo, sino tambin las organiza en categoras, tales como estilos de flujo de datos. Clements et al. (2010) organiza estos estilos en viewtypes y proporciona una descripcin exhaustiva de los elementos, relaciones y restricciones de cada uno. Los estilos arquitectnicos y los patrones estn ambos incluidos en Buschmann et al. (1996), junto con los patrones de diseo de nivel inferior y modismos. Ms reciente escrito sobre los patrones y estilos incluye Taylor, Medvidovic y Dashofy (2009) y los patrones de arquitectura empresarial en Fowler (2002).