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.
Figura 1 - Service Oriented Architecture
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).
Figura 2 - Tecnologie ARAD
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.
Figura 3 - Impiego pragmatico di MDA
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)
Tali
modelli costituiscono nel loro complesso il Business
Model di partenza, e sono la chiave per il successivo
sviluppo della applicazione enterprise, giacchè
è ad essi che vanno applicati i transformation
patterns sopra citati. Sono dunque questi modelli di
partenza la base cui dedicare molta attenzione, ed è
proprio per tale motivo che esiste un formalismo appositamente
messo a punto per disegnarli: stiamo parlando di UML
e dei diversi diagrammi che con UML stesso possono essere
realizzati, ciascuno dedicato a descrivere diverso aspetto
della nostra realtà di business.
In figura 4 un esempio di Class Model (UML Class Diagram),
Figura 4 - Esempio di Class Model
in
figura 5 un esempio di Process Model (UML Activity Diagram)
Figura 5 - Esempio di Process Model
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).
Figura 6 - Business Process Automation
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.
Bibliografia
[1]
D. Frankel "SOA and MDA" - MDA Journal, June
2005, copia on-line su http://www.bptrends.com/
[2]
Mokabyte - "Uso della Model Driven Architecture
nello Sviluppo di Applicazioni J2EE", parte 1 http://www.mokabyte.it/2004/07/mda-1.htm
e parte 2 http://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 l'Enterprise Application
Integration, i Portali Web, gli strumenti di Business
Process Modeling.
|