1. Capacitacion_ SOA MDC 4pp.pdf

3/04/2023
1
SOA, SERVICES & MICROSERVICES
(S90.01B)
Material Complementario
SOA
FUNDAMENTAL
SOA, SERVICES & MICROSERVICES (S90.01B)
OBJETIVO
Este curso ofrece una visión general fácil de entender, de principio a fin, los conceptos del
Servicio &
Computación
tecnologías
Orientada a
modernas relacionadas
Servicios, así como temas relacionados con negocio
a Microservicios & a la
&
tecnología asociada con la Arquitectura Orientada a Servicios (SOA).
ÍNDICE
1. INTRODUCTION TO SERVICESAND MICROSERVICES.
2. BUSINESSAND TECHNOLOGY DRIVERS OF SERVICES AND MICROSERVICES.
3. STRATEGIC GOALS AND BENEFITS.
4. FUNDAMENTALCHARACTERISTICS OF SOA.
5. UNDERSTANDING SERVICE-ORIENTATIONAND SERVICE-ORIENTEDARCHITECTURE.
6. FOUR PILLARS OF SERVICE-ORIENTATION.
7. FUNDAMENTALTERMINOLOGYAND CONCEPTS.
8. INTRODUCTION TO COMMON SERVICE TECHNOLOGIES.
9. ADOPTION IMPACTS AND REQUIREMENTS.
- RONDADE PREGUNTAS.
1 2
3 4

3/04/2023
2
TEORÍA
1. INTRODUCTION TO SERVICES AND MICROSERVICES
_ Una organización que lleva a cabo tareas asociadas con un propósito enfocado en el negocio,
también está brindando un servicio.
_ Así mismo, siempre que dicha tarea o función que se brinda esté bien definida, puede estar
relativamente aislada de otras tareas asociadas, esto puede puede clasificarse claramente como
un servicio.
_ Por otro lado, existen ciertos requisitos básicos para permitir que un grupo de
Service Providers independientes colaboren para proporcionar colectivamente un Servicio más
grande (armen un flujo).
_ La imagen siguiente muestra un grupo de
empleados (‘despachador, conductor, encargado
de arranque’) que brindan un Servicio llamado
Delivery ABC (Emplea a tres personas para
componer sus capacidades de negocio).
_ Aunque cada individuo contribuye con un
Servicio distinto (funcionalidad), para que la
empresa funcione de manera correcta, el personal
también necesita tener características comunes
como: disponibilidad & capacidad de comunicarse
fácilmente.
_ Con todos estos requerimientos en su lugar,
estos individuos pueden unificarse en un equipo de
clave de Orientación de
trabajo productivo. Esto es un objetivo
Servicio.
_ Desde una perspectiva general un Servicio es una Software que brinda una funcionalidad
a través de una API (Interfaz de Programación de Aplicaciones), que está relacionado a un
Contrato de Servicio.
_ Una API proporciona un conjunto de funciones generales para los programadores se
beneficien usándolas, evitándose el trabajo de programar todo desde el principio.
_ Así mismo, la implementación de diferentes tecnologías pueden ser usadas para la creación de
estos Servicios.
_ Actualmente existen dos tipos de implementaciones comunes que son:
Web Service basados en SOAP & Web Service basados en REST.
Servicios en Automatización Empresarial:
5 6
7 8

3/04/2023
3
_ El símbolo de círculo cordado es utilizado para referenciar a un Contrato de Web Service
(SOAP) (izquierda). Así mismo, una variante de este símbolo (triángulo), es utilizado para
referenciar a un Contrato de Web Service (REST) (derecha).
Servicios en Automatización Empresarial:
Servicios son Colecciones de Capacidades:
_ Cuando se discute sobre Servicios, es importante recordar que un solo servicio puede ofrecer
una API que proporcione una colección de funcionalidades (capacidades).
_ Estas capacidades son agrupadas porque se relacionan con un contexto funcional establecido
por el Servicio respectivamente.
_ El contexto funcional del Servicio que se muestra en el diagrama es el relacionado al
Servicio de envío” (shipment).
_ Este Servicio en particular proporciona un conjunto de capacidades asociadas con el
procesamiento de envíos.
_ “Al igual que un Humano (ejemplo),
un Servicio automatizado puede
proporcionar múltiples capacidades”.
_ Un Servicio es esencialmente una colección de capacidades relacionadas.
_ Está compuesto por una lógica diseñada para realizar dichas capacidades &
un Contrato de Servicio que detalla las capacidades disponibles, para su invocación
públicamente.
_ Al hacer referencia a las capacidades del Servicio, se refiere específicamente a aquellas que
se definen como parte de la API de Contrato de Servicio.
Servicios son Colecciones de Capacidades:
MicroServicios son Colecciones de CapacidadesAltamente ‘Autónomas’:
_ Algunas capacidades pueden ser más críticas que otras, lo que puede aumentar la
importancia de su ejecución.
_ Específicamente, puede ser de mayor importancia que una capacidad determinada se ejecute
de manera correcta o de la más eficientemente posible, sobre una base consistente.
_ En tales casos, puede tener sentido aislar dichas capacidades en Servicios autónomos
(servicios que pueden tomar la decisión por sus propios medios), por medio de un entorno
especial, donde se cumplan sus requisitos de procesamiento.
_ Los tipos de servicios, que tienen un alcance funcional
más estrecho que otros servicios, se denominan
MicroServicios.
_ “En la imagen se aprecia, el MicroServicio ‘Express
Delivery’ que contiene una capacidad con un requisito
funcional para consulta”.
9 10
11 12

3/04/2023
4
2. BUSINESS AND TECHNOLOGY DRIVERS OF SERVICES
AND MICROSERVICES
_ Una serie
tecnología llevaron al surgimiento de
de factores del negocio &
la
Arquitectura Orientada a Servicios (SOA),
enfocada en la necesidad de Servicios &
ahora MicroServicios.
_ Las siguientes secciones a explicar
proporcionarán detalles por separado para
‘Servicios SOA’ & ‘MicroServicios’ por medio
de diferentes enfoques.
AND MICROSERVICES
_ A medida que una organización crece & evoluciona, los requisitos de automatización
empresarial pueden estar sujetos a continuos cambios.
_ Las actividades empresariales como fusión & adquisición (alianzas) entre compañías, aumenta aún
más la probabilidad de tecnología incompatible que requiera alguna forma de integración.
_ La adopción de Servicios SOA brinda la oportunidad de establecer soluciones, basadas
en estándares, para poder interoperar.
_ Debido a ello, se puede considerad el crear lo que se conoce como servicio federado de APIS
(gobierno).
BUSINESS DRIVER: “Relacionado a Reducción de Costos & Acuerdos Empresariales”
AND MICROSERVICES
_ El continuo cambio en los requerimientos del negocio & clima comercial, son hechos que pasan en
la mayoría de la organizaciones.
_ Históricamente, ha sido un desafío para muchas organizaciones el adaptarse a dichos cambios,
debido a los límites (alcance) en sus soluciones implementadas de automatización.
_ La adopción de Servicios SOA permite la creación de soluciones de automatización que son
adaptables a los posibles cambios del negocio.
BUSINESS DRIVER: “Adaptabilidad y Responsabilidad”
AND MICROSERVICES
_ Tiempo
soluciones
antes de la introducción de tecnologías basadas en Servicios, las
de automatización frecuentemente eran cerradas & patentadas. (paga)
_ Esto se debió a que los proveedores de TI (vendors), creían que el libre acceso, reduciría su cuota de
mercado, minimizando también la posible dependencia entre el cliente con su proveedor.
_ Los vendors luego cambiaron esta tendencia, al colaborar para producir estándares abiertos que
ayudaron a establecer tecnologías para la comunicación e interoperabilidad entre proveedores & otras
áreas.
_ La disponibilidad de estándares abiertos permitió la creación de soluciones de automatización
abiertas, construidas por servicios basados en dichos estándares.
TECHNOLOGY DRIVER: “Estándares Abiertos”
13 14
15 16

3/04/2023
5
AND MICROSERVICES
_ La aparición de la World Wide Web popularizó el conocimiento de computación distribuida.
_ La Web se basa en estándares abiertos, que permiten a diversos recursos distribuidos por todo
el mundo, comunicarse vía HTTP con el objetivo del intercambio de mensajes. .
_ Así mismo, debido a su flexibilidad HTTP es considerado un protocolo que permite a los Servicios
ser publicados por medio de endpoints, & poder ser accedidos distribuídamente por
los diferentes Service Consumers.
TECHNOLOGY DRIVER: “Computación Distribuida y la World Wide Web”
AND MICROSERVICES
_ Las organizaciones que desean ampliar el alcance de su negocio hacia nuevos tipos de clientes &
regiones internacionales, requieren escalar parte de su lógica en automatización de negocios.
_ Las soluciones tradicionales de automatización basadas en la Web, comúnmente se implementan
para ser ejecutadas en un “Servidor Web”, requiriendo de recursos que se incluirán en un paquete de
implementación.
_ Este enfoque no es ideal para altos niveles de escalabilidad (habilidad para reaccionar & adaptarse a
un posible cambio sin perder calidad), debido a que la unidad de respuesta es el mismo Servidor Web
(el que responde).
_ El uso de MicroServicios soluciona estos problemas mediante el aislamiento de unidades con lógica
de negocios de alta escalabilidad.
BUSINESS DRIVER: “Negocios a Escala en Internet”
AND MICROSERVICES
_ Con la práctica de desarrollo de software AGILE, una aplicación de software se desarrolla de manera
incremental por un equipos cross-functional (grupo de personas con diferentes roles funcionales
trabajando con un mismo objetivo común), en muchas iteraciones.
_ El beneficio de este enfoque es que permite la retroalimentación frecuente los clientes,
lo que reduce el riesgo de una única gran entrega de solución, que posiblemente no cumpla con las
expectativas, en entregas por iteración.
_ Los equipos de desarrollo ágiles deben trabajar de forma independiente, cada uno enfocado en una
parte de la solución (distribuir las tareas), que se debe completar en un determinado tiempo.
_ Estas tareas automatizadas pueden ser manejadas de manera más fácil por MicroServicios.
_ Una metodología de desarrollado ágil se ejecuta normalmente de manera contraria
a una metodología SOA, esto debido a su enfoque táctico (a corto plazo) & al enfoque estratégico
(a largo plazo) que esta última tiene.
_ El uso de MicroServicios permite seleccionar porciones de lógica de solución (iteraciones), que serán
entregadas por medio del enfoque ágil, como parte de la entrega en un proyecto SOA.
BUSINESS DRIVER: “SOA con Desarrollo Agile”
AND MICROSERVICES
_ La Computación en la Nube (Cloud Computing), proporciona acceso masivo a recursos informáticos
(servicios, servers, etc), altamente confiables & escalables.
_ La Contenerización proporciona la capacidad de establecer un entorno aislado & más escalable
mediante la replicación de: Soluciones, Servicios & Recursos asociados.
_ La utilización de una o ambas de estas dos innovaciones tecnológicas, permite que los
MicroServicios cumplan con los requisitos para manejar un alto rendimiento y procesamiento.
TECHNOLOGY DRIVER: “Computación en la Nube & Contenerización”
17 18
19 20

