Arquitectura orientada a Servicios

Arquitectura orientada al servicio ( SOA , Inglés arquitectura orientada a servicios ), y la arquitectura orientada a servicios es un patrón de arquitectura de tecnología de la información en el campo de los sistemas distribuidos a servicio de estructuración de los sistemas informáticos y el uso. El enfoque en los procesos comerciales juega un papel especial , cuyos niveles de abstracción son la base para implementaciones de servicios específicos: "Otorgar un préstamo", por ejemplo, es de alto nivel; en una empresa bancaria, este es un proceso comercial con varios personas y sistemas de tecnología de la información involucrados ("Abrir la relación comercial", "abrir una o más cuentas", "contrato de crédito ...", etc.), mientras que "agregar el cliente al directorio de clientes" es un servicio de menor nivel. Al combinar ( orquestar ) servicios de niveles de abstracción más bajos, los servicios de niveles de abstracción más altos se pueden crear de manera bastante flexible y con la mayor reutilización posible .

General

En términos simplificados, SOA puede verse como un método o paradigma para encapsular los componentes de TI existentes, como bases de datos , servidores y sitios web en servicios y luego coordinarlos ("orquestación") para que sus servicios se combinen en servicios superiores y estén disponibles para otros. los departamentos organizativos o los clientes pueden estar disponibles. El factor decisivo no son las tareas técnicas individuales, como consultas a bases de datos, cálculos y procesamiento de datos, sino la consolidación de estos servicios de TI para "fines superiores", como ejecutar un pedido o verificar la rentabilidad de un departamento, etc., ofrecidos por un departamento organizativo. SOA es una estructura que permite la integración de aplicaciones de la empresa al ocultar la complejidad de las aplicaciones individuales detrás de las interfaces estandarizadas.

Los objetivos aquí son la reducción a largo plazo de los costos en el desarrollo de software y una mayor flexibilidad en los procesos comerciales mediante la reutilización de los servicios existentes. Se deben eliminar los costos de programar la enésima aplicación implementada con SOA, ya que todos los servicios necesarios ya están disponibles y estos solo tienen que ser orquestados. Esto deja solo los costos para el análisis comercial y la configuración del software.

SOA requiere una integración muy sólida de los componentes de TI individuales para que su orquestación sea rentable. Por lo tanto, SOA ya juega un papel en la selección de componentes de TI.

Una forma técnica de implementar SOA es ofrecer estos servicios en Internet o en la nube. La comunicación entre dichos servicios ofrecidos puede tener lugar a través de SOAP , REST , XML-RPC o protocolos similares. El usuario de estos servicios solo sabe que se está ofreciendo el servicio, qué insumos requiere y qué tipo de resultado es. No es necesario conocer los detalles sobre cómo se determinan los resultados.

Un servicio de directorio como UDDI puede averiguar qué servicios se pueden utilizar y cómo se controlan .

definición

Estructura y elementos de SOA

El término "arquitectura orientada a servicios" fue utilizado por primera vez en 1996 por la empresa de investigación de mercado Gartner . Por lo tanto, se considera que Gartner es el inventor del término SOA. No existe una definición generalmente aceptada de SOA. Sin embargo, la definición de OASIS de 2006 se cita a menudo :

"Un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el control de diferentes dominios de propiedad"

"SOA es un paradigma para estructurar y utilizar la funcionalidad distribuida de la que son responsables diferentes propietarios".

Los servicios son fundamentales para todas las definiciones. Las propiedades ideales de los servicios en una SOA se enumeran a continuación. En la práctica, no todos estos requisitos se cumplen por completo.

  • Un servicio es una representación de TI de la funcionalidad técnica.
  • Un servicio es autónomo (autosuficiente) y se puede utilizar de forma independiente.
  • Hay un servicio disponible en una red.
  • Un servicio tiene una interfaz publicada bien definida (contrato). Para usarlo, basta con conocer la interfaz. Sin embargo, no es necesario conocer los detalles de la implementación.
  • Un servicio es independiente de la plataforma , i. H. Los proveedores y usuarios de un servicio se pueden implementar en diferentes lenguajes de programación en diferentes plataformas .
  • Un servicio está registrado en un directorio.
  • Un servicio está vinculado dinámicamente , i. H. al crear una aplicación que utiliza un servicio, no es necesario que el servicio esté presente. Solo se localiza e integra durante la ejecución.
  • Un servicio debe ser de grano grueso para reducir la dependencia entre sistemas distribuidos.

