Per la costruzione di una SOA, Sun consiglia un disegno (e un investimento) globale. Che si può ripagare come fanno le utilità
Con l’acquisizione di SeeBeyond dello scorso anno, Sun ha messo i piedi nel territorio delle Service oriented architecture, mettendosi a fianco di rivali del middleware come Ibm o Bea Systems. Il risultato dell’operazione ha dato i suoi frutti con Java Composite Application Platform Suite (Java Caps), un set di strumenti di integrazione, inseriti in Java Enterprise System, per far comunicare vari pezzi applicativi con la minima attività di codifica. Java Caps comprende quattro suite: le nuove Sun Java B2b Suite (per le integrazioni su network distruibuiti) e Java Esb Suite (l’Enterprise service bus) e le esistenti Java Application Platform (creazione di portali da applicazioni composite) e Java Web Infrastructure (con l’identity management). La valenza della proposta la spiega Ross Altman, Cto of Business Integration Plaftorms. «Le tecnologie associate a una SOA sono molte. Si può scegliere di acquistarle da più fornitori, ma il prodotto ideale, secondo noi, è completamente integrato. Sun fa questo, grazie ai puri open standard di Java Enterprise Edition». Anche Sun dà un senso di SOA al di là della tecnologia, facendo capire come l’avvio di un progetto debba essere per sua natura “globale”. «Adottare SOA – ha spiegato Altman – significa non solo decidere un’architettura, ma anche la metodologia e la governance: chi detiene il progetto, per chi è, chi decide i criteri e quali sono. Se si è “risicati” con l’allocazione di tempo, risorse e investimenti, non si potrà essere soddisfatti del risultato». Sun usa il seguente motto: “think big, start small, scale fast”. Significa approntare un disegno globale ma partire da processi singoli, perché qui si cela la complessità. «Si potrebbero impiegare mesi per definire gli oggetti di business relativi a tutte le attività aziendali, con i dati e le policy associate – ha precisato il manager -. Realisticamente, penso che non sia possibile». Infine, è consigliabile scalare velocemente perché così si sfruttano i benefici del riutilizzo dei processi: una volta costruita la prima applicazione SOA si può realizzarne una seconda agevolmente, per lo meno se si resta nel medesimo ambito. Sun non nasconde che i costi dell’infrastruttura software possono essere “pesanti” e non si ammortizzano con il primo progetto. Tra l’altro, si pone un problema di “attribuzione”, dato che ciascuna linea di business vuole pagare solo per la tecnologia che utilizza. Altman propone un’idea mutuata dalle utility: come per l’erogazione dell’elettricità, chi si sobbarca l’investimento in infrastruttura (magari il dipartimento It), potrà far pagare a chi si collega in base a ciò che consuma.