3/04/2023
6
AND MICROSERVICES
_ DevOps (Operaciones de Desarrollo), que consiste en un enfoque que acelera el desarrollo de software
a través de la automatización & monitoreo, en las etapas de: compilación, prueba e implementación
del software.
_ DevOps es comúnmente utilizado de la mano del desarrollo ágile. Así mismo, apunta a ciclos de
desarrollo más cortos (iteraciones), mayor frecuencia en las implementaciones (desarrollos), entregas
más confiables, y que estén alineación con los objetivos del negocio.
_ La modularidad (subdividir una aplicación en partes más pequeñas) de los MicroServicios
& la capacidad de probarlos a través de sus interfaces de mensajería los hace compatibles con DevOps.
TECHNOLOGY DRIVER: “DevOps”
3. STRATEGIC GOALS AND BENEFITS
ESTRATEGIA vs TÁCTICA:
_ Todos los objetivos son de naturaleza estratégica, lo que significa que son para el beneficio a
largo plazo en una compañía de TI.
_ En comparación, las metas tácticas que están enfocadas en el cumplimiento de requisitos
inmediatos a corto plazo.
_ La naturaleza estratégica de la Computación Orientada a Servicios es una de sus
características diferenciadoras.
_ Contrasta la naturaleza táctica aplicada normalmente en el desarrollo tradicional
de aplicaciones basadas en silos.
_ Una característica importante de la ‘Computación Orientada a Servicios’ es su
naturaleza Estratégica más no la Táctica.
_ Existen siete objetivos estratégicos asociados con la adopción de la
“Computación Orientada a Servicios”.
_ Es importante entender & porque
distintas características,
ayudarán
cualidades
a comprender
& preferencias
tener
por
durante
claro estos objetivos estratégicos
qué
el
existen
proceso de adopción de SOA.
“Los objetivos estratégicos de la Computación Orientada a Servicios son”:
A. Incrementar la Interoperabilidad Intrínseca.
B. Incrementar la Federación.
C. Incrementar el Alineamiento entre Negocio y Tecnología.
D. Incrementar la Opción de Trabajar con Diferentes Proveedores (Vendors).
F. Incrementar el Retorno de la Inversión (ROI).
G. Incrementar la Agilidad Organizacional.
H. Reducir la Carga Operativa de TI.
Es importante conocer que la aplicación correcta de los primeros 4 objetivos estratégicos llevarán
al logro de los 3 objetivos estratégicos siguientes (Considerándose como benefícios):
21 22
23 24

3/04/2023
7
Se consideran 2 conceptos importantes:
*. Interoperabilidad: representa la habilidad del software para interactuar e intercambiar datos.
*. Integración: representa el esfuerzo requerido para lograr la interoperabilidad entre programas
de software (no son compatibles).
El esfuerzo de la INTEGRACIÓN es usualmente requerido cuando los programas de software
NO son compatibles & debido a ello no son interoperables.
A. Incrementar la Interoperabilidad Intrínseca:
_ Un objetivo de la Orientación a Servicios es establecer la interoperabilidad nativa o intrínseca
entre los Servicios con el fin de reducir la necesidad de integración.
_ Esto significa que los Servicios están diseñados para ser compatibles e interoperables,
sin importar cuándo y por quién son enviados.
_ Como resultado, la integración como concepto comienza a desvanecerse cuando se aplica la
Orientación a Servicios, porque la interoperabilidad intrínseca entre los Servicios se convierte
en norma.
_ El objetivo entonces es el de reducir la Integración como tal & aumentar la
comunicación nativa.
_ La interoperabilidad intrínseca se refiere a la capacidad de intercambiar información de
forma ‘natural’, esto quiere decir que las aplicaciones de software de una organización puedan
hablar entre ellas sin tener nada en medio que les permita NO interactuar. Haciendo una analogía
con las personas, esto se refiere que en una reunión internacional con muchos participantes de
diferentes países, estos se puedan comunicar entre ellos sin necesidad de usar traductores entre
los diferentes idiomas, sino que a todos se les haya preparado en un idioma común que les
permita interactuar ágilmente.
“Esto quiere decir que por medio del
Equipo C se puede consumir
(reutilizando) lo desarrollado por el
Equipo A y B. [Pueden Interoperar
Intrínsicamente]”.
_ Federación es la unificación de ambientes dispares (diferentes), permitiendo que esos
ambientes sean gobernados de manera correcta.
_ SOA pretende establecer una perspectiva ‘federada’ (agrupaga, unida), de una empresa
a través del amplio despliegue de servicios estandarizados los cuales encapsulan la lógica de
negocio de la empresa (por medio de sus servicios).
_ Cada servicio establece una interfaz o endpoint técnico estandarizado que representa
un segmento de la empresa expresado de manera consistente.
_ SOA fomenta el establecer una perspectiva federada de la empresa a través de los
servicios compuestos (Ofreciendo una interfaz estándar ‘WSDL’ hacia el cliente, uniendo servicios
con diferente tecnología).
B. Incrementar la Federación:
25 26
27 28

3/04/2023
8
B. Incrementar la Federación:
_ La federación se refiere al hecho de tener ‘reglas de juego comunes’ que gobiernen las
aplicaciones en su conjunto, pero a la vez permitan que estas internamente sean autónomas
a la hora de decidir su implantación interna. Haciendo una analogía con los estados, es como
funciona un país como EEUU, allí se establecen unas leyes que deben cumplir todos los estados,
pero estos tienen la potestad de incorporar otras que regulan su funcionamiento interno.
_ “En la imagen se aprecian tres contratos de
servicio estableciendo una federación. Cada una
de las cuales encapsulan diferente
implementaciones de manera interna”. “Cuando
soluciones
construidas
orientadas
basadas
a servicios, son
en Web Service
(tecnología)”, el nivel de la federación es elevado
porque los servicios pueden aprovechar la
naturaleza NO propietaria de la tecnología.
C. Incrementar la Opción de Trabajar con Diferentes Proveedores (Vendors):
_ La diversificación de proveedores representa la opción de refactorizar o ampliar partes de una
empresa con nuevas tecnologías & productos de proveedores.
_ Esto puede lograrse definiendo SOA en alineación con plataformas neutrales a vendors
& posicionando servicios como puntos estandarizados.
_ La diversificación de proveedores no siempre es deseable,
tener la opción de diversificar cuando
pero es importante
sea necesario.
_ El enfoque es poder en cualquier momento cambiar una parte de T.I o el añadir un nueva
basada en tecnologías del mercado sin estar amarradas al producto de un vendor
en concreto (tener la opción de Diversificación).
C. Incrementar la Opción de Trabajar con Diferentes Proveedores (Vendors):
_ Lo que se quiere dar a entender es poder contar siempre con la opción de trabajar con un
proveedor nuevo en lugar del actual, para aprovechar las ventajas o innovaciones tecnológicas
nuevas que puedan llegar, sin depender de una tecnología y/o vendor en particular.
“Se aprecian 3 servicios expuestos,
que encapsulan automatizaciones con
diferentes tecnologías (lenguajes, bd, etc).
El objetivo es la Diversificación, para que
cuando se requiera extender o reemplazar
NO estar ligado a un tecnología en
particular”.
D. Incrementar el Alineamiento entre Negocio y Tecnología:
_ "Alineación de negocios & tecnología" representa la medida en que los sistemas
automatizados & la empresa de TI pueden reflejar & evolucionar con el negocio.
_ Se puede lograr un mayor alineamiento comercial y tecnológico a través de la colaboración de
expertos empresariales y tecnológicos durante las fases de “análisis” y “modelado”.
_ La computación orientada al servicio introduce un paradigma de diseño que promueve la
abstracción (separar), encapsulación & el enfoque en el negocio.
_ La colaboración entre Negocio & Tecnología es importante, ya que al aplicar SOA el
enfoque de por si está alineado al negocio, por medio de la aplicación de Servicios que
representan a una necesidad y dichos servicios al combinarse & ser reutilizados darán lugar a
nuevos servicios que cubren otras necesidades del negocio.
29 30
31 32

3/04/2023
9
_ Negocio & Tecnología deben trabajar de la mano, por medio de los roles respectivos de cada
lado. Estos son: ‘Arquitecto’ (TI), ‘Analista Funcional’ (Negocio).
_ Uno de los medios fundamentales para permitir la alineación comercial y tecnológica es a través
de la definición y creación de servicios de negocio.
_ Siguiendo el análisis orientado a servicios y las prácticas de diseño, la lógica de negocio
puede dividirse en servicios de negocio flexibles, que pueden aumentarse y combinarse
repetidamente para responder continuamente al cambio de negocio posible.
_ Los procesos de análisis y diseño de servicios se introducen en la sección
Ciclo de entrega del proyecto SOAplanificada más adelante.
_ Este objetivo estratégico
alianza de dominio Empresarial
también se conoce como: "Aumento de la
& Tecnológico"
_ Modelo Tradicional: Tanto el ‘Arquitecto’ como el ‘Analista Funcional’ trabajan cada uno por su lado.
_ Modelo SOA: Tanto el ‘Arquitecto’ como el ‘Analista Funcional’ trabajan de manera colaborativa
(juntos).
Conceptual:
Diseño
Enfocado a entradas,
procedimiento y salidas.
Diseño Físico:
Enfocado a la solución
implementada.
E. Incrementar la Retorno de la Inversión (ROI):
_ ROI (Retorno de la Inversión) representa el valor tangible & ahorro de costos que ofrece algo en
comparación con el costo de producirlo & gobernarlo (Lo que se espera recuperar por parte de la
empresa).
_ La Computación Orientada al Servicio fomenta la creación de una lógica de solución
agnóstica, una lógica que es agnóstica para cualquier propósito y por lo tanto multiuso.
_ Se aplican las técnicas de diseño que se originaron con el área de diseño comercial del
producto, las que se aplicaron para convertir la lógica agnóstica en una lógica altamente
reutilizable capaz de aprovechar la interoperabilidad intrínseca para proporcionar un mayor
ROI.
_ Responde a la pregunta .. ¿Por qué invertir en esto?.... El cálculo del ROI es difícil ya que
representa la recuperación del dinero invertido luego de la adopción de SOA.
Esto se logra normalmente mediante la reutilización de los servicios N veces.
_ Esto se refiere a que el esfuerzo invertido en construir los sistemas, se vea recompensado a
futuro con el cumplimiento de las necesidades sin grandes inversiones, sino más bien que lo
invertido se devuelva en grandes beneficios para el negocio & que cada vez que aparezcan
nuevos proyectos se requiera menos esfuerzo para realizarlos, porque se puede aprovechar lo ya
construido & reutilizarlo.
33 34
35 36

