Nombre:

Leonel Rafael Bermúdez Reyes

Curso:

5 Desarrollo de software

Sección:

Docente:

Antonio Joffre Baque Solís

Periodo Lectivo:

2020-2021

Contenido
1.- Realizar las diferencias entre SOA y SOAP........................................................................3
SOA: Service Oriented Architecture....................................................................................3
 SOAP: Simple Object Access Protocol.................................................................................4
2.- Investigar las diferentes aplicaciones (¿Cómo se aplican estas herramientas?)...............5
Jenkins....................................................................................................................................5
SonarQube..............................................................................................................................6
3.- 20 Ejemplos de SOAP...........................................................................................................7
Ejemplo 1:...............................................................................................................................7
Ejemplo 2:...............................................................................................................................7
Ejemplo 3:...............................................................................................................................7
Ejemplo 4:...............................................................................................................................8
Ejemplo 5:...............................................................................................................................8
Ejemplo 6:...............................................................................................................................9
Ejemplo 7:...............................................................................................................................9
Ejemplo 8:...............................................................................................................................9
Ejemplo 9:...............................................................................................................................9
Ejemplo 10:...........................................................................................................................10
Ejemplo 11:...........................................................................................................................10
Ejemplo 12:...........................................................................................................................10
Ejemplo 13:...........................................................................................................................11
Ejemplo 14:...........................................................................................................................11
Ejemplo 15:...........................................................................................................................12
Ejemplo 16:...........................................................................................................................12
Ejemplo 17:...........................................................................................................................12
Ejemplo 18:...........................................................................................................................12
Ejemplo 19:...........................................................................................................................13
Ejemplo 20:...........................................................................................................................13
4. - ¿Cómo puede aplicar estos en sus proyectos anteriores?................................................13
Bibliografía................................................................................................................................14

1.- Realizar las diferencias entre SOA y SOAP.

En el mundo de la integración orientada a servicios en ocasiones es fácil equivocarse
cuando estamos hablando y confundir SOA con SOAP. En un principio, se trata de acrónimos
muy parecidos pero que en la realidad se trata de cosas diferentes.
 Con esta breve entrada, podremos ver la diferencia entre ambos. Sabremos así distinguir
entre un paradigma de arquitectura orientada a servicios y una tipología de mensaje.

SOA: Service Oriented Architecture

Pero, realmente qué es esto de SOA. Según el manifiesto original de SOA que podemos
encontrar en serviceorientation.com se trata de:

La Orientación a Servicios es un paradigma que enmarca lo que usted hace.

La Arquitectura Orientada a Servicios (SOA) es un tipo de arquitectura

que resulta de aplicar la orientación a servicios.

En un primer momento, se definieron 8 principios básicos de que debería cumplir SOA.

Posteriormente, con la evolución de los servicios, se añadió la “interoperabilidad” como un
nuevo principio:

Contratos de servicio estandarizados: para que los servicios interactúen entre ellos, estos
deben de hacerlo mediante un contrato formal que describa cada servicio y defina los términos
en los que será entregada la información

Servicios con bajo acoplamiento: los servicios deben ser diseñados para interactuar
entre ellos de forma autónoma, evitando dependencias entre los mismos

Abstracción: contarán con una parte visible del servicio y su contrato. De esta forma,
los consumidores del servicio, se abstraerán de la lógica del servicio y la tecnología utilizada en
el mismo

Reusabilidad: todos los servicios deben ser diseñados para el soporte potencial de la
reutilización de lógicas de negocio existentes. El fin de éstos servicios no es sustituir a las
mismas

Autonomía: la lógica del servicio debe ser autónoma y no tener dependencia de la

lógica de otros servicios. Un servicio debe poder ser ejecutado de manera independiente

Sin estado: los servicios deben ser diseñados para maximizar el bajo acoplamiento y su
escalabilidad. El manejo del estado en los mismos podría impedir estas características

Capacidad de descubrimiento: los servicios deben contener descripciones para ser

descubiertos y entendidos por humanos y los consumidores del servicio, permitiéndoles emplear
la lógica descrita en los mismos
 Composición: los servicios podrían estar a su vez compuestos por otros servicios. De
esta manera se podrían definir diferentes modelos granulares de servicio. Permitiría de esta
forma capas de abstracción de servicios por medio de la agrupación a alto nivel de servicios
complejos a bajo nivel

