Arquitectura orientado a Servicios

La forma más sencilla de entender qué es SOA es imaginando un patrón de

arquitectura de software, cuyos componentes de aplicación proporcionan servicios a otros
componentes

Cuando escuchamos SOA no sabemos a qué se refieren las siglas, los que las
entendemos sabemos que estas siglas se refieren a una Arquitectura Orientada a Servicios.

Pero, ¿Qué es una Arquitectura Orientada a Servicios? Es un concepto que define la

organización de las interfases de acceso a los datos, ordenadas en un modelo de madurez
que permite administrarlas y gobernarlas adecuadamente, esto para mejorar la eficiencia
del servicio en la disponibilidad de los datos para los procesos y transacciones operativas
en los negocios.

Al escuchar, por primera vez, este tipo de definiciones quizás se nos hace un poco
difícil comprender ¿Cómo la aplicamos en nuestra vida cotidiana? Por ello quisiera
compartir con ustedes cuáles son algunos de los ejemplos de la vida diaria, en donde la
Arquitectura SOA participa y es indispensable para garantizar el oportuno nivel de respuesta
para agilizar el proceso de validación de datos en cada caso.

Ejemplo de uso de SOA:

1.- Cuando utilizamos nuestra tarjeta de débito para sacar dinero en el cajero automático.
1. La identidad del usuario es validada por la institución bancaria a través de un NIP
contra el Chip de seguridad de la tarjeta.
2. Una vez aceptada la identidad la transacción consulta el saldo de la cuenta para
verificar los fondos.
3. El servicio de información actualiza el saldo y confirma la transacción al cajero.
4. El cajero automático dispensa el dinero y emite un recibo de la transacción.

2.- Cuando utilizamos nuestra tarjeta de crédito en algún establecimiento para adquirir
bienes o servicios.
3.- Cuando utilizamos nuestro teléfono y el consumo de tiempo utilizado es facturado
automáticamente en nuestro plan en tiempo real.
4.- Cuando pasamos por migración y se verifican nuestro datos contra los millones de
registros de bases de datos de incidencia delictiva.

Estas operaciones deben realizarse en lapsos de centésimas de segundo, aun

cuando se procesen billones de transacciones en todo el mundo cada segundo, es por ello
que los operadores de este tipo de transacciones requieren de una Arquitectura de Software
que permita alcanzar estos niveles de rendimiento y respuesta para asegurar al usuario una
respuesta aceptable.

Lea también: Procesos de negocio: La nueva era de la planificación empresarial.

Sin una Arquitectura Orientada a Servicios esto no podría ser posible.
 También existe en nuestra vida diaria Arquitecturas de Software que han
evolucionado del concepto de SOA, tales como los Microservicios, los cuales permiten
asegurar la confiabilidad y consistencia de operación de aplicaciones como Netflix, Amazon,
Uber y algunas otra más.

Los Microservicios representan el desacoplamiento de los servicios complejos en la

estructura de las aplicaciones. Para optimizar la publicación, ejecución y proceso de
Microservicios en diversos ambientes de virtualización, se debe asegurar la consistencia en
el nivel de respuesta de la aplicación desde cualquier dispositivo fijo o móvil conectado a
Internet.

Gracias a esta Arquitectura de Microservicios es posible que existan aplicaciones tan

eficientes y robustas que pueden funcionar en diferentes partes del mundo y que son
ejecutadas desde diferentes sistemas operativos en los Smartphones o equipos de
cómputo.

Cada vez que solicitamos un servicio de taxi ya sea por Uber o algún servicio similar,
estamos haciendo uso tanto de SOA como de Microservicios, aplicados a nuestra vida
diaria.

Sin Microservicios nuestra vida diaria sería muy distinta.

La arquitectura orientada a servicios y sus ventajas

para el negocio
SOA es un estilo arquitectónico para la construcción de aplicaciones de software en
base a servicios disponibles. Entre sus principales características destacan:

● Su flexibilidad, que permite la reutilización.

● Su versatilidad, que hace posible que los servicios puedan ser consumidos por los
clientes en aplicaciones o procesos de negocio distintos.

● Sus posibilidades, que optimizan el trabajo con datos y su coordinación.