3/04/2023
10
_ En lo relacionado a MicroServicios, estos no brindan un mayor retorno de la inversión (ROI)
a través de una alta reutilización, sino que aumentan los ingresos a nivel de la línea superior
(escalabilidad).
_ Para maximizar la escalabilidad en MicroServicios son capaces de acomodarse a
tantos consumidores concurrentes como sea posible, especialmente durante los períodos pico.
_ Cuantos más MicroServicios puedan satisfacer la necesidad comercial actual, más ingresos en
la línea superior podrán generar.
_ “En la imagen se aprecia un manejo de
MicroServicios en respuesta a la
necesidad cambiante (incremento). Esto
quiere decir, que en un ‘entorno de
implementación’ flexible se permite a los
MicroServicios maximizar el consumo en
tiempo de ejecución de los requisitos,
maximizando la generación de ingresos”.
F. Incrementar la Agilidad Organizacional:
_ Cuando se tiene más capacidad de respuesta, se puede reaccionar & adaptarse al cambio
de manera más eficiente & correcta.
_ Los Servicios agnósticos se vuelven activos TIC reutilizables, que pueden ser
compuestos repetidamente con diferentes configuraciones.
_ Como resultado, una vez que se disponga de una colección madura de servicios agnósticos
(inventario de servicios), se reducen dramáticamente el tiempo & esfuerzo requeridos
para crear nuevos requerimientos del negocio o modificaciones a los existentes (servicios).
_ La agilidad al cambio en una organización se ve reflejada por medio de su fácil adaptación en
los casos que se requiera: Modificación, Agregación, Creación de alguna lógica de negocio.
Esto se ve reflejado a nivel de Servicios (1 solo cambio se replica a todos), esto es gracias
al correcto ‘desacoplamiento’que existe a nivel de los servicios que recomienda SOA’.
“En la imagen se aprecia que
una vez que se ha conformado
un Inventario de Servicios
interoperable & federado, el
costo & el esfuerzo requerido
para construir o modificar las
soluciones se reduce de manera
significativa”.
_ En lo relacionado a MicroServicios se maneja un entorno de despliegue aislado
(especialmente cuando se combina con DevOps), en donde puede actualizarse rápidamente &
ser redesplegado independientemente de otros servicios que componen una solución mayor.
_ En MicroServicios una lógica de solución no agnóstica, puede aumentar más la capacidad de
respuesta de las organizaciones para adaptarse a los cambios del negocio.
_ La velocidad con que nuevas versiones de MicroServicios pueden ser desplegadas,
independientemente, aumentar la agilidad en la solución &
a adaptarse a los
ayuda a
cambios comerciales que afectan la lógica de automatización.
37 38
39 40

3/04/2023
11
_ “En la imagen se aprecia el tiempo
requerido para modificar una
aplicación tradicional (basada en
Silo), la cual se compara con la
velocidad a los tiempos aplicables
para una solución orientada a
servicios basada en:
MicroServicios”.
G. Reducir la Carga Operativa de TI:
conceptos
_ Se enfoca a aplicar
en una empresa
consistentemente los
de TI, obteniendo con
de orientación
ello lo
al servicio
siguiente:
* Menos redundancia.
* Menos costos operativos.
* Menos sobrecarga asociada con gobernanza & evolución.
_ En si este objetivo estratégico se refiere a que la tecnología aplicada debe ser lo más limpia
posible, evitando la redundancia de lógica de negocio en múltiples sistemas de información
construidos como silos (pensando solo en las necesidades inmediatas o en un área específica).
consiguiendo
En esencia, si se aplican todos los objetivos estratégicos anteriores se estará
también:
“bajar la carga operativa de las tecnologías de información”.
_ El
puede
logro de los
llegar a crear
Objetivos
una dirección
Estratégicos
de TI
previamente
más ligera
descritos
& ágil:
_ La incorporación de MicroServicios en un ‘Inventario de servicios’ puede ayudar aún más
a reducir la carga de TI, especialmente en entornos inciertos.
_ Los MicroServicios & la lógica no agnóstica pueden escalarse automáticamente para permitir
un rendimiento bueno & garantizar que se cumplan con los SLA (acuerdos de nivel de servicio).
_ En tiempo de diseño, la independencia de la gobernanza & el contexto no agnóstico
que poseen los MicroServicios, permiten estos Servicios actualizarse & redesplegarse
rápidamente (DevOps), reduciendo la sobrecarga del gobierno & ayudando a la evolución de la
solución.
41 42
43 44

3/04/2023
12
“Inventario de Servicios”
_ La agregación estratégica de
(Taxonómicamente así se debe
MicroServicios
se considerar),
a un
a nivel de dicho inventario:
4. FUNDAMENTAL CHARACTERISTICS OF SOA
_ Una “Arquitectura Orientada a Servicios (SOA) representa un modelo de arquitectura
que apunta a reforzar la agilidad & la efectividad a nivel de costos de una empresa, al mismo
tiempo que reduce la carga global de las TIC sobre la organización (interconectar).
_ Esto se logra considerando a los Servicios como el medio principal
a través del cual se representa una lógica de la solución.
_ SOA aporta la orientación a servicios & con ella la aplicación de los ‘objetivos estrategicos’
sociados con la computación orientada a las servicios“ (paradigma).
_ Un error muy común sobre SOA es considerar su adopción como una iniciativa
centrada en la tecnología (error), ya que en si es centrada directamente en el negocio.
_ Existen 2 mitos para poder llegar a aplicar SOA:
1. Comprando el camino a SOA por medio de un Vendor de tecnología (IBM, ORACLE, etc).
2. Por medio de la adopción de “estándares de la industria” como: XML, WSDL, XSD, XSLT, etc.
_ SOA es un modelo de arquitectura distribuida con características relacionadas a la
“Orientación a Servicios”:
_ Las características son:
✓ Business-Driven (Orientado al Negocio).
✓ Vendor-Neutral (Neutral a los Vendors).
✓ Enterprise-Centric (Centrado en la Empresa).
✓ Composition-Centric (Centrado en las Composiciones).
_ Este contexto está asociado con los objetivos estratégicos globales ya explicados.
_ Las arquitecturas basadas en tecnología tradicionales, son frecuentemente entregadas en
alineación con el estado actual de un negocio, pero son incapaces de
mantenerse actualizadas a medida que el negocio evoluciona.
_ En la medida que las arquitecturas de negocio y tecnología se vuelven cada vez más
desfasadas, el cumplimiento de requisitos de negocio disminuye (no se evoluciona al ritmo del
negocio).
_ Esto ocurre frecuentemente hasta el punto de que se requiere una arquitectura basada en
tecnología completamente nueva.
A. Business-Driven (Orientado al Negocio):
45 46
47 48

3/04/2023
13
_ “En la imagen se aprecia la relación
que se da entre los requerimiento del
negocio & el soporte de tecnología,
bajo una Arquitectura Clásica.
Con el pasar del tiempo el alcance &
contexto de una arquitectura basada
en una tecnología es superada por el
negocio que evoluciona en nuevas
direcciones”.
_ Esto tiene como resultado, la
necesidad de ‘sustituir’ toda la
arquitectura por una nueva más ágil.
_ “En la imagen
relación que
requerimiento
se
del negocio
se aprecia la
da entre los
&
el soporte de tecnología, bajo una
Arquitectura SOA.
_ Al aplicar un enfoque estratégico
orientado al negocio, la arquitectura
basada en una tecnología, puede
mantenerse en constante
sincronización con la evolución del
negocio en el tiempo”.
B. Vendor-Neutral (Neutral a los Vendors):
_ “En la imagen se aprecia que las
arquitecturas centradas en los
vendors
acopladas
son frecuentemente
a la plataforma del
verdor propiamente”.
_ “Esto puede
oportunidades de
reducir las
aprovechar las
innovaciones suministradas por las
plataformas de otros vendors &
puede tener como resultado la
necesidad de sustituir enteramente
toda la implementación
(demasiado acoplada)”. Así mismo,
los diseños estarán amarrados a
a nivel tecnológico, de
plataformas de los
alcance
dichas
vendors.
B. Vendor-Neutral (Neutral a los Vendors):
_ “Por otro lado, si el modelo de
arquitectura es diseñado para ser
neutral (independiente, no amarrada)
hacia las plataformas de los vendors,
se mantiene la libertad de
diversificar sus implementaciones
se podrá aprovechar las múltiples
vendors, pero
innovaciones de los diferentes
la arquitectura se
mantendrá intacta sin ser impactada”.
_ Esto incrementará la longevidad
de la arquitectura permitiendo poder
crecer & evolucionar en respuesta a
los posibles requerimientos
cambiantes en el tiempo (plasmados
en los diseños respectivos).
49 50
51 52

3/04/2023
14
C. Enterprise-Centric (Centrado en la Empresa):
Una arquitectura orientada a servicios es centrada en la empresa (negocio),
que apoya
_
en la medida
de la lógica de negocio
a
(tareas
la creación
& procesos
& reutilización
del negocio).
_ La característica del enfoque centrado en la
a la naturaleza manejada con aplicaciones
empresa
basadas
es opuesta
en silos.
_ El enfoque centrado en la empresa impone requerimientos de arquitectura específicos
enfocándose siempre en las soluciones orientadas a servicios.
D. Composition-Centric (Enfocado en las Composiciones):
orientadas a servicios están compuestas de Servicios
_ Las soluciones
que necesitan frecuentemente contener lógica reutilizable.
Servicios puedan ser reutilizados, deben
_ Sin embargo, para que tales
ser parte de soluciones distribuidas con diferentes ‘arquitecturas’ o
‘composiciones’de Servicios.
_ Una arquitectura orientada a servicios debe
composiciones, para facilitar que los Servicios reutilizables puedan
ser siempre enfocada a las
ser
incorporados en variedades de diferentes diseños de composiciones de servicios.
*. Componer: Cuando un Servicio A consume Servicios: B, C, D en un flujo
respectivamente.
*. Recomponer: Cuando un Servicio A es consumido por Servicios: X, Y, Z.
5. UNDERSTANDING SERVICE-ORIENTATION AND SERVICE-ORIENTED
ARCHITECTURE
_ La Orientación a Servicios, es un paradigma de diseño destinado a la creación de unidades
lógicas de solución, diseñadas de forma individual para que puedan utilizarse de forma colectiva
& reutilizada en apoyo de la realización de un conjunto específico de objetivos estratégicos
& beneficios asociados con SOA & la ‘Computación Orientada a Servicios’.
_ En la lógica de solución diseñada de acuerdo
con la Orientación del Servicio, las unidades de
la lógica se denominan Servicios.
_ La esencia de la Orientación del Servicio
es establecer un entorno de TI capaz de adaptarse
a los posibles cambios requeridos por medio de
Servicios.
_ “En la imagen se aprecia como el Soporte de TI,
debe brindar soluciones, en base a las
necesidades & requerimientos
(por medio de los
del Negocio”
Servicios).
ARCHITECTURE
_ La Orientación a
utilizado para
Servicios es el enfoque de diseño (o paradigma de diseño)
crear soluciones ‘Orientadas a Servicios’.
_ La aplicación de la Orientación a Servicios da como resultado la creación de características
de diseño específicas, que apoyan & se relacionan con el logro de los Objetivos Estratégicos
asociados con la Computación Orientada a Servicios.
compone
_ La Orientación a Servicios
para ser aplicadas
de una serie de Principios
de forma colectiva.
de Diseño
.
_ En resumen, se requiere una correcta comprensión de la Orientación a Servicios
para construir soluciones Orientadas a Servicios.
53 54
55 56

3/04/2023
15
ARCHITECTURE
SOA:
_ Los principios de la Orientación del Servicio son 8 & son responsables de modelar diferentes
aspectos del diseño & para una Arquitectura de Servicios.
_ La aplicación de estos
principios está guiada
(normada) por estándares de
diseño organizacional.
ARCHITECTURE
SOA:
_ Los principios de la Orientación del Servicio se relacionan de la siguiente manera,
teniendo como principio central el de: Service Reusability.
ARCHITECTURE
MicroServicios:
_ En lo relacionado a MicroServicios estos servicios especializados generalmente requieren un
alto nivel de ‘autonomía’, para cumplir requisitos basados en un: alto rendimiento & escalabilidad
‘no agnóstica’.
_ Como resultado, solo un
subconjunto de principios
de diseño de Orientación
de Servicio son aplicables
al manejo de
MicroServicios.
ARCHITECTURE
_ Una perspectiva importante de cómo se relaciona la Orientación del Servicio con SOA
& cómo esta relación da como resultado un conjunto de prioridades de diseño (lineamientos),
es proporcionada por el Manifiesto de SOA.
_ El Manifiesto SOA fue escrito por 17 expertos de la industria y su objetivo es proporcionar una
declaración concisa de que es SOA & la Orientación a Servicio, que defina claramente su
importancia & prioridades.
Prioridades de Diseño:
57 58
59 60

3/04/2023
16
6. FOUR PILLARS OF SERVICE-ORIENTATION
_ Debido a la naturaleza “estratégica” como objetivo que la Orientación al Servicio pretende
establecer, un conjunto de factores de críticos éxito fundamentales son
requisitos importantes para una correcta adopción de SOA.
_ Estos factores de críticos éxito se denominan pilares, porque establecen una base sólida
sobre la cual: crear, implementar & gobernar Servicios. La existencia de estos cuatro pilares se
considera esencial para cualquier iniciativa SOA. Así mismo, la ausencia de uno de estos pilares
en gran medida introduce un factor de riesgo importante para un proyecto SOA.
de la Orientación a Servicios son lo siguientes:
_ Los cuatro pilares
A. Trabajo en Equipo.
B. Educación.
C. Disciplina.
D. AlcanceEquilibrado.
_ Considerando que las aplicaciones tradicionales basadas en silos requieren la cooperación
de los miembros de los equipos de proyectos, la entrega de Servicios & Soluciones Orientadas
a Servicios requieren cooperación entre múltiples equipos de proyectos.
_ El alcance de un Equipo de Trabajo es notablemente mayor (que en un enfoque tradicional)
& puede introducir nuevos roles & la necesidad de crear & mantener nuevas relaciones entre
personas & departamentos.
_ Los integrantes de este Equipo de Trabajo de SOA, necesitan confiar el uno del otro,
de lo contrario, como equipo fracasarán.
Trabajo en Equipo (Teamwork):
_ Un factor clave para lograr la fiabilidad & confianza requeridas por los miembros del
equipo SOA (Teamwork), es asegurar que utilicen un lenguaje de comunicación común
basado en: definiciones, conceptos, métodos con una comprensión común (todos)
como objetivo, para que dicho equipo trabaje colectivamente de manera correcta.
_ Para lograr este entendimiento común, se requiere una educación no solo en temas generales
relacionados con: Orientación de Servicios, SOA & tecnologías de Servicio, sino también
en el correcto conocimiento sobre: principios, patrones & buenas prácticas, así como estándares,
políticas & metodología definidos como propios de la organización.
_ La combinación de los pilares: Equipo de Trabajo & Educación establecen una
base de conocimiento & comprensión de cómo usar dicho conocimiento entre los miembros del
equipo SOA. El resultado de esto elimina muchos riesgos comunes que tradicionalmente se ven
en proyectos SOA.
Educación:
_ Un factor de éxito crítico para cualquier iniciativa de SOA es la coherencia en la forma en que
se aplican los conocimientos & prácticas en un equipo.
_ Para tener éxito como un todo, los miembros del equipo deben ser disciplinados
en cómo aplican su conocimiento & llevan sus respectivos roles.
_ Las medidas requeridas de disciplina se expresan en el alineamiento con relación a los
estándares, metodología, modelado & diseño, así como en las reglas definidas
por el gobierno SOA. “Es importante saber que un equipo educado fracasará si
NO cumple con disciplina”.
Disciplina:
61 62
63 64

3/04/2023
17
Alcance Equilibrado:
_ Hasta ahora se ha establecido la necesidad siguiente:
✓ ‘Equipos de Trabajo’cooperativos.
✓ Una comprensión común & ‘educación’ de las áreas de conocimiento de la industria &
la empresa ...
✓ Cooperar correctamente con un equipo, aplicar el entendimiento, seguir una metodología &
estándares comunes de una manera disciplinada.
_ En algunas empresas de TI, especialmente aquellas
acostumbradas al desarrollo de aplicaciones basadas
en silos, lograr cumplir estos pillares puede ser
todo un desafío.
_ Existen formas: culturales, políticas & otras de cuestiones que dificultan el logro
organizacionales necesarios
de los cambios
tres pilares (resistencia
& requeridos por dichos
al cambio).
_ Una
grado
vez que se ha definido un alcance equilibrado en la adopción,
en que los otros tres pilares deben ser
se determina el
establecidos.
Los factores comunes involucrados en la determinación de un alcance equilibrado incluyen:
*. Obstáculos culturales.
*. Estructuras de autoridad.
*. Alineación del dominio comercial.
*. Apoyo & financiación disponibles para los interesados.
*. Recursos de TI disponibles.
Alcance Equilibrado:
7. FUNDAMENTAL TERMINOLOGY AND CONCEPTS
_ Los conceptos que se tratarán serán los siguientes:
A. Servicios (Services).
B. MicroServicios (MicroServices).
- ServiciosAgnósticos (Agnostic Services).
- Consumidores de Servicios (Service Consumers).
- Contratos de Servicio (Service Contracts).
- Capacidades de Servicio (Service Capabilities).
C. Composiciones de Servicio (Service Compositions).
D. Lógica Orientada al Servicio (Service Oriented Logic).
E. Inventario de Servicio (Service Inventory).
- Inventarios del Servicio de Dominio (Domain Service Inventories).
- Inventarios de Servicios Normalizados (Normalized Service Inventories).
F. Modelos de Servicio y Capas de Servicio (Service Models and Service Layers).
G. Gobernanza y Gestión de API de Servicio (ServiceAPI Governance and Management).
H. Computación Orientada a Servicios (Service Oriented Computing).
_ La siguiente imagen muestra como están relacionados gran cantidad de términos revisados:
.
65 66
67 68

3/04/2023
18
INTERMEDIO
_ Un Servicio es la unidad más fundamental en una “Lógica Orientada a Servicios”.
_ Una unidad de lógica de solución se clasifica como ‘Servicio’ cuando la orientación a
servicios ha sido aplicada en un grado significativo.
_ Las soluciones orientadas a servicio son compuestas de múltiples Servicios (flujo)
que conforma lo que se conoce como: composición de servicios o servicios compuestos.
_ Un Servicio debe de ser considerado como un ‘activo de la empresa’, ya que en base a su
funcionamiento correcto se cumple la lógica de negocio deseada que generará a futuro el ROI.
_ Mientras los Servicios sean más pequeños, estos serán más reutilizables & mientras estos sean
más grandes pueden generar más problemas para ser reutilizados.
_ Los Servicios son los bloques de construcción elementales de una plataforma orientada a servicios.
_ Los Servicios deben ser diseñados de una manera muy específica, de acuerdo al enfoque de diseño
propio de la Orientación a Servicios.
A. Servicio (Service):
_ Un MicroServicio es un tipo especial de un Servicio con la característica de ser: ‘no agnóstico’
que contiene lógica de procesamiento con requisitos específicos de: rendimiento, escalabilidad
y / o confiabilidad.
_ Para permitir el cumplimiento de estos requisitos mencionados, comúnmente se implementan
MicroServicios en un entorno especial ‘aislado’, equipado con infraestructura & recursos
dedicados.
_ Al compararse con la mayoría de otros tipos de Servicios, el alcance funcional
de un MicroServicio suele ser bastante pequeño & limitado a una Lógica de Solución
basada en los requisitos anteriormente mencionados.
_ “El tener dependencias a nivel de: (datos, lógica, API) acopla el servicio”, debido a ello
un beneficio importante de los MicroServicios, es no tener dicha dependencia.
_ Debido a que un MicroServicio se implementa & mantiene de manera independiente
no se espera que brinde funcionalidad ‘reutilizable’. Así mismo, por lo general solo debe cumplir
parte de los principios de la Orientación a Servicios.
B. MicroServicio (MicroService):
_ La relación entre SOA & MicroServicios debe ser visto de a siguiente manera.
Así mismo, más adelante se darán detalles.
B. MicroServicio (MicroService):
69 70
71 72

