Partire dai requisiti di business per costruire un modello che implementi in modo affidabile un‘architettura di tipo SOA. Troppo complesso? No, se partiamo col piede giusto! E‘ infatti di fondamentale importanza individuare e applicare un approccio metodologico completo, che parta dai requisiti di business, si traduca successivamente in una architettura solida e di qualità, possegga meccanismi per implementarla adeguatamente secondo quanto richiesto dalle specifiche SOA
Introduzione
L‘idea di mettere la nostra infrastruttura applicativa in grado di offrire i propri servizi ad altre applicazioni tramite rete è nata in ambito CORBA all‘inizio degli anni ‘90, ben prima dell‘avvento delle architetture cosiddette Service Oriented (abbreviate in SOA), in cui la “rete” (all‘epoca di CORBA denominata in modo abbastanza pittoresco “meganet”) è oggi la rete Internet (rif.[1]). In effetti in questi ultimi tempi si è parlato molto di SOA, grazie anche alla sempre maggiore diffusione della tecnologia Web Services, che proprio in ambito SOA giocano un ruolo da protagonisti. Tuttavia, pensare di implementare in modo efficiente e affidabile una SOA rivolgendo il proprio focus al solo sviluppo di Web Services non è la soluzione migliore. E‘ infatti di fondamentale importanza individuare e applicare un approccio metodologico completo, che parta dai requisiti di business, si traduca successivamente in una architettura solida e di qualità , possegga meccanismi per implementarla adeguatamente secondo quanto richiesto dalle specifiche SOA e porti a una infrastruttura applicativa facilmente manutenibile e, al tempo stesso, estremamente flessibile a rispondere a eventuali cambiamenti. Stiamo chiedendo un pò troppo? Forse no, e ne parleremo in questo articolo.
Service Oriented Architecture (SOA)
Con l‘avvento dei Web Services è nato un diverso e più evoluto modo di concepire la possibilità di fornire servizi applicativi, sfruttando quel gigantesco canale di intercomunicazione che è la rete Internet. Come è noto, un Web Service non è molto diverso da un componente software “tradizionale”. Ciò che lo differenzia è un ristretto – ma significativo – insieme di caratteristiche, e cioè:
- è univocamente individuato da un identificativo (detto URI, concettualmente analogo al ben noto URL)
- la sua interfaccia è descritta in un file XML
- può essere reperito da altri sistemi software
Gli Web Services giocano un ruolo centrale nelle cosiddette Service Oriented Architecture (SOA), di cui possono costituire i componenti base e in cui trovano definiti i propri elementi caratteristici, quali operazioni, tipi dati, indirizzi di rete ecc.
In generale, una SOA è sostanzialmente un sistema in cui sono definiti tre ruoli e tre operazioni, ossia:
Ruoli
- Service Provider, chi fornisce il servizio e ne pubblica la descrizione per reperirlo
- Service Consumer, chi usufruisce del servizio, in sostanza l‘applicazione che ne richiede una o più funzionalità
- Service Broker, chi gestisce le descrizioni dei servizi pubblicati, rendendole disponibili
Operazioni
- Publish, azione tramite cui un servizio pubblica la propria descrizione (una sorta di “carta d‘identità del servizio)
- Find, azione tramite cui chi cerca un servizio “consulta” l‘insieme delle descrizioni disponibili
- Bind, azione tramite cui chi ha trovato il servizio richiesto si “lega” a chi lo fornisce, usufruendone e in tal modo invocandone le funzionalità
In figura 1 è riportata una schematizzazione della SOA.
Impiegare la SOA
D‘accordo, vada per la SOA per i nostri obiettivi di business, ma ecco immediatamente il problema successivo: come realizzarla in modo pratico, efficiente e soprattutto affidabile? In effetti, molti sono i casi in cui aziende di ragguardevoli dimensioni decidono di procedere a implementare architetture Service Oriented, ma lo fanno con strumenti tradizionali, spesso semplicemente “raccogliendo a piene mani” dal proprio parco applicativo una serie di componenti software e predisponendone l‘uso – in modo talora alquanto artigianale – a mò di Web Services. Va da sè che questo porta spesso a implementazioni frammentarie e alquanto costose (in termini di tempo e denaro) che, anche se più o meno compatibili con le specifiche tecniche di una SOA, perdono l‘allineamento con gli obiettivi di business che dovrebbero essere alla base di quanto una SOA dovrebbe poter offrire. In sostanza il problema non è soltanto di “promuovere in avanti” la propria infrastruttura a un livello SOA – ad esempio “pubblicando” sul Web i propri componenti – ma anche di “guardare indietro”, facendo in modo che essa rifletta in pieno, in modo efficace ed efficente, il proprio business. Il problema quindi comincia a cambiare formulazione: quale soluzione o metodologia scegliere per colmare questo gap tra business requirements e architettura IT, e che porti a una infrastruttura che sia “SOA-compliant”?
Il parere degli analisti
La risposta ci viene direttamente dal gran numero di storie di successo che documentano come un approccio basato su metodologie e tecniche di modellazione possa essere la strada ideale. Stiamo parlando di impiegare in modo pragmatico la Model Driven Architecture (MDA, vedere rif.[1] e rif.[2]). E‘ proprio grazie all‘impiego di tale metodologia che è possibile rendere veloce ed efficiente la realizzazione di potenti architetture di livello enterprise che se da una parte sono totalmente compatibili con i propri business requirements, dall‘altra sono completamente allineate con le specifiche tecniche richieste dalla SOA. Su questi aspetti diverse community di analisti si sono pronunciate in modo chiaro e dettagliato. Ad esempio, in uno studio condotto da Gartner Group (rif.[3]), gli autori descrivono una serie di risultati raccolti presso aziende che hanno impiegato con successo MDA nell‘ambito di tool cosiddetti ARAD (Architected Rapid Application Development). Secondo quanto affermano gli autori, il valore aggiunto di un simile approccio è dovuto a diversi fattori tra cui:
- costi sostenuti minori rispetto al previsto (fino a un quinto del previsto budget per l‘intero sviluppo) per acquisizione di tool ARAD, compresi i costi di training
- ROI maggiore del previsto, oltre il 900% in media
- aumento della produttività maggiore del previsto, grazie all‘impiego di tool e tecniche ARAD
Gli ARAD tool vengono considerati “facili da apprendere e in grado di garantire elevata produttività “. Le applicazioni sviluppate con tali tool sono considerate “rapide da mettere in esercizio, più performanti e di qualità media elevata” (fig. 2).
Gartner Group non è la sola a descrivere questi aspetti. Uno studio pubblicato da Middleware Company (rif.[4]), mette a confronto, scegliendo una applicazione J2EE-tipo (la ben nota PetStore di Sun, vedere rif[5]), l‘impiego di un tool tradizionale e l‘impiego di un tool che adotta un approccio ARAD basato su tecniche di modellazione MDA. Il risultato – ampiamente documentato nello studio citato – è sorprendente: 35% di aumento della produttività a favore del tool ARAD/MDA senza alcuna perdita di qualità . Un ulteriore studio, condotto dall‘azienda EDS, effettua un confronto tra il numero di linee di codice da scrivere manualmente necessarie a implementare la Java PetStore Application utilizzando uno strumento MDA e la quantità di codice da scrivere impiegando un tool tradizionale. I risultati – 610 linee nel caso MDA, 14.273 nel caso IDE tradizionale – parlano da soli)
Modellare il business
Impiegare MDA in modo pragmatico significa unire alla potenza espressiva dei modelli l‘efficacia e l‘efficienza di quei meccanismi necessari a trasformare un modello in un altro – i cosiddetti transformation patterns – il cui ruolo chiave in ambito MDA è esemplificato nella figura 3.
In tal modo è possibile creare applicazioni complesse di livello enterprise attraverso l‘impiego di un insieme di modelli sviluppati a partire dai business requirements, e precisamente:
- Un modello che riflette la struttura delle informazioni che l‘applicazione dovrà utilizzare (Class Model)
- Un modello che riflette gli aspetti comportamentali dell‘applicazione (Service Model)
- Un modello che riflette l‘esatta sequenza in cui i diversi task devono essere eseguiti (Process Model)
In figura 4 un esempio di Class Model (UML Class Diagram)
In figura 5 un esempio di Process Model (UML Activity Diagram)
Il passo successivo: Business Process Automation
Una volta ottenuta una solida e stabile infrastruttura di livello enterprise in grado di mappare senza soluzione di continuità i requisiti di business (punto di partenza) con le specifiche tecniche di una SOA (punto di arrivo), il passo successivo che consegue in modo logico consiste nell‘individuare e comprendere l‘esatta sequenza di componenti e sub-componenti necessari ad eseguire un determinato processo – fase detta tipicamente di orchestrazione (fig.6).
Siamo dunque arrivati a una architettura orientata al servizio (SOA), che grazie all‘impiego pragmatico di MDA riflette completamente il nostro business e che opera adesso come esecutore di processi aziendali attraverso un workflow engine basato sulla cosiddetta “orchestration technology”. Verrebbe quindi la curiosità di estendere ulteriormente il discorso e di esplorare le potenzialità di questo nuovo ambito, la cosiddetta Business Process Automation….ma questa è un‘altra storia, e ne parleremo prossimamente!
Conclusioni
Mettere in piedi una solida infrastruttura applicativa di livello enterprise in grado di implementare i propri processi di business in modo tanto efficiente da rispondere con prontezza agli eventuali cambiamenti, e che sia al tempo stesso in grado di offrire servizi all‘esterno – tramite il Web – nel modo previsto dalle specifiche SOA. Come risolvere questo problema in modo efficace ed efficiente? Impiegando la modellazione MDA in modo pragmatico, cioè assieme ai cosiddetti transformation patterns, necessari per mappare tra loro i modelli MDA. Nel presente articolo si è cercato di discutere come le diverse esigenze – tecnologiche da un lato, di business dall‘altro – potessero trovare in questo tipo di approccio una soluzione completa, affidabile ed estremamente flessibile, fino ad affacciarsi sulla soglia del passo immediatamente successivo, laddove i Processi di Business stessi vengano gestiti in modo “orchestrato”: la Business Process Automation.
Riferimenti
[1]
D. Frankel “SOA and MDA”, MDA Journal, June 2005
http://www.bptrends.com/
[2]
Mokabyte, “Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE”, parte 1 e 2
https://www.mokabyte.it/2004/07/mda-1.htm
https://www.mokabyte.it/2004/09/mda-2.htm
[3]
M. Blechar – M. Hotle, “ARAD Methods and Tools: Improve Productivity and ROI”, Gartner Group, October 11, 2004
[4]
Middleware Company “Model Driven Development for J2EE utilizing a Model Driven Architecture (MDA) Approach”
http://www.compuware.com/products/optimalj/1794_ENG_HTML.htm
[5]
Sun Microsystems “The Java Petstore Application”
http://java.sun.com/developer/releases/petstore/
Doriano Gallozzi è nato a Roma nel 1964 e si è laureato in Ingegneria Elettronica (indirizzo Informatica) nel 1989. Da sempre interessato a problematiche di analisi, progettazione e sviluppo di Sistemi Informativi, ha lavorato per diversi anni in aziende del settore informatico italiano (gruppo ENI, gruppo Telecom Italia), dove ha acquisito diverse esperienze tanto nel campo della progettazione e sviluppo del software (in ambiente M/F come in ambiente distribuito) quanto nel campo dei RDBMS (DBA su diversi progetti per clienti finali quali Telecom Italia). Da gennaio 2000 lavora nella Divisione Prevendita di Compuware Italia. La sua attività verte principalmente sulla piattaforma J2EE e tecnologie correlate, ma anche su ambiti tecnologici quali le soluzioni di Project Management per IT-Governance, i Portali Web, gli strumenti di Business Process Automation, l‘Enterprise Application Integration.