Interoperabilidad: se trata de la capacidad de poder orquestar servicios para que

trabajen entre sí. La falta de alguno de los principios anteriores, repercutiría definitivamente en
este último, haciendo imposible el mismo

SOAP: Simple Object Access Protocol

En la misma página que indicaba antes, podéis encontrar una referencia a las
especificaciones de tecnología de los servicios o “Service Technology Specs” y dento de “WS-*
Specs” encontramos (entre otros) la siguiente definición de SOAP:

Aunque originalmente se concibió como una tecnología para salvar la brecha entre las
distintas plataformas de comunicación basadas en RPC*, SOAP ha evolucionado hasta
convertirse en el formato de mensajería más compatible con el protocolo para su uso con
servicios Web XML.

La especificación SOAP establece un formato de mensaje estándar que consiste en un

documento XML capaz de alojar RPC y datos centrados en documentos. Esto facilita los
modelos de intercambio de datos síncronos (petición y respuesta) así como asíncronos
(impulsados por el proceso). Con WSDL estableciendo un formato de descripción de punto final
estándar para aplicaciones, el formato de mensaje centrado en documentos es mucho más
común.

Al igual que ocurre con SOA, SOAP también consta de 3 características principales,
que son las que definen el prototipo del mensaje:

Extensibilidad: por medio de la aplicación de seguridad y WS-routing aplicables en el

desarrollo

Neutralidad: para ser utilizado sobre múltiples protocolos de transporte como HTTP,
SMT, JMS o TCP

Independencia: permitiendo la abstracción de la tecnología, para aplicar cualquier

modelo de programación

Dentro del sitio W3C, podemos consultar las dos versiones de especificación existentes:
SOAP 1.1 y SOAP 1.2
 Ejemplo de este tipo de servicios serían los denominados JAX-WS – Java API for
XML-based Web Services (usando WSLD/SOAP)

Visto todo lo anterior, podríamos resumir diciendo que SOA es un paradigma de

arquitectura orientada a servicios que permite entre otros, el uso de SOAP, como forma de
mensajería de la misma.

2.- Investigar las diferentes aplicaciones (¿Cómo se aplican estas herramientas?)

Jenkins
Jenkins es un aplicativo para la automatización del proceso completo de desarrollo de software,
con tareas comunes como la integración continua, pero sobretodo potenciando los equipos para
implementar la parte técnica de la entrega continua.

esto viene a decir que disponemos de un software que nos permite automatizar los procesos de
despliegue, la actualización de entornos, revisión de calidad de código y testing. Esto finalmente
se traduce en entregas periódicas a cliente, en tiempo y forma con resultados que garantizan un
producto funcional y listo para su explotación.

Jenkins debe su potencial a su amplio y versátil sistema de plugins que nos permiten realizar
diferentes conjuntos de acciones, que permiten modularizar y extender la funcionalidad.

Como servidor de automatización, Jenkins permite que una máquina realice numerosas tareas a
las que los humanos destinamos demasiado tiempo en demasiadas ocasiones. Para esto,
encontramos en Jenkins centenas de plugins hechos por la comunidad, que se pueden integrar en
varias etapas del proceso de desarrollo. Aunque podríamos hacer con él todo tipo de tareas
automáticas, Jenkins se suele usar perfectamente como servidor de integración continua. Escrito
en Java y accesible mediante interfaz web, Jenkins es multiplataforma y se ha consolidado
últimamente como una de las herramientas más usadas en la actualidad para realizar las tareas
de integración continua.

Los desarrolladores y gestores de proyecto saben que llevar a producción un software o una
nueva versión es una tarea delicada. Para que sea posible, es fundamental contar con algún
sistema de automatización, que sea capaz de construir el software, o desplegarlo en servidores,
pero que sólo permita esa puesta en producción cuando el software ha sido probado
convenientemente.

En este punto es donde entra Jenkins, como sistema de automatización, capaz de realizar cientos
de tareas necesarias para asegurar la calidad del software y facilitar su despliegue o
construcción. Algunas de las tareas más habituales que Jenkins es capaz de hacer son las
siguientes:

 Testar el software.
 Revisar las métricas de calidad del software establecidas por el equipo de trabajo.
 Enviar las modificaciones del software, una vez pasadas todas las validaciones, al
repositorio principal.
 Automatizar la compilación del software o su despliegue, una vez se hayan integrado
nuevos cambios en el proyecto.
 Notificar debidamente a los desarrolladores o al equipo de aseguramiento de la calidad
cuando se encuentra cualquier tipo de error, ya sea en base a las pruebas del software o
a las métricas de calidad definidas.
 Generar o visualizar la documentación de un proyecto

Como servidor de automatización, además, Jenkins es capaz de extender sus funcionalidades

con centenares de plugins para realizar un sin fin de tareas útiles

SonarQube
SonarQube es una plataforma de código abierto que se usa principalmente para realizar un
análisis estático del código fuente. Además, cabe destacar que, aunque inicialmente la
herramienta estaba pensada para proyectos Java, se ha ampliado de forma que acepte
extensiones para otros lenguajes.

El análisis estático de código es aquel que se realiza sin ejecutar el software, es decir, evaluando
el código fuente, de forma que podamos obtener información y métricas para mejorar nuestro
código detectando errores lo más temprano posible, algo que Scrum –la metodología base con la
que Solid Gear trabaja- también aconseja.

Sin embargo, para el análisis dinámico necesitamos ejecutar el software para poder comprobar
su comportamiento en tiempo de ejecución. Además, para el análisis dinámico necesitamos ser
especialmente cautos y contar con los suficientes casos de prueba -que nos ayudarán a asegurar
que una porción de código ha sido comprobada y observada- como para que el comportamiento
que probamos sea lo suficientemente relevante como para dar nuestro OK al código.
3.- 20 Ejemplos de SOAP
Ejemplo 1:
Un ejemplo de aplicación orientada a servicios podría ser una aplicación B2B de una gran
empresa de la automoción (fabricante de vehículos) que ofrece sus productos con la información
y las posibilidades de personalización de cada uno. Por otro lado, un concesionario multimarca,
que puede vender vehículos de diferentes fabricantes o marcas, puede disponer de una
aplicación web que muestre a sus clientes (B2C), con la identidad corporativa del concesionario,
la información de los vehículos (de las diferentes marcas) con las opciones de personalización.
La aplicación del concesionario accederá a los servicios que ofrece la aplicación B2B del
fabricante (u otros fabricantes) para obtener la información de los vehículos, que posteriormente
será presentada a los usuarios con el valor añadido que ofrecen los concesionarios. La figura 1
muestra este escenario.

Ejemplo 2:
resultaría complejo introducir el simulador de terremotos mencionado anteriormente en uno de
los LMSs actuales. Estas limitaciones, que pueden ser descritas como deficiencias de
adaptabilidad y de extensibilidad, están limitando el desarrollo y la usabilidad de los LMSs.
Estas deficiencias han sido identificadas como las principales carencias en los LMSs actuales, y
algunas soluciones han sido propuestas, pero con un éxito limitado. Por ejemplo, Moodle y
Blackboard tienen la capacidad de extender sus funcionalidades mediante las llamadas
“extensiones”. No obstante, estos sistemas son diseñados primeramente como sistemas
monolíticos, con la integración de herramientas externas considerada como un suplemento. Por
ello, es posible incluir una nueva herramienta en Moodle o Blackboard, pero esto no es una
verdadera integración. Además, el LMS carece de formas de monitorizar y controlar la forma en
que los usuarios trabajan con las herramientas. Este es el caso, por ejemplo, cuando se quiere
hacer un seguimiento de las actividades de los estudiantes.

Ejemplo 3:
En un proceso de compra de un producto o servicio, las funciones de cálculo de impuestos o
comisiones asociadas y la facturación y emisión del comprobante de compra forman parte del
mismo bloque. Gracias a estos sistemas, se ha logrado una mejora considerable en la
productividad de las empresas automatizando procesos de negocio, sin embargo, la concepción
monolítica de estos, hace que los cambios y adaptaciones tiendan a ser más lentas y costosas de
lo deseable. En muchas organizaciones, este tipo de situaciones provoca que los sistemas
avancen detrás de las necesidades de negocio. Para conseguir mayor agilidad, se hace necesaria
la capacidad de poder cambiar de forma rápida los distintos componentes de los sistemas,
necesidad que tiene muchas restricciones en la concepción monolítica tradicional. En el
desarrollo de este proyecto se describirá cómo la arquitectura SOA separa los procesos de
negocio de las funciones automatizadas y organiza estas últimas en módulos individuales
catalogados en un diccionario de servicios que permite su utilización por parte de toda una
organización. En la actualidad han sido pocos los avances tecnológicos que han despertado
tanto interés como la arquitectura SOA. Es de vital importancia comprender exactamente el
papel que ésta puede desempeñar a la hora de ayudar a las empresas a alcanzar un alto
rendimiento. A menudo se suele caer en la tentación de considerar los nuevos avances (por
ejemplo, la arquitectura SOA) como la “varita mágica” que permitirá mejorar el funcionamiento
de la empresa. Las nuevas tecnologías tienden a ser objeto de este tipo de planteamientos, pero
frecuentemente el resultado es decepcionante. La arquitectura SOA trata de estructurar las
aplicaciones de negocio y la tecnología para responder de forma ágil y flexible a las demandas
del mercado. Es la base que garantiza la agilidad de un negocio, que hoy por hoy es un
prerrequisito para alcanzar el éxito en un mercado globalizado y competitivo. Esta agilidad es la
capacidad de añadir, modificar y optimizar fácilmente los procesos de negocio, aprovechando la
sinergia que ocurre entre los servicios y procesos. El fin es contar con nuevas capacidades
mediante la combinación de alguno de los elementos o servicios de los procesos de negocio
actuales, que permitan dar soporte a nuevos segmentos de clientes, canales o mercados.

Ejemplo 4:
Los diferentes tipos de relaciones: con clientes, con proveedores y/o partners, así como
relaciones internas (Comunidades de jefes de proyectos, de consultores, de comerciales y/o
responsables de marketing,) que utilizan estos medios colaborativos aprendiendo tanto de
experiencias de éxito o best practices, como de experiencias negativas o lessons learned,
beneficiándose del conocimiento y experiencia de otros con anterioridad. Ambos conceptos;
"web 2.0" y "trabajo en red" van de la mano y se complementan perfectamente, siendo difícil,
que uno pueda evolucionar rápidamente sin el desarrollo del otro.

Ejemplo 5:
Los servicios ofrecen la flexibilidad requerida por las organizaciones modernas, en las que el
cambio y la continua evolución son características primordiales. Esta evolución requiere la toma
de decisiones arquitecturales las cuales deben garantizar y controlar la evolución coherente de la
SOA. Para esto es necesario definir e implementar un modelo de gobierno SOA. En esta
propuesta, presentamos una estrategia basada en la Ingeniería Dirigida por Modelos (MDE),
para apoyar la gobernabilidad de la arquitectura, permitiendo definir políticas de gobierno SOA
y evaluar si estas políticas se cumplen o no en la arquitectura de solución.
Ejemplo 6:
El apoyo que brindan las tecnologías de información a las empresas representa una fuente de
ventaja competitiva y permite a las organizaciones optimizar sus procesos, mejorando tanto el
desempeño interno como la entrega de calidad al cliente. En Colombia, surge la in-quietud de
mostrar cómo las PYMES podrían hacer uso de herramientas libres para lograr reducir costos de
licenciamiento y desarrollo invertidos en la creación de TI que soporte sus procesos de negocio
bajo una filosofía BPM SOA. Éste trabajo de grado ilustra la experiencia y el desarrollo que se
realizó al respecto para solucionar esta inquietud, aportando una guía práctica que ilustra cómo
implantar con herramientas libres un ejemplo de proceso de negocio a partir de su modelaje.

Ejemplo 7:
Servicios que se pueden enumerar dentro del mundo real son: la localización de la información
de facturación para un paciente, solicitud de transacciones recientes de una cuenta financiera,
identificación del propietario de un vehículo registrado, o solicitud de una lista de vuelos
disponibles para un determinado destino.

Ejemplo 8:
En este marco, los servicios pueden compartirse y reutilizarse en varios procesos de negocio. El
resultado es un entorno altamente adaptable, con menores costos para el desarrollo de
aplicaciones, mejoras en la integración y despliegue rápido.

Un error común es creer que una SOA es una nueva versión de los Web Services. SOA define
un modelo para la ejecución de un determinado proceso.

Los Web Services, por otra parte, pueden facilitar la aplicación táctica del modelo SOA. Así, los
Web Services son sólo una de las maneras en que puede construirse una SOA.