Finalmente, cabe señalar que “la SOA” no existe; Más bien, SOA es solo un punto de vista que se puede interpretar de diferentes maneras.

Demarcación

  • SOA no son servicios web : SOA describe un paradigma de arquitectura, separado de métodos y técnicas de implementación concretos.
  • SOA no es nuevo: una arquitectura orientada a servicios podría implementarse años antes de que se introdujera el término utilizando los métodos y procedimientos disponibles en ese momento y se usó con CORBA en 1991, entre otras cosas .
  • SOA no es una solución para los problemas empresariales; como paradigma arquitectónico, SOA no ofrece ninguna recomendación para tratar los problemas empresariales. Consulte también la sección Crítica .
  • SOA es individual: no existe un "SOA estándar". Una empresa siempre tiene que adaptar una SOA a sus propias necesidades.

ejemplo

El pedido de un cliente de una empresa de pedidos por correo sirve como ejemplo de un proceso comercial . Existen los siguientes pasos del proceso para esto:

Adquisición - verificación de disponibilidad - verificación de crédito - pedido - picking - envío - facturación - recibo de pago

Hay un servicio para cada paso del proceso empresarial. La implementación (lenguaje de programación, requisitos del sistema, etc.) puede ser diferente. Los servicios también se pueden implementar en diferentes sistemas, incluso en diferentes empresas. La solvencia del cliente podría ser determinada por un proveedor de servicios financieros, o los diversos servicios logísticos los proporcionará un proveedor de servicios logísticos. La infraestructura pone a disposición de los servicios información clave , como el número de cliente o el número de artículo , siempre que sea necesario.

La secuencia no tiene que ser tan secuencial como se muestra. Por el contrario, la mayoría de los pasos del proceso empresarial pueden fallar. La falta de inventario, la falta de solvencia y la falta de pagos entrantes conducen a sucursales que requieren diferentes procedimientos. También es posible el procesamiento simultáneo de varios pasos del proceso comercial, por ejemplo, envío y facturación.

Sin embargo, es importante que la verificación de crédito, por ejemplo, sea siempre la misma, incluso si la utilizan una amplia variedad de procesos o incluso empresas. De esta manera, se logran objetivos importantes de SOA, como un mantenimiento más fácil, una mejor consistencia y más uniformidad: una vez que se ha implementado un servicio, se puede retener a largo plazo, no es necesario tocarlo una y otra vez cuando Los procesos de negocio cambian, lo que ahorra esfuerzos y evita que se conviertan en errores.

Si la empresa decide transferir la verificación de crédito a otras manos, la infraestructura solo tiene que solicitar este servicio de otro proveedor. De lo contrario, nada cambiará.

Implementación de una SOA

Es necesario revisar el siguiente párrafo. Los detalles se deben dar en la página de discusión . Ayude a mejorarlo y luego elimine esta marca.

La implementación de una SOA se basa esencialmente en decisiones sobre la comunicación y la integración entre los proveedores de servicios (incluidos los proveedores de servicios ) y los usuarios del servicio (incluidos los usuarios del servicio , los consumidores del servicio ), así como el mapeo de los procesos comerciales.

Se puede utilizar cualquier protocolo de red para la comunicación entre los usuarios del servicio y los proveedores de servicios , ya que estos solo sirven como vehículo de transporte para el mensaje real de la aplicación. Protocolos como IIOP , DCOM , DCE o SNA , CORBA , SAP RFC (Remote Function Call) y también el protocolo de transmisión web HTTP , que, a pesar de algunas desventajas en el área de seguridad y confiabilidad, ganó especial popularidad gracias a Internet. , están muy extendidos . Incluso si el servicio web no es un término estandarizado, se usa comúnmente para describir la transmisión de mensajes entre aplicaciones que utilizan el protocolo de transporte HTTP. Como alternativa a HTTP, de vez en cuando se utilizan los protocolos asíncronos SMTP y FTP .

