Arquitectura de componentes de servicio

Service Component Architecture ( SCA ) es una tecnología de software diseñada para proporcionar un modelo para aplicaciones que siguen los principios de la arquitectura orientada a servicios . ^[1] La tecnología, creada por los principales proveedores de software, incluidos IBM , Oracle Corporation y TIBCO Software , abarca una amplia gama de tecnologías y, como tal, se especifica en especificaciones independientes para mantener la neutralidad del lenguaje de programación y del entorno de la aplicación. ^[1] Muchas veces utiliza un bus de servicio empresarial (ESB).

Los socios originales anunciados el 30 de noviembre de 2005 fueron: BEA Systems , IBM , IONA Technologies , Oracle Corporation , SAP AG , Sybase , Xcalia y Zend Technologies . ^[2] Los miembros adicionales anunciados el 26 de julio de 2006 fueron Cape Clear , Interface21 , Primeton Technologies, Progress Software , Red Hat , Rogue Wave Software , Software AG , Sun Microsystems y TIBCO Software . ^[3] Siemens AG se unió a la colaboración de empresas que trabajan en la tecnología el 18 de septiembre de 2006.

Además de los socios, la comunidad SCA contaba con algunos partidarios formales. ^[4]

El 21 de marzo de 2007, la Colaboración OSOA publicó la primera versión de la especificación. ^[5] Las especificaciones establecían que una aplicación diseñada con SCA debería tener:

• Desacoplamiento de la lógica empresarial de la aplicación de los detalles de las llamadas de servicio invocadas
• Servicios de destino en una multitud de lenguajes, incluidos C++ , Java , COBOL y PHP , así como XML , BPEL y XSLT.
• La capacidad de trabajar con diversas construcciones de comunicación, incluidas las unidireccionales, asincrónicas, de devolución de llamada y de notificación.
• La capacidad de "vincularse" a componentes o servicios heredados, a los que se accede normalmente mediante tecnologías como Web Services , EJB , JMS , JCA , RMI , RPC , CORBA y otros
• La capacidad de declarar (fuera de la lógica empresarial) los requisitos de calidad del servicio , como la seguridad, las transacciones y el uso de mensajería confiable.
• Los datos podrían representarse en objetos de datos de servicio

Por lo tanto, se promovió SCA para ofrecer flexibilidad para aplicaciones compuestas , incorporando de manera flexible componentes reutilizables en un estilo de programación SOA.

En diciembre de 2005, la empresa de marketing Gartner Group publicó un breve informe que promocionaba la SCA y su tecnología incluida de Objetos de Datos de Servicio (SDO). ^[2]

Ventajas:

• Atiende todas las tecnologías de plataforma Java existentes y C++
• Menor dependencia de la tecnología: no tiene que depender del lenguaje de programación Java o XML
• Objetos de datos de servicio es una especificación tecnológica para el acceso a datos

Desventajas:

• La especificación no aborda el rendimiento de las aplicaciones SOA, lo que continúa siendo un factor que impide su adopción.
• Centrándose en la portabilidad (en lugar de la interoperabilidad), ^[6] lo que lo hace vulnerable a repetir los errores de CORBA . ^[7]

Se decía que SCA proporcionaba interoperabilidad a través de un enfoque llamado "Activación". Es el método que proporciona el mayor grado de autonomía de los componentes, en comparación con la "mediación" más antigua (por ejemplo, JBI ) o el método de "Invocación" utilizado en JCA , como explicó un arquitecto de SAP. ^[8]

El modelo de ensamblaje de SCA consta de una serie de artefactos, que se definen mediante elementos contenidos en archivos XML. Un entorno de ejecución de SCA puede tener otras representaciones no estándar de los artefactos representados por estos archivos XML y puede permitir que la configuración de los sistemas se modifique de forma dinámica. Sin embargo, los archivos XML definen la representación portátil de los artefactos de SCA.

El artefacto básico es el compuesto , que es la unidad de implementación para SCA y que contiene servicios a los que se puede acceder de forma remota. Un compuesto contiene uno o más componentes , ^[9] que contienen la función comercial proporcionada por el módulo. Los componentes ofrecen su función como servicios, que pueden ser utilizados por otros componentes dentro del mismo módulo o que pueden estar disponibles para su uso fuera del módulo a través de Puntos de entrada . Los componentes también pueden depender de servicios proporcionados por otros componentes: estas dependencias se denominan referencias . Las referencias pueden estar vinculadas a servicios proporcionados por otros componentes en el mismo módulo, o pueden estar vinculadas a servicios proporcionados fuera del módulo, que pueden ser proporcionados por otros módulos. Las referencias a servicios proporcionados fuera del módulo, incluidos los servicios proporcionados por otros módulos, se definen mediante Servicios externos en el módulo. También se incluyen en el módulo los vínculos entre referencias y servicios, representados por cables .