SOA permite la reutilización de activos existentes para nuevos servicios que se pueden
crear a partir de una infraestructura de TI que ya se había diseñado. De esta forma, permite
a las empresas optimizar la inversión por medio de la reutilización que, además, conlleva
otra ventaja: la interoperabilidad entre las aplicaciones y tecnologías heterogéneas.

La arquitectura orientada a servicios es fuente de ventaja competitiva ya que, por su

configuración:

● Aumenta la eficiencia en los procesos.

● Amortiza la inversión realizada en sistemas.

 ● Reduce costes de mantenimiento.

● Fomenta la innovación orientada al desarrollo de servicios.

● Simplifica el diseño, optimizando la capacidad de organización.

Los drivers de SOA

La arquitectura orientada a servicios es cambio en sí misma y precisamente éste es el
motor que impulsa a las empresas a buscar beneficiarse de sus atributos persiguiendo:

● Integración con los sistemas heredados.

● Reordenamiento de responsabilidades a través de reorganizaciones empresariales.
● Modernización de los sistemas obsoletos por razones económicas, funcionales o
técnicas.
● Adquisición o decomiso de productos de software.

Aunque también sucede, en muchos de los casos, que lo que se busca es la adaptación a
los cambios del entorno de mercado, o se decide implementar SOA como reacción ante las
acciones de la competencia, o como medida para optimizar la inversión en IT y minimizar
costes asociados.

La transición a la arquitectura orientada a servicios

Para llevar a cabo el proceso de transición a SOA sin problemas, administradores y
desarrolladores han de tener en cuenta que:

● SOA no es algo nuevo, por lo que es necesario y posible adquirir el conocimiento

suficiente acerca de la arquitectura orientada a servicios y los Web Services
antes de poner el plan en marcha.
● La arquitectura orientada a servicios es mucho más que un software de
despliegue. Se requiere un análisis de las técnicas de diseño y desarrollo para
avanzar con garantías de éxito desechando ineficiencias.
● Este proceso de transición hacia SOA ha de abordarse de forma gradual y
teniendo un cuenta que implica un cambio en la forma de trabajar.

Las organizaciones que ya trabajan con SOA pero busquen optimizar sus resultados con
Data Services, tendrán que observar las siguientes reglas:

● Ser exigentes con la granularidad del servicio escogido, evitando extremos y

persiguiendo la coherencia.
● Entender los servicios como algo limitado y no como una aplicación completa.
● Aplicar la máxima simplicidad a la hora de diseñar, al fin y al cabo, se trata de
representar acciones de negocio.
● Garantizar la alta disponibilidad y escalabilidad de los servicios.

Esta optimización es la vía más indicada para superar las limitaciones que adolecen a un
proyecto SOA, a través de la visualización de datos que ayuda a evitar:
 ● Falta de disponibilidad del servicio dependiente: que se da cuando este servicios
aún no está implementado y resulta en tiempos de inactividad o en la construcción
de componentes redundantes.
● Falta de disponibilidad de recursos: puede suceder cuando los recursos se tiene
que compartir entre distintos equipos de desarrollo.
● Restricciones de tiempo: la variable indefectiblemente asociada a todo proyecto y
que marca una de las limitaciones más importantes.
● Cambio de comportamiento del servicio dependiente: que, no sólo invalida los
flujos de trabajo presentes, sino que también incide en la consistencia de los datos.

Enfoques arquitectónicos de SOA

A pesar de que el enfoque tradicional a la hora de abordar el diseño de los sistemas
distribuidos se basaba en comunicaciones de red, seguridad, gestión transaccional, glosario
y ubicación, con la arquitectura orientada a servicios es distintos, las preocupaciones se
centran en dos aspectos:

● Comunicación.
● Integración de servicios.

A la hora de evaluar la arquitectura construida hay que fijarse en:

● Capacidad de modificación.
● Rendimiento.
● Fiabilidad.
● Disponibilidad.
● Seguridad.

Sin embargo, ninguna de estas cuestiones resulta tan crítica como la gobernabilidad, un
aspecto que debe tomarse en consideración mucho antes que el propio diseño, de forma
previa a la implementación. Al tratarse de una estrategia de arquitectura, SOA implica
mucho más que la simple construcción de software.

La creación de una arquitectura basada en una cartera de servicios requiere de una

