Translate

Mostrando las entradas con la etiqueta SCA. Mostrar todas las entradas
Mostrando las entradas con la etiqueta SCA. Mostrar todas las entradas

jueves, 24 de marzo de 2011

Aprendiendo SOA


Dejo una serie de libros y links para la persona que quiere empezar con SOA

Libros:


Open Source SOA.

Autor: Jeff Davis

Publicado por Manning Publications corp.

ISBN: 1933988541


Java SOA cookbook

Autor: Eben Hewitt

Publicado por O’Reilly Media, Inc.

ISBN: 978-0-596-52072-4


Service-Oriented Architecture: Concepts, Technology, and Design

Autor: Thomas Erl

Publicado por Prentice Hall PTR

ISBN: 0-13-185858-0


Service-Oriented Architecture Governance for the Services Driven Enterprise

Autor: Eric E. Marks

Publicado por Wiley Publishing.

ISBN 978-0-470-17125-7


Adopción de SOA para Dummies.

Autores:Miko Matsumura, Bjoern Brauel y Jignesh Shah

ISBN: 978-0-470-48334-3

Publicado por Wiley Publishing.


Introducción a BPM para Dummies.

Autores: Kiran Garimella, Michael Lees y Bruce Williams

ISBN: 978-0-470-37359-0

Publicado por Wiley Publishing.


Papers:

Introducing SCA

autor: David Chappell

Url: http://www.davidchappell.com/articles/introducing_sca.pdf


BPM and SOA

Autor: Mike Rosen

Url:http://www.bptrends.com/publicationfiles/04-08-COL-BPMandSOA-OrchestrationorChoreography-%200804-Rosen%20v01%20_MR_final.doc.pdf


Oracle SCA – The Power of the Composite

Autor: Pat Shepherd

Url: http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle-sca-the-power-of-the-composi-134500.pdf


Fabric3 Reference
 Guide

Url: http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf


Sitios Web:

http://msdn.microsoft.com/webservices/

http://complexevents.com/

http://www.soapatterns.org

http://www.osoa.org/

http://tuscany.apache.org/

http://wso2.com/

http://www.oasis-opencsa.org/

http://blogs.tecsisa.com/



¿Cómo se desarrolla sobre una arquitectura SOA?

El desarrollo sobre una arquitectura SOA debe siempre tener en cuenta las funcionalidades desarrolladas y debe consumir estos servicios y exponer las nuevas funcionalidades. Por lo tanto es importante tener un registro actualizado donde se registran los servicios desarrollados y si la empresa cuenta con sistemas heredados con servicios expuestos se debe realizar un relevamiento de los servicios desarrollados y reflejarlos en el registro. Que el registro esté actualizado y sea visual para todos los desarrolladores es vital para que no exista comportamiento replicado.

El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad.

El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO y publicar la funcionalidad por medio de servicios o utilizar el patrón facade. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas sumado a la arquitectura SOA.

Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás.

Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.
En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.

Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos.

También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección.


lunes, 22 de noviembre de 2010

OSGI y SCA


Antes de empezar vamos a describir estas tecnologías.

OSGI (Open Services Gateway Initiative), podríamos definirlo como un sistema (o framework) modular para Java que establece las formas de crear módulos y la manera en que estos interactuaran entre sí en tiempo de ejecución. OSGI intenta solventar los problemas del tradicional "classloader" de la máquina virtual y de los servidores de aplicaciones Java. En OSGI, cada módulo tiene su propio classpath separado del resto de
classpath de los demás módulos.

SCA (Service Component Architecture) es un estándar de OASIS originalmente creado por diferentes vendedores como BEA, IBM, Oracle, SAP, etc. La especificación SCA define como crear un componente y como estos componentes interactúan para formar una aplicación. Los componentes en SCA pueden ser construidos en Java o en otros lenguajes y además permite interactuar con otras tecnologías como JEE, Spring o BPEL. SCA define un mecanismo común de ensamblaje que indica como los componentes son combinados dentro de la aplicación.
El objetivo de SCA es a nivel alto o de negocios en ca
mbio el objetivo de OSGI esta centrado en la modularidad por lo tanto es de más bajo nivel.

