SCA (Service Component Architecture): introduzione

SCA (Service Component Architecture) è un paradigma per sviluppare applicazioni aggregando componenti. Individuato inizialmente da un consorzio di produttori (BEA ed IBM poi Oracle, SAP, …) è ora sotto l’egida di Oasis (organismo di standardizzazione).

Le specifiche descrivono come sviluppare componenti, come configurarli e come comporli.

SCA è stato pensato per essere applicabile a più tecnologie contemporaneamente: i componenti possono essere sviluppati con Java, C++ o con altri linguaggi e risultare comunque aggregabili tra loro; nell’aggregazione possono essere coinvolti anche applicazioni e componenti non SCA.

I componenti aggregati possono risiedere in un unico processo, su più processi eseguiti sulla medesima macchina o su macchine diverse.

Le composizioni ottenibili dall’aggregazione di componenti e altre composizioni sono descritte tramite un file XML che segue il formato SCDL (Service Component Definition Language). Mediante questo file è possibile indicare i componenti e le composizioni da aggregare, la loro implementazione, le proprietà che richiedono (inversione di controllo), i punti di accesso che espongono (binding), le policy che esigono (sicurezza, affidabilità, …) e le dipendenze (altri componenti o composizioni cui fanno riferimento); anche per il risultato della composizione (il service) è possibile esporre uno o più punti di accesso (binding) e richiedere che un certo numero di policy vengano soddisfatte.

Il “contesto” in cui questi componenti sono eseguiti implementa le comunicazioni, astraendo ciò che realmente avviene e provvedendo ad esporre ciò che è esplicitamente richiesto mediante i binding indicati nel file di configurazione (utili per l’invocazione tra “contesti” diversi e per esporre il risultato, o “parte”, di una composizione).

Il “contesto” cui accenno coincide con il concetto di Dominio. Un Dominio è l’insieme di componenti che “girano” su runtime dello stesso produttore (comprendente processi e macchine diverse); il Dominio implementa le diverse modalità di comunicazione (intra-processo, inter-processo e binding).

L’implementazione di queste modalità sono del tutto nascoste al programmatore: tramite assertion ed API si ottengono le comunicazioni implicite (tra componenti SCA) e quelle esplicite (i binding) senza la necessità di conoscerne i dettagli; il “contesto”, inoltre, grazie alle interfacce, astrae dalla “natura” dell’oggetto con cui si interagisce (web service, EJB, …) permettendo al programmatore di non curarsene.

L’obiettivo dell’attuale specifica è quello della portabilità del codice, ciò che è sviluppato con un certo linguaggio in un certo Dominio può essere eseguito in un altro Dominio ottenendo gli stessi effetti: SCA è, in poche parole, un’interfaccia standard implementata dai diversi produttori in modo proprietario (alla stregua di molte altre specifiche).

La specifica non impone le modalità di comunicazione tra Domini diversi, semplicemente ne offre la capacità: qualora si pensi di avvalersene inevitabilmente si dovrà procedere alla contrattazione di interfacce, qualità del servizio e così via.

L’interazione con l’esterno è totalmente supportata: applicazioni non SCA, ad esempio, possono invocare composizioni o componenti SCA mediante i binding esposti ed i componenti SCA, a loro volta, possono invocare web service, EJB o accedere a database usando ciò che il linguaggio in uso mette a disposizione o ciò che il “contesto” SCA offre (in quest’ultimo caso l’implementazione di interfacce e la loro indicazione come dipendenze nel file SCDL maschera le modalità di comunicazione che avvengono, specie se si tratta di Domini diversi, mediante web service).

SCA, concludendo, sembra una specifica piuttosto promettente:

• Modalità di comunicazione preconfezionate (offerte dal “contesto”)

• Sostanziale riduzione del codice scritto (grazie alle assertion ed a ciò che il “contesto” offre)

• Netta separazione tra la logica ed i dettagli di comunicazione (anche con l’esterno, ancora grazie al “contesto”)

• Riuso dei componenti e delle composizioni (al solito, se prodotti con un ciclo di vita adeguato)

• Aggiunta e rimozione di binding e policy agendo unicamente sul file SCDL

• Possibilità di assortire componenti sviluppati in casa ed acquisiti

• Esposizione di binding standard (ad esempio web service)

• Distribuzione di componenti accedibili con standard

• Implementazione mediante linguaggi diversi

• Schematizzazione dell’applicazione mediante il file SCDL

—-><—-

Già presenti sul mercato alcune implementazioni opensource (Apache Tuscany e Fabric3), a breve saranno rilasciate anche implementazioni commerciali (ad esempio Bea).

—-><—-

Sullo stesso argomento:

• David Chappell’s Blog: Introducing SCA

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione