architecture - servicios - soa serie

Si SOA está muerta, ¿qué la está reemplazando? (12)

Diría que no está muerto, pero ahora está incluido en el conjunto de herramientas del arquitecto, ya que ahora se entiende dónde puede ayudar y de dónde no.

No tiene sentido utilizar SOA para hablar con su base de datos porque desea que la integración sea estrecha y eficaz. Pero usarlo en los lugares correctos puede permitirle tener interfaces agradables y limpias entre diferentes partes de sus organizaciones y posiblemente permitirle actualizar cada sistema independientemente de la otra.

Pero en la vida real, si su sistema de nómina de pago se cae, todos se sentirían muy descontentos, solo porque su aplicación pueda cojear sin uno de sus componentes, no significa que no afectará su sistema.

No es posible crear sistemas que tengan conocimiento solo de una interfaz pero no del sistema subyacente (advertiré esa afirmación con: "eso funciona bien y es eficaz"). Tome un navegador web como un ejemplo interesante de esto, todo buen sitio web comienza con "qué navegador están usando y arregle mi sitio web y se beneficia de la característica xyz".

Por favor, perdóname si esta pregunta es densa.

Antecedentes: tenemos varias aplicaciones internas que se integran en la base de datos. Estamos viendo cómo dividir eso, y parece que pasar a una arquitectura donde cada aplicación expone su funcionalidad a través de servicios, en lugar de llamar a las bases de datos de otras aplicaciones, tiene más sentido. Esto me parece una arquitectura orientada al servicio. Cuando busco información sobre cómo comenzar con una arquitectura orientada a servicios, veo muchas conversaciones en torno a este artículo: SOA está muerta; Servicios de larga duración . Y también veo esto de Martin Fowler y Jim Webber: ¿Mi bus se ve grande en esto? .

Pregunta:

¿Está SOA muerta, o solo el zumbido a su alrededor?
¿Cuál es la mejor manera de comenzar en una arquitectura orientada a servicios para que pueda mantenerse tan delgada y simple como sea posible?

El "mejor" ejemplo de SOA sería la aventura BusinessByDesign de SAP. Pasé mucho tiempo y recursos, incluso comencé a venderlo antes de hacerlo funcionar correctamente y luego tratar de arreglarlo / apagarlo.

Te sugiero que no dejes que estos artículos te asusten o te influyan de otra manera. Considere su situación particular: ¿trae su beneficio tener servicios alrededor? Si es así, ve por ello. Si no, entonces el curso de acción es obvio.

Creo que las mentes detrás de SOA tienen básicamente una idea utópica: crear el mundo de varios servicios numerosos que se descubren e interoperar para proporcionarle de forma automática servicios de alto nivel. Pero eso es algo en la dirección de AI / ciencia ficción. Solo puede lograr algo cercano en un escenario muy específico que puede programar con un enfoque algorítmico. Más que eso ... bueno, no en este siglo ...

En lugar de SOA, ¿por qué no optar por un diseño modular que exponga la funcionalidad a través de las interfaces?

Es lo mismo, pero menos objetable.

La mayoría de las SOA intentaban trivializar un proceso mejor servido por el subconjunto menos utilizado de SOA conocido como Event Driven Arcitecture (EDA).

El problema es que SOA se popularizó como algo construido a partir de servicios web, lo que puede ser una elección difícil de la tecnología subyacente para implementar SOA en primer lugar. SOAP no tiene que ser, pero generalmente se usa como un mecanismo RPC de acoplamiento tenso. Esto no se adapta bien ni siquiera a los sistemas internos, y mucho menos a los sistemas que cruzan o, peor aún, a las empresas.

Puedes construir una EDA por encima de SOAP, pero por lo general terminas con una bolsa de herramientas ad-hoc además de eso. Las operaciones asíncronas y los servicios web entran en algunos posibles hacks.

Sin embargo, incluso cuando ha superado la naturaleza estrechamente acoplada de los servicios web de RPC, tiene el problema de la vinculación estrecha y el control de versiones WSDL entre socios que cooperan.

Aún puede usar cargas útiles y esquemas XML, pero el propio SOAP degenera en una envoltura de transporte bastante tonta alrededor de ese "blob" de carga útil definido completamente fuera del WSDL.

es una aplicación web mayoritariamente aislada. Lo más cercano a ser SOAish podrían ser los mecanismos OpenId que utiliza. Es simple cliente-servidor, no SOA. Estás pensando demasiado pequeño.

