Descrizione principale |
Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 by IBM Corporation. Tutti i diritti
riservati.
Argomenti
Questo documento descrive il terzo aggiornamento al RUP (Rational Unified Process) incentrato su SOA (Service-Oriented
Architecture). Questo aggiornamento rappresenta una pietra miliare importante nella guida RUP relativa a SOA poiché
fornisce un metodo unificato combinando il RUP precedente per il contenuto SOA con il contenuto dal metodo IBM GBS (Global Business Services) Service-Oriented Modeling and Architecture (SOMA). Il metodo SOMA è stato correttamente utilizzato
da IBM in un numero di operazioni client e mentre è stato sviluppato inizialmente utilizzando il metodo GS Global
Services IBM, si pensa che nell'area di SOA sia IBM che i clienti potrebbero beneficiare più da un approccio del metodo
unificato che da due metodi separati. Quando si guarda ai due metodi, è chiaro che gli autori avevano in mente uno
scopo simile e avevano strutturato i metodi in modi simili - infatti i due team si sono incontrati nel 2004 e hanno
eseguito alcune modifiche ai metodi e alla terminologia di allineamento. Mentre questo allineamento non è
necessariamente sorprendente poiché entrambi i metodi sono focalizzati sulle attività pragmatiche di sviluppo della
soluzione orientata al servizio, si è notato che un framework generico potrebbe essere estratto in modo che sia in
grado di descrivere i metodi ad un livello alto.
Per i clienti che conoscono Classic RUP è possibile che si desideri rivedere Concetto: Sviluppo delle soluzioni orientate al servizio.
Per lo staff IBM che conosce SOMA è possibile che si desideri rivedere Roadmap: Transizione da IBM SOMA.
Il seguente diagramma illustra il framework su menzionato. Questo rappresenta un insieme neutrale del metodo richiesto
dal processo per lo sviluppo di soluzioni orientate al servizio. Ora, questo diagramma è significativamente
semplificato dal contenuto del metodo ma rappresenta chiaramente le attività chiave di entrambi i metodi --
Identificazione del servizio, Specifica del servizio e Realizzazione del servizio. Nell'area del prodotto di
lavoro era chiaro che c'era molto allineamento concettuale. Simili prodotti di lavoro sono richiesti con ruoli e
azionisti simili, ma in alcuni casi sono stati realizzati in modo diverso; ad esempio, come un modello UML o un
documento Word. Questo è visto come un allineamento semplice da eseguire. Di nuovo, in generale le influenze più
importanti corrispondono bene alle attività sebbene, ovviamente, la realtà è che tutti i requisiti hanno un rapporto
con tutte le attività.
Figura - Il framework del metodo SOA unificato
È possibile espandere un ulteriore livello del framework, poiché le attività qui identificate sono supportate da un
numero di tecniche ed è nell'area delle tecniche dettagliate che avviene l'integrazione dei metodi. Questo documento
non fornisce il dettaglio sull'integrazione della tecnica, tuttavia, è importante notare che lo sviluppo di un metodo
singolo e coerente porta ad alcune modifiche in entrambi i metodi utilizzati come punti di inizio per assicurare che il
lettore veda una coerenze nel concetto, nell'approccio, nell'attività e nelle definizioni del prodotto di lavoro. Una
decisione, ad esempio, che fornisce un livello di coerenza al contenuto è di utilizzare il RUP esistente per il
prodotto di lavoro SOA: il modello di servizio come origine principale dalla quale un numero di report testuali e
tabelle può essere generato per fornire i prodotti di lavoro previsti dai professionisti SOMA. In generale questa
modifica fornisce il valore che il modello del servizio UML ha altre semantiche e può essere utilizzato per sviluppare
la specifica del servizio e i modelli di realizzazione, tuttavia il modello del servizio deve essere esteso per
riportare ulteriori informazioni richieste dai prodotti di lavoro SOMA esistenti; ad esempio, il prodotto di lavoro: la
specifica del servizio è stato estesa con altre origini di proprietà e stato che riporta le informazioni utilizzate di
routine dai professionisti SOMA.
Il plugin è basato sulle seguenti idee guida:
-
Consentire una crescita futura; ridurre al minimo o evitare i vincoli su aggiunte di attività future, prodotti
di lavoro, ruoli, ecc...
-
Conservare la capacità di aggiungere le estensioni del proprietario a metodi commerciali correnti o futuri: ad
esempio, le estensioni specifiche del settore, o gli asset in SOMA; è inoltre possibile aggiungere il contenuto del
proprietario al framework per l'utilizzo del servizio
-
Coprire la messaggistica rivolta al cliente e interna a IBM
-
Il metodo deve rimanere scettico riguardo agli strumenti, ma fornisce le linee guida dell'integrazione per le guide
agli strumenti, favorendo il portafoglio IBM
-
Abilitare le funzioni delle attività del metodo piuttosto che limitarle in base al metodo GS o RUP o piuttosto
altri metodi legacy.
Questo aggiornamento al RUP (Rational Unified Process) ha lo scopo di introdurre una guida per l'Architetto del software ed il Progettista nello sviluppo di un Modello del servizio, un modello che rappresenti un portafoglio
di servizi che è possibile utilizzare come base per le attività di implementazione già nel RUP. L'intento è anche
quello di descrivere la connessione tra il modellamento del business ed il modello del servizio. Molti progetti SOA
(Service-Oriented Architecture) utilizzano il modello del processo business per comprendere il business, i requisiti
funzionali ed i servizi richiesti come supporto ad un processo.
L'ambito di questo aggiornamento è stato trattato brevemente nell'introduzione, ma qui verranno trattati l'insieme dei
requisiti e delle istruzioni dell'ambito utilizzati come guida al progetto.
-
Bilanciamento del RUP esistente; in questo caso significa che dove possibile verranno descritte
nuove attività e nuovi prodotti di lavoro in relazione a quelli esistenti nel RUP e non verranno necessariamente
aggiunti concetti nuovi. Inoltre, è necessario aggiungere elementi nuovi come quelli inseriti nel flusso generale
del RUP.
-
Guardare avanti alle future capacità dello strumento; sebbene il RUP non sia dipendente dallo
strumento, è necessario comprendere che non esiste alcuno sviluppo di contenuto nelle aree in cui non esisterà mai
uno strumento quindi non è necessario scrivere una sezione poiché lo strumento non è sul mercato ma è possibile
prevedere che lo sarà presto.
-
Integrazione di altra esperienza IBM in SOA; è chiaro che altri gruppi all'interno dell'IBM hanno
esperienze che è possibile utilizzare, raccogliere ed aggiungere ai concetti, alle linee guida ed alla prassi in
presentazione.
-
Modifiche di ambito in Analisi e progettazione; si è guardato alla letteratura che descrive
l'applicazione di SOA alla progettazione del business e l'implicazione di SOA sui modelli del business,
sull'organizzazione operativa e sull'integrazione del business. Sono state trattate inoltre le differenze che SOA
tende a effettuare nell'implementazione, nella distribuzione e della gestione operativa. E' un ambito troppo ampio
per cui come prima iterazione si è focalizzata l'attenzione solo sui problemi relativi all'architettura ed alla
progettazione.
-
Distribuzione di una fondazione; questa è la prima iterazione. Si prevede che venga aggiunta una
guida ulteriore alla struttura qui presentata e alla connessione effettuata tra questo contenuto ed il resto del
RUP in successive iterazioni.
-
Osservare le modifiche necessarie per la base, ma rimandarle al rilascio futuro; alcuni concetti
introdotti si inseriscono meglio al RUP di base con la terminologia o altre modifiche minori. E' possibile che si
desideri effettuare delle modifiche al RUP, ma ciò avrebbe ampie implicazioni e impiegherebbe molto tempo.
E' previsto che questo contenuto sia parte del RUP di base nel prossimo rilascio commerciale del prodotto. Nel
frattempo, il contenuto verrà reso disponibile ai clienti per cui il contenuto qui descritto verrà impacchettato come
plugin RUP e reso disponibile per il download.
In parallelo, verranno effettuate modifiche alla disciplina BM (Business Modeling) che renderà più forte la connessione
tra BM e SOA; tuttavia è stata presa la decisione di attendere le modifiche BM prima di completare il plugin SOA. Verrà
effettuata l'integrazione di entrambi gli insiemi di modifiche per il rilascio commerciale.
Alcune idee chiave verranno incorporate dal GBS SOMA (Service-Oriented Modeling and
Architecture). Se non è possibile incorporare tutte le idee e le guide in SOMA, principalmente al di fuori
dell'ambito impostato, è comunque stata un'utile guida per il lavoro svolto.
Sono stati introdotti determinati principi nuovi, che includono concetti relativi al modo in cui è stato approcciato il
resto del contenuto, uno dei quali è il concetto di un portafoglio servizi ed una vista dell'intera impresa dei servizi
forniti nell'impresa.
Gli autori desiderano ringraziare per il loro valido contributo a questo lavoro: Alan Brown e Sky Matthews per il loro
supporto e la revisione del contenuto. Grazie a Eoin Lane, Steve Graham, Ed Kahan e Grant Larsen per aver fornito non
solo commenti sul lavoro, ma anche molti esempi che sono stati d'aiuto e qualche volta hanno lasciato sconcertati. Si
desidera ringraziare inoltre i colleghi che lavorano alla SOMA, Ali Arsanjani, Luba Cherbakov e Kerrie Holley. Altro
materiale è stato incluso in questa revisione da Maryann Hondo, Web Services Security Architect alla IBM.
Si desidera ringraziare anche Claus Torp Jensen ed il suo team della della banca danese per il suo dialogo
aperto e franco sull'esperienza bancaria relativa all'applicazione di SOA nel mondo reale.
|