Ejemplo 9:
Posteriormente se expondrá el diseño arquitectónico con que cuentan los organismos
informáticos gubernamentales encargados de procesar las aplicaciones mencionadas
anteriormente y con posterioridad se desarrollará una propuesta de utilización de Servicios Web
SOAP/REST, particularizada para el proceso centralizado de liquidación de haberes, por
ejemplo, a nivel provincial.

Es importante señalar que la arquitectura de software propuesta puede ser extendida a cualquier
solución tecnológica que se encuentre en producción en los sistemas informáticos de los
distintos organismos públicos, independientemente del nivel jurisdiccional al que pertenezca;
municipal, provincial o nacional.
Ejemplo 10:
Posteriormente se expondrá el diseño arquitectónico con que cuentan los organismos
informáticos gubernamentales encargados de procesar las aplicaciones mencionadas
anteriormente y con posterioridad se desarrollará una propuesta de utilización de Servicios Web
SOAP/REST, particularizada para el proceso centralizado de liquidación de haberes, por
ejemplo, a nivel provincial.

Es importante señalar que la arquitectura de software propuesta puede ser extendida a cualquier
solución tecnológica que se encuentre en producción en los sistemas informáticos de los
distintos organismos públicos, independientemente del nivel jurisdiccional al que pertenezca;
municipal, provincial o nacional.

Ejemplo 11:
Una organización puede tener la necesidad de conocer rápidamente los costos de los
artículos que le suministra determinada empresa proveedora, por su parte la empresa proveedora
puede ofrecerle un servicio que le brinda la capacidad de consultar esta información a través de
una página de internet. Sin embargo, no existe necesariamente una correlación uno a uno entre
las necesidades y capacidades; de manera que para satisfacer determinada necesidad puede ser
necesario combinar múltiples capacidades, mientras que una capacidad puede abarcar más de
una necesidad. Esto genera una gran complejidad, el gran aporte que ofrece SOA como
propuesta arquitectural es que proporciona un marco bajo el cual es posible combinar las
capacidades ofrecidas para hacer frente a las necesidades de un negocio promoviendo la
reutilización e interoperabilidad de las capacidades. Tanto en la industria como en la academia
se encuentran distintos enfoques para describir una SOA. En este trabajo hemos decidido usar
como referencia el marco de modelamiento orientado a servicios SOMF (Service Oriented
Modeling Framework)

Ejemplo 12:
La implementación redundante de servicios lo que genera un crecimiento desordenado de la
arquitectura y disminuye la posibilidad de reutilizar los servicios existentes [6], o la interrupción
de procesos de negocio cuando se realizan cambios en los servicios, sin considerar todos y cada
uno de los procesos de negocio que hacen uso de este servicio [7]. Las consecuencias de este
tipo de situaciones pueden ir desde el incumplimiento en los acuerdos de nivel de servicio, hasta
el abandono de la implementación de la arquitectura por que se pierde la credibilidad en el
paradigma orientado a servicios. El costo de implementar una decisión arquitectural que tiene
un impacto negativo, se incrementa a medida que se avanza en el ciclo de vida de los servicios.
Por esta razón se hace necesario contar con un modelo de gobierno SOA que permita
administrar cada uno de los servicios, su ciclo de vida y como éstos se relacionan con sus
consumidores en la ejecución de los procesos de negocio, para lograr una arquitectura sólida,
confiable, segura y escalable. Pensando en apoyar a las organizaciones en hacer frente a esta
problemática en la gobernabilidad de sus arquitecturas SOA, presentamos una estrategia
dirigida por modelos (MDE), que apoya la definición de políticas de gobierno SOA y la
evaluación de su cumplimiento en la arquitectura.

Ejemplo 13:
La integración de equipamiento y dispositivos en células robotizadas industriales con
tecnologías de interfaz de Ethernet y dispositivos de bajo coste como sistemas de visión,
cámaras láser, sensores de fuerza, autómatas programables, PDAs, etc. permite el desarrollo de
soluciones potentes e inteligentes. Sin embargo, la programación eficiente de todos estos
dispositivos requiere conocimientos muy específicos sobre estos equipos, sus arquitecturas
hardware, lenguajes de programación dedicados y detalles sobre protocolos de bajo nivel de
comunicación de sistemas.