3/04/2023
19
*. ServiciosAgnósticos (Agnostic Services):
_ Una objetivo importante de la Orientación del Servicio es producir la mayoría de Servicios
con un contexto funcional agnóstico.
_ Los Servicios Agnósticos son altamente reutilizables, ya que están libres de dependencias
lógicas que limitarían su uso a un proceso comercial específico.
_ Un Servicio Agnósticos tiene un contexto que es útil para múltiples procesos de negocio,
lo que ayuda a la reutilización.
_ Es importante mencionar que los
Servicios especiales como los
MicroServicios
diseñados ser agnósticos,
debido a
para
ello
a menudo están
no
se clasifican como
no reutilizables.
Servicio, se le denomina como
*. Consumidores de Servicios (Service Consumers):
_ Cuando un programa invoca e interactúa con un
Service Consumer.
_ Es importante comprender que este término se refiere a la función: en tiempo de ejecución
temporal, asumida por un programa en el momento que requiera consumir un Servicio
durante un intercambio de información.
_ Un Service Consumer puede o no ser otro Servicio (aplicación, componente, etc).
_ “En la imagen se aprecia la capacidad de
un Servicio para invocar (consumir)
otro
una
Servicio, forma la base de
Composición del Servicio”.
_ Un Contrato de Servicio muestra la metainformación de un Servicio & define los términos
de participación (los requisitos para invocar e interactuar con el Servicio).
_ Para que un Contrato de Servicio tenga acceso e interactúe con un Servicio,
debe cumplir con los requisitos propios del Contrato de Servicio.
_ La parte fundamental de un Contrato de Servicio es su interfaz técnica que conforma lo que se
denomina como: “Contrato Técnico de Servicio”.
_ Un Contrato de Servicio puede estar asociados a documentos definidos por personas
como un SLA, donde describen la calidad adicional requerida, comportamientos & limitaciones
posibles que el Servicio debe cumplir.
*. Contratos de Servicio (Service Contracts):
_ El diseño de los Contrato de Servicio es independiente a qué tecnología de implementación
se utiliza para construir el Servicio respectivo.
_ Las opciones de tecnología de implementación de servicios se introducen al final de este
módulo.
_ Dentro de la Orientación al Servicio, el diseño & la estandarización del Contrato de Servicio
es muy importante, tanto así que existe un principio de diseño llamado:
Contrato de Servicio Estandarizado dedicado a la definición del estándar de manejo
de los Contratos de Servicio respectivamente.
_ La creación de Contratos de Servicio Estandarizados es un requisito clave para alcanzar los
Objetivos Estratégicos de: incrementar la federación & la interoperabilidad intrínseca,
que ya se ha revisado previamente.
*. Contratos de Servicio (Service Contracts):
73 74
75 76

3/04/2023
20
_ Cada Servicio debe tener asignado un contexto funcional distinto & compuesto por un
conjunto de funciones relacionadas con dicho contexto.
_ Estas funciones son conocidas como Capacidades de Servicios (en tiempo de diseño),
hasta que se sepa cómo se será construido el servicio (en tiempo de desarrollo).
_ Un Servicio puede tener una o más capacidades. Las capacidades del Servicio pueden ser
expresadas en un Contrato de Servicio.
_ Un Consumidor de Servicio a menudo invocará una capacidad específica, lo que significa
que invocará solo un subconjunto de funcionalidades que ofrece el Servicio.
* Tiempo Diseño (Servicio):
* Tiempo Desarrollo (Servicio):
capacidad
operacion
* Tiempo Diseño (Componente): capacidad
* Tiempo Desarrollo (Componente): metodo.
*. Capacidades de Servicio (Service Capabilities):
_ Una Composición de Servicio esta enfocado a automatizar una tarea o proceso empresarial
en particular.
_ Para se calificado como una Composición, deben de existir Servicios participantes,
más un iniciador de la composición presentes.
_ De lo contrario, la interacción del Servicio solo será considerada como un intercambio:
punto a punto.
_ La Composición de Servicio es muy importante para el éxito de una iniciativa SOA,
porque los beneficios de los Objetivos Estratégicos de: retorno de la inversión (ROI) &
agilidad organizativa, dependen de la capacidad de componer & recomponer los Servicios.
_ Gran parte de la Orientación a Servicios está enfocada a lograr estos objetivos de diseño.
C. Composición de Servicio (Service Composition):
_ Una Composición del Servicio depende de la capacidad de los Servicios para poder
consumirse entre sí.
C. Composición de Servicio (Service Composition):
_ Cualquier Lógica de Solución a la que se haya aplicado la Orientación a Servicios
en una medida importante está considerada como: Lógica Orientado al Servicio.
_ Un Servicio representa la unidad más fundamental de la Lógica Orientada a Servicios.
_ Existen 2 tipos básicos de ‘Lógica Orientada a Servicios’ que son: Servicios Simples
& Servicios Compuesto.
_ Una solución Orientada a Servicios puede abarcar una o más Composiciones de Servicio,
porque representa una lógica que puede llevar a cabo: 1 o * tareas relacionadas o
procesos de negocio.
_ Por otro lado, la solución más simple Orientada a Servicios puede consistir
en un solo Servicio (expuesto / virtualizado).
D. Lógica Orientada a Servicios (Service Oriented Solution Logic):
77 78
79 80

3/04/2023
21
_ Un Inventario de Servicios es una selección regulada de Servicios,
dentro de un límite que representa una empresa o un dominio de una compañía.
_ Cuando una organización tiene varios inventarios de servicio, se denomina como:
Inventario de ‘Dominio’de Servicios.
E. Inventario de Servicio (Service Inventory):
_ Lo ideal es que todos los Servicios se entreguen como parte del mismo
Inventario de Servicios empresarial. Es importante mencionar que en empresas muy grandes,
la estandarización de toda la empresa puede ser casi imposible.
_ En estos casos, es recomendable & necesario definir Inventario de Servicios de tipo: Dominio.
_ La definición de los Inventario de Servicios normalmente se analiza en la fase inicial de análisis
definiendo ‘Servicios Candidatos’ para ser considerados en el ‘Inventario de Servicios’.
_ Parte de esta fase de análisis se enfoca en evitar la superposición (traslape) entre los Servicios
que forman parte del Inventario, ya que se tiene como objetivo lograr la normalización de los Servicios.
_ Los problemas comunes de diseño con relación a los Inventarios de Servicio incluyen:
*. Alcance & Límite (empresa / dominio).
*. Estandarización del Servicio.
*. Escalabilidad.
*. Selección & Versiones de Estándares de la Industria.
*. Plataformas de Tiempo de Ejecución & Entornos en Contenedores.
*. Infraestructura.
*. Gobernabilidad.
_ Los Objetivos Estratégicos de la Computación Orientada a Servicios se realizan
dentro de los límites definidos de los Inventarios de Servicios.
_ La manejo fundamental que un Inventarios de Servicio debe soportar con éxito es la
Composición & Recomposición de servicios.
* Componer: Cuando un Servicio A consume Servicios: B, C, D en un flujo respectivamente.
* Recomponer: Cuando un Servicio A es consumido por Servicios: X, Y, Z.
_ Para lograr esto, el Inventarios de Servicio debe ser respaldado por: tecnologías, plataformas
e infraestructura especiales.
81 82
83 84

3/04/2023
22
_ En la imagen se aprecia como los Procesos de Negocio son soportados, a nivel de tecnología,
por medio de los Inventarios de Servicios respectivos.
*. Inventarios de Dominio del Servicio (Domain Service Inventories):
_ Se pueden crear múltiples Inventarios de Servicios para una empresa. Así mismo, el alcance
de cada uno de dichos Inventarios de Servicio representa un Dominio bien definido de la
Empresa.
_ Dentro de cada Dominio los Inventarios de
Servicios pueden ser manejados de manera
independiente cada uno, esto quiere decir
“manejarlos con sus propios estándares,
namespace, tecnología, etc”.
_ Un Inventario de Servicio que contiene
Servicios con superposición (traslape) a
nivel de sus límites funcionales, genera una
desnormalización.
_ Los Servicios se pueden modelar de
forma colectiva, de modo que cada límite del
Servicio se analice para garantizar la
correcta distribución de los Servicios.
_ El resultado es un Inventario de Servicio
con un mayor grado de normalización.
*. Inventarios de Servicios Normalizados (Normalized Service Inventories):
_ Un Modelo de Servicio es una clasificación utilizada para indicar un Servicio según el
tipo de lógica que contiene, el nivel de reutilización de lógica & cómo un Servicio puede
relacionarse con elementos de la lógica de negocio para la automatización.
_ Los siguientes Modelos de Servicio son: ‘Servicio de Tarea’, ‘MicroServicios’, ‘Servicio de
Entidad’, ‘Servicio Utilitario’.
A.SERVICIO DE TAREA: Es un Servicio con un contexto funcional no agnóstico que contiene
la lógica del proceso comercial basada en un único propósito.
B.MICROSERVICIO: Es un Servicio con un contexto funcional no agnóstico & un alcance
funcional estrecho, que contiene la lógica con requisitos específicos enfocados al: rendimiento,
escalabilidad y / o confiabilidad.
C.SERVICIO DE ENTIDAD: Es un Servicio reutilizable con un contexto funcional agnóstico
asociado con una o más ‘entidades’comerciales (ejemplo: factura, cliente, contrato, etc).
F. Modelos de Servicio y Capas de Servicio (Service Models and Service Layers):
85 86
87 88

