Ultimamente c’è molto rumore attorno ai tentativi di standardizzazione legati al mondo SOA. I due standard più promettenti sembrano essere JBI e SCA (quest’ultimo recentemente trasferito a OASIS).

Si tratta di standard che spesso vengono presentati in contrapposizione, ma la realtà è diversa, come risulta evidente dall’analisi degli obiettivi che si pongono.

L’obiettivo di SCA è la definizione di un modello architetturale coerente con SOA e la specifica delle relative API. I componenti di SCA devono contenere logica di business (che può essere scritta utilizzando diversi linguaggi come Java, C++ e BPEL) e possono a loro volta essere composti per produrre ulteriore logica, collegati tramite binding standard. Si tratta quindi un modello estendibile per la costruzione e l’evoluzione dei sistemi informativi.

JBI invece, basandosi su un modello architetturale a bus (ESB), si occupa in maniera più specifica di integrazione. JBI non prevede un set di implementazioni “iniziali”: descrive due tipologie di componenti (binding component e service engine) che devono essere installabili su qualunque ESB JBI-compliant. Questo significa che, se si hanno esigenze di integrazione di qualunque tipologia, possono essere risolte procurandosi i componenti JBI adatti alle proprie esigenze. Un esempio di questo sono i componenti Jbi4Corba e Jbi4Cics sviluppati da Gruppo Imola.

In sintesi si tratta di specifiche sostanzialmente diverse (anche se entrambe basate su concetti SOA): JBI è orientato all’integrazione ed è meno vincolante di SCA che, dall’altra parte, si pone degli obiettivi più ambiziosi.

Non ci sono però reali sovrapposizioni! Si può tranquillamente ipotizzare in futuro di utilizzare sia SCA che JBI allo stesso tempo, ottenendo quindi i vantaggi di entrambi. Ad esempio, integrando servizi SCA su un bus attraverso un opportuno Service Engine JBI, potremmo avere i vantaggi del modello SOA di SCA uniti alla capacità di integrazione assicurata da JBI.