Dado que HTTP es un protocolo de transporte para garantizar la transmisión completa y sin errores de cualquier mensaje, no dice nada sobre la estructura y el contenido del mensaje transmitido. Por lo tanto, el mensaje real se empaqueta nuevamente en un protocolo de servicio web. Se pueden concebir transmisiones basadas en REST , JSON o JMS o mensajes basados ​​en SOAP , que se describen a través del WSDL y ambos se formulan a través de XML . AMQP es una alternativa a esto porque, como formato binario abierto para Middleware orientado a mensajes (MOM), no intercambia datos a través de HTTP , sino directamente a través de TCP .

La integración de servicios individuales se puede implementar en una SOA a través de conexiones punto a punto . En el caso de las conexiones punto a punto, una conexión entre el empleador y el usuario se diseña, desarrolla y administra de forma individual. Sin embargo, en el caso de un gran número de vías de comunicación, generalmente es recomendable enviar los mensajes a través de un agente intermediario, un middleware o también llamado intermediario de mensajes . Este middleware asume trabajos recurrentes como la conversión de protocolos, filtros y redireccionamiento (enrutamiento) de mensajes y garantiza su entrega segura y procesamiento de eventos. Si este middleware se puede expandir según sea necesario y se configura independientemente del protocolo, se denomina Enterprise Service Bus (ESB). Con algunas excepciones, un middleware orientado a mensajes reduce la complejidad general de un entorno informático incluso con muy pocas computadoras comunicándose entre sí.

El mapeo de procesos de negocio se puede desarrollar especialmente o utilizar un estándar como BPEL . Los procesos descritos en BPEL se pueden ejecutar directamente en plataformas adecuadas. Por tanto, el BPEL es adecuado para la implementación técnica de procesos comerciales o para la definición de la orquestación de servicios. En 2007, muchas implementaciones de SOA mapearon los procesos comerciales utilizando aplicaciones especialmente desarrolladas. A largo plazo, se espera que BPEL prevalezca para mapear los procesos comerciales.

Cuando se trata de implementación, el paradigma SOA generalmente se rompe en cierto punto; los servicios individuales de la SOA son luego dirigidos por clientes puros, como los navegadores web, que ya no forman parte de la SOA.

Las actividades, decisiones, roles y responsabilidades para regular y controlar una arquitectura orientada a servicios se conocen como gobernanza SOA . Las reglas de una SOA se desarrollan y supervisan dentro del gobierno de SOA.

Modelado de una SOA

Hay varias formas de describir SOA con un lenguaje de modelado. De la OMG existe la especificación de código abierto SoaML , con la que los servicios SOA se pueden representar mediante un perfil UML extendido utilizando sus propios estereotipos .

Implementación técnica en tiempo de ejecución

La interacción entre el proveedor de servicios y el usuario del servicio se ejecuta de acuerdo con el paradigma de (publicar o registrar), buscar, vincular, ejecutar , en alemán: (publicar o registrar), buscar, vincular, ejecutar.

Publicar o registrar
El proveedor de servicios publica o registra su servicio en un directorio.
Encontrar
El componente de software que desea utilizar un servicio lo busca en un directorio. Si encuentra un servicio adecuado, puede pasar al siguiente paso.
Unir
El componente que usa recibe una referencia (dirección) del directorio bajo el cual puede acceder al servicio. La llamada de función está vinculada a esta dirección .
Ejecutar
El servicio se llama. Los parámetros de entrada se transmiten al servicio y los parámetros de salida se devuelven en respuesta a la llamada.

ambiente

El término arquitectura orientada a servicios se puede clasificar en el siguiente entorno:

Riesgos de la implementación de SOA

Debido a la medida en que las estructuras organizativas y los procesos comerciales existentes se ven influenciados, la introducción de una arquitectura orientada a servicios depende en gran medida del apoyo y la cooperación de la fuerza laboral y, sobre todo, de la dirección. Debido a su mayor complejidad en comparación con las estructuras de programas monolíticos, el desarrollo de una SOA requiere un mayor esfuerzo inicial y solo aprovecha sus ahorros cuando los servicios básicos ya existen y pueden usarse en áreas de aplicación más amplias de una empresa. La introducción de un solo proyecto con la esperanza de mejorarlo suele estar condenada al fracaso debido a la mayor complejidad y también es inútil mientras no se aclaren los requisitos de otras áreas potenciales de aplicación. Además, el diseño, la implementación y el mantenimiento de una SOA requieren un alto nivel de soporte de métodos.