3/04/2023
23
D. SERVICIO UTILITARIO: Es un Servicio con un contexto funcional altamente agnóstico,
este tipo de Servicio no se relaciona a las especificaciones & modelos de análisis de negocios
(no maneja lógica). Este tipo de Servicio encapsula funcionalidad basada en la tecnología de
bajo nivel.
F. Modelos de Servicio y Capas de Servicio (Service Models and Service Layers):
_ API Management (gestión de APIs), está cobrando cada vez más importancia en las
arquitecturas software modernas.
_ Se puede definir API Management como el proceso de: publicar, promocionar y monitorear
APIs en un entorno seguro y escalable. Asimismo, incluye los recursos enfocados a la:
creación, documentación y socialización de las APIs.
_ Las APIs (Application Programming Interface) son activos estratégicos de una empresa
& se administran de la mano con las reglas definidas a nivel de gobierno.
_ Una API es el ‘medio’ por el cual usuarios remotos, pueden consumir Servicios.
Las APIs hacen posible interconectar módulos & aplicaciones, facilitando el acceso a sus
backends & permitiendo la reutilización de Servicios.
G. Gobernanza y Gestión de API’s de Servicio (Service API Governance and Management):
G. Gobernanza y Gestión de API’s de Servicio (ServiceAPI Governance and Management):
_ Es importante diferenciar una API de un Servicio, siendo una API la manera con la que se
interactúa & se consume el Servicio (el medio).
“Haciendo una analogía: una API podría ser un ‘enchufe de la casa’ & el Servicio sería la
‘electricidad’que es proporcionada por la empresa distribuidora”.
_ El objetivo final es permitir que las
API evolucionen de forma controlada,
para minimizar el impacto en los
Consumidores de Servicios,
maximizando el valor que se les brinda,
para ello está API Management .
_ Es un término general utilizado para representar una plataforma de Computación Distribuida:
‘Basada en la Orientación a Servicios’.
_ Este término abarca muchas cosas incluyendo su propio paradigma, principios de diseño,
patrones de diseño, modelo de arquitectura, conceptos, terminologías, etc.
_ Todo lo revisado hasta el momento se considera como parte de la plataforma de
‘Computación Orientada a Servicios’.
_ Se deben de incluir también todos los: productos & soluciones importantes de vendors,
tecnologías Open Source, especificaciones de estándares, etc.
_ En conclusión la ‘Computación Orientada a Servicios’ representa en esencia un
tipo especializado de ‘Computación Distribuida’.
H. Computación Orientada a Servicios (Service Oriented Computing):
89 90
91 92

3/04/2023
24
8. INTRODUCTION TO COMMON SERVICE TECHNOLOGIES
_ Esta sección cubre las siguientes tecnologías de Servicio.
A. Servicios como Componentes.
B. Servicios como Servicios Web.
C. Servicios como Servicios REST.
D. Servicios y Formatos de datos de mensajería.
E. Servicios y Modelos de datos de mensajería.
F. API Gateway.
G. Virtualización.
H. Computación en la nube.
I. Servicios en la nube.
J. Containerización.
.
_ Es importante conocer que SOA como arquitectura, es neutral para cualquier plataforma de
tecnología (vendors), esto quiere decir que cualquier tecnología de implementación útil para
crear sistemas distribuidos, puede ser adecuada para la Orientación del servicio.
_ Las tecnologías para la construcción de servicios incluyen.
*. COMPONENTES.
*. SERVICIO WEB (Basados en SOAP).
*. SERVICIOS REST (Basados en REST).
_ Un Componente es un programa informático diseñado para ser parte de un sistema
(distribuido en este caso).
_ Un Componente expone su interfaz técnica, como sus capacidades
llamadas métodos, permitiéndole ser explícitamente invocado por otros programas.
_ Los Componentes son típicamente parte
JAVA o .NET. Un ejemplo de
de plataformas propietarias
ello son: EJB’s, RMI,
como:
etc.
_ La Orientación a Servicios puede ser aplicada a los Componentes a fin de que sean
diseñados como Servicios.
A. Servicios como Componentes:
_ Por ejemplo, un Service Consumer
debe implementarse en el mismo lenguaje
de programación del manejado por el
Componente (dependencia). Esto se debe
a que el Contrato de Servicio está
físicamente “acoplado” a la lógica de la
solución, como se muestra en la imagen
superior.
_ Debido a la naturaleza de sus contratos
acoplados, es difícil manejar correctamente
los Servicios basados en Componentes
como recursos de la empresa.
“Sin embargo, la Orientación de Servicios
aún se puede aplicar a los Componentes
para ayudar a darles forma de Servicios”.
A. Servicios como Componentes:
93 94
95 96

3/04/2023
25
_ Los Web Service (basados en SOAP) son creados utilizando un conjunto específico de estándares de
la industria que generalmente incluyen WSDL (para la definición del Contrato de Servicio),
SOAP (para la definición de mensajes) & XML Schema (para la definición de los modelos de datos de
mensajería).
Service
_ Por
basados
definición
en
los SOAP
el protocolo
son Web
de
Service que
comunicación
están
SOAP.
por el cual servicios
_ El protocolo
SOAP 1.1 o SOAP
se basan dichos
1.2 &
de tipo:
tipo:
Síncrono, Asíncrono, Oneway,
manejar
etc
su
(XML
pueden ser
comunicación
en realidad).
B. Servicios como Servicios Web:
_ Exigen estándares adicionales que proporcionan
numerosas funciones & extensiones que permiten a los
Web Service el manejo de Composiciones de
Servicios complejas. Estas extensiones incluyen: WS-
Security WS-Policy, WS-SecurityPolicy & WS-
Addressing (WS-*).
C. Servicios como Servicios REST:
_ REST (Representational State Transfer) es un ‘estilo de arquitectura’ software para el manejo
de Web Service el cual trabaja sobre el protocolo HTTP.
_ Los Servicios REST (Web Service basado en REST), no pueden tener
Contratos de Servicio individuales, sino que manejan un contrato uniforme a través
de los métodos HTTP, por ejemplo: GET, POST & DELETE.
_ Los Servicios REST son amigables para el navegador, ya que se basan en el protocolo HTTP
a nivel de mensaje, mediante un formato de tipo: JavaScript Object Notation (JSON).
_ La Orientación del Servicio se puede
aplicar a los Servicios REST. Así mismo,
el Contrato Uniforme puede limitar la
aplicación de algunos Principios de Diseño del
Servicio.
_ REST es el medio de implementación principal para MicroServices, esto debido a que
REST es más abierto para el soporte de formatos de datos más allá de XML.
_ Además, los Servicios REST no dependen de tantos estándares como los
Servicios Web (basados en SOAP) & debido a ello, son más simples de implementar
en cualquier lenguaje de programación que soporte HTTP.
_ Esto proporciona una mayor autonomía en tiempo de diseño & aumenta el rendimiento a nivel
en runtime, al evitar la sobrecarga de procesamiento basado en XML.
D. Servicios & Formato de Datos de Mensajería:
_ Los Servicios incluidos en un Inventario de Servicio establecen un conjunto de
APIs de Servicio en forma de Contratos de Servicio (considerados).
_ Estos Contratos de Servicio establecen una capa de representación de datos compuesta de
modelos de datos definidos como esquemas XML o JSON.
_ Los esquemas definen la estructura de los datos en los mensajes para los intercambios entre
los Servicios y los Service Consumers.
_ Los MicroServicios de preferencia manejan esquemas JSON, pero también pueden admitir
esquemas XML.
E. Servicios & Modelos de Datos de Mensajería:
97 98
99 100

3/04/2023
26
_ Los documentos con extensión .xsd son (esquemas XML) & aquellos con extensiones .json
son (esquemas JSON). Así mismo, los documentos WSDL tienen una extensión .wsdl.
Finalmente, pueden usarse muchas tecnologías para las definiciones (en si son un marco
diseñado para describir, crear, visualizar & consumir Servicios), de una API REST como lo son:
WADL , Swagger, OpenAPI, RAML, etc.
E. Servicios & Modelos de Datos de Mensajería:
_ Una API Gateway (puerta de enlace API) es una forma de middleware que ofrece funciones &
herramientas de nivel comercial para el procesamiento & la administración en Runtime
de determinados Servicios dentro de una empresa de TI.
_ Las características proporcionadas por productos API Gateway incluyen procesamiento &
administración de seguridad, enrutamiento, mediación, monitoreo, balanceo de carga,
escalamiento, etc.
_ Para la publicación del servicio, una 'API Gateway para Microservicios‘, funciona como un
único punto de entrada a una arquitectura interna (para los ‘Service Consumers’ externos a
la organización), proporcionando una dirección estática a dichos Service Consumers &
encaminados dinámicamente los request a la dirección expuesta del Servicio.
F. API Gateway:
como un
API Gateway posicionado
Endpoint
‘Centralizado’ dando la cara
del: Inventario de Servicios.
Esto con relación a los posibles
Service Consumers externos
existentes”.
F. API Gateway:
_ “En la imagen se aprecia un
F. API Gateway (vs ‘API Management’):
_ Las API Gateway crean una barrera entre los
clientes externos solicitantes & las API internas
que unen los Microservicios. Por otro lado,
API Management tiene un alcance mayor,
ya manejan lo mismo que el API Gateway,
así como también: “analíticas, datos comerciales,
servicios de proveedores, control de versiones”
(una ‘suite’ enfocada a la administración).
_ En resumen, una API Gateway es considerado
como un componente dentro de una solución
de API Management completa.
101 102
103 104

3/04/2023
27
_ Ante la necesidad de reducción de costos en las organizaciones de: (infraestructura, energía,
refrigeración, etc) la Virtualización es la salida, consistiendo en la creación, a través de software,
de una versión virtual de recursos de TI, relacionados a: servidores, aplicaciones, etc.
_ La Virtualización permite la simulación de entornos físicos de TI, proporcionando
múltiples imágenes virtuales de sí mismos, para que sus capacidades de procesamiento puedan
ser compartidas a múltiples consumidores. Así mismo, facilitando de esta manera la
administración.
_ Un Servidor
(servidor físico).
Virtual es una software de virtualización, que emula
Así mismo, cada Servidor Físico puede alojar y/o
una computadora
contener múltiples
Servidores Virtuales (se maneja una relación de: 1 a *).
_ Los Servidores Virtuales permiten el ahorra en costos, ya que si se requiere tener varios
servidores, se puede tener varios Servidores Virtuales dentro de uno Servidor Físico.
G. Virtualización:
_ Estas son algunas diferencias considerables con relación a la Virtualización:
*. Servidor Físico:
Ejemplo: dedicado, físicamente se puede “ver & tocar”, se trata de una combinación de
hardware & software que se configura.
*. Servidor Virtual:
Es una porción de un Servidor Físico, configurada para actuar como justamente un Servidor.
Se trata de una instalación de software realizada sobre un Servidor Físico, que puede alojar
diferentes Servidores Virtuales que comparten entre sí hardware & recursos,
pero su funcionamiento es completamente independiente.
G. Virtualización:
_ “En la imagen se aprecian tres Servidores Virtuales alojados en dos Servidores Físicos”:
G. Virtualización:
_ Cloud Computing es una forma especializada de Computación Distribuida que presenta
modelos para el aprovisionamiento remoto de recursos escalables & medidos de TI
(engloba muchos conceptos).
_ El término nube (cloud), se originó teniendo como base el símbolo de nube, utilizado para
representar a la Internet.Así mismo, es importante conocer los siguientes términos:
_ El término on-premise, significa que se tiene instalado y ejecutándose en computadoras en las
instalaciones (edificio) de la persona u organización de TI, que usa el software (localmente).
_ La contraparte de on-premise, es on-cloud (en la nube), significa que se está ejecutando en
una instalación ‘remota’ (posiblemente en una granja de servidores).
H. Computación en la Nube:
105 106
107 108