metodología de desarrollo centralizado y única, de una buena documentación de servicios y
de personal cualificado. También hace falta la motivación suficiente por parte de la
organización y quienes se encargan de la toma de decisiones para que den vía libre a la
interacción con los principales procesos de negocio de la compañía. La comprensión de los
procesos y la disposición son las claves de la transformación de un negocio en base a
SOA y derivan de atributos de su gobernabilidad de los que no se puede prescindir para
tener éxito en un proyecto de estas características.

La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented

Architecture) es un estilo de arquitectura de TI que se apoya en la orientación a servicios.
La orientación a servicios es una forma de pensar en servicios, su construcción y sus
resultados. Un servicio es una representación lógica de una actividad de negocio que tiene
un resultado de negocio específico (ejemplo: comprobar el crédito de un cliente, obtener
datos de clima, consolidar reportes de perforación)

El estilo de arquitectura SOA se caracteriza por:

 ● Estar basado en el diseño de servicios que reflejan las actividades del negocio en el
mundo real, estas actividades hacen parte de los procesos de negocio de la
compañía.
● Representar los servicios utilizando descripciones de negocio para asignarles un
contexto de negocio.
● Tener requerimientos de infraestructura específicos y únicos para este tipo de
arquitectura, en general se recomienda el uso de estándares abiertos para la
interoperabilidad y transparencia en la ubicación de servicios.
● Estar implementada de acuerdo con las condiciones específicas de la arquitectura
de TI en cada compañía.
● Requerir un gobierno fuerte sobre las representación e implementación de servicios.
● Requerir un conjunto de pruebas que determinen que es un buen servicio.[1]

El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos
en el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en 2
grandes etapas:

1. Análisis orientado a servicios (Modelado de servicios)

2. Diseño orientado a servicios, El diseño orientado a servicios cuenta con 8 principios
de diseño que se aplican sobre cada uno de los servicios modelados, esto principios
de diseño son:
○ Contrato de servicio estandarizado: Los contratos de servicio cumplen con
los mismos estándares de diseño.[2]
○ Bajo acoplamiento: Los servicios evitan acoplarse a la tecnología que los
implementa y a su vez reducen el acoplamiento impuesto a los
consumidores.[3]
○ Abstracción: Los contratos presentan la información mínima requerida y la
información de los servicios se limita a los expuesto en el contrato.[4]
○ Reusabilidad: Los servicios expresan y contienen lógica de negocio
independiente del consumidor y su entorno, por lo tanto se convierten en
activos de la empresa.[5]
○ Autonomía: Los servicios deben tener un gran control de los recursos
tecnológicos sobre los cuales están implementados.[6]
○ Sin estado: El servicio reduce el consumo de servicios al delegar el manejo
de estados (sesiones) cuando se requiera.[7]
○ Garantizar su descubrimiento: Lo servicios cuentan con metadata que
permite descubrirlos e interpretar el servicio en términos de negocio.[8]
○ Preparado para ser usado en composiciones: Los servicios pueden hacer
parte de una composición sin importar el tamaño y complejidad de la misma.
[9]

Origen
Los modelos de desarrollo han ido evolucionando con el paso de los años. En los
años 80 aparecieron los modelos orientados a objetos, en los 90 aparecieron los modelos
basados en componentes y en la actualidad han aparecido los modelos orientados a
servicios.1

Aunque la arquitectura orientada a servicios no es un concepto nuevo (si bien fue

descrita por primera vez por Gartner hasta en 1996), sí se ha visto incrementada su
presencia en la actualidad, en gran medida debido al aumento de uso de servicios web. Con
la llegada de éstos, la arquitectura SOA ha hecho que el desarrollo de software orientado a
servicios sea factible. Aunque los servicios web usan con frecuencia SOA, SOA es neutral e
independiente de la tecnología utilizada y por tanto no depende de los servicios web,
aunque estos la popularizan.2

