Si SOA está muerto, ¿qué lo está reemplazando?

Question

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

Antecedentes: Tenemos varias aplicaciones internas que se integran en la base de datos. Estamos estudiando cómo dividir eso, y parece que cambiar 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 a servicios. Mientras busco información sobre cómo comenzar a utilizar una arquitectura orientada a servicios, veo muchas conversaciones sobre este artículo: SOA Is Dead; Long Live Services. Y también veo esto de Martin Fowler & Jim Webber: Does My Bus Look Big In This?.

Pregunta:

• Es SOA muertos, o simplemente el zumbido alrededor de ella?
• ¿Cuál es la mejor manera de comenzar en una arquitectura orientada a servicios para que pueda mantenerse lo más delgada y simple posible?

Answer 1

SOA es una idea ingeniosa, pero una enorme algarabía hizo que la gente escribiera "SOA AHORA ES MUERTO". Esto no es cierto, al igual que la frase "¡La programación estructural está muerta, todos hacen OOP ahora!" tampoco es siempre cierto: a veces el código estructural es la única opción, pero la decisión debe tomarse en la evaluación y no en la exageración. Lo mismo es cierto cuando se habla de SOA: a veces necesitará SOA, a veces necesitará servicios.

Answer 2

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

Le sugiero que no permita que estos artículos lo asusten o lo influencien de ninguna otra manera. Considere su situación particular: ¿trae beneficios a su 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 básicamente tienen una idea utópica: crear el mundo de varios servicios numerosos que se descubren e interactúan para brindarle de manera 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 ...

Answer 3

SOA no está muerto. 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 ni siquiera usamos la palabra. Ni siquiera uso el término orientado a objetos, ya casi se supone.

El hype 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 es allí donde necesita que el código se ejecute de manera eficiente. No se puede vencer a un buen servicio local si hace bien el trabajo.

Answer 4

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 principal para la integración de la empresa".

Las empresas de middleware son especialmente susceptibles a este tipo de conceptos, porque ellos mismos tienen un desafío tratando de vincular sus productos y servicios, y necesitan grandes ideas con grandes presupuestos potenciales.

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

Answer 5

en lugar de SOA, ¿por qué no optar por una funcionalidad de exposición de diseño modular a través de interfaces?

es lo mismo, solo menos objetable.

Answer 6

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

Answer 7

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

No tiene sentido utilizar SOA para hablar con su base de datos porque desea que la integración sea ajustada y efectiva. Pero usarlo en los lugares correctos puede permitirle tener buenas interfaces limpias entre las diferentes partes de su organización y posiblemente le permita actualizar cada sistema independientemente del otro.

Pero en la vida real si su sistema de nómina falla, todo el mundo estaría descontento, solo porque su aplicación pueda cojear sin uno de sus componentes no significa que no afecte su sistema.

No es posible crear sistemas que solo tengan conocimiento de una interfaz pero no del sistema subyacente (voy a advertir esa afirmación con: "que funciona bien y está en plena ejecución"). Tome un navegador web como un ejemplo interesante de esto, cada buen sitio web comienza con "qué navegador usan y arreglan mi sitio web y aprovechan la función xyz".

Answer 8

La mayoría de las SOA intentaban trivializar un proceso que funciona mejor con 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 los servicios web, que en primer lugar puede ser una elección difícil de la tecnología subyacente para implementar SOA. SOAP no es tiene que ser pero normalmente es utilizado como mecanismo RPC ajustado. Esto no se escala bien incluso en sistemas internos, y mucho menos en sistemas de cruce o, peor aún, en empresas.

Puedes construir una EDA encima de SOAP, pero usualmente terminas con un montón de técnicas ad-hoc además de eso. Asynchronous operations and Web services entra en algunos posibles hacks.

Sin embargo, incluso cuando ha analizado la naturaleza estrechamente unida de los servicios web RPC, tiene el problema de las versiones de enlace cerrado y WSDL entre socios colaboradores.

Puede seguir utilizando esquemas y cargas XML, pero SOAP degenera en una envoltura de transporte bastante tonta alrededor de esa "burbuja" de carga útil definida por completo fuera del WSDL.

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

Answer 9

No sé nada de SOA, pero por lo general ver este tipo de tecnología pasan por un ciclo:

1. Tecnología sale.
2. La tecnología está tan bien, que todos lo recomiendan a todos para todo.
3. La gente trata de usar la tecnología para todo.
4. Cuando la gente se da cuenta de que no puede hacer todo, se enojan y publican que está muerto en sus blogs.

Supongo que SOA es solo otra de esas tecnologías.

Answer 10

Mientras existan las 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 las preocupaciones de rendimiento. Para proponer una posible solución, publiqué un artículo sobre "Fluid Services" para aprovechar el paralelismo entre clientes y servidores mediante el uso de comunicación orientada a flujo 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 el código de WCF muestra en CodeProject: 'Un experimento en Servicios de Fluidos de alta capacidad de respuesta, escalable y reutilizable SOA Servicios' (Lo siento, no se puede poner el enlace)

Answer 11

SOA es para arquitecturas que son por naturaleza 'distribuidas'. Si está hablando simplemente de un enfoque de programación basado en interfaz, entonces se dirige hacia la tecnología 'basada en componentes' como COM +, CORBA. O algo así como .NET Remoting. Pero si se trata de un desarrollo basado en contratos en un entorno distribuido que evoluciona con el tiempo y es desarrollado por múltiples grupos independientes, entonces usted está en el paradigma SOA. Esos servicios tienen que ser distribuidos. Pero no digo que los conceptos de SOA no puedan usarse para el procesamiento local. Digo, ahí es donde realmente apunta donde nadie más lo hace. Pero, de nuevo, SOA no se preocupa por cosas como el rendimiento, lo cual es desafortunado. Porque ahí es donde está fallando miserablemente.

Answer 12

Sí, SOA está muerto, pero ha sido resucitado para convertirse en algo efímero, vea - http://www.soa-manifesto.org/. Ahora todo el mundo todavía puede decir que están haciendo SOA no importa lo que hagan, siempre y cuando puedan anunciar a estar siguiendo los 6 mandamientos (o principios):

• valor de negocios sobre la estrategia técnica
• objetivos estratégicos más de proyecto beneficios específicos de
• interoperabilidad intrínseca más de integración personalizada
• servicios compartidos a través de las implementaciones de propósito específico
• flexibilidad en la optimización
• refinar evolutiva sobre la búsqueda de la perfección inicial

Esto para mí es más como decir, cualquier empresa que esté gastando un poco más de tiempo y dinero haciendo soluciones informáticas "a prueba de futuro" puede proclamar que está haciendo SOA. Esto es algo bueno realmente