SCA, un modelo para SOA
SCA (Service Component Architecture) es una tecnología que simplifica el desarrollo de aplicaciones dentro de una Arquitectura Orientada a Servicios (SOA). Permite crear recursos IT en servicios reusables de una manera muy sencilla. Además, reduce la complejidad de la creación de los mismos ya que unifica la forma de crear dichos servicios de una manera independiente del lenguaje de programación o la plataforma utilizada.
Utilizando SCA se pueden implementar esos recursos IT en términos de funciones de negocio y evitar la exposición de su programación interna (con todo lo complejo que pueda llegar a ser) al usuario. No solo eso, SCA propone un modelo de ensamblaje de los componentes dando solución a todo tipo de problemas como los métodos de acceso o la seguridad.
Cuando hablamos de SOA hablamos de una arquitectura que nos permite conectar unidades funcionales; esto es, servicios, a través de contratos bien definidos (WSDL) además de toda una serie de características propias e intrínsecas a la definición de un Servicio Web. Una de las ventajas principales es el débil acoplamiento y la independencia con carencia de estado de los servicios; que permite acometer cambios minimizando el impacto sobre el resto de componentes de la Arquitectura.
SOA no es nuevo, muchas empresas llevan varios años intentando (con más o menos acierto) construir arquitecturas de este tipo; ahora es cuando SCA aparece como un modelo diseñado para desarrollar SOA. SCA nos va a permitir encapsular o modificar aplicaciones ya existentes utilizando una "abstracción SOA". Se va a encargar de los temas relacionados con el ensamblaje de servicios heterogeneos; que a su vez dan lugar a servicios nuevamente reutilizables y siguiendo dichos principios.
SCA no es incompatible con los Servicios Web, todo lo contrario; SCA define la manera de ensamblarlos (incluso con otros elementos que no sean Servicios Web como EJB’s, CORBA, etc…)
El modelo de ensamblaje SCA consiste en una serie de Artefactos (o "Artifacts") definidos por medio de ficheros XML. El artefacto base es una Composición (o "Composite") que define los servicios que pueden ser accedidos. La composición a su vez, se define por medio de uno o más Componentes (o "Components") que contienen las funciones u operaciones de negocio provistas por el módulo a través de sus "entry points" (las implementaciones de los mismas pueden ser con cualquier lenguaje/plataforma que se quiera). Las dependencias que existan con respecto a otros componentes (ya bien sean del mismo módulo o de otros externos) son llamadas Referencias (o "References"). Y las uniones entre referencias y servicios son definidos por medio de cables (o "Wires").
Por último comentar, que al igual que SCA nos permite construir arquitecturas SOA de una manera más sencilla y "componible", existe otro elemento importante que es SDO (Service Data Object); un modelo para representar datos de manera universal y que se suele utilizar con arquitecturas SCA para el intercambio de información entre elementos… pero esto será tema para otro post…
Links interesantes:
El año pasado estuve mirando SCA y me pareció una propuesta muy interesante aunque algo compleja (imagina que las herramientas facilitarán la labor). De hecho en las JSWEB 2006 tuvimos una charla de Paco Curbera (co-autor de WSDL y WS-BPEL) sobre este tema.
A mi lo que me preocupa es la sinergia con JBI, pues no olvidemos que dicha especificación está muy presente en los ESBs open source. Entiendo que en un futuro JBI (basada en contenedor j2ee) se integrará en SCA (modelo mas general).
Un saludo,
Jose.
Lo de la sinergia entre JBI y SCA es algo que creo puede llegar a ser dificil de confluir.
En principio son dos modelos para SOA algo distintos: A mi entender (corregirme si me equivoco), JBI se basa en un modelo de Mediación a través de lo que llaman NMR (Normalized Message Router); algo más centralizado (con los problemas de centralización que ello pueda conllevar; sería algo más parecido a los antiguos EAI). En cambio, SCA se basa en un modelo de activación más descentralizado (la implementación lógica de los componentes no depende de un middleware y son independientes unos de otros).
En cualquier caso, existen posibles aproximaciones entre los dos modelos propuestos por gente como Brian O’Neill. Veremos a ver en que termina todo esto, porque como apuntas, las apuestas Open Source pasan por JBI y creo que a futuro serán algo a tener muy en cuenta.
Gracias por el enlace. SCA en general es un modelo mas extenso que JBI, quizás la diferencia principal es que SCA es neutral en cuanto la plataforma y lenguaje.
En mi blog he comentado algunas veces el tema de los ESBs open source:
http://jcdelarco.blogspot.com/search/label/esb
Aqui he guardado enlaces sobre SCA/SDO y JBI:
http://del.icio.us/swwsman/jbi
http://del.icio.us/swwsman/sca
http://del.icio.us/swwsman/jdo
JC.
Siento llegar algo tarde a esta conversación, pero es que justamente estoy haciendo mis primeros pinitos con SCA (sin herramientas, que tiene más mérito)
Justo en la web de OpenSOA hay un artículo acerca de la relación entre SCA y JBI donde justamente explica que JBI y SCA no compiten ni entran en conflicto uno con otro, sino que más bien se complementan. Según el autor, los runtimes SCA pueden implementarse sin utilizar JBI (de hecho, SCA no asume ningún compromiso con ningún lenguaje de programación, al contrario que JBI, que es Java) y, al revés, un runtime JBI se puede construir sin implementar SCA.
En cuanto a la postura de Sun respecto a SCA, en una presentación que hizo Eduard Pelegrí en Madrid, justamente le preguntamos y coincidió plenamente con el “estamos a verlas venir” de Mark Hapner en una presentación de la JavaOne de este año.
P.S.
Enrique, enhorabuena por tu blog, es muy interesante.