Por lo tanto, la posibilidad de reutilizar o compartir servicios o módulos de servicio por otros procesos, departamentos, etc. no pudo realizarse en la medida esperada; incluso Gartner Research, los creadores del concepto, estima que su probabilidad es solo del 20 por ciento. Además, el objetivo de la reutilización entra en conflicto con el de la flexibilidad. Como resultado, muchos proyectos SOA han fracasado. Si bien, según AMR Research, se gastaron 22.000 millones de dólares en proyectos SOA en 2007 y 6.000 millones según IDC , el bombo publicitario (y con él el volumen de literatura recientemente publicada sobre SOA) ha disminuido significativamente desde el informe financiero de 2008. crisis. Sin embargo, según evaluaciones de expertos, otros enfoques de arquitectura orientada a servicios, como el software como servicio (SaaS) y la computación en la nube, seguirán siendo relevantes .

crítica

  • SOA está actualmente sujeta al uso indebido del término por parte de los departamentos de marketing que prometen a sus clientes la solución a todos los problemas anteriores mediante la introducción de SOA. Sin embargo, como se describe en Delimitación, SOA no es una solución para los problemas técnicos en las empresas, ni existe una SOA estandarizada que pueda venderse a una empresa como tal. Si hay problemas técnicos, la introducción de SOA probablemente fracasará por las razones mencionadas.
  • Debido al trabajo que debe realizarse en el desacoplamiento de servicios, SOA genera más esfuerzo que las estructuras de programa monolíticas anteriores.
  • SOA genera procesos mucho más complejos en el código, lo que dificulta mucho más la escritura de archivos de registro ("registro") y la resolución de problemas ("depuración"). Las pruebas también son inevitablemente mucho más complejas.
  • SOA requiere un conocimiento considerable de los desarrolladores involucrados. Esto significa que los desarrolladores no son tan fáciles de reemplazar y las empresas dependen cada vez más de los desarrolladores individuales.
  • SOA se implementa principalmente con servicios que se comunican entre sí de alguna forma a través de XML , lo que se debe al alto nivel de estandarización y la independencia de plataforma de este lenguaje de marcado. Sin embargo, dado que XML para análisis y uso en el proceso del programa con el estado actual de la técnica requiere significativamente más tiempo de cálculo y un mayor volumen de datos para transmitir que una llamada de función convencional, esto crea costos y gastos generales adicionales.

Ver también