3/04/2023
28
_ Un Recurso de TI es un artefacto físico o virtual relacionado con TI (software o hardware),
como por ejemplo: “servidor físico, servidor virtual, aplicación o servicio, etc’”.
_ El enfoque comercial en la computación en la nube, consiste en la disponibilidad de los
Recursos de TI para su alquiler, ya que utiliza como Cloud Providers un modelo: ‘pay-for-use’.
_ Esto permite a las organizaciones aprovechar los enormes recursos a nivel de infraestructura
on-cloud, sin tener ya que invertir en configurar & mantener una infraestructura on-
premise (local).
_ Un Cloud Provider generalmente se apoyará en tecnología de virtualización para hacer
que los recursos compartidos estén disponibles para los: Cloud Consumers.
_ La Innovación Tecnológica ha permitido a las nubes proporcionar recursos de TI
dinámicamente escalables (que puedan adaptarse automáticamente a las demandas de uso).
_ Las Soluciones Orientadas a Servicios, pueden reutilizar & consumir Servicios
desplegados en la nube o también, pueden hospedarse completamente en entornos de nube
(todo el ‘Inventario de Servicios’).
_ El término Servicio en el contexto de Cloud Computing es muy amplio.
_ Desde una perspectiva de Cloud Computing, cualquier Recurso de TI (‘accesible de forma
remota’), se clasifica como un Servicio.
_ Los Cloud Service son todos aquellos programas o servicios (Recurso de TI),
que usamos &que no están “físicamente instalados” localmente (Su instalación está en nube).
_ T
ener en cuenta que, aunque un Cloud Service existe como un Recurso de TI,
puede proporcionar acceso a otros Recurso de TI basados en la nube (reutilizables).
I. Servicios en la Nube (Cloud Service):
una perspectiva de SOA un Cloud Service
_ Desde
consistiría
que
en un software (instalado en la nube)
actúa como endpoint.
IAAS: (“Infraestructura como Servicio”)
_ Requiere de alquilar un servidor en nube.
_ Requiere hacer un desarrollo & desplegarlo.
_ Todo se debe hacer manualmente en la nube
(instalaciones & configuración).
I. Servicios en la Nube (Cloud Service):
PAAS: (“Plataforma como Servicio”)
_ Se amplían los servicios de IAAS.
_ Requiere hacer desarrollos en los lenguajes de
programación soportados por el proveedor de la
nube.
_ No se requiere instalar nada, se escoge el
software disponible (autoinstala / autoconfigura).
SAAS: (“Software como Servicio”)
_ Enfocado al uso de usuarios.
_ Se usan aplicaciones hechas & desplegadas por el
proveedor Cloud (ya activas).
_ El fabricante personaliza la aplicación (Modo usuario).
_ Son programas que funcionan sobre un navegador.
_ No se instala nada, ya esta instalado solo se usa el
servicio en la nube: Google Drive, Dropbox, etc
109 110
111 112

3/04/2023
29
_ De la misma manera que la virtualización permite la replicación de Recursos de TI
(Servidores Físicos, etc), la Contenedorización permite la replicación de software
(servicios, componentes, aplicaciones).
tecnología
_ El software se desplegará dentro del Contenedor, pero a diferencia de la
de virtualización tradicional, el Contenedor no incluye el Sistema Operativo interno.
J. Containerización:
_ Así mismo, el Sistema
Operativo de la máquina física o
‘Contenedor’ que facilitará
virtual ejecutará el motor del
la
los
comunicación entre
Contenedores & el sistema
operativo del host.
_ Esto significa que es más
eficiente replicar contenedores
en lugar de replicar máquinas
virtuales completas.
9. ADOPTION IMPACTS AND REQUIREMENTS
_ Los principales impactos & requisitos durante una adopción SOAincluyen:
A. Consideraciones de Estandarización.
B. Consideraciones de Organización.
C. Consideraciones de Metodología.
D. Consideraciones de Gobierno.
E. Consideraciones de Rendimiento.
F. Consideraciones de Seguridad.
G. Consideraciones de Infraestructura.
H. Consideraciones de Madurez.
I. Consideraciones de Migración.
_ Los estándares de la industria generalmente están representados por especificaciones
tecnológicas que son producidas por organizaciones de estándares & desarrolladas por
comités técnicos: (W3C, OASIS, WS-I).
_ Es importante saber que el uso de estándares de la industria por sí solos,
no da como resultado entornos SOA completamente estandarizados.
_ Se necesitan estándares de diseño personalizados (propios de la empresa), para
lograr un nivel de estandarización requerido apoyándose en los Objetivos Estratégicos
& beneficios de la Computación Orientada a Servicios.
_ Los desafíos para trabajar con la estandarización del diseño (propios de la empresa),
suelen ser más culturales que técnicos. Así mismo, la aplicación de estándares de diseño
puede ser un ‘punto de conflicto’ internamente en la organización (asumirlos).
A. Consideraciones de Estandarización:
A. Consideraciones de Estandarización:
_ Los estándares de diseño personalizados (propios de la empresa), determinarán qué
estándares de la industria (versiones) se asumirán & usarán:
_ “En la imagen se aprecian diferentes
Servicios basados en SOAP & REST,
pero que a nivel de diseño respetan lo
establecido en la documentación de
estándares de diseño, definidor por la
empresa”.
113 114
115 116

3/04/2023
30
_ Las iniciativas de SOA pueden introducir muchas consideraciones nuevas, que pueden
impactar a la organización en una variedad de formas. Por ejemplo:
*. Definición de nuevos procesos.
*. Necesidad de nuevos recursos con nuevos conocimientos (Skills).
*. Cambios en la estructura organizacional en los proyecto y ciclos de vida.
*. La adopción de nuevas metodologías y herramientas de desarrollo de software.
*. Cambios al análisis de negocios y enfoques de modelado.
*. El uso y la aplicación de estándares de diseño internos.
B. Consideraciones de Organización:
_ Uno de los impactos más importantes se origina en el énfasis (hincapié), en la creación de
Servicios altamenteAgnósticos.
_ Una vez que existe una colección de Servicios Agnósticos (‘Inventario de Servicios’),
los: estándares, procesos & custodios deben saber para
administrar & gobernar correctamente
que hacer
los Servicios.
_ Dependiendo del alcance de la Iniciativa SOA, esto puede conducir a un:
cambio en la Estructura Organizacional del Departamento de TI (nuevos roles).
_ Los estándares de diseño personalizados (propios de la empresa), determinarán
qué estándares de la industria (versiones) se usarán dentro de la organización.
"En imagen se aprecia el total de Roles necesarios en un escenario óptimo de un
proyecto SOA’".
117 118
119 120

3/04/2023
31
_ Los cambios organizacionales requeridos en una adopción de SOA, a
menudo se subestiman (no se tomar con la importancia debida), dejando a las organizaciones
NO preparadas para posibles impactos.
_ Además, a menudo existe resistencia a
los cambios por parte del personal de la
organización.
_ Los equipos de proyecto deben
comprender el por qué de los beneficios
principales
por lo tanto
son estratégicos
son a largo plazo.
_ Antes de comenzar con una Iniciativa de SOA, se debe elegir un enfoque de entrega
de proyectos, para organizar mejor el ciclo de vida de entrega del servicio.
Actualmente, existen 4 enfoques de entrega (delivery).
*. ‘TOPDOWN’ DELIVERY:
Es un enfoque estratégico que incorpora niveles significativos de inventario & análisis orientado al
servicio, llevado a cabo antes del diseño y desarrollo de los Servicios. El objetivo de este
enfoque es la prestación de Servicios que seguirán siendo altamente interoperables &
reutilizables a largo plazo.
*. ‘BOTTOM, UP’ DELIVERY:
Es un enfoque táctico que se centra en la entrega de servicios para cumplir con los requisitos
comerciales (tácticos) inmediatos. Este tipo de proyecto se manejan de similar
forma a los proyectos de aplicación tradicionales basados en silos.
C. Consideraciones de Metodología:
*. ‘MEET IN THE MIDDLE’ DELIVERY (Conocerse en el medio de entrega):
Es un enfoque híbrido que intenta equilibrar la ejecución táctica con la alineación estratégica,
al permitir que el análisis de negocio se realice al mismo tiempo con la entrega del Servicio.
*. ‘TOP-DOWNAND AGILE’DELIVERY (Entrega ágil y descendente):
Es un enfoque híbrido que sigue dos enfoques, el enfoque top-down para el manejo de algunos
Servicios & enfoque de desarrollo ágil estándar para otros. Debido a las características de un
entorno de despliegue aislado los Servicios de tipo MicroServicios suelen ser los mejores
candidatos para una entrega ágil (facilitan las entregas).
‘ANÁLISIS’Orientado a Servicios:
_ SOA enfatiza una relación directa entre el análisis del negocio & Servicios, que terminan
implementando una lógica de negocios.
_ Eso hace que se requiera una forma única de análisis, que debe ser realizada
antes del diseño de los Servicios individuales.
_ El modelado de servicios es la parte de la etapa de análisis orientada a servicios
durante la cual los Servicios & sus capacidades se conceptualizan antes de su definición &
desarrollo (normalmente mediante la: Descomposición de un Proceso de Negocio).
121 122
123 124