Terminología
Término Definición / Comentario Servicio Una función sin estado, auto-contenida,
que acepta una(s) llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien
definida. Los servicios pueden también ejecutar unidades discretas de trabajo como serían
editar y procesar una transacción. Los servicios no dependen del estado de otras funciones
o procesos. La tecnología concreta utilizada para prestar el servicio no es parte de esta
definición. Existen servicios asíncronos en los que una solicitud a un servicio crea, por
ejemplo, un archivo, y en una segunda solicitud se obtiene ese archivo. Orquestación
Secuenciar los servicios y proveer la lógica adicional para procesar datos. No incluye la
presentación de los datos. Coordinación. Sin estado No mantiene ni depende de condición
pre-existente alguna. En una SOA los servicios no son dependientes de la condición de
ningún otro servicio. Reciben en la llamada toda la información que necesitan para dar una
respuesta. Debido a que los servicios son "sin estado", pueden ser secuenciados
(orquestados) en numerosas secuencias (algunas veces llamadas tuberías o pipelines) para
realizar la lógica del negocio. Proveedor La función que brinda un servicio en respuesta a
una llamada o petición desde un consumidor. Consumidor La función que consume el
resultado del servicio provisto por un proveedor
Principios
No hay estándares en relación a la composición exacta de una arquitectura orientada a
servicios, aunque muchas fuentes de la industria han publicado sus propios principios.

Algunos de los principios publicados son los siguientes:

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

comunicación, según se define en conjunto con uno o más documentos de
descripción de servicios.
● Acoplamiento débil de sistemas: los servicios mantienen una relación que
minimiza las dependencias y sólo requiere que mantengan un conocimiento de uno
al otro.
● Abstracción de servicios: más allá de las descripciones del contrato de servicios,
los servicios ocultan la lógica a los demás.
● Reutilización de servicios: la lógica se divide en servicios con la intención de
promover la reutilización.
● Autonomía de servicios: los servicios tienen control sobre la lógica que
encapsulan, desde una perspectiva de diseño y ejecución.
● Servicios sin-estado: los servicios minimizan el consumo de recursos aplazando la
gestión de la información de estado cuando sea necesario.
● Descubrimiento de servicios: los servicios se complementan con los metadatos
mediante los cuales se pueden descubrir e interpretar la eficacia.
● Composición de servicios: servicios están compuestos por partes eficazmente,
independientemente del tamaño y la complejidad de la composición.
● Granularidad de servicios: una consideración de diseño para proporcionar un
ámbito óptimo y un correcto nivel granular de la funcionalidad del negocio en una
operación de servicio.
● La normalización de servicios: los servicios se descomponen a un nivel de forma
normal para minimizar la redundancia. En algunos casos, los servicios se
desnormalizan para fines específicos, como la optimización del rendimiento, el
acceso y agregación.
● Optimización de servicios: los servicios de alta calidad son preferibles a los de
baja calidad.
● Relevancia de servicios: la funcionalidad se presenta en un nivel de granularidad
reconocido por el usuario como un servicio significativo.
● Encapsulación de servicios: muchos servicios están consolidados para el uso de
SOA. A menudo, estos servicios no fueron planificados para estar en un SOA.
● Transparencia de ubicación de servicios: se refiere a la capacidad de un
consumidor de servicios para invocar a un servicio independientemente de su
ubicación en la red. Esto también reconoce la propiedad de descubrimiento (uno de
los principios fundamentales de SOA) y el derecho de un consumidor para acceder
al servicio. A menudo, la idea de la virtualización de servicios también se refiere a la
transparencia de ubicación. Aquí es donde el consumidor simplemente llama a un
servicio lógico, mientras que un SOA habilita la ejecución del componente de la
infraestructura, normalmente un bus de servicios, que mapea este servicio lógico y
llama al servicio físico.

SOA y los Servicios Web

Hay que tener cuidado cuando se manejan estos términos y no confundirlos. Web
Services (WS) engloba varias tecnologías, incluyendo XML, SOAP, WSDL, UDDI…los
cuales permiten construir soluciones de programación para mensajes específicos y para
problemas de integración de aplicaciones.3

En cambio SOA es una arquitectura de aplicación en la cual todas las funciones

están definidas como servicios independientes con interfaces invocables que pueden ser
llamados en secuencias bien definidas para formar los procesos de negocio.

En SOA la clave está en la interfaz, puesto que define los parámetros requeridos y la
naturaleza del resultado. Esto significa que define la naturaleza del servicio y no la
tecnología utilizada. Esta función permite realizar dos de los puntos críticos: los servicios
son realmente independientes y pueden ser manejados.

WS es el estándar apoyado por la industria (Microsoft, IBM, BEA, Oracle, Sun y

otros), por empresas de distintos rubros, no tecnológicas (Ford, United Airlines, KPMG,
Daimler-Chrysler), agrupadas en un comité conocido como Web Services Interoperability
(WS-I). Este organismo tiene por principal objetivo asegurar que los grupos de trabajo que
definen las especificaciones sobre WS utilizan estándares adecuados, a la vez que
monitoriza el avance de sus trabajos; no define ni desarrolla estándares.4

