Lo scenario che analizzeremo in questo articolo, è un tipico scenario di integrazione dei servizi di una azienda che si ripropone di fornirli attraverso molteplici canali ai propri clienti o fornitori.
La multi canalità offre alle aziende l’opportunità di aggiungere
al proprio business aree di mercato sempre più ampie, rendendo disponibili
i propri servizi ad un pubblico raggiungibile attraverso i canali preferenziali.
Il costi in tecnologia legati alla multi canalità in una azienda, sono
fortemente dipendenti dagli standard adottati e quindi dall’aumento dell’infrastruttura
richiesta dai sistemi. Un secondo aspetto è che incide notevolmente sui
costi, è la complessità nell’integrare i sistemi tipicamente eterogenei
che sono di supporto al business dell’azienda stessa; questo aspetto prende il
nome di integrazione delle applicazione aziendali (EAI – Enterprise Application
Integration).
Architettura di sistema
Nell’affrontare la progettazione di una soluzione per la multi canalità
e l’EAI al fine di avere un veloce ritorno sugli investimenti, ci ripropone
fondamentalmente di definire delle soluzioni per le seguenti tematiche:
– Unificazione dei sistemi esistenti
– Standardizzazione dell’accesso ai servizi
– Standardizzazione dell’integrazione alle applicazioni aziendali
Unificazione dei sistemi
La progettazione di un sistema unico di accesso attraverso più canali ha
lo scopo di ridurre al minimo le duplicazioni dei sistemi e di fare convogliare
per quanto possibile tutti gli sforzi su di un’unica soluzione.
In pratica si tratta di passare da una architettura A, tipica di una azienda che
nel corso degli anni a adottato nuove soluzioni per fare fronte alle problematiche
della multi canalità, alla architettura B di nuova concezione.
L’introduzione di una architettura siffatta comporta che venga definita una interfaccia
verso il nuovo sistema e che questa usufruibile da tutti i client (canali) indipendentemente
dalla tecnologia su cui essi sono basati.
Adozione di uno standard
La definizione di uno standard d’interfaccia svolge un ruolo chiave per
definire una architettura funzionale ed estendibile, i cui costi di implementazione
e manutenzione decrescono con il tempo.
Lo standard WSDL e SOAP su Http hanno tutte le caratteristiche richieste per essere
un candidato ideale: lo standard WSDL definisce in modo preciso e ricco le interfacce
a metodi di applicazioni, mentre SOAP definisce un protocollo di invocazione di
essi molto estendibile. Esistono inoltre svariati client SOAP su diverse tecnologie
che lo rendono adatto allo scopo di poter definire una interfaccia indipendente
dalla piattaforma e di facile integrazione.
Un vantaggio notevole nell’uso di questo standard, viaggiando esso su Http
e non essendo session-oriented (non viene gestita nessuna sessione nel protocollo
SAOP) è che è estremamente semplice bilanciare il carico di lavoro
su una server farm attraverso Load Balancer (hardware o software) del carico di
rete. Questo garantisce alte performance e robustezza ai guasti.
Considerazioni ulteriori sull’adozione di SOAP:
Vanno fatte alcune considerazioni ulteriori per adottare tale standard. Va in
fatti tenuto in considerazione che il protocollo SOAP è estremamente estendibile
ma che allo stato attuale non esente uno standard definito per la gestione degli
aspetti quali la sicurezza, o sulla garanzia di invio dei dati, e soprattutto
essendo basato sul trasporto Http esso non è transazionale; inoltre SOAP
viene considerato "prolisso", di fatto tutte le informazioni viaggiano
in XML il che può comportare un notevole overhead di rete e di parsing
dei dati, questo lo rende poco adatto in applicazioni real time.
In merito a questo molto però si sta facendo, oggigiorno vari consorzi
di aziende pubblicano soluzioni proposte come standard per la soluzione a questi
problemi.
