sistemas servicios practicos orientada objetivos negocios gobierno ejemplos definicion datos arquitectura web-services soa architecture

web-services - servicios - soa ejemplos practicos



¿Qué es SOA(arquitectura orientada a servicios)? (10)

Llámame Troll si quieres, pero hablo en serio: ¿cómo es exactamente la nueva tendencia SOA diferente de la arquitectura de servicio al cliente que estaba construyendo hace 15 años? Sigo escuchando SOA, pero no veo cómo es diferente de lo que siempre hemos hecho.

Hace 10 años, mi empresa tenía varios clientes (en varios idiomas) que hablaban con el mismo servicio. No era XML (era un protocolo binario llamado Microsoft DCOM) y no había descubrimiento automático a través de WSDL, pero eso está bien ya que leer los documentos era igual de fácil. Nuestro sistema incluso fue "abierto" en el sentido en que lo documentamos lo suficiente como para permitirle a terceros hablar con nuestros servicios. No fuimos pioneros, todas las demás empresas que conocí hace 10 años hacían lo mismo.

La ÚNICA diferencia que veo entre entonces y ahora es que ahora hay un solo servicio disponible en Internet, mientras que hace 10 años, cada cliente hospedaba su propia instancia del servicio. Pero ese no es un problema de arquitectura: donde el servicio vive físicamente es transparente para cualquiera que use el servicio.

Entonces, ¿qué es exactamente SOA que es diferente de lo que hemos estado haciendo durante años? ¿Es SOA simplemente un término de marketing que representa una mejor práctica que realmente se hizo común hace mucho tiempo? ¿O me estoy perdiendo algo de SOA que es diferente de lo que hemos estado haciendo todo el tiempo?

Creo que SOA es tanto un término de marketing como una integración de soluciones existentes con la idea de que, en lugar de vender todo el software o la máquina, vendamos los servicios.

El profesor Frank Leymann, de la Universidad de Stuttgart, considera a SOA como un concepto clave para su trabajo de investigación Service Oriented Computing (SOC) mientras habla sobre SOA . Se ve que se le pregunta acerca de la definición de SOA y que la conversación resultante podría ser una buena lectura.

Tenga en cuenta que nuestro mapa de ruta es sobre "informática orientada a servicios (SoC)", es decir, el paradigma de cómputo detrás de la orientación al servicio. Service Oriented Architecture (SOA) es una realización arquitectónica de este paradigma de cómputo. Puede comparar esto con "computación cliente / servidor" como paradigma y "navegador / servidor web" o "cliente DB / procedimiento almacenado" como dos (de varias otras) realizaciones arquitectónicas de este paradigma.

...

SOA no es completamente nuevo. Algunos aspectos individuales de SOA se utilizan en la práctica durante mucho tiempo. Por ejemplo, eche un vistazo al "acoplamiento flexible": las empresas están utilizando tecnología de mensajería confiable desde hace décadas para integrar aplicaciones, es decir, para acoplarlas de manera poco precisa. No me malinterpreten, hay nuevos conceptos en SOA, por ejemplo, conceptos resultantes de la combinación de conceptos reunidos en SOA, es decir, que resultan de la emergencia.

Las especificaciones del servicio web hacen que las tecnologías correspondientes estén disponibles a través de la plataforma. Es decir, las especificaciones correspondientes no inventan conceptos fundamentalmente nuevos, sino que definen cómo estos conceptos y las implementaciones correspondientes funcionan en entornos heterogéneos. La interoperabilidad resultante es pionera, por lo que SOA es real.

En resumen, SOA es una mezcla de cosas maduras y nuevas cosas emergentes.

También hay una referencia en papel SoC con fecha de abril de 2006.

Una búsqueda en google identifica al profesor Frank Leymann y his works .

