Aquí hay una pregunta bastante teórica y abstracta: ¿cómo difiere la arquitectura orientada a servicios (SOA) del enfoque basado en componentes? ¿El concepto de SOA es una extensión del enfoque basado en componentes?¿Cómo se relacionan entre sí la arquitectura orientada a servicios y el desarrollo basado en componentes?
¿Cuáles son sus pensamientos? ¿Tal vez conoces algún buen documento que cubra este tema?
Los dos conceptos son bastante ortogonales, sin completarse ni contradecirse entre sí. Si amenazaste con ponerme un tenedor oxidado en el ojo y me forzaste a generalizar, diría que el desarrollo basado en componentes fue una técnica para modelar y ensamblar una pieza específica de software, mientras que SOA es una técnica para organizar sistemas separados, por lo que ellos pueden hablar el uno al otro.
como he dicho, una generalización burda, pero es todo lo que voy a dar sin una pregunta más específica :)
Se podría decir que SOA es una forma de alto nivel de desarrollo basado en componentes, donde los componentes se han convertido en piezas reutilizables de funcionalidad llamadas servicios.
En this article los autores vista del desarrollo basado en componentes como el apoyo a SOA - en el final de su SOA necesita servicios que se aplicarán y el diseño de usted componentes como las prestaciones que proporcionan la aplicación. Algunas de las habilidades consisten en obtener la granularidad y la cohesión de los componentes correctamente.
Creo que esta perspectiva es una caracterización razonable de cómo SOA se hace actualmente. Para mí, la clave es que primero se concentre en los servicios, lo que debe hacer en un sentido comercial, y más tarde llegar a los diseños de los componentes. [Aquí hay un article sobre la identificación de servicios. Descargo de responsabilidad: soy una persona de IBM, estos artículos están escritos por colegas.]
Sin embargo, si se retrasa el reloj, creo que encontrará que el desarrollo basado en componentes era un enfoque anterior a SOA, y tenía muchos de los mismos objetivos que SOA. Considero excesivamente cínica la opinión de que SOA no es más que mercadotecnia, pegando nuevas etiquetas a conceptos antiguos. Sin embargo, existe una superposición considerable entre CBD y SOA. Simplemente veo SOA como la mejor sabiduría colectiva que tenemos hasta la fecha sobre cómo hacer la integración, sin duda a medida que aprendemos más nuevas técnicas surgirán hasta que el kitbag en general merezca un nuevo nombre nuevamente.
Mi opinión personal es que SOA obtuvo impulso porque surgió un conjunto de tecnologías que permitieron a equipos técnicos dispares dentro de una organización (por ejemplo, una base de IBM y una base de Microsoft) construir componentes que pudieran usar los servicios de los demás. En otras palabras, surgió un nivel de madurez en cómo hacer los componentes, de modo que una nueva etiqueta (SOA) era atractiva.
Desarrollo basado en componentes requirió un depósito de fragmentos de código (a veces completas pilas de objetos) generalmente en una sintaxis de código. Para ser útil en cualquier otra cosa, estos fragmentos deberían ser portados o llamados a través de una interfaz común (por ejemplo, API de Windows o COM, COM + et al) entre VB6 & VC++, por ejemplo. Por lo tanto, las funciones de VC++ podrían ser utilizadas y llamadas por VB6. Por lo tanto, la reutilización de componentes a veces requería una gran cantidad de refactorización para ser reutilizada, lo que era contrario a la intuición. También estaba el problema de la vinculación temprana y tardía. Los componentes del repositorio aún necesitaban ser desarrollados y desplegados como una parte funcional de la base de código para ser utilizados. El código debería haber sido probado en unidades antes de agregarlo al repositorio, pero aún así requería pruebas de integración para confirmar la funcionalidad. También tendría que construir los parámetros correctos para "cruzar la interfaz del objeto". Nuevamente, este código de envoltura generalmente requerido.
Estos repositorios de código pueden no incluir todo para ser realmente multiplataforma. La independencia de la plataforma generalmente se requiere cuando los problemas se segmentan entre dominios, especialmente en sistemas integrados. La interfaz está incluida en el software desarrollado e implementado, no en el código de funcionamiento real.
Lo que hace falta entre los dos es un Framework. SOA no es CBDv2 ni una extensión del mismo, debe pasar por el marco de la implementación del servicio. Los marcos tampoco son un concepto nuevo.
Ambos CBD & SOA finalmente promueven la reutilización de códigos. CBD es generalmente de un alcance más estrecho que SOA! SOA necesita un marco para ser efectivo, CBD no. CBD está acoplado a su lenguaje de desarrollo y plataforma de destino.