3/04/2023
32
al servicio, continúa
‘DISEÑO’Orientado a Servicios:
_ Cuando se sigue un enfoque Topdown, el diseño orientado
exactamente desde donde terminó el análisis orientado a servicios.
_ Los Servicios Candidatos son el punto de partida, dando como resultado una colección de
Contratos de Servicio (Para ser considerados luego a nivel del ‘Inventario de Servicio’).
_ Durante el diseño orientado al servicio, el conocimiento de los principios de la orientación
a servicios & patrones son aplicados.
_ La Orientación a Servicio pone énfasis en la estandarización & desacoplamiento del
‘contrato técnico’ de cada Servicio.
_ Por lo tanto, el ‘Diseño Orientado a Servicios’ deber ser basado en un enfoque de tipo:
‘Contract First’ también conocido como: top-down, que exige a los desarrolladores evitar el uso
de herramientas de autogeneración de contratos (bottom-up).
_ Una de las metas primarias del ‘Diseño Orientado a Servicios’ es el evitar el impacto
a causa de las tecnologías de ‘transformación’ en apoyo al objetivo estratégico
de ‘Incrementar la Interoperabilidad Intrínseca’.
_ La Gobernanza es el acto de
una organización toma
gobernar o administrar algo. Es el medio por el cual
decisiones sobre la toma de decisiones.
_ Dentro de TI, un Sistema de Gobierno es responsable de: organizar, dirigir & guiar
la creación & evolución de los activos & recursos de TI.
_ Un Sistema de Gobierno tiene los objetivos de:
*. Definir restricciones & parámetros que controlan, guían o influyen en las decisiones.
*. Definir quién tiene la responsabilidad & la autoridad para tomar decisiones.
*. Definir las consecuencias por el incumplimiento de las restricciones requeridas.
D. Consideraciones de Gobierno:
125 126
127 128

3/04/2023
33
_ El Gobierno de TI tiene la responsabilidad de regular & desarrollar un correcto ambiente de TI
a lo largo de su ciclo de vida. Así mismo, un Gobierno SOA está considerado como parte de un
Gobierno de TI.
_ Un Gobierno SOA está relacionado en un ambiente SOA con:
*. Servicios Simples.
*. Servicios Compuestos.
*. Soluciones Orientadas a Servicios.
*. Arquitecturas Orientadas a Servicios.
*. Infraestructura de Apoyo.
*. Modelos & Especificaciones Comerciales Compatibles.
_ Los requisitos de Gobierno de SOA pueden imponer desafíos organizacionales que afectan:
*. Políticas & Regulaciones.
*. Asignación de Personal (nuevos roles).
*. Creación de Nuevos Procesos (ciclo de vida).
*. Normas de Diseño Interno.
*. Responsables de Servicios.
_ También, imponer desafíos tecnológicos relacionados a:
*. Monitoreo de Servicios.
*. Servicio de Vitalidad (identificar servicios:Activos).
*. Servicio de Versionamiento.
*. Manejo de un Middleware Moderno.
_ Dado que los MicroServicios se pueden manejar con desarrollos ágiles (iterativos),
sus Contratos de Servicio pueden necesitar ‘cambiarse’ con mayor frecuencia
que los ServiciosAgnósticos estandarizar.
_ Por ello, la carga de Gobernanza tiende a enfocarse a cuestiones de diseño de contratos,
(topdown) para el manejo cambios & una estrategia de control de versiones.
_ Como regla general, se debería aplicar lo siguiente: el análisis inicial realizado como parte de
un enfoque Top-Down reduce la carga de Gobernanza (le favorece), mientras que un enfoque
Buttom-Up genera un menor impacto inicial, pero aumenta la carga de Gobernanza.
_ Todo enfoque tiene sus Ventajas
& Desventajas, la clave es tomar
siempre en cuenta el nivel del
mantenimiento posterior (futuro).
129 130
131 132

3/04/2023
34
_ Los desafíos de rendimiento son un tema importante de diseño cuando se crean
Soluciones Orientadas a Servicios complejas debido a lo siguiente:
*. Dependencia de las tecnologías de mensajería.
*. Alta reutilización de Servicios Agnósticos & escalabilidad relacionada.
*. Necesidad de Composiciones de Servicios más grandes & más complejas.
*. Requerimientos de alto rendimiento & escalabilidad de MicroServices no agnósticos.
_ Debido a que las Soluciones Orientadas a Servicios modernas están construidas
con tecnologías de mensajería (esquemas), a menudo tienen mayores capas de procesamiento
de mensajes (taxonomía), sujetas a posibles sobrecarga de rendimiento.
E. Consideraciones de Rendimiento:
_ Los Servicios Agnósticos bien diseñados son reutilizables & por lo tanto, están sujetos
a un mayor uso en simultáneo (reutilización).
_ Los Servicios Agnósticos contienen lógica de procesamiento genérica
que se utiliza al momento de su consumo más en
(común),
runtime.
_ El manejo de la implementación de: clustering & reintentos, pueden ser usados para
garantizar el rendimiento & garantía durante los períodos de alta uso concurrente.
_ Es importante saber que durante un intercambio de datos entre servicios se introduce un
nivel de gastos generales de procesamiento (a más interacciones más consumo),
esto al combinarse varios Servicios en Composiciones
_ El rendimiento es una de las principales
consideraciones para MicroServicios.
_ Las tecnologías modernas como la
Contenedorización, son utilizadas para
soportar requisitos de alto rendimiento.
_ Un MicroServicio implementado en un
Contenedor, incluye otros recursos de
los que dependen los MicroServicios
(todos soportados a nivel del
Contenedor).
_ La inclusión de recursos de TI
dependientes dentro del contenedor
favorece el principio de Autonomía en el
MicroServicio & permite un mejor
rendimiento.
_ T
odos los entornos tendrán limites de procesamiento finitos (recursos de TI), que
imponen límites de rendimiento a los proyectos SOA.
_ Un objetivo clave en cualquier plan de adopción SOA, es identificar las limitaciones de
rendimiento en los entornos ‘por adelantado’& luego plantear posibles soluciones.
_ Normalmente los parámetros de rendimiento de los Servicios son formalmente definidos en los
SLA.
133 134
135 136

3/04/2023
35
_ Las preocupaciones de Seguridad incluyen un inicio de sesión único & la administración de
identidad federada.
_ Estas capacidades facilitan un rendimiento más eficiente de Composiciones de Servicio
Complejas y flujos de servicio minimizando el número de llamadas de autenticación &
autorización que se requieren.
_ Una vez que los Servicios asumen una mayor cantidad de responsabilidad de procesamiento,
surge la necesidad de aplicar medidas de Seguridad a nivel en la Capa de Mensajes,
así como en el Control de Seguridad en los Servicios Compartidos.
_ El marco de trabajo WS-Security provee extensiones que pueden ser utilizados para
implementar seguridad a nivel de la ‘capa de mensajes’.
_ Esto permite proteger el contenido de los mensajes durante el transporte & el procesamiento
que se va a nivel de los Servicios Intermediarios.
F. Consideraciones de Seguridad:
_ La seguridad en la capa de
es
transporte (SSL)
‘normalmente’
cuando existen
insuficiente
Servicios
Intermediarios que están
involucrados. Esto debido a que
el mensaje mientras que está
siendo procesado por dichos
Servicios Intermediarios
no está protegido tal como
se muestra en imagen.
_ La seguridad que brinda
WS-Security funciona
teniendo como base XML-
Signature & XML-Encryption,
esto para garantizar la
integridad de los mensajes
(incluyendo cuando están
siendo procesados por los
Servicios Intermediarios), la
autenticidad (persona) & la
confidencialidad.
_ “El XML-Signature & XML-
Encryption, ambas son
W3C que definen
sintaxis XML para
recomendaciones de la
una
la
firma digital & para el cifrado
de datos”.
_ Todas las consideraciones previamente mencionadas afectan la infraestructura requerida,
para la implementación de soluciones de Arquitectura Orientada a Servicios.
Las áreas de impacto incluyen:
*. Encapsulación de Legacy.
*. Orquestación.
*. Confiabilidad.
*. Control de fallas.
*. Disponibilidad.
*. MicroServicios & Contenerización.
G. Consideraciones de Infraestructura:
137 138
139 140

3/04/2023
36
G. Consideraciones de Infraestructura:
_ Al estudiar la implementación
de arquitecturas
Composiciones
de tipo:
de Servicios,
los impactos relacionados con la
infraestructura se vuelven más
evidentes, especialmente cuando se
trata de: encapsulación legacy.
_ “En la imagen se aprecia como el
principio de Autonomía del Servicio
es aplicado en diferentes niveles”.
_ Es importante conocer que SOA a nivel la industria, no está definido y/o asociada a ningún
proveedor (vendor).
_ En apoyo a los Objetivos Estratégicos de: diversificación de proveedores &
el
agilidad organizacional,
modelo de arquitectura,
es importante
el paradigma
mantener una separación clara entre
de diseño & las opciones de tecnología
para la implementación.
_ Las áreas que actualmente
plataformas de gobierno, seguridad & procesamiento de altos volúmenes de
continúan madurando, incluyen en su manejo:
datos.
_ Las campañas de marketing de proveedores (Vendors) han sido responsables de cierta
confusión. Afectando, que la palabra de SOA ha sido incorrectamente relaciona
a productos de tecnología,cuando SOA en si está relacionado al negocio.
_ Debido a ello para evaluar mejor la capacidad de los productos & tecnología disponibles,
es requerido ignorar la palabra SOA. Debiendo considerar la Orientación del Servicio &
los requisitos de la empresa son los criterios fundamentales
H. Consideraciones de Madurez:
_ Un plan de transición SOA permite coordinar una incorporación controlada
Orientación del Servicio, para que la
de la
migración se pueda planificar a nivel de:
tecnología, arquitectura & organización.
_ Se debe establecer un Repositorio Central para controlar todos los documentos & artefactos
relacionados a los Servicios (durante el ciclo de vida).
_ Los planes de transición SOA intentan equilibrar los requisitos: tácticos, con el logro de los
Objetivos Estratégicos de la Computación Orientada a Servicios.
_ Un plan de transición SOA típico debe de incluir:
*. Visión empresarial organizacional.
*. Análisis de impacto.
*. Estrategias de transición.
*. Estimación de alcance de ‘Inventario e Servicios’(crecimiento).
_ Una vez se tienen definidos cada uno de los puntos anteriores, se puede tener una idea
de qué tan grande será el proyecto. .
I. Consideraciones de Migración:
PREGUNTAS
141 142
143 144

1. Capacitacion_ SOA MDC 4pp.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a 1. Capacitacion_ SOA MDC 4pp.pdf

Similar a 1. Capacitacion_ SOA MDC 4pp.pdf (20)

Último

Último (20)

1. Capacitacion_ SOA MDC 4pp.pdf