En realidad, SOA es una colección de servicios bien definidos. Básicamente, SOA usa un servicio débilmente acoplado para obtener el resultado deseado fácilmente. Los detalles de implementación de un servicio están ocultos para el cliente / consumidor, por lo que cualquier cambio en la implementación no afectará el servicio hasta que el contrato entre ellos cambie. Los proveedores de servicios son componentes que ejecutan cierta lógica comercial basada en entradas y salidas predeterminadas, y exponen esta funcionalidad a través de una implementación SOA. Esto permite que los sistemas basados ​​en SOA respondan de manera más rápida y rentable para el negocio. La principal diferencia entre el componente y SOA es que SOA proporciona un mensaje de estándares abiertos que no es específico de ningún lenguaje de programación o plataforma. Como resultado, puede lograr un alto grado de acoplamiento flexible e interoperabilidad entre plataformas y tecnologías. En un mundo tradicional de cliente-servidor, el proveedor será un servidor y el consumidor será un cliente. Puede leer más sobre SOA aquí: Arquitectura orientada a servicios (SOA).

Olvídate de XML. Olvídate de WSDL. SOA no es una tecnología que puede comprar, aunque a menudo se comercializa de esa manera.

El verdadero objetivo de SOA es todo acerca de la organización de TI. El objetivo de SOA es evitar tener un enorme grupo de "aplicaciones" que tengan grupos de datos aislados y que no se comuniquen entre sí (y, por lo tanto, a menudo dupliquen datos), o solo de forma ineficiente y con errores a través de capas de adaptadores. o sistemas EAI.

Para las grandes empresas, este es un problema grave: tienen literalmente cientos de aplicaciones separadas que no están lo suficientemente integradas. Hay datos duplicados e inconsistentes en todos lados y el resultado es que los clientes se cabrean y se pierde dinero real porque el departamento de facturación sigue enviando facturas por un pedido cancelado y el representante del servicio de atención al cliente no puede encontrar el pedido porque se canceló en el seguimiento del pedido sistema, pero no el sistema de facturación.

Se supone que SOA soluciona esto diseñando cada aplicación desde cero para publicar sus servicios de forma estandarizada y cruzada de manera que otras aplicaciones puedan acceder a los datos y no tengan que duplicarlos.

Desde una perspectiva comercial, esto es altamente deseable. La exageración de la palabra de moda y la sopa de acrónimos son solo los intentos de las empresas de TI para sacar provecho de esa conveniencia. Desafortunadamente, esto ha llevado a muchas personas, incluidos los CEOs, a creer que SOA es un producto que puedes comprar y que hará mágicamente que tu TI sea más eficiente, sin darte cuenta de que esto solo sucederá si también reorganizas toda tu TI (y bastante posiblemente sus unidades de negocios también) para que sea compatible con SOA.

Para mí, una arquitectura orientada a servicios se produce cuando una empresa desea integrar una selección de aplicaciones dispares que se refieren a un dominio común en un conjunto de servicios interoperables que operan contra una única fuente de datos.

En el caso de una nueva empresa de inicio con una idea para un elemento de software / suite de software, no puedo ver cómo una empresa puede comenzar con una arquitectura orientada a servicios desde el principio. Al principio, cada solución (que bien puede evolucionar hasta convertirse en un servicio que pueda volverse interoperable) debería tratar de resolver su espacio problemático de forma aislada.

Quizás estará en la hoja de ruta para una capacidad o suite empresarial para que cada solución se convierta en un servicio interoperable a medida que las soluciones se completan y entran en servicio. Para esto, tal vez los equipos de desarrollo llevarán a cabo un enfoque modular / orientado a componentes para construir la solución (servicio eventual), para facilitar la inclusión de la solución como un servicio en una Arquitectura Orientada a Servicios.

En el caso donde las islas de software existentes se conviertan en servicios interoperables en una Arquitectura Orientada a Servicios, el enfoque permite que los elementos de software -que pueden ser distribuidos y pueden escribirse en diferentes idiomas- se comuniquen a través de una API expuesta y / o un protocolo común. (por ejemplo, un sabor de servicio web) y formato de datos genérico (por ejemplo, XML).

SOA es un enfoque o idea. No es un marco o una herramienta. Cuando WDSLs y EJBs son eliminados, esto a menudo se olvida ... como es que la idea de SOA no es nueva en absoluto.

Permítanme usar el famoso niño azotador de Integration Hell: Telco.