El artículo describe y utiliza una de las arquitecturas orientadas a servicios más interesante y
que mejor se adapta a las células robotizadas: la arquitectura Universal Plug-and-Play.
Utilizando esta arquitectura en el artículo se ha desarrollado un banco de pruebas basado en dos
robots industriales. Los resultados obtenidos muestran claramente que la utilización de
esquemas integrados basados en arquitecturas SOA reduce los tiempos de integración,
adaptándose muy bien a la integración de células robotizadas industriales.

Ejemplo 14:
Una arquitectura como SOA está en capacidad de involucrar diferentes tecnologías y representa
mejor la integración de las mismas. SOA define las funciones como servicios independientes,
que poseen interfaces bien definidas. Los componentes de esta definición son: • Todas las
funciones son definidas como servicios. Estas están compuestas por tres tipos de funciones que
son las funciones puramente de negocios (Ej. Crear una Orden), las transacciones de negocios
compuestas de funciones de más bajo nivel (Ej. Obtener historia crediticia) y las funciones de
servicios del sistema (Ej. Validar identificación). • Todos los servicios son independientes. Lo
único que interesa entre componentes es que cada servicio entregue los datos que necesita otro
para poder realizar operaciones. • Las interfaces son invocables, dejando a un lado cualquier
diferencia entre protocolos de comunicación, arquitectura, etc. Lo importantes es que respondan
a los llamados de peticiones de servicios.

Ejemplo 15:
SOAP permite que las aplicaciones se ejecuten en diferentes sistemas operativos e
implementados con diferentes plataformas de tecnología y lenguajes de programación, para
comunicarse con los demás, SOAP tiene dos propiedades fundamentales: puede enviar y recibir
HTTP (u otro) transportar paquetes de protocolo y procesar los mensajes XML. Una meta
importante de SOAP es ser extensible con características incluyendo los patrones de
intercambio de confiabilidad, seguridad, enrutamiento y mensaje. Las WS-Extensions pueden
utilizarse para añadir más características en los mensajes SOAP. REST (Representation State
Transfer) es una tecnología que puede utilizarse para construir servicios web en lugar de SOAP.

Ejemplo 16:
Permite la construcción de sistemas distribuidos débilmente acoplados, lo que ayuda en la
integración de sistemas los heterogéneos que intervienen en los ITS. En este artículo
proponemos crear un modelo basado en servicios que facilite la integración y el
aprovechamiento de las Tecnologías de la Información en el ámbito de la prestación de
servicios de valor agregado en los ITS. De esta forma se propicia la necesaria especialización de
los fabricantes, la fácil incorporación de nuevas tecnologías, la interoperabilidad de los sistemas
y los servicios existentes y la creación de nuevos modelos de negocio. Para comprobar la
validez de nuestro modelo hemos desarrollado un caso de estudio que involucra uno de los
principales servicios que atienden los ITS (Sistemas de gestión de aparcamientos).

Ejemplo 17:
Una aplicación escrita en Java reciba información generada por otra aplicación realizada con C+
+, PHP o cualquier otro lenguaje de programación.

Debido al auge de estas tecnologías en el mundo empresarial se proyectó la realización del

curso “Web 2.0: Arquitectura Orientada a Servicios en Java”, organizado por la Escuela de
Posgrado de la Universidad de Granada, para familiarizar a los estudiantes de carreras técnicas
(sobre todo los de Ingeniería en Informática o Telecomunicación), en estas tecnologías, ya que
no están presentes en el plan de estudios de la Universidad de Granada.

Ejemplo 18:
Los servicios son funcionalidades concretas que pueden ser descubiertas en internet, y que
ejecutan tareas que van desde la realización de una operación matemática simple, hasta otras
más complejas, como, por ejemplo, la consulta o modificación de información de clientes en
una base de datos. Aunque no necesariamente se deben implantar servicios Web en el camino
hacia la adopción de una solución de diseño basada en SOA, sin duda alguna, ésta es la
implementación más habitual y madura de éste modelo arquitectónico.

Ejemplo 19:
Un ejemplo típico de arquitectura SOA son los Web Services (Servicios Web) que proporcionan
una interfaz de acceso a un servicio escondiendo las particularidades de dicho servicio de modo
que sea accesible desde cualquier tipo de cliente a través de protocolos estándar. El presente
documento contiene la investigación base de la Arquitectura de Software Orientada a Servicios
(SOA), entregando sus características, ventajas y componentes principales, así como la
evolución que da origen a su utilización como plataforma que soporta las Tecnologías de
Información dentro de las grandes empresas