Los Micro-Kernels se volvieron cada vez más populares (jboss, glassfish, ...). OSGi ha estandarizado muchos de los "servicios del núcleo" (registro, configuración, aprovisionamiento) de móviles, y ahora comienza a entrar en la empresas. Considerando que el enfoque JEE fue en la infraestructura de middleware, OSGi provee muchas ventajas que quedaban a cargo de los desarrolladores. La Carga dinámica (Dynamic loading) de OSGi hace perfecto los micro-núcleo, dado que no es necesario bajar el servidor para cargar un modulo, el nucleo tiene solo lo necesario y los módulos se van cargando a medida que se los demande.

La composición de los servicios/componetes se llevará a cabo y se expone como un servicio de negocios con múltiples puntos finales. Este es el lugar donde podemos ver que la pareja OSGi / SCA aporta mucho y ayuda a centrarse en su negocio. Módulos OSGi para gestionar los componentes técnicos para mantener los principios DRY (Don't Repeat Yourself) y SCA para exponer punto final de negocios con conexión automática y la seguridad habilitada.


Este esquema tomado de la página de Apache Tuscany expresa como SCA cablea los servicios de negocio. Como SOA típico, expondrá su "contrato". Dentro de SCA, va a configurar, además, cómo quieres que lo exponga (usando RMI, WS o cualquier tipo de protocolo).
Al hacerlo, le permiten decidir el protocolo en la fase de implementación, no en la fase de desarrollo. Esto hace que su software sea muy flexible y le permiten centrarse en el código de negocio.

Gestión de módulos y componentes y hay dependencias requieren el uso de una herramienta automatizada (Maven, nexus).

Apache Tuscany es una implementación de SCA que en su versión 2.0 traera el esquema OSGI. Apache Tuscany 2.0 fue totalmente reescrito para soportar OSGi.

viernes, 18 de junio de 2010

SCA

Podríamos definir una aplicación como un conjunto de componentes de software interrelacionados. Todos estos componentes están construidos bajo la misma o diferentes tecnologías. Estos componentes pueden correr sobre la misma maquina en un sistema operativo y sobre una misma plataforma o en diferentes procesos, diferentes maquinas con diferentes plataformas y sistemas operativos. Sin embargo una aplicación es organizada para esto es requerido: una forma de crear los componentes y un mecanismo para describir cómo los componentes trabajan juntos.

Service Component Architecture (SCA) define un enfoque general para realizar estas dos cosas. SCA es un estándar de OASIS originalmente creado por diferentes vendedores como BEA, IBM, Oracle, SAP, etc. La especificación SCA define como crear un componente y como estos componentes interactuan para formar una aplicación. Los componentes en SCA pueden ser construidos en Java o en otros lenguajes y además permite interactuar con otras tecnologia como JEE, Spring o BPEL. SCA define un mecanismo común de ensamblaje que indica como los componentes son combinados dentro de la aplicación.

viernes, 14 de mayo de 2010

Apache Tuscany y Spring

Sigo experimentando con Apache Tuscany, hoy el objetivo es hacer un ejemplo con integración con spring. Mismo ejemplo que hicimos en : http://emanuelpeg.blogspot.com/2010/05/desarrollar-un-ejemplo-con-apache.html

Comenzamos escribiendo la interfaz:

@Remotable
public interface ExampleService {

String sayHello();

}

Su implementación :

@Service(ExampleService.class)
public class ExampleServiceImpl implements
ExampleService {

private String hello = "Holasss !!! \n";

public void setHello(String hello) {
this.hello = hello;
}

/**
* @see org.assembly.nornas.ExampleService#sayHello()
*/
@Override
public String sayHello() {
System.out.print("llamaron a Say");
return hello;
}

@Init
public void init() {
System.out.println("Starting with "+ExampleServiceImpl.class + " \n");
}

}

Ahora tenemos que configurar el beans de spring, en un archivo que llamaremos: appcontext-spring.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:sca="http://www.springframework.org/schema/sca"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/sca http://www.osoa.org/xmlns/sca/1.0/spring-sca.xsd ">


<bean id="service.example" class="com.elpaquete.ExampleServiceImpl">
<property name="hello" value="Hola desde Spring!!" ></property>
</bean>


<sca:service name="ExampleService"
type="org.assembly.nornas.sandbox.service.example.ExampleService" target="service.example" />


</beans>

Notaron que además de declarar el bean le indicamos a Apache Tuscany cual es la interfaz de nuestro bean que va a ser un componente de Apache Tuscany.

Ahora escribimos el archivo ExampleSpring.composite:

<?xml version="1.0" encoding="UTF-8" ?>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://nornas"
xmlns:nornas="http://nornas"
name="Example" >

<component name="ExampleServiceComponent">
<implementation.spring location="spring-sandbox.xml" />

<service name="ExampleService">
<interface.java interface="org.assembly.nornas.sandbox.service.example.ExampleService"/>
<binding.ws uri="http://localhost:8080/nornas/ws" />
<t:binding.atom uri="http://localhost:8080/nornas/atom" />
<t:binding.jsonrpc uri="http://localhost:8080/nornas/jsonrpc" />
<t:binding.rss uri = "http://localhost:8080/nornas/rss"/>
<binding.sca />
</service>

</component>


</composite>

Notaron que la implementación del componente no se indica clase si no el archivo appcontext-spring.xml, Apache tuscany va a leer y buscar de ahí la implementación.

Ya lo tenemos, ahora vamos a hacer la clase main:

public class MainSpring {

public static void main(String[] args) throws IOException {

System.out.println("Starting ...");
SCADomain scaDomain = SCADomain.newInstance("ExampleSpring.composite");
System.out.println("Example in "+scaDomain.getURI());
System.in.read();
System.out.println("Stopping ...");
scaDomain.close();
System.out.println();

}

}

Si todo salio bien, en http://localhost:8080/nornas/ws?wsdl va a estar wsdl de su web service soap.

Por ultimo las dependencias de maven:

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6.SEC01</version>
</dependency>


<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-sca-api</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-core-spi</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-policy-security</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-embedded</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-data-api</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.5.3</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-java-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-atom-abdera</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rss-rome</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-ws-axis2</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-jsonrpc-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rmi-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-resource-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-http-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-jetty</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-spring</artifactId>
<version>1.6</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-spring-runtime</artifactId>
<version>1.6</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
</exclusions>
</dependency>

sábado, 8 de mayo de 2010

Desarrollar un ejemplo con Apache Tuscany

Como ven no estoy escribiendo mucho dado que estoy dedicando tiempo a mi tesis. Por esta razón rápidamente vamos a desarrollar un ejemplo con Apache Tuscany.
En otro post les prometo dar más detalles de mi tesis.
Si no leyeron estos posts, sería bueno que lo hagan :
http://emanuelpeg.blogspot.com/2010/02/apache-tuscany_4551.html
http://emanuelpeg.blogspot.com/2010/02/sca.html

La idea es desarrollar un ejemplo facil usando maven.
Veamos la descripción del componente:

import org.osoa.sca.annotations.Remotable;

@Remotable
public interface ExampleService {

String sayHello();

}

Veamos la implementación:

import org.assembly.nornas.service.example.ExampleService;
import org.osoa.sca.annotations.Init;
import org.osoa.sca.annotations.Service;


@Service(ExampleService.class)
public class ExampleServiceImpl implements
ExampleService {

@Override
public String sayHello() {
System.out.print("llamaron a Say");
return "Holasss !!! \n";
}

@Init
public void init() {
System.out.println("Starting with "+ExampleServiceImpl.class + " \n");
}

}

Ahora hay que hacer un archivo composite que describe el componente:
Example.composite

<?xml version="1.0" encoding="UTF-8" ?>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0"
targetNamespace="http://nornas"
xmlns:nornas="http://nornas"
name="Example" >

<component name="ExampleServiceComponent">
<implementation.java class="org.assembly.nornas.serviceImpl.example.ExampleServiceImpl" />

<service name="ExampleService">
<interface.java interface="org.assembly.nornas.service.example.ExampleService"/>
<binding.ws uri="http://localhost:8080/nornas/ws" />
<t:binding.atom uri="http://localhost:8080/nornas/atom" />
<t:binding.jsonrpc uri="http://localhost:8080/nornas/jsonrpc" />
<t:binding.rss uri = "http://localhost:8080/nornas/rss"/>
<binding.sca />
</service>

</component>


</composite>

Ahora vamos a correr todo esto, para lo cual vamos a tener que hacer una clase que tenga el método main:

import java.io.IOException;

import org.apache.tuscany.sca.host.embedded.SCADomain;

public class Main {

public static void main(String[] args) throws IOException {
System.out.println("Starting ...");
SCADomain scaDomain = SCADomain.newInstance("Example.composite");
scaDomain.getURI();
System.out.println("store.composite ready for big business !!!");
System.in.read();
System.out.println("Stopping ...");
scaDomain.close();
System.out.println();
}

}

Ojo hago esto porque no tengo servidor, para otro ejemplo probamos con tomcat o jetty. Internamente Apache tuscany levanta un jetty.

Y Listo!!

Si vamos a esta url: http://localhost:8080/nornas/ws?wsdl deberíamos tener en wsdl de nuestro web server SOAP.
Si fueron observadores vieron que use varios bildings (solo lo hice para probarlos)

Les dejo las dependencias del pom para correr el ejemplo:

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-core-spi</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-policy-security</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-embedded</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-data-api</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
<version>1.5.3</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-java-runtime</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-atom-abdera</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rss-rome</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-ws-axis2</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-jsonrpc-runtime</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-rmi-runtime</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-resource-runtime</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-binding-http-runtime</artifactId>
<version>1.6</version>
</dependency>

<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-host-jetty</artifactId>
<version>1.6</version>
</dependency>

Acabamos de hacer un servicio SOA con Apache Tuscany, muy fácil no?

sábado, 27 de febrero de 2010

Apache Tuscany



Apache Provee soluciones para todo y más todavía. Tuscany 
es una implementación de la especificación SCA.

Apache Tuscany 
provee una infraestructura para facilitar el desarrollo de una Arquitectura orientada a servicios (SOA). Apache Tuscany implementa SCA por lo tanto reduce el costo de desarrollo de soluciones basadas en SOA.

Apache Tuscany 
provee soporte para SCA 1.0. También se integra muy bien con tecnologías web 2.0 y OSGI. Soporta SCO y SDO 2.0 para C++ y 2.1 para Java.


Blogged with the Flock Browser

sábado, 20 de febrero de 2010

SDO

Service Data Objects es una tecnología que permite que los datos sean heterogéneos para arquitecturas SOA. La espacificación SDO fue desarrollada en 2004 en una colaboración entre BEA, IBM y JCP. La versión 2.0 fue parte ya de SCA.
Un modelo simple de programación para desarrollar aplicaciones que utilicen diferentes tipos y fuentes de Datos:
Acceso uniforme a datos de fuentes heterogéneas: XML, RDB, POJO, SOAP, LDAP, JCA, etc.
Soporta modelo desconectado
Provee ambos estilos de programación: Estático (altamente tipado), Dinámico (estilo lenguajes de scripts).
Provee introspección a Metada. Ejemplo: para acceso a los tipos de datos
Es neutral con el lenguaje de programación. Soporte a Java, PHP, C++, etc

SDO reemplaza los diferentes APIs que existen para el acceso a los Datos.
SDO libera al desarrollador de los detalles técnicos del backend de los Datos.
SDO define una forma única y simple de acceso a fuentes heterogéneas de Datos.

SCA

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.

Qué es, concretamente, SCA? Es un conjunto de especificaciones que describen un modelo para construir aplicaciones y sistemas basadas en una Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA). El propósito de este proyecto es doble

· Definir en forma única un modelo de componentes de servicios, tanto para la provisión como para el consumo. Lo novedoso es que esta filosofía procura trascender Java para abarcar también C++, COBOL, PHP o incluso lenguajes basados en XML como BPEL, XSLT o XQuery

· Definir en forma única la manera de ensamblar esos componentes, de referenciarlos para poder construir aplicaciones orientadas a servicios

SCA define la manera de ensamblar servicios web (incluso con otros elementos que no sean Servicios Web como EJB’s, CORBA, etc…) . SCA consiste en un conjuntos de “artefactos” los cuales son definidos en un XML.

Si se quedaron con gansa de más info dejo pdf de IBM:

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-sca/SCA_White_Paper1_09.pdf

http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-sca/SOAProgrammingModelBusinessValue.pdf