Allá por los años 90, las compañías de teléfonos celulares eran pletóricas en mi vecindario, casi tan abundantes como los distribuidores de larga distancia fueron posibles gracias a la desregulación de las comunicaciones a mediados de los 90. Bueno, el tiempo continúa, y Bell Atlantic se convierte en la potencia que es Verizon, y se traga compañía tras compañía (y al menos un Baby Bell). Cada una de estas empresas tiene tecnologías en su lugar, en torres, en equipos de conmutación, en sistemas de facturación que son COMPLETAMENTE incompatibles entre sí.

Entonces, la compañía se va y dice, está bien, tenemos estos modelos de cómo hacemos negocios, pongamos una cara amigable y consistente en TODA nuestra tecnología en forma de WSDL / SOAP / XSD, todos los idiomas y sistemas que tenemos hoy en día pueden estar conectado a esto! Lenta pero seguramente, la compañía está haciendo que todos sus sistemas sean capaces de informar sobre las capacidades, ser interrogados con fines de carga y facturación, y expuestos para que los futuros visionarios exploten de maneras que aún no se han tenido en cuenta.

Cualquiera puede construir un cliente SOA. Cualquiera con wget y un editor de texto. Y cualquiera puede analizar los resultados (XML).

Eso es lo que es fundamentalmente diferente de las arquitecturas pasadas de cliente / servidor. El otro día le estaba hablando a alguien sobre la interfaz de los sistemas basados ​​en Cobol y Smalltalk con las arquitecturas SOA. Ese es un problema fácil de resolver. Dime que puedes decir lo mismo de tus sistemas DCOM.

SOA no es más que una forma de diseño , en la que los módulos se comunican entre sí a través de "servicios". Es solo eso, y ahora la siguiente pregunta es: ¿qué es exactamente un "servicio" y cuál es su diferencia con un "método" regular?

Un servicio es una operación que realiza una única operación comercial atómica. Esta atomicidad lo hace altamente reutilizable de muchos módulos. Entonces, una operación comercial compleja es solo la búsqueda de la invocación de muchos de estos servicios en un orden específico.

SOA no tiene nada que ver con tecnología específica, es solo una forma específica de diseño.

Una arquitectura orientada a servicios (SOA) es un patrón arquitectónico en el que los softwares están diseñados como bloques de construcción. es decir, desarrollo modular, que hace que la flexibilidad se pueda ensamblar de la manera que queramos. Si desea comenzar un nuevo proyecto en lugar de comenzar de cero, podemos reutilizar los servicios y si desea un nuevo servicio, podemos integrarlo fácilmente con el servicio existente para realizar un nuevo proyecto. Así que podemos ahorrar mucho tiempo y dinero. Los principios básicos de la arquitectura orientada al servicio son independientes de los proveedores, los productos y las tecnologías.

Analogía: construcción de juguetes usando bloques de construcción de Lego.

La mayoría de las respuestas aquí parecen transmitir que SOA (Service Oriented architecture) se trata de construir aplicaciones de manera estandarizada para que otras aplicaciones puedan interactuar con ellas de manera independiente de la plataforma.

No estoy seguro de si el significado ha cambiado desde entonces, pero he tenido la oportunidad de trabajar con una empresa que ofrece suites SOA y seguir mis ideas al respecto.

Por supuesto, cuando diseñas una aplicación no puedes garantizar que sea compatible con plataformas cruzadas. Tomemos como ejemplo stock Trading systems . Usan el Fix protocol para transferir mensajes. ¿Espera que ahora devuelva datos en formato XML para que pueda ser llamado SOA? ¡Definitivamente no! SOA es un enfoque arquitectónico que puede ayudarlo a decouple your application/services y permitirles interactuar entre ellos. El backbone de SOA es un ESB (Enterprise Service Bus) que se utiliza para transferir datos de un servicio a otro. La arquitectura SOA debe encargarse de las conversiones de formatos. Por ejemplo -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)

Estos módulos de conversión comúnmente se denominan adapters y generalmente forman parte de la suite SOA. Para obtener un poco más de información, consulte otra respuesta:

Diferencia entre SOA y ESB

Claro que SOA es una palabra promocionada con fines de marketing. Técnicamente hablando, es tan simple como deserializar y serializar datos para que los servicios se puedan desacoplar y sean independientes de la plataforma, pero la idea subyacente es concreta.

También refiera la SOA para el mismo.