UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS

CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
SISTEMAS OPERATIVOS DISTRIBUIDOS
SERVICE FACADE-REDUNDANT IMPLEMENTATION
GRUPO 1

Cuñishpuma Lema César

Mata Bravo María Belén

Pizarro Figueroa Ginger

Quijije Lucas Evelyn

Naranjo Loma Kevin

DOCENTE:

ING. CRESPO LEON CHRISTOPHER

CURSO:
ISI-S-CO-7-5

AÑO LECTIVO:
2018-2019
 TABLA DE CONTENIDO

1 ¿QUÉ ES SOA? .......................................................................................... 4

2 ¿QUÉ ES UN PATRÓN DE DISEÑO? ........................................................ 4

2.1 Objetivos de los patrones ...................................................................... 5

3 ¿QUÉ ES UN PATRON COMPUESTO? ..................................................... 6

4 ¿QUÉ ES UN LENGUAJE DE PATRÓN DE DISEÑO? .............................. 7

5 ¿QUÉ ES UN CATÁLOGO DE PATRÓN DE DISEÑO? ............................. 7

5.1 Patrones orientados a objetos: .............................................................. 8

5.2 Patrones de arquitectura de software.................................................... 8

5.3 Patrones de arquitectura de aplicaciones empresariales ...................... 9

5.4 Patrones EAI ......................................................................................... 9

5.5 Patrones SOA ....................................................................................... 9

6 NOTACIÓN DE PATRONES ..................................................................... 10

6.1 Símbolos de patrones: ........................................................................ 10

6.2 Figuras de patrones: ........................................................................... 10

6.3 Capitalización: ..................................................................................... 11

6.4 Referencias del número de página: .................................................... 11

7 PERFILES DE PATRONES ....................................................................... 12

7.1 Requisito: ............................................................................................ 12

7.2 Icono: .................................................................................................. 12

7.3 Resumen: ............................................................................................ 12

7.4 Problema: ............................................................................................ 12

7.5 Solución: ............................................................................................. 12

7.6 Solicitud:.............................................................................................. 12

7.7 Impactos:............................................................................................. 12

7.8 Relaciones: ......................................................................................... 13

8 PATRONES DE IMPLEMENTACIÓN DE SERVICIO ................................ 13

 8.1 INTRODUCCIÓN ................................................................................ 13

9 SERVICE FACADE ................................................................................... 14

9.1 Problema ............................................................................................. 14

9.2 Solución .............................................................................................. 15

9.3 Aplicación ............................................................................................ 16

9.4 Impacto ............................................................................................... 18

9.5 Relación con otros patrones................................................................ 18

9.6 Caso de estudio .................................................................................. 19

10 PATRON DE IMPLEMENTACIÓN REDUNDANTE ................................... 23

10.1 Problema.......................................................................................... 23

10.2 Solución ........................................................................................... 24

10.3 Solicitud ........................................................................................... 25

10.4 Aplicación......................................................................................... 25

10.5 Impacto ............................................................................................ 26

10.6 Relación con otros patrones ............................................................ 26

10.7 Caso de estudio de ejemplo............................................................. 27

 1 ¿QUÉ ES SOA?
La arquitectura orientada a servicios representa un modelo arquitectónico que
tiene como objetivo mejorar la agilidad y la rentabilidad de una empresa al tiempo
que reduce la carga de TI en la organización en general. Establece una
estructura de diseño para la integración de aplicaciones, que permite a las
organizaciones unir los objetivos de negocio, en cuanto a flexibilidad de
integración con sistemas legados y alineación directa a los procesos de negocio,
con la infraestructura de TI.

Esto permite la reducción de costos de implementación, innovación de servicios

a clientes, adaptación ágil ante cambios y reacción temprana ante la
competitividad, ya que, combinan fácilmente las nuevas tecnologías con
aplicaciones independientes, permitiendo que los componentes del proceso se
integren y coordinen de manera efectiva y rápida.

