Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
GRUPO 1
DOCENTE:
ING. .
CURSO:
ISI-S-CO-7-5
AÑO LECTIVO:
2019-2020
TABLA DE CONTENIDO
1 ¿QUÉ ES SOA? .......................................................................................... 3
12 PREGUNTAS ............................................................................................ 30
1 ¿QUÉ ES SOA?
establece una estructura de diseño para la integración de aplicaciones, que permite a las
TI.
efectiva y rápida.
Principios
servicios, aunque muchas fuentes de la industria han publicado sus propios principios.
• 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.
• Autonomía de servicios: los servicios tienen control sobre la lógica que encapsulan,
desde una perspectiva de diseño y ejecución.
• Optimización de servicios: los servicios de alta calidad son preferibles a los de baja
calidad.
Ventajas
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.
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:
Service facade
Redundant Implementation
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:
• 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.
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:
Lógica de retransmisión.
Lógica de agente.
Corrección de comportamiento.
Requisitos específicos del contrato.
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.
Service Refactoring
Service Decomposition
Proxy Capability
Agnostic Sub-Controller
Inventory Endpoint
Distributed Capacidad
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.
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
Archivo: MobileShop.java
Paso 2
Archivo: Iphone.java
Paso3
Archivo: Samsung.java
Paso 4
Archivo: Blackberry.java
Paso 5
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
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
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.
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.
Podemos ver el ID y replicas iagen puertos del servico que creamos en especifico.
11 CONCLUSIONES
12 PREGUNTAS