Mi chiamo Andrea Gumina. Sono laureato in Scienze dell'Informazione e lavoro per un'azienda di consulenza IT. Da qualche anno mi occupo di integrazione di sistemi, di SOA (Service Oriented Architecture) da poco meno di due.
la questione è risolta offrendo sempre entrambi? (vedi ad esempio le API di Flickr)
oppure, più ragionevolmente, le circostanze e il problema determinano uno o l’altro?
La presentazione che Paul Fremantle condivide su Slideshare (tenuta all’ApacheCon 2008) fa chiarezza sulla controversia, evidenzia fatti su cui riflettere e consiglia di scegliere ciò che è più appropriato per il problema e la situazione.
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.
Mi ricordo quando, nella prima metà degli anni novanta, munito della guida Doctor Bob’s Guide to Offline Internet Access, iniziavo ad esplorare internet grazie ad un account di posta elettronica che una BBS (Bulletin Board System) mi offriva gratis.
La presentazione fatta da Andy Denmark e pubblicata su Slideshare, anacronisticamente (sicuri?) parla di posta elettronica, partendo da semplici constatazioni:
tutti la usano (anche se contemporaneamente ad altri mezzi)
cattura l’attenzione per buona parte della giornata (non solo tramite computer, aggiungo)
veicola tante e “interessanti” informazioni che rimangono chiuse all’interno dell’inbox
Procedure automatiche potrebbero offrire servizi a valore aggiunto consumando questi dati.
La presentazione descrive quattro possibili categorie di servizi che potrebbero interagire, o che già interagiscono, con la nostra posta elettronica.