Un componente consta de una implementación configurada , donde una implementación es el fragmento de código de programa que implementa funciones empresariales. El componente configura la implementación con valores específicos para propiedades configurables declaradas por la implementación. El componente también puede configurar la implementación con el cableado de referencias declaradas por la implementación a servicios de destino específicos.

Los composites se implementan dentro de un sistema SCA . Un sistema SCA representa un conjunto de servicios que proporcionan un área de funcionalidad empresarial controlada por una única organización. Por ejemplo, para el departamento de contabilidad de una empresa, el sistema SCA podría cubrir todas las funciones relacionadas con las finanzas y podría contener una serie de módulos que se ocupen de áreas específicas de contabilidad, uno para las cuentas de los clientes y otro para las cuentas por pagar. Para ayudar a construir y configurar el sistema SCA, los composites se pueden utilizar como implementaciones de componentes, de la misma manera que las clases Java o los procesos BPEL . En otras palabras, SCA permite una jerarquía de composites con una profundidad arbitraria; un modelo anidado de este tipo se denomina recursivo.

La captura y expresión de requisitos no funcionales, como la seguridad, es un aspecto importante de la definición de servicios y afecta a SCA durante todo el ciclo de vida de los componentes y composiciones. SCA proporciona el marco de políticas para respaldar la especificación de restricciones, capacidades y expectativas de calidad de servicio (QoS), desde el diseño de componentes hasta la implementación concreta.

Después de varios años de incubación bajo una colaboración informal de la industria, las primeras implementaciones (V1.0) de la especificación están llegando al mercado. Los socios de la colaboración indicaron que la estandarización formal de la industria sería el siguiente paso apropiado y anunciaron sus intenciones en marzo de 2007. La Organización de Desarrollo de Estándares elegida es la organización OASIS , y se ha establecido una nueva Sección de Miembros de OASIS Open CSA. ^[10] Se han enviado a OASIS los estatutos de seis nuevos Comités Técnicos (TC) ^[11] y se ha emitido una Convocatoria de Participación para los miembros de los Comités Técnicos dentro de la organización OASIS. Los Comités Técnicos planearon comenzar su trabajo en septiembre de 2007. La participación en estos TC de OASIS SCA sigue abierta a todas las empresas, grupos sin fines de lucro, gobiernos, instituciones académicas e individuos. Los archivos del trabajo serán accesibles tanto para miembros como para no miembros, y OASIS ofrecerá un mecanismo para comentarios públicos. ^[12]

• Servicio mixto Apache
• Modelo y notación de procesos de negocio (BPMN)
• Docker (software)
• Integración de aplicaciones empresariales (EAI)
• Mula (software)
• ESB abierto
• Programación reactiva
• Arquitectura orientada a servicios semánticos (SSOA)
• Modelado orientado a servicios
• Fundación de comunicación de Windows (WCF)

• Comprender la SCA según los expertos Jim Marino y Michael Rowley [2]
• SOA para desarrolladores de negocios: conceptos, BPEL y SCA— ISBN 978-158347-065-7 
• Apache Tuscany en acción, ISBN 978-1-933988-89-4 
• SOA de código abierto, ISBN 1-933988-54-1 

• Correo del 19-02-2013 con Fallecimiento del comité técnico de la Asamblea SCA de OASIS, en ese correo falleció el asombroso SCA
• Correo del 20/02/2015 con el líder Jim Marino contando sobre el asesinato de SCA por parte de Oracle
• Proyecto de aplicación compuesta NetBeans SOA
• camello
• Ejecución de Apache Camel en OpenESB
• Introducción a la programación para SCA Dr. Dobb's
• Apache Tuscany: implementación de código abierto de la especificación SCA
• SALT: entorno de ejecución de SCA listo para empresas para C++, Python, Ruby y PHP
• PocoCapsule para WS y SCA Archivado el 19 de noviembre de 2007 en Wayback Machine Un contenedor SCA C++ de código abierto basado en inversión de control (IoC) y modelado específico de dominio (DSM)
• Tiempo de ejecución de SCA y OSGi distribuido de código abierto de Newton
• Un proyecto de investigación público francés, que incluye un entorno de ejecución de SCA llamado FraSCati
• Página de inicio de SCA en el sitio web de OASIS
• Recursos y material complementario actuales de SCA
• Últimas noticias de SCA y SDO
• Presentación de SCA: un tutorial de David Chappell, Chappell & Associates
• Subproyecto Eclipse STP/SCA Un proyecto Eclipse de código abierto que proporciona un conjunto de herramientas para SCA
• Patrones y mejores prácticas de arquitectura de microservicios
• Sitio de arquitectura de microservicios de Martinfowler
• Puntos finales inteligentes y conductos tontos – martinfowler