literatura

  • Stephan Aier, Marten Schönherr (ed.): Integración de aplicaciones empresariales. Orientación al servicio y arquitecturas sostenibles. (= Arquitectura empresarial. Volumen 2). 2ª Edición. Gito, Berlín 2006, ISBN 3-936771-74-X .
  • Norbert Bieberstein, Robert G. Laird, Keith Jones, Tilak Mitra: Ejecución de SOA: una guía práctica para el arquitecto orientado a servicios Pearson, Upper Saddle River 2008, ISBN 978-0-13-235374-8 .
  • Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah: brújula de arquitectura orientada a servicios. Valor empresarial, planificación y hoja de ruta empresarial. Pearson, Upper Saddle River 2006, ISBN 0-13-187002-5 .
  • Daniel Liebhart: SOA se vuelve real. Hanser Verlag, 2007, ISBN 978-3-446-41088-6 .
  • Knut Hildebrand: integración y migración de TI . Dpunkt Verlag, Heidelberg 2007, ISBN 978-3-89864-455-6 .
  • Kai J. Oey, Holger Wagner, Simon Rehbach, Andrea Bachmann: Más que vino viejo en botellas nuevas. Una presentación introductoria del concepto de arquitecturas orientadas a servicios. En: Stephan Aier, Marten Schönherr (ed.): Arquitecturas empresariales e integración de sistemas. (= Arquitectura empresarial. Volumen 3). 2ª Edición. Gito, Berlín 2006, ISBN 3-936771-75-8 , págs. 197 y siguientes.
  • Martin van den Berg, Norbert Bieberstein, Erik van Ommeren: SOA con fines de lucro, una guía para el éxito del gerente con la arquitectura orientada a servicios. 2007, ISBN 978-90-75414-14-1 .
  • Thomas Erl: Arquitectura orientada a servicios. Conceptos, Tecnología y Diseño. Prentice Hall PTR, Upper Saddle River 2004, ISBN 0-13-185858-0 .
  • Ingo Melzer entre otros: Arquitecturas orientadas a servicios con servicios web. 3ª Edición. Spektrum Verlag, 2008, ISBN 978-3-8274-1993-4 .
  • Plataforma de servicio OSGi, versión 3. IOS Press, 2003, ISBN 1-58603-311-5 . (Inglés)
  • David A. Chappell: Enterprise Service Bus. Teoría en la práctica. O'Reilly Media 2004; Inglés, ISBN 978-0-596-00675-4 .
  • Frank Leymann , Dimka Karastoyanova et al. (Eds.): Arquitectura orientada a servicios: descripción general de tecnologías y estándares . Número central de la revista it - Tecnologías de la información . Vol. 50 (2008) número 2.
  • Jörn-Axel Meyer, Alexander Tirpitz: Arquitecturas orientadas a servicios en empresas medianas: entre lo técnicamente factible y lo comercialmente sensato. Josef Eul Verlag, Lohmar 2009, ISBN 978-3-89936-765-2 .
  • Hans-Peter Fröschle, Stefan Reinheimer: Arquitecturas orientadas a servicios. (= Práctica de la informática empresarial. HMD 253). dpunkt verlag, 2007, ISBN 978-3-89864-434-1 .
  • Dirk Krafzig, Karl Banke, Dirk Slama: SOA empresarial : mejores prácticas de arquitectura orientada a servicios. Prentice Hall PRT, 2007, ISBN 978-0-13-146575-6 .
  • Dieter Masak: SOA ?, orientación de servicios en negocios y software. Springer Verlag, 2007, ISBN 978-3-540-71871-0 .
  • Louise E. Moser, PM Melliar-Smith: Arquitectura orientada a servicios y servicios web. En: Wiley Encyclopedia of Computer Science and Engineering. 2009, ISBN 978-0-471-38393-2 . doi: 10.1002 / 9780470050118.ecse510
  • Johannes Maximilian Ahrens: Diseño y mejora de servicios con especial atención al cloud computing y arquitecturas orientadas a servicios. Disertación . St. Gallen 2016. (con 64 páginas de bibliografía)

Fuentes principales

enlaces web

Evidencia individual

  1. ^ Nota de investigación SPA-401-068, 12 de abril de 1996, "Arquitecturas 'orientadas a servicios', Parte 1" y Nota de investigación de SSA SPA-401-069, 12 de abril de 1996, "Arquitecturas 'Orientadas a servicios', Parte 2"
  2. ↑ Reference Architecture Foundation for Service Oriented Architecture Versión 1.0, 04 de diciembre de 2012 en línea
  3. ↑ Modelo de referencia para la arquitectura orientada a servicios 1.0, Especificación del comité 1, 2 de agosto de 2006 oasis-open.org
  4. ^ A b Bianco Phil, Kotermanski Rick, Merson Paulo: Evaluación de una arquitectura orientada a servicios. Instituto de Ingeniería de Software de la Universidad Carnegie Mellon , septiembre de 2007 http://www.sei.cmu.edu/publications/documents/07.reports/07tr015.html
  5. ↑ SOA en la práctica, Nicolai Josuttis, 2008
  6. ^ Haibin Zhu: Desafíos para los servicios reutilizables , scc, 2005, IEEE International Conference on Services Computing (SCC'05) Vol-2, 2005, págs. 243-244.
  7. ↑ Ver críticamente en 2006: David Chappell: SOA y la realidad de la reutilización. Agosto de 2006. En línea: davidchappell.com , consultado el 16 de mayo de 2015.
  8. ↑ Wolfgang Herrmann: La recesión rompió el cuello de SOA. En: Computerwoche. 16 de octubre de 2008. en línea: computerwoche.de .