SCA (Service Component Architecture) e Java Enterprise Edition

La presentazione "Service Component Architecture (SCA) and Java Platform, Enterprise Edition: Integration Inside", tenuta da Ron Barack e Peter Peshev al JavaOne 2008, auspica un container SCA (Service Component Architecture) nativo all'interno della piattaforma Java Enterprise Edition (alla stregua di quelli standard – EJB, Servlet, ecc.).

Tra i benefici indica:

• protocolli, policy, ecc. celati dal modello di programmazione e dall'infrastruttura SCA (anche all'interno dei componenti Enterprise Edition)

• agevole coinvolgimento, nelle composizioni SCA, del codice Enterprise Edition già sviluppato

• utilizzo, anche per i deployment SCA, degli strumenti già consolidati sugli Application Server – monitoraggio, ciclo di vita, ecc.

SCA, in tal modo, diverrebbe un'estensione della piattaforma Java Enterprise Edition, non un concorrente.

Tutti i più grandi produttori di software, Sun compresa, aderiscono all'iniziativa di SCA presso Oasis, vedremo.

—-><—-

Sullo stesso argomento:

• OSOA: SCA & Java EE Integration

• InfoQ: Strengthening the Alliance Between Java EE and SCA

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

SCA e JBI

SCA (Service Component Architecture) è un modello a componenti per applicazioni di business. E’ definito da un certo numero di specifiche Oasis: implementazione dei componenti (Java, C++, BPEL e Spring), modalità di composizione, binding permessi (SOAP, JMS e EJB) e policy (sicurezza e affidabilità).

JBI (Java Business Integration) è un modello a componenti principalmente per soluzioni di integrazione. E’ definito dalle specifiche Java JSR-208 (JBI 1.0) e JSR-312 (JBI 2.0).

La presentazione “The Best of Both Worlds with Java Business Integration and Service Component Architecture”, tenuta al JavaOne 2008 da Jos Dirksen e Tijs Rademakers, suggerisce come queste due tecnologie possano convivere cooperando: un container SCA che “gira” come Service Engine all’interno di un container JBI.

Come beneficio il riuso: ad esempio Binding Component JBI esistenti utilizzabili come binding non previsti dalle specifiche SCA.

E’ da valutare: nel caso dei binding, ad esempio, si potrebbe considerare anche di estendere il container SCA (programmando – se open source si dispone del codice, solitamente modulare e la specifica permette le estensioni) o di utilizzare un broker (intermediario stand-alone – riflettere sulle prestazioni e sull’assetto di produzione).

—-><—-

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

SCA: modello di programmazione per SOA

SCA (Service Component Architecture), insieme di specifiche Oasis, si propone come modello di programmazione per SOA (Service Oriented Architecture).

SCA consente di scomporre l’applicazione in componenti riutilizzabili, ricomponibili tra loro, raggiungibili dall’esterno con protocolli diversi, e capaci, a loro volta, di accedere a servizi esterni.

In molti credono che questa nuova tecnologia sia valida; ne sono convinto anch’io.

SCA è definita, come accennato, da un certo numero di specifiche Oasis:

• implementazione dei componenti (Java, C++, BPEL e Spring)

• modalità di composizione

• bindings permessi: SOAP, JMS e EJB

• policies (sicurezza e affidabilità)

SCA prevede che l’implementazione dei componenti si curi della sola logica di business: le interfacce nascondono il colloquio con altri componenti o con servizi definiti all’esterno (dipendenze) e i bindings, le policies e la composizione sono indicati su file XML di configurazione.

SCA, quindi, permette di:

• concentrarsi sulle logiche di business piuttosto che sulle logiche di infrastruttura

• disporre di un’infrastruttura sufficiente agli scopi ed, eventualmente, capace di concentrare in un unico punto il governo

• comporre componenti a “grana grossa” a partire da componenti a “grana piccola”

• riutilizzare componenti in ambiti diversi (quindi anche con trasporti e policies differenti)

• avere l’applicazione come intrinsecamente distribuibile su più containers

• usare il protocollo più adatto, più efficiente o, semplicemente, più alla moda

• disporre delle policies comunemente richieste

Quanto SCA prevede è sorprendentemente in accordo con il SOA Reference Model di Oasis che definisce SOA come un paradigma per organizzare e utilizzare capabilities distribuite e i servizi come meccanismi per accedere, attraverso un’interfaccia, a queste capabillities, consistentemente con vincoli e policies specificate dalla descrizione del servizio stesso.

Da osservare, inoltre, come il SOA Reference Model specifichi chiaramente che benché SOA sia comunemente implementata usando Web Services, i servizi possono essere esposti anche tramite altre tecnologie.

—-><—-

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