UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS

GRUPO 1

DOCENTE:

ING. .

CURSO:
ISI-S-CO-7-5

AÑO LECTIVO:
2019-2020
TABLA DE CONTENIDO
1 ¿QUÉ ES SOA? .......................................................................................... 3

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

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

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

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

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

7 PERFILES DE PATRONES ....................................................................... 10

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

8.1 INTRODUCCIÓN ................................................................................. 11

9 SERVICE FACADE ................................................................................... 12

9.1 Problema .............................................................................................. 12

9.2 Solución ............................................................................................... 13

9.3 Aplicación ............................................................................................ 14

9.4 Impacto ................................................................................................ 15

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

9.6 Caso de estudio ..................................................................................... 16

9.7 Implementación ..................................................................................... 18

9.8 Herramientas utilizadas .......................................................................... 23

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

10.1 Problema ........................................................................................... 24

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

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

10.4 Aplicación ......................................................................................... 26

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

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

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

10.8 Implementación .................................................................................. 28

11 CONCLUSIONES ...................................................................................... 30

12 PREGUNTAS ............................................................................................ 30

1 ¿QUÉ ES SOA?

SOA (Arquitectura orientada a servicios) es un marco de trabajo conceptual que

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.
Principios

No hay estándares en relación a la composición exacta de una arquitectura orientada a

servicios, aunque muchas fuentes de la industria han publicado sus propios principios.

Algunos de los principios publicados son los siguientes:

• Contrato de servicios estandarizados: los servicios adhieren a un acuerdo de

comunicación, según se define en conjunto con uno o más documentos de descripción de
servicios.

• Acoplamiento débil de sistemas: los servicios mantienen una relación que minimiza
las dependencias y sólo requiere que mantengan un conocimiento de uno al otro.

• Abstracción de servicios: más allá de las descripciones del contrato de servicios, los
servicios ocultan la lógica a los demás.

• Reutilización de servicios: la lógica se divide en servicios con la intención de promover

la reutilización.

• Autonomía de servicios: los servicios tienen control sobre la lógica que encapsulan,
desde una perspectiva de diseño y ejecución.

• Servicios sin-estado: los servicios minimizan el consumo de recursos aplazando la

gestión de la información de estado cuando sea necesario.
• Descubrimiento de servicios: los servicios se complementan con los metadatos
mediante los cuales se pueden descubrir e interpretar la eficacia.

• Composición de servicios: servicios están compuestos por partes eficazmente,

independientemente del tamaño y la complejidad de la composición.

• La normalización de servicios: los servicios se descomponen a un nivel de forma

normal para minimizar la redundancia. En algunos casos, los servicios se desnormalizan
para fines específicos, como la optimización del rendimiento, el acceso y agregación.

• Optimización de servicios: los servicios de alta calidad son preferibles a los de baja
calidad.

• Relevancia de servicios: la funcionalidad se presenta en un nivel de granularidad

reconocida por el usuario como un servicio significativo.

• Encapsulación de servicios: muchos servicios están consolidados para el uso de SOA.

A menudo, estos servicios no fueron planificados para estar en un SOA.

• Transparencia de ubicación de servicios: se refiere a la capacidad de un consumidor

de servicios para invocar a un servicio independientemente de

su ubicación en la red. Esto también reconoce la propiedad de descubrimiento (uno de los

principios fundamentales de SOA) y el derecho de un consumidor para acceder al
servicio. A menudo, la idea de la virtualización de servicios también se refiere a la
transparencia de ubicación. Aquí es donde el consumidor simplemente llama a un servicio
lógico, mientras que un SOA habilita la ejecución del componente de la infraestructura,
normalmente un bus de servicios, que mapea este servicio lógico y llama al servicio físico.

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

Los patrones de diseño son una técnica para resolver problemas comunes en el desarrollo
de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una
solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que
debe haber comprobado su efectividad resolviendo problemas similares en ocasiones
anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes
problemas de diseño en distintas circunstancias.

Dependiendo de su finalidad pueden ser:

• Patrones de creación: utilizados para crear y configurar de clases y objetos.

• Patrones estructurales: su objetivo es desacoplar las interfaces e implementar
clases y objetos. Crean grupos de objetos.
• Patrones de comportamiento: se centran en la interacción entre asociaciones
de clases y objetos definiendo cómo se comunican entre sí.

3 ¿QUÉ ES UN PATRON COMPUESTO?

El patrón compuesto sirve para construir objetos complejos a partir de otros más simples
y similares entre sí, gracias a la composición recursiva y a una estructura en forma de
árbol.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una
interfaz común, se tratan todos de la misma manera. Dependiendo de la implementación,
pueden aplicarse procedimientos al total o una de las partes de la estructura compuesta
como si de un nodo final se tratara, aunque dicha parte esté compuesta a su vez de muchas
otras. Un claro ejemplo de uso extendido de este patrón se da en los entornos de
programación 2D para aplicaciones gráficas. Un videojuego puede contener diferentes
capas "layers" de sprites (como una capa de enemigos) pudiéndose invocar un método
que actúe sobre toda esta capa de sprites a la vez (por ejemplo, para ocultarlos, darles un
filtro de color etc.).

Ventajas

• Permite jerarquías de objetos tan complejas como se quiera.

• Simplifica el cliente. Al eliminar el código para distinguir entre unos y otros.

• Se pueden añadir nuevos componentes fácilmente.
Desventajas

• Podría hacer el diseño demasiado general, especialmente cuando queremos

restringir los componentes que pueden formar parte de un compuesto
determinado.

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

En diseño, un lenguaje de patrón es un método estructurado para describir una serie de
buenas prácticas de diseño en un área particular. Se caracteriza por:

• Descubrir y nombrar los problemas más comunes en el campo de interés.

• Describir las características principales de las soluciones efectivas para llegar al
objetivo marcado.
• Ayudar al diseñador a moverse de un problema a otro de una forma lógica.
• Permitir diferentes caminos en un mismo proceso de diseño.

Los lenguajes de patrón se utilizan para formalizar los valores de decisiones cuya
efectividad resulta obvia a través de la experiencia, pero que es difícil de documentar y
pasar a los aprendices. También son herramientas útiles a la hora de estructurar el
conocimiento y comprender sistemas complejos sin caer en la simplificación extrema.
Estos procesos incluyen la organización de personas o grupos que tienen que tomar
decisiones complejas, y revelan cómo interactúan las diferentes funciones como parte del
total.

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

Un catálogo es un grupo de patrones clasificados por uno o más criterios y relacionados
entre sí, los cuales pueden ser utilizados de forma conjunta o independiente y que se
encuentran documentados en forma de colección, los cuales están asociados a con la SOA
y orientación a servicios.

En la literatura se pueden encontrar los siguientes criterios utilizados para clasificar

diferentes tipos de patrones:
• Por su dominio: Dentro del campo de la ingeniería del software, los patrones
no están restringidos a resolver problemas de diseño o de arquitectura software.
Considerando el problema del diseño, se han propuesto gran cantidad de
patrones en diferentes áreas, como pueden ser los de sistemas distribuidos,
concurrentes o paralelos o colaborativos.
• Por su paradigma: Cada paradigma tiene sus propios patrones. Un patrón de
diseño imperativo (uno de los paradigmas de la programación) podría dirigir un
problema similar que un patrón de diseño orientado a objetos, pero la solución
se describiría en términos de cada paradigma. Un ejemplo de este tipo sería el
patrón Decorator que es presentado según el paradigma de la orientación a
objetos y el patrón Navigational Context que es el mismo patrón, pero adaptado
al paradigma del hipertexto.
 6 NOTACIÓN DE PATRONES
UML: por sus siglas en inglés cuya traducción al español es Lenguaje Unificado de
Modelado, es una familia de notaciones gráficas que facilitan la descripción y diseño de
los sistemas de software.

A inicios de los ochenta, cuando algunos empezaron a pensar en la programación

orientada a objetos también empezaron a pensar en un lenguaje gráfico de diseño
orientado a objetos.