Ejemplo 20:
Una empresa de viajes sería importante tener la información actualizada sobre los autos
arrendados junto con las reservaciones de una línea aérea y del hotel. En otros casos, pudieran
ser necesarios los últimos datos sobre los precios comunes de un cierto tipo de producto. En
todos estos escenarios, si los datos necesitan estar altamente disponibles, se necesita desplegar
la arquitectura de procesos distribuidos en un hardware y software altamente disponibles.

4. - ¿Cómo puede aplicar estos en sus proyectos anteriores?

Una arquitectura SOA concreta será el producto de aplicar la arquitectura de referencia
desarrollada según el modelo de referencia y los patrones de esa arquitectura, así como los
requerimientos necesarios, incluyendo los impuestos por los entornos tecnológicos.

La aplicación de un modelo de referencia para lograr una arquitectura completa, equivale a

pasar de una etapa de análisis a una de diseño en analogía con las etapas del ciclo de vida del
software. Implica dar un paso más en el nivel de detalle y comenzar a buscar metodologías para
aplicar sobre los conceptos analizados.

Una arquitectura concreta se desarrolla en un contexto predefinido donde se fijan protocolos,

perfiles, especificaciones y estándares. La plataforma SOA combina estos elementos a los
efectos de generar un producto operativo.
Bibliografía
Alarcón, R. C. (2011). Implementación de arquitectura SOA y SOA governance en una empresa
de servicios financieros. Obtenido de Universidad Mayor para espiritus emprendedores:
http://repositorio.umayor.cl/xmlui/handle/sibum/163

Bazan, P. (2009). Un modelo de integrabilidad con SOA y BPM. Obtenido de Repositorio

Institucional de la UNLP: http://sedici.unlp.edu.ar/handle/10915/4181

Bocchio, F. (2013). Estudio Comparativo de Plataformas Cloud Computing para Arquitecturas

SOA. Obtenido de Revista Latinoamericana de Ingenieria de Software:
http://revistas.unla.edu.ar/software/article/view/107

Cámara, J. (2008). Recomendaciones para la adopción de SOA. Obtenido de Software AG

España, S.A: https://www.isa.us.es/downloads/proceedings/0212.pdf

Casasola Girón, N. E. (2019). Diseño de un modelo de integración continua utilizando Jenkins

para proyectos de desarrollo en una empresa de telecomunicaciones para el módulo de
contabilidad. Obtenido de Repositorio del sistema Bibliotecario de la Universidad San
Carlos de Guatemala: http://biblioteca.ingenieria.usac.edu.gt

González, F. (1987). Driver para un gobierno 2.0. Obtenido de astic.es:

https://www.astic.es/sites/default/files/articulosboletic/tecno_1_6.pdf

Gonzalez, J. F. (2009). Congreso Iberoamericano de Telemática. Obtenido de researchgate:

https://www.researchgate.net/profile/Manuel_Caeiro_Rodriguez/publication/
233855962_Una_Arquitectura_SOA_para_sistemas_de_e-
Learning_a_traves_de_la_integracion_de_Web_Services/links/
54187e930cf203f155adafb2.pdf

Melgarejo, R. (2011). Modelado e implementación de un proceso de negocio BPM mediante

herramientas SOA de software libre. Obtenido de Pontifica Universidad Javeriana:
https://repository.javeriana.edu.co/handle/10554/7546

Ortega, D. (2011). Estrategia dirigida por modelo para el gobierno SOA. Obtenido de
Universidad Nacional de Colombia:
https://revistas.unal.edu.co/index.php/avances/article/view/26728

Ospina Delgado, J. P. (2015). Análisis de seguridad y calidad de aplicaciones. Obtenido de

Universitat Oberta de Catalunya: http://hdl.handle.net/10609/43263
Tobar, M. B. (2015). Un marco de trabajo para la migración de aplicaciones SOA a Cloud
siguiendo una aproximación dirigida por modelos . Obtenido de Universidad
politecnica de Valencia: https://scholar.google.es/scholar?
start=10&q=ejemplos+soa&hl=es&as_sdt=0,5

Torres, D. (09 de 05 de 2017). Obtenido de Wordpress:

https://innova20.wordpress.com/2017/05/09/soa-y-soap-no-es-lo-mismo/