2 ¿QUÉ ES UN PATRÓN DE DISEÑO?

La forma más sencilla de describir un patrón es que proporciona una solución
comprobada para un problema común documentado individualmente en un
formato coherente y generalmente como parte de una colección más grande.

La noción de un patrón ya es una parte fundamental de la vida cotidiana. Sin

reconocerlo cada vez, naturalmente utilizamos soluciones comprobadas para
resolver problemas comunes cada día. Los patrones en el mundo de TI que giran
en torno al diseño de sistemas automatizados se conocen como patrones de
diseño.

Los patrones de diseño son útiles porque:

 Representar soluciones probadas en el campo para problemas de diseño

comunes.
 Organizar la inteligencia de diseño en un formato estandarizado y
fácilmente "referenciable"
 Generalmente son repetibles por la mayoría de los profesionales de TI
involucrados con el diseño
 Se puede utilizar para garantizar la coherencia en la forma en que se
diseñan y construyen los sistemas
 Puede convertirse en la base de los estándares de diseño.
 Suelen ser flexibles y opcionales (y documentar abiertamente
 Se puede utilizar como ayuda educativa al documentar aspectos
específicos del diseño del sistema (independientemente de si se aplican)
 A veces se puede aplicar antes y después de la implementación de un
sistema.
 Se puede admitir a través de la aplicación de otros patrones de diseño
que forman parte de la misma colección.

2.1 Objetivos de los patrones

Los patrones de diseño pretenden:

 Proporcionar catálogos de elementos reusables en el diseño de sistemas

software.
 Evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
 Formalizar un vocabulario común entre diseñadores.
 Estandarizar el modo en que se realiza el diseño.
 Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.

Asimismo, no pretenden:

 Imponer ciertas alternativas de diseño frente a otras.

  Eliminar la creatividad inherente al proceso de diseño.

3 ¿QUÉ ES UN PATRON COMPUESTO?

Documentan los efectos de aplicar varios patrones juntos. Un "compuesto" es
generalmente algo que se compone de partes interconectadas. Por ejemplo,
podría referirse legítimamente a una composición de servicios como un conjunto
de servicios porque las partes individuales deben diseñarse en un agregado para
que actúen en conjunto.

Un "compuesto", por otro lado, puede considerarse simplemente el resultado de

combinar un conjunto específico de cosas. Un compuesto químico consiste en
una combinación de ingredientes que resultan en algo nuevo cuando se mezclan.

La notación utilizada para expresar patrones compuestos que comprenden

patrones que se aplican conjuntamente frente a los aplicados de manera
coexistente difiere, como se muestra aquí:

Los patrones compuestos que se componen de patrones que se aplican para

coexistir se expresan en una jerarquía, mientras que los que se componen de
patrones que se aplican de forma conjunta se representan mediante una
notación de estilo de fórmula.
 4 ¿QUÉ ES UN LENGUAJE DE PATRÓN DE DISEÑO?
Un lenguaje de patrones es un conjunto de patrones relacionados que actúan
como bloques de construcción en el sentido de que pueden llevarse a cabo en
secuencias de patrones (o secuencias de aplicación de patrones), donde cada
patrón subsiguiente se basa en el anterior.

Los lenguajes de patrones estructurados son útiles porque:

 Puede organizar grupos de patrones de diseño probados en el campo en

secuencias de aplicación propuestas y probadas en el campo
 Garantizar la coherencia en la forma en que se logran los objetivos de
diseño particulares (porque al realizar conjuntos de patrones
interdependientes en un orden comprobado, la calidad de los resultados
se puede garantizar más fácilmente).
 Son herramientas de aprendizaje efectivas que pueden proporcionar
información sobre cómo y por qué se debe aplicar un método o una
técnica en particular, así como los efectos de su aplicación.
 Proporcionar un nivel adicional de profundidad en relación con la
aplicación del patrón (porque documentan los patrones individuales más
los efectos acumulativos de su aplicación)

5 ¿QUÉ ES UN CATÁLOGO DE PATRÓN DE DISEÑO?

Un catálogo de patrones de diseño es simplemente una colección documentada
de patrones de diseño relacionados. Lo que pretende un catálogo de patrones
no es favorecer al diseñador experto, sino más bien ayudar al diseñador
inexperto a adquirir con cierta rapidez las habilidades de aquél, es decir es un
medio para comunicar la experiencia de forma efectiva.

La noción del patrón de diseño debe su existencia a la obra de Christopher

Alexander, fue pionero en el concepto de patrones en relación con la arquitectura
de edificios y áreas relacionadas. Documentó una colección de patrones y los
organizó en una serie predefinida que denominó "secuencia". El resultado fue un
lenguaje de patrones arquitectónicos que inspiró a la comunidad de TI a crear
sus propios patrones para el diseño de sistemas automatizados, también
proporciona información sobre cómo los patrones en general deben y no deben
estructurarse y organizarse.

5.1 Patrones orientados a objetos:

El más reconocido catálogo de patrones es el publicado en Patrones de diseño:
Elementos de software orientado a objetos reutilizables (Gamma, Helm,
Johnson, Vlissides; Addison- Wesley, 1995). Incluye 23 patrones que ayudó a
establecer la orientación a objetos como un enfoque de diseño para soluciones
distribuidas.

5.2 Patrones de arquitectura de software

Estos catálogos de patrones se desarrollaron en cinco volúmenes separados
durante un período de una docena de años como parte de la serie de
Arquitectura de Software Orientada a Patrones (F. Buschmann, K. Henney, M.
Kircher, R. Meunier, H. Rohnert, D. Schmidt , P. Sommerlad, M. Stal, Wiley
1996–2007).

Describe un problema particular y recurrente del diseño, que surge en un

contexto específico, y presenta un esquema genérico y probado de su solución.
Permiten identificar y completar los casos de uso básicos expuestos por el
cliente, comprender la arquitectura del sistema a construir así como su
problemática, y buscar componentes ya desarrollados que cumplan con los
requisitos del tipo de sistema a construir (es decir, permiten obtener de una forma
sencilla la arquitectura base que se busca durante la fase de diseño
arquitectónico).
5.3 Patrones de arquitectura de aplicaciones empresariales
Un catálogo de patrones respetado en este campo se publicó en Patrones de
arquitectura de aplicaciones empresariales (Fowler, Addison-Wesley, 2003). Los
patrones arquitectónicos representan decisiones importantes sobre las
estructuras de aplicaciones empresariales, los patrones de diseño ayudan a
materializar esa arquitectura.

El patrón arquitectónico dominante es el de capas, cómo se descompone una

aplicación empresarial en capas y cómo estas capas trabajan juntas. Las
aplicaciones empresariales normalmente involucran persistencia de datos; hay
muchos datos y se acceden a ellos desde múltiples sitios al mismo tiempo,
concurrentemente.

5.4 Patrones EAI

Estos patrones establecen enfoques sólidos para una comunicación sólida
basada en mensajería y abordan varios desafíos relacionados con la
integración.Una publicación reconocida en este campo es Enterprise Integration
Patterns (Hohpe, Woolf, Addison-Wesley, 2004).

Definen diseños comunes en el desarrollo de funcionalidades relacionadas con

la integración de aplicaciones. Especifican una manera estándar de realizar
ciertas tareas y ayudan a conocer con un lenguaje común determinadas cosas
que desarrollamos habitualmente.

5.5 Patrones SOA

Nos permiten tener una base para encontrar soluciones a problemas comunes
de arquitectura; actualmente existen muchos de ellos que nos permiten obtener
mejor resultados de acuerdo a las necesidades del negocio.
 6 NOTACIÓN DE PATRONES
Los patrones de diseño deben ser referenciados y explicados en texto e
ilustraciones. Se utiliza una notación simple para representar de manera
consistente diferentes tipos de patrones.

6.1 Símbolos de patrones:

Los símbolos estándar utilizados para representar diferentes tipos de
patrones de diseño y cómo los patrones de diseño se relacionan con el
tema actual que se está cubriendo.

6.2 Figuras de patrones:

o Figuras de secuencia de aplicación de patrones

o Figuras de relación de patrón

 o Figuras de jerarquía de patrón compuesto

6.3 Capitalización:
Todos los nombres de patrones de diseño se escriben con mayúscula.
Los nombres de los grupos de patrones relacionados se escriben en
mayúsculas cuando se muestran en Figuras, pero no cuando se hace
referencia en el texto del cuerpo.

6.4 Referencias del número de página:

Este número entre paréntesis, se proporciona con fines de referencia
rápida. Su uso se ha convertido en una convención común entre los
catálogos de patrones. La única vez que no se muestra el número es
cuando se hace referencia a un nombre de patrón dentro de la sección de
perfil de ese patrón.
 7 PERFILES DE PATRONES
Cada uno de los patrones en este catálogo se describe utilizando el mismo
formato de perfil y estructura basados en las siguientes partes:

7.1 Requisito:
Declaración concisa de una sola oración que presenta el requisito
fundamental abordado por el patrón en forma de una pregunta.

7.2 Icono:
Cada descripción de patrón está acompañada por una imagen de icono
que actúa como un identificador visual.

7.3 Resumen:
Tabla de resumen, que consta de declaraciones que colectivamente
proporcionan una sinopsis concisa del patrón para propósitos de
referencia rápida.

7.4 Problema:
El problema que causa un problema y los efectos del problema se
describen en esta sección, generalmente acompañados por una figura
que ilustra con más detalle el "estado del problema".

7.5 Solución:
Esto representa la solución de diseño propuesta por el patrón para
resolver el problema y cumplir el requisito. Es una breve declaración
seguida de un diagrama que comunica de manera concisa el estado final
de la solución.

7.6 Solicitud:
Describe cómo se puede aplicar el patrón. Puede incluir pautas, detalles
de implementación y, a veces, incluso un proceso sugerido.

7.7 Impactos:
Destaca las consecuencias comunes, los costos y los requisitos
asociados con la aplicación de un patrón.
7.8 Relaciones:
Es importante comprender los requisitos y las dependencias que pueden
tener un patrón y los efectos de su aplicación sobre otros patrones.

7.9 Ejemplo de estudio de caso:

Ejemplo de estudio de caso que demuestra la aplicación de muestra de
un patrón.

8 PATRONES DE IMPLEMENTACIÓN DE SERVICIO

8.1 INTRODUCCIÓN
Estos patrones de diseño afectan o aumenta la arquitectura del servicio de una
manera específica, afectando así su implementación física. La mayoría se
consideran especializados, lo que significa que deben utilizarse para requisitos
específicos y es posible que no sean necesarios en absoluto (y rara vez se usan
todos juntos).

Entre los cuales tenemos:

 Service facade

 Redundant Implementation

 Service Data Replication

 Partial State Deferral

 Partial Validation

 UI Mediator
 9 SERVICE FACADE
Resumen del perfil:

9.1 Problema
Cuando un servicio está sujeto a cambios ya sea debido a cambios en el contrato
o en su implementación subyacente, esta lógica de servicio central puede
encontrarse ampliada y aumentada para adaptarse a ese cambio. Como
resultado, el conjunto inicial de la lógica del servicio central con la lógica de
procesamiento específica del contrato o la implementación puede eventualmente
resultar en desafíos de tiempo de diseño y tiempo de ejecución.

Por Ejemplo:

• Se requiere un único cuerpo de lógica de servicio para admitir contratos

múltiples, introduciendo así una nueva lógica de decisión y requiriendo que las
rutinas de negocios centrales procesen diferentes tipos de mensajes de entrada
y salida.

• Los patrones de uso de los recursos compartidos a los que accede el servicio
se modifican, lo que da como resultado cambios en el comportamiento del
servicio establecido que terminan afectando negativamente a los consumidores
de servicios existentes.

• La implementación del servicio se actualiza o redacta, dando como resultado

cambios en la lógica de negocios central para acomodar la implementación
nueva y / o mejorada.

• El servicio está sujeto a descomposición, según la descomposición del servicio.

Si la lógica del servicio central está acoplada directamente al contrato, cualquier

cambio en la forma en que el servicio interactúa con los consumidores requerirá
cambios en la lógica del servicio central.

9.2 Solución
La lógica de fachada se inserta en la arquitectura del servicio para establecer
una o más capas de abstracción que pueden acomodar cambios futuros en el
contrato de servicio, la lógica del servicio y la implementación del servicio
subyacente.
9.3 Aplicación
La lógica de fachada de servicio se considera parte de la lógica de servicio
general pero distinto de la lógica de servicio central, de la siguiente manera:

 Se espera que la lógica de servicio principal proporcione el rango de

funciones responsables de llevar a cabo las capacidades expresadas por
el contrato de servicio.
 La lógica de la fachada de servicio es la principal responsable de
proporcionar una lógica de procesamiento intermedia suplementaria en
apoyo de la lógica de servicio central.

La lógica de la fachada de servicio generalmente está aislada en un componente

separado que forma parte de la arquitectura del servicio. Los tipos comunes de
lógica que tienden a residir dentro de un componente de fachada de servicio
incluyen:

 Lógica de retransmisión.
 Lógica de agente.
 Corrección de comportamiento.
 Requisitos específicos del contrato.

Los componentes de la fachada de servicio se pueden posicionar dentro de una

arquitectura de servicio de diferentes maneras, dependiendo de la naturaleza y
el alcance de la abstracción requerida.
Al diseñar servicios, se nos recomienda adaptar la lógica de servicio subyacente
para respaldar los contratos de servicio personalizados y estandarizados de
forma independiente. La primera arquitectura (izquierda) requiere una nueva
versión de la lógica de servicio central que ahora está acoplada a dos contratos,
mientras que la segunda (derecha) requiere la creación de un nuevo servicio en
conjunto, lo que lleva a una lógica de servicio central redundante.

Los componentes de la fachada de servicio están intencionalmente acoplados

estrechamente a sus respectivos contratos, lo que permite que la lógica de
servicio central permanezca acoplada o incluso desacoplada.

Los nuevos contratos de servicio se pueden acomodar repitiendo este patrón

para introducir nuevos componentes de fachada, con lo que potencialmente se
puede proteger la lógica del servicio central.
9.4 Impacto
La creación de componentes de fachada da como resultado una mayor cantidad
de descomposición de la lógica física. Esto naturalmente introduce un esfuerzo
adicional de diseño y desarrollo, así como requisitos adicionales de
comunicación entre componentes. Aunque se espera cierta sobrecarga de
rendimiento, generalmente es menor siempre que los componentes de la
fachada y el servicio central estén ubicados en el mismo servidor físico.

9.5 Relación con otros patrones

La solución estructural proporcionada por Service Facade ayuda a respaldar la
aplicación de varios otros patrones, entre ellos:

 Service Refactoring
 Service Decomposition
 Proxy Capability
 Agnostic Sub-Controller
 Inventory Endpoint
 Distributed Capacidad
9.6 Caso de estudio
Los arquitectos de FRC deciden diseñar un componente de fachada de servicio
que se utilizará para vincularse con el contrato oficial de WSDL para el servicio
de evaluaciones apeladas. El componente de fachada se llama apropiadamente
Data Relayer, y su responsabilidad principal es recibir solicitudes del consumidor
del servicio a través del contrato WSDL estandarizado, retransmitir esas
solicitudes a los componentes de envoltura internos correspondientes y luego
transmitir las respuestas al consumidor del servicio.

El componente Data Relayer contiene una cantidad modesta de lógica, la

mayoría de las cuales se enfoca en validar los informes de datos recibidos del
componente Data Controller y convertirlos al formato y modelo de datos
requeridos por la messageconstrucción WSDL del servicio de Appealed
Assessmentments y el XML asociado.

La arquitectura de servicio resultante permite que el componente del Controlador

de datos original evolucione de forma independiente al establecer el componente
Relay de datos como una fachada intermedia dedicada al servicio de
evaluaciones apeladas.

Esta arquitectura acomoda aún más los cambios esperados en el componente

Controlador de datos. Si alguno de estos cambios afecta el formato o los datos
de los informes generados por las funciones del Controlador de datos, el
componente Data Relayer puede aumentarse para compensar estos cambios,
de modo que el contrato de servicio de evaluaciones de apelaciones permanezca
sin cambios y los consumidores de este servicio no se vean afectados.

9.7 Implementación

Creamos nuestros paquetes con sus respectivas clases.

CLASE APP

CLASE CHECKFACADE

CALSE AVION
CLASE HOTEL

SOLUCION DE LA FACHADA

9.8 Herramientas utilizadas

ECLIPSE
 10 PATRON DE IMPLEMENTACIÓN REDUNDANTE
Implementación redundante es el nombre de un patrón de diseño creado por
Thomas Erl y publicado como parte del catálogo de patrones de diseño
SOA. Dentro del catálogo, este patrón se categoriza aún más como uno de los
Patrones de Implementación del Servicio.

El ícono usado para identificar la Implementación Redundante es:

La declaración de requisitos para la Implementación Redundante es:

¿Cómo se puede aumentar la confiabilidad y disponibilidad de un servicio?

Ventajas Desventajas
* La implementación de este * Se requiere un esfuerzo adicional para
patrón permite el aumento de la mantener la gobernabilidad todas las
disponibilidad del servicio. implementaciones redundantes en
* Mejora la confiabilidad y sincronía.
escalabilidad de los servicios y el * Se incrementan los requerimientos de
inventario de servicios en su infraestructura y asociados, demanda
conjunto. operativas relacionadas con el gobierno.
* Autonomía del servicio.

10.1 Problema
 Un servicio que se está reutilizando activamente introduce un posible
punto único de falla que puede poner en peligro la confiabilidad de todas
las composiciones en las que participa si se produce una condición de
error inesperado.
  Los servicios agnósticos son propensos a ser reutilizados repetidamente
por diferentes composiciones de servicios. Como resultado, cada servicio
independiente puede introducir un único punto de falla para cada
composición. Teniendo en cuenta el énfasis en la reutilización repetida
dentro de la orientación al servicio, es fácilmente previsible que cada
composición compleja esté compuesta por múltiples servicios agnósticos
que introducen múltiples puntos potenciales de falla

Cuando un servicio altamente reutilizado no esté disponible inesperadamente,

pondrá en peligro a todos sus consumidores de servicios.

10.2 Solución
 Los servicios reutilizables se pueden implementar a través de
implementaciones redundantes o con soporte de conmutación por error.
 Se pueden implementar múltiples implementaciones de servicios con un
alto potencial de reutilización o que proporcionan una funcionalidad crítica
para garantizar una alta disponibilidad y una mayor confiabilidad, incluso
cuando ocurren excepciones inesperadas o interrupciones.
Tener implementaciones redundantes de servicios agnósticos proporciona
protección contra fallas en caso de que alguna implementación caiga

10.3 Solicitud
 La misma implementación de servicio se implementa de forma redundante
o es compatible con la infraestructura con funciones de redundancia.
 Cuando los servicios se implementan de forma redundante, hay varias
formas en que se puede aplicar este patrón:
o Se pueden establecer diferentes implementaciones de servicios
redundantes para diferentes conjuntos de consumidores de
servicios.
o Una implementación de servicio se designa como el punto de
contacto oficial para los consumidores, pero está respaldada por
una o más implementaciones de respaldo que se utilizan en caso
de falla o falta de disponibilidad.

El Servicio A tiene múltiples contratos de servicio, así como una implementación

redundante, lo que permite que este servicio facilite una amplia gama de
programas para el consumidor.

10.4 Aplicación
La implementación del mismo servicio se implementa redundantemente o es
apoyada por infraestructura con características de redundancia.
10.5 Impacto
Si bien la aplicación de Implementación redundante mejorará la autonomía, la
confiabilidad y la escalabilidad de los servicios y el inventario de servicios en su
conjunto, claramente trae consigo algunos impactos tangibles, los principales de
los cuales son el aumento de los requisitos de infraestructura y las demandas
asociadas de gobierno relacionadas con las operaciones.

Por ejemplo, es posible que sea necesario un esfuerzo de administración y

hardware adicional para cada servicio implementado de forma redundante y se
requiere un gobierno adicional para mantener sincronizadas todas las
arquitecturas de servicios duplicadas en la medida que sea necesario.

10.6 Relación con otros patrones

Los servicios agnósticos naturalmente tienen las demandas de uso más
concurrentes y, por lo tanto, tienen la mayor necesidad de este patrón, por lo que
es importante para los servicios definidos a través de Entity Abstraction ( 175 ) y
Utility Abstraction ( 168 ). Sin embargo, incluso los servicios no agnósticos, como
los realizados a través de Inventory Endpoint ( 260 ), pueden requerir una
implementación redundante debido a las demandas de confiabilidad. La
autonomía de la composición ( 616 ) a menudo aplicará repetidamente la
implementación redundante para garantizar que los servicios que participan en
la composición puedan lograr mayores niveles de autonomía y aislamiento.
Además, el establecimiento de una implementación redundante de un servicio
que requiere acceso a fuentes de datos compartidas generalmente exigirá la
participación de la replicación de datos de servicio
El soporte de Implementación redundante para el principio de diseño de
Autonomía del servicio afecta a varios otros patrones más especializados
(relacionados con la autonomía).

10.7 Caso de estudio de ejemplo

Como se ilustra en el ejemplo de estudio de caso para la capa de utilidad de
dominio cruzado

Los inventarios de los servicios Alleywood y Tri-Fold se han diseñado para

compartir un conjunto de servicios de utilidad comunes. Posteriormente a la
implementación de esta nueva arquitectura de dominios cruzados, algunos de
estos servicios de utilidad, naturalmente, se hicieron muy populares. En
particular, el servicio Alert se vio afectado por una gran cantidad de uso
simultáneo en cualquier día laboral. Al ser el servicio responsable de emitir
notificaciones importantes cuando ocurrieron condiciones de excepción
predefinidas específicas (incluidas las infracciones de seguridad y políticas), el
servicio de alerta se clasificó como una parte de misión crítica de la arquitectura
empresarial general. Como resultado, se emitió un requisito en firme, que no
permite que el servicio Alert alcance su límite de uso y que se reduzcan al mínimo
las posibilidades de falla del servicio. Para satisfacer estos requisitos, se crearon
tres implementaciones redundantes del servicio de alerta, lo que dio como
resultado cuatro implementaciones de servicio totales. Dos se implementaron
dentro de cada entorno (Alleywood y Tri-Fold), el segundo en cada entorno
consideró la copia de seguridad del primero. Los agentes de enrutamiento
inteligentes realizaron equilibrio de carga y conmutación por error en cada par
de servicios de alerta, según sea necesario.

10.8 Implementación
Disponibilidad de un servicio mediante un balanceador de carga Haproxy.

1.-Se instala 3 máquinas virtuales para:

 Haproxy
 Servidor web 1
 Servidor web 2

2.- En la maquina donde estará el balanceador de carga se instala haproxy con

el comando apt-get install haproxy
3.- Verificamos si el script de inicio está habilitado mediante el comando sudo
nano /etc/default/haproxy Si no está habilitado cambiamos ENABLED=1
4.- Antes de configurar el haproxy tenemos que saber las direcciones ip de los
servidores web que son las otras máquinas virtuales.
5.- Mediante el comando nano /etc/haproxy/haproxy.cfg se ingresa a la
configuración del haproxy y se añade algunas líneas de código en donde indica
que todo lo que ingresa por el puerto 80 utilizara los servidores antes
mencionado.

6.- Se recarga el servicio de haproxy con el comando sudo service haproxy

reload y se verifica si está activo con service haproxy status
7.- En las máquinas virtuales donde están alojados los servidores web se instala
Apache2 mediante el comando sudo apt-get install apache2

8.- Se edita el archivo html en los dos servidores web mediante el comando nano
/var/www/html/index.html (SERVIDOR 1 y SERVIDOR 2)
9.- En la máquina virtual donde está alojado el balanceador de carga abrimos
nuestro navegador web e ingresamos la dirección ip de la máquina virtual en
donde está instalado el haproxy y se verifica que está utilizando los dos
servidores web.

10.9 Herramientas utilizadas

 Vmware
 Haproxy
 Apache2

11 CONCLUSIONES
11.1 Ginger Pizarro
El patrón de implementación redundante ocurre cuando un servicio es reutilizado
en varias composiciones activamente y tiene un punto de falla que pone en
peligro la fiabilidad de todas las composiciones generando un error, para lo cual
este patrón usa servicios de forma redundante o con soporte failover
(conmutación por error) en el caso de llegar a fallar un servicio, existe uno
alterno.
11.2 Evelyn Quijije
Los patrones ayudan a poder estructurar para poder resolver un problema en
específico. Los patrones de diseño ayudan a estandarizar el código haciendo
que la programación sea más comprensible para los programadores. Es decir,
los patrones de diseño son muy útiles, es por ello que son conocidos como las
mejores prácticas en el desarrollo y construcción de software.

11.3 Cesar Cuñishpuma

La alta disponibilidad es una función del diseño del sistema que permite que una
aplicación se reinicie o redirija automáticamente el trabajo a otro sistema capaz
en caso de una falla. El uso más común de HAproxy es mejorar el rendimiento y
la confiabilidad de un entorno de servidor distribuyendo la carga de trabajo entre
múltiples servidores (por ejemplo, web, aplicación, base de datos).

11.4 María Mata

El patrón Service Facade es de mucha utilidad cuando se necesita brindar
servicios a web mediante la arquitectura SOA, con ello es posible realizar la
migración de sistemas legados que poseen mucha complejidad, además brinda
la posibilidad de que ciertos sistemas o servicios puedan evolucionar sin afectar
a los consumidores.

11.5 Kevin Naranjo

El patrón de diseño facade o fachada nos permite simplificar el interface de
comunicación entre dos objetos A y B de tal forma que para el objeto A sea más
sencillo interactuar con el objeto B. De esta manera el cliente solo se conecta
con una interface sencilla, mientras que la interface sencilla se conecta a su vez
a otras interfaces más complejas.

12 PREGUNTAS
12.1 Service Facade
¿En qué se centra el patrón de diseño Service Facade?

En el diseño central de los servicios.

En los contratos de los sistemas

En hacer más complejos los servicios

¿Cuál es el objetivo fundamental al diseñar soluciones orientadas a servicios?

Lograr un qué sistemas seas complejos

Lograr un grado reducido de acoplamiento entre servicios

12.2 Redundant Implementation

¿Qué es HAproxy?

HAProxy es un software gratuito de código abierto que proporciona

un equilibrador de carga y un servidor proxy de alta disponibilidad
para aplicaciones basadas en TCP y HTTP que distribuyen las solicitudes en
varios servidores. Está escrito en C y tiene una reputación de ser rápido y
eficiente.