Mientras existan empresas, tendrán necesidades de integración, los sistemas siempre tendrán que hablar. SOA parece ser una forma inteligente de abordar estos problemas distribuidos. Pero desafortunadamente, ignora los problemas de rendimiento. Para proponer una posible solución, publiqué un artículo sobre ''Servicios de fluidos'' para aprovechar el paralelismo entre clientes y servidores utilizando la comunicación orientada a la transmisión como una alternativa a la comunicación orientada a mensajes.

Este artículo sobre SOA Maganizine describe el concepto: http://www.soamag.com/I41/0710-2.php Este es un artículo más práctico que también incluye un ejemplo de código WCF en CodeProject: ''Un experimento sobre servicios de fluidos para personas altamente receptivas Servicios de SOA escalables y reutilizables (Lo siento, no puedo poner el enlace)

No sé nada sobre SOA, pero generalmente veo que este tipo de tecnología pasa por un ciclo:

La tecnología sale.
La tecnología es tan buena que todos lo recomiendan a todos para todo.
La gente trata de usar la tecnología para todo.
Cuando las personas se dan cuenta de que no puede hacer todo, se enojan y publican que está muerto en sus blogs.

Mi conjetura es que SOA es solo otra de esas tecnologías.

Sí, SOA está muerta, pero ha resucitado para convertirse en algo efímero, véase http://www.soa-manifesto.org/ . Ahora todos pueden decir que están haciendo SOA sin importar lo que hagan, siempre que puedan proclamar que están siguiendo los 6 mandamientos (o principios):

Valor comercial sobre estrategia técnica.
Objetivos estratégicos sobre beneficios específicos del proyecto
Interoperabilidad intrínseca sobre integración personalizada
Servicios compartidos sobre implementaciones de propósito específico
Flexibilidad sobre optimización
Refinamiento evolutivo sobre la búsqueda de la perfección inicial.

Para mí, esto es más como decir, cualquier compañía que esté gastando un poco más de tiempo y dinero haciendo soluciones de TI "a prueba de futuro" puede proclamar que está haciendo SOA. Esto es algo realmente bueno.

SOA es para arquitecturas que por naturaleza están ''distribuidas''. Si solo se trata de un enfoque de programación basado en interfaz, entonces se está dirigiendo hacia la tecnología ''basada en componentes'' como COM +, CORBA. O algo como .NET Remoting. Pero si está hablando de desarrollo basado en contrato en un entorno distribuido que evoluciona con el tiempo y es desarrollado por múltiples grupos independientes, entonces está en el paradigma SOA. Esos servicios deben ser distribuidos. Pero no estoy diciendo que los conceptos de SOA no puedan usarse para el procesamiento local. Estoy diciendo que ahí es donde realmente apunta a donde nadie más lo hace. Pero una vez más, a SOA no le importan las cosas como el desempeño, lo cual es desafortunado. Porque ahí es donde está fallando miserablemente.

SOA es un ejemplo típico de lo que sucede cuando se vende un patrón útil (y ni siquiera uno particularmente nuevo) como base para una arquitectura. Como en "Un diseño de núcleo para la integración de la empresa".

Las compañías de middleware son especialmente susceptibles a este tipo de conceptos, ya que ellos mismos tienen un desafío al tratar de vincular sus productos y servicios, y necesitan Big Ideas con presupuestos potencialmente grandes.

¿No parece sospechoso que una sola arquitectura pueda abarcar todas las necesidades de integración de todo el software en una empresa?

SOA es una idea inteligente, pero un enorme bombo a su alrededor hizo que la gente escribiera "SOA ESTÁ MUERTA". Esto no es cierto, al igual que la frase "¡La programación estructural está muerta, todos hacen POO ahora!" Tampoco es siempre cierto: a veces el código estructural es la única opción, pero la decisión debe tomarse sobre la evaluación y no sobre las exageraciones. Lo mismo ocurre cuando se habla de SOA: a veces necesitará SOA, a veces necesitará servicios.

SOA no está muerta. Como toda buena idea se convierte en parte de nuestro paisaje. El término eBusiness fue una gran idea en los primeros días y ahora ya no usamos la palabra. Ya ni siquiera uso el término orientado a objetos, casi se asume.

El bombo actual es la computación en la nube. Pon todo en la nube.

La mejor práctica para SOA es escribir buenos servicios donde los necesite. El uso excesivo de SOA aumentará su latencia. Use un procedimiento almacenado en su base de datos si allí es donde necesita que el código se ejecute de manera eficiente. Usted no puede vencer a un buen servicio local si hace el trabajo tampoco.

Si va a utilizar aplicaciones internas para toda la empresa, está bien implementarlas con SOA. Si está creando una aplicación orientada a la web (con eso, me refiero a una aplicación que funciona bien con la nueva pila abierta oAuth, OpenID, etc.), luego reemplace SOA con WOA. .com es un ejemplo de tal bestia.