SOA y Web 2.0

SOA, acrónimo de Service-Oriented Architectures (Arquitecturas orientadas a Servicios) es
una arquitectura que permite que las nuevas aplicaciones no sean desarrolladas de cero
sino una integración de un conjunto de servicios publicados. Web 2.0 es un avance de la
web tradicional que permite una gran colaboración entre usuarios de Internet y otros
usuarios.

Aunque estas se basan en la arquitectura de tecnologías Web y en la Arquitectura orientada

a servicios presentan diferencias. Entre estas, podemos mencionar que cuando se habla de
SOA se hace referencia acerca de conexiones de aplicación y bases de datos pero no de
conectar personas. Por el contrario, Web 2.0 se centra en la posibilidad que las personas
interactúen colaborando entre ellas. Es decir, esta asociada a la conexión de aplicaciones y
datos pero con una visión más social. Originalmente la información se ubicaba en un sitio
Web y los usuarios simplemente veían o descargaban el contenido(llamada Web Tradicional
o Web1.0). En forma creciente, los usuarios tienen más que decir sobre la naturaleza y el
alcance del contenido en la Web y en algunos casos control en tiempo real sobre este
contenido. Por ejemplo, las enciclopedias dinámicas como Wikipedia.

SOA y los microservicios

Artículo principal: Arquitectura de microservicios

Los microservicios son una interpretación moderna de la arquitectura orientada a servicios

usada para construir sistemas distribuidos. Los servicios en una arquitectura de
microservicios5 son procesos que se comunican con otros a través de una red para
conseguir el objetivo final. Estos servicios pueden usar protocolos simples (típicamente
HTTP con REST o mensajería liviana como RabbitMQ o ZeroMQ). 6

Capas de software
SOA define las siguientes capas de software:
 ● Aplicaciones básicas: sistemas desarrollados bajo cualquier arquitectura o
tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
● De exposición de funcionalidades: donde las funcionalidades de la capa aplicativa
son expuestas en forma de servicios (generalmente como servicios web);
● De integración de servicios: facilitan el intercambio de datos entre elementos de la
capa aplicativa orientada a procesos empresariales internos o en colaboración;
● De composición de procesos: que define el proceso en términos del negocio y sus
necesidades, y que varía en función del negocio;
● De entrega: donde los servicios son desplegados a los usuarios finales.

Diseño y desarrollo de SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y
diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de
trabajo para el desarrollo de software como un marco de trabajo de implementación. Para
que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos
mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o
middleware para implementar los procesos de negocio. El desarrollo de sistemas usando
SOA requiere un compromiso con este modelo en términos de planificación, herramientas e
infraestructura.

Elementos de una arquitectura SOA, por Dirk Krafzig, Karl Banke, y Dirk Slama. 7

Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están

hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios
web. Existen diversos estándares relacionados a los servicios web; incluyendo los
siguientes:

● XML
● HTTP
● SOAP
● REST
● WSDL
● UDDI
Hay que considerar, sin embargo, que un sistema SOA no necesariamente utiliza estos
estándares para ser "Orientado a Servicios" pero es altamente recomendable su uso.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros
participantes en la red como servicios independientes a los que tienen acceso de un modo
estandarizado. La mayoría de las definiciones de SOA identifican la utilización de servicios
web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar
SOA utilizando cualquier tecnología basada en servicios.

Lenguajes de alto nivel

Los lenguajes de alto nivel como BPEL o WS-Coordination llevan el concepto de servicio un
paso adelante al proporcionar métodos de definición y soporte para flujos de trabajo y
procesos de negocio.

Beneficios
El gran beneficio de SOA es la agilidad que proporciona a las organizaciones que la usan.
Las características propias de SOA permiten a las organizaciones la capacidad de controlar
un problema de forma general, permitiendo una respuesta más rápida y eficaz y por tanto
adaptarse de la mejor forma a los cambios.8

Otra de sus ventajas es la independencia de las plataformas e infraestructuras tecnológicas,

lo que le permite integrarse con sistemas y aplicaciones diferentes de forma sencilla.
Gracias a esta independencia SOA es su arquitectura flexible que permite la reutilización de
las tecnologías existentes. Así que, una empresa no necesita realizar un cambio integral
para adoptar SOA.9

Los beneficios que puede obtener una organización que adopte SOA son:

● Mejora en los tiempos de realización de cambios en procesos

● Facilidad para evolucionar a modelos de negocios basados en tercerización
● Facilidad para abordar modelos de negocios basados en colaboración con
otros entes (socios, proveedores): facilita la integración de sistemas y
aplicaciones diferentes, lo cual mejora la comunicación y la capacidad de respuesta
con sistemas externos
● Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en
el proceso de negocio
● Facilidad para la integración de tecnologías disímiles
● Mejora en la toma de decisiones: la organización dispone de mayor información y
más actualizada, lo que le permite una respuesta rápida y eficaz cuando surgen
problemas o cambios
● Aplicaciones flexibles: la orientación a servicios permite desarrollar aplicaciones
con independencia de las plataformas y lenguajes de programación que realizan los
procesos
● Aplicaciones reutilizables y adaptables: permite que las aplicaciones existentes
para ser reutilizadas y adaptadas a nuevos entornos con facilidad. Así conseguimos
optimizar los recursos empleados en su desarrollo
● Reducción de costes: el coste de ampliar o crear nuevos servicios se reduce
considerablemente tanto en aplicaciones nuevas como ya existentes
● Riesgo de migración: al adaptar SOA a partir de una tecnología existente se siguen
utilizando los componentes existentes, por lo que se reduce el riesgo de introducir
fallos
Diferencias con otras arquitecturas
Al contrario de las arquitecturas orientado a objetos, las SOA están formadas por servicios
de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí,
estos servicios se basan en una definición formal independiente de la plataforma
subyacente y del lenguaje de programación (p.ej., WSDL). La definición de la interfaz
encapsula (oculta) las particularidades de una implementación, lo que la hace independiente
del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como
Plataforma Java o Microsoft .NET). Con esta arquitectura, se pretende que los componentes
de software desarrollados sean muy reutilizables, ya que la interfaz se define siguiendo un
estándar; así, un servicio C# podría ser usado por una aplicación Java. En este sentido,
ciertos autores definen SOA como una Súper-Abstracción.[cita requerida].

Mitos y realidades
Hay varios mitos asociados a SOA que son importantes entender antes de profundizar en el
tema. La siguiente tabla describe algunos de los principales mitos que rodean a SOA y los
hechos que ayudan a desacreditarlos.10

Mito Realidad

SOA es una tecnología SOA es una filosofía de diseño independiente de cualquier

proveedor, producto, tecnología o industria. Las necesidades
de SOA varían de una compañía a otra, por tanto la
adquisición de una arquitectura SOA de otra compañía no
será la solución apropiada para su propia compañía

Las SOA requieren de SOA se puede realizar a través de servicios web pero los
servicios web servicios web no son un requisito necesario para implementar
SOA

SOA es nuevo y EDI, CORBA y DCOM son ejemplos conceptuales de

revolucionario orientación de servicios

SOA garantiza la SOA no es una metodología

alineación de TI y el
negocio

Una arquitectura de No hay dos SOA iguales. Una arquitectura de referencia SOA
referencia SOA reduce puede no ofrecer la mejor solución para su organización
riesgo de implementación

SOA requiere una SOA debe ser gradual y construirse sobre sus inversiones
revisión completa de la actuales
tecnología y procesos de
negocios

Necesitamos construir SOA es un medio, no un fin

una SOA
Centrarse en la entrega de una solución, no en crear una arquitectura SOA. SOA es un
medio para la entrega de su solución y no debe ser su objetivo final.

Conclusión
Hoy en día las organizaciones tienen la necesidad de adaptarse a constantes cambios en el
mercado, y por tanto, deben ser capaces de adaptar sus procesos a unas condiciones
dinámicas como única forma de mantener y mejorar su competitividad.

A su vez, los sistemas que dan soporte a esos procesos deben poderse adaptar fácilmente
para responder de forma ágil a las necesidades del negocio. El estado del arte actual de la
tecnología da respuesta a este reto con SOA.

https://web.archive.org/web/20100521014149/http://blogs.tecsisa.com/?p=101

Unos pequeños Ejemplos.

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/soa.rup_soma/guidances/examples/reso
urces/soa_model_example.htm