Arquitectura_orientada_a_servicios.pdf

1. Arquitectura orientada a servicios
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 forman 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] (http://www.opengroup.org/soa/source-book/soa/p1.htm#soa_
definition)
El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en el manifiesto SOA (http://www.soa-manifesto.org/default.html).
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) (https://web.archive.org/web/20170725180231/http://serviceorientation.com/soaproje
ct/serviceorientedanalysis)
2. Diseño orientado a servicios
(https://web.archive.org/web/20170720141628/http://serviceorientation.com/soaproject/serviceorienteddesign), 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] (https://web.archive.or
g/web/20170823012603/http://serviceorientation.com/serviceorientation/standardized_service_contract)
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] (https://web.archive.org/web/20170805215048/http://serviceorientation.com/serviceorientation/service_loose_coup
ling)
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] (https://web.archive.org/web/20170804194737/http://serviceorientation.com/serviceorientation/service_abstraction)
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] (https://web.archive.org/web/20170725190421/http://serviceorientation.com/serviceorientation/s
ervice_reusability)
Autonomía: Los servicios deben tener un gran control de los recursos tecnológicos sobre los cuales están implementados.[6] (https://we
b.archive.org/web/20170804192620/http://serviceorientation.com/serviceorientation/service_autonomy)
Sin estado: Los servicios reducen el consumo de recursos al delegar el manejo de estados (sesiones) cuando se requiera.[7] (https://w
eb.archive.org/web/20170805125839/http://serviceorientation.com/serviceorientation/service_statelessness)
Garantizar su descubrimiento: Lo servicios cuentan con metadata que permite descubrirlos e interpretar el servicio en términos de
negocio.[8] (https://web.archive.org/web/20170817081616/http://serviceorientation.com/serviceorientation/service_discoverability)
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] (https://web.archive.org/web/20170925100017/http://serviceorientation.com/serviceorientation/service_com
posability)
Origen
Terminología
Principios
SOA y los Servicios Web
SOA y Web 2.0
SOA y los microservicios
Capas de software
Diseño y desarrollo de SOA
Lenguajes de alto nivel
Beneficios
Diferencias con otras arquitecturas
Mitos y realidades
Véase también
Bibliografía
Referencias
Enlaces externos
Índice

2. 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 ​
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
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.
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.
Origen
Terminología
Principios
SOA y los Servicios Web

3. Elementos de una arquitectura SOA, por Dirk Krafzig, Karl Banke, y Dirk
Slama.7 ​
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, 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.
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 ​
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.
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.
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 con 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.
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.
SOA y Web 2.0
SOA y los microservicios
Capas de software
Diseño y desarrollo de SOA
Lenguajes de alto nivel

4. 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
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].
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.1 ​
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 servicios
web
SOA se puede realizar a través de servicios web pero los servicios web no son un requisito necesario para implementar SOA
SOA es nuevo y revolucionario EDI, CORBA y DCOM son ejemplos conceptuales de orientación de servicios
SOA garantiza la alineación de TI
y el negocio
SOA no es una metodología
Una arquitectura de referencia
SOA reduce riesgo de
implementación
No hay dos SOA iguales. Una arquitectura de referencia SOA puede no ofrecer la mejor solución para su organización
SOA requiere una revisión
completa de la tecnología y
procesos de negocios
SOA debe ser gradual y construirse sobre sus inversiones actuales
Necesitamos construir una SOA SOA es un medio, no un fin
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.
Back office
Gestión de procesos de negocio (Business Process Management)
Gobernabilidad de arquitectura orientada a servicios
Oficina de servicios
Scrum
Beneficios
Diferencias con otras arquitecturas
Mitos y realidades
Véase también
Bibliografía

5. Norbert Bieberstein et al. Service-Oriented Architecture Compass, Pearson 2006, ISBN 0-13-187002-5 (https://web.archive.org/web/20070
312191723/http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?z=y&endeca=1&isbn=0131870025&itm=1)
Eben Hewitt. Java SOA Cookbook, 1st Edition, O'reilly 2009
http://shop.oreilly.com/product/9780596520731.do (http://shop.oreilly.com/product/9780596520731.do) - Evaluating a Service Oriented
Architecture (http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8443) (SEI)
1. «Copia archivada» (https://web.archive.org/web/20140321085658/http://msdn.microsoft.com/en-us/library/bb833022.aspx). Archivado
desde el original (http://msdn.microsoft.com/en-us/library/bb833022.aspx) el 21 de marzo de 2014. Consultado el 5 de mayo de 2014.
2. http://upcommons.upc.edu/pfc/bitstream/2099.1/12312/1/ESTUDIO_DE_ARQUITECTURAS_DE_REDES_ORIENTADAS_A_SERVICIO.pdf
3. Kishore Channabasavaiah and Kerrie Holley, IBM Global Services, and Edward M. Tuggle, Jr., IBM Software Group, “On demand operating
environment solutions: Migrating to a service-oriented architecture”, white paper, April 2004.
4. ARQ-RFC “Pautas y recomendaciones para SOA v.091”, July 2006
5. «Microservices: yesterday, today, and tomorrow» (https://arxiv.org/pdf/1606.04036v1.pdf). Consultado el 6 de julio de 2016.
6. James Lewis and Martin Fowler. «Microservices» (http://martinfowler.com/articles/microservices.html).
7. Enterprise SOA. Prentice Hall, 2005
8. «Copia archivada» (https://web.archive.org/web/20140505232142/http://www.ilustrados.com/tema/12463/Arquitectura-software-Arquitectura
-orientada-servicios.html). Archivado desde el original (http://www.ilustrados.com/tema/12463/Arquitectura-software-Arquitectura-orientada-
servicios.html) el 5 de mayo de 2014. Consultado el 5 de mayo de 2014.
9. http://upcommons.upc.edu/pfc/bitstream/2099.1/12312/1/ESTUDIO_DE_ARQUITECTURAS_DE_REDES_ORIENTADAS_A_SERVICIO.pdf
wso2.org (http://wso2.org/) WSO2 Project
soaAgenda.com (http://www.soaAgenda.com/) Artículos sobre SOA, BPM, y Ajax
OASIS - Modelo de referencia para SOA (http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf), (en inglés)
mule.codehaus.org (https://web.archive.org/web/20100607034718/http://mule.codehaus.org/) Mule - SimphonySoft
Kumbia Enterprise Framework (https://web.archive.org/web/20090428085514/http://www.loudertechnology.com/site/projects/kumbia_enter
prise_framework): Arquitectura SOA en PHP y BPM
SOPERA - Open Source SOA (https://web.archive.org/web/20100207015506/http://www.sopera.de/en/products/sopera-at-a-glance)
pensandoensoa.com (http://pensandoensoa.com/) Pensando en SOA (blog dedicado a SOA, Gobierno SOA, Servicios Web, REST, etc.)
¿Por qué SOA? (https://web.archive.org/web/20100521014149/http://blogs.tecsisa.com/?p=101)
Introducción a los Servicios Web en Java (http://www.davidmarco.es/archivo/tutorial-serviciosweb)
Evaluating a Service Oriented Architecture (http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8443) (SEI)
Obtenido de «https://es.wikipedia.org/w/index.php?title=Arquitectura_orientada_a_servicios&oldid=144243951»
Esta página se editó por última vez el 17 jun 2022 a las 05:51.
El texto está disponible bajo la Licencia Creative Commons Atribución Compartir Igual 3.0; pueden aplicarse cláusulas adicionales. Al usar este sitio, usted acepta nuestros
términos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de la Fundación Wikimedia, Inc., una organización sin ánimo de lucro.
Referencias
Enlaces externos