Grady Booch, Peter Coad, Ivar Jacobson, Jim Odell, Jim Rumbaugh son algunos de los
nombres de los principales directores de proyectos enfocados en proyectos de este tipo
que se desarrollaron entre 1988 y 1992. Todos los métodos eran similares y los mismos
conceptos aparecían en diferentes notaciones, durante este período de tiempo no había un
estándar. Cuando Jim Rumbaugh se unió a Grady Booch de Rational, parte de IBM, esta
alianza parecía que podría tomar una porción importante del mercado, lo que propició
algunas alianzas anti Rumbaugh-Booch en 1995 se les unió Ivar Jacobson, a quienes se
les otorga el crédito de la creación de UML.

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:

 Requerimiento que atiende: el requerimiento consiste en una sentencia simple

que muestre el origen del patrón en forma de pregunta.
 Sumario: consiste en una tabla en la que se muestra un grupo de sentencias que
proporcionan una referencia rápida del propósito del patrón, en esta parte se
muestra una sinopsis del problema, solución, aplicación e impacto.
 Problema: en esta sección se describe la cuestión que genera el problema, se
describen sus efectos, este es el caso para el que el patrón aportará una solución.
 Solución: representa la solución de diseño que se propone para resolver el
problema y cumplir con el requerimiento, generalmente consiste en una sentencia
corta y seguida por un diagrama que muestra la solución final, sin embargo, en
este no se muestra el detalle del ¿cómo?
  Aplicación: esta parte contiene el ¿cómo? en referencia a la aplicación del patrón,
puede incluir líneas guía, detalles de implementación e incluso sugerir procesos y
mejores prácticas.
 Impacto: generalmente un patrón tendrá ventajas y desventajas, por lo que será
importante poder remarcar las consecuencias más comunes de su implementación,
costo y requerimientos asociados si los hubiera.
 Relaciones: el uso del diseño de patrones puede conllevar interacción entre los
aspectos del diseño y la arquitectura, es importante entender los requerimientos
que tiene un patrón, aunque no es posible diagramar todas las relaciones que
surgen de manera directa o indirecta.

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

Paso 1

Crear una interfaz de MobileShop .

Archivo: MobileShop.java

Paso 2

Cree una clase de implementación de Iphone que implementará la interfaz

de Mobileshop .

Archivo: Iphone.java
 Paso3

Cree una clase de implementación de Samsung que implementará la interfaz

de Mobileshop .

Archivo: Samsung.java

Paso 4

Cree una clase de implementación de Blackberry que implementará la interfaz

de Mobileshop .

Archivo: Blackberry.java
 Paso 5

Cree una clase concreta de ShopKeeper que usará la interfaz de MobileShop .

Archivo: ShopKeeper.java
 Paso 6

Ahora, creando un cliente que puede comprar los móviles desde MobileShop a través
de ShopKeeper.

Archivo: FacadePatternClient.java
Salida
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 patrón * Se requiere un esfuerzo adicional para
permite el aumento de la mantener la gobernabilidad todas las
disponibilidad del servicio. implementaciones redundantes en sincronía.
* Mejora la confiabilidad y * Se incrementan los requerimientos de
escalabilidad de los servicios y el infraestructura y asociados, demanda
inventario de servicios en su operativas relacionadas con el gobierno.
conjunto.
* 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
Balanceador de carga con Dockers.

Crear el archibo docker-compose.yml

Poner el usuario/repo:tag puede editar la configracion.

Si no ejecuta docker swarm init, obtendrá un error de que "este nodo no es un
administrador de enjambres".

Ejecutamos y le damos nombre a la aplicación.

Podemos ver el ID y replicas iagen puertos de todos servicos creados.

Podemos ver el ID y replicas iagen puertos del servico que creamos en especifico.

Podemos ver el ID de cada uno de los servicios que creamos

Podemos ver el ID o hostname del contenedor.

El servicio ya va a estar balanceado y podemos actualizar la pagina y ver como cambia el

ID.

11 CONCLUSIONES

12 PREGUNTAS