Più volte nei post precedenti mi è capitato di sottolineare la sottile differenza tra Architettura e Design, evidenziando che si commette un errore parlando di “Design Architetturale” perché si coniugano tra loro due fasi progettuali diverse.
Cerchiamo allora di fare un po’ di chiarezza in merito.
Prima di tutto, cos’è un Architettura Software? Ebbene, forse sorprenderà sapere che ad oggi non esiste una definizione universalmente accettata di “Architettura Software”: si tratta del design del sistema o del blue print? Deve contenere dettagli relativi alla tecnologia o deve essere agnostico rispetto ad essa? E’ una visione di business del sistema o un costrutto da passare ai tecnici?
Tutte domande legittime che mettono in evidenza come un’Architettura Software abbracci diversi campi e ammetta più definizioni che enfatizzano diversi aspetti in funzione di chi è il destinatario dell’Architettura stessa.
Partiamo da due assunti:
1. Tutti i sistemi hanno un Architettura!
Sia essa voluta (intentional) che accidentale (accidental), esplicita (explicit) che implicita (implicit), buona (good) o cattiva (poor), non esiste un software senza Architettura.
2. Esistono diversi modi di descrivere e leggere la stessa Architettura!
Ciò è vero perché intorno ad un progetto (soprattutto enterprise) ruotano una serie disomogenea di stakeholder: dal committente, al developer, allo sponsor. Ognuno ha bisogno di una declinazione dell’Architettura in funzione delle proprie esigenze.
Bisogna evitare di sovraccaricare la descrizione architetturale (overly complex) così come bisogna essere capaci di non renderla povera (poor) e quindi inutile.
Lo scopo di una buona Architettura è quello di rendere il sistema “evolvibile”, quindi favorirne l’evoluzione in funzione di nuovi requisiti e nuove necessità, esplicite o implicite che siano:
Un Architettura è una Buona Architettura se riesce a governare la sua evoluzione e i costi che i cambiamenti comportano. Chiaramente se l’Architettura introduce elementi che semplifichino la realizzazione del sistema, di certo la cosa non dispiace, ma non è indispensabile.
Bisogna poter far evolvere (attenzione: evolvere, non stravolgere) l’Architettura, senza la paura che ciò si trasformi in un’impresa difficile da raggiugere, introducendo più problemi che vantaggi.
Questo aspetto è ben evidenziato da Martin Fowler nel suo Patterns of Enterprise Application Architecture:
“Architecture is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change.”
Tale definizione pone l’accento sulla scomposizione del sistema e sugli elementi che ne costituiscono la struttura, principali responsabili dei costi di modifica. Con essa si evidenzia, implicitamente la differenza tra Architettura e Design di un sistema software, abilmente sintetizzata da Grady Booch
“All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”
E’ interessante notare che in quest’ultima definizione la questione del “costo del cambiamento” è esplicitata in modo diretto (esattamente come abbiamo evidenziato ed enfatizzato nel precedente post Agile Architecture una scelta possibile), creando uno spartiacque tra Architettura e Design.
L’Architettura infatti è assimilabile al blue print del progetto, ovvero ad una visione d’insieme sufficientemente completa da descriverlo, ma non tanto da dettagliarne i tecnicismi. Tocca al Design entrare nello specifico e descrivere come raggiungere gli obiettivi descritti dall’Architettura. Ecco il punto: l’Architettura è la STRATEGIA che adotto per raggiungere l’obiettivo mentre il Design è la TATTICA (o l’insieme di esse) che mi avvicina all’obiettivo.
Chiaramente la terminologia è preso a prestito dall’ambito militare in cui la tattica indica l'utilizzo di risorse in un ambito territoriale ristretto per limitate esigenze temporali (una singola battaglia con relativi movimenti e utilizzo di determinate tecniche). La strategia è, al contrario, l'impiego e l'organizzazione di risorse in funzione di un obiettivo di medio o lungo periodo.
Strategy vs Tactics
Modificare l’Architettura è più costoso che modificare il Design. Questo è dovuto proprio al fatto che il Design “specializza” l’Architettura, mentre quest’ultima definisce i confini in cui muoversi: si pensi all’utilizzo di un Pattern Architetturale come MVC (Model-View-Controller) e al costo di una sua sostituzione con un modello differente come PAC (Presentation-Abstraction-Controller). Dualmente la sostituzione a livello di Design di due diversi framework MVC è si costosa, ma sicuramente molto meno che nel caso precedente.
Possiamo quindi affermare che [FP]:
“Da un’Architettura possono scaturire più Design, mentre un Design è identificabile da una specifica Architettura”
["From an architecture may arise more Design, while a Design is identified by a specific Architecture".
La differenza tra Architettura e Design non è però così delineata, non essendo semplice individuare il giusto grado di astrazione dell’Architettura. Un utile esercizio è quello di rispondere a tre obiettivi fondamentali che sono alla base della definizione dell’Architettura:
1. “what” (cosa), indica cosa il sistema deve garantire da un punto di vista qualitativo per coprire le esigenze del relativo contesto applicativo;
Quali sono le esigenze qualitative (non – funzionali) del sistema?
2. “why” (perché) indica perché vengono effettuate determinate scelte;
Perché devo garantire determinati livello qualitativi (SLA, Service Level Agreement)?
3. “how” (come) indica come si intende rispondere alle esigenze non funzionali.
Quali sono gli elementi strutturali (moduli, module views and styles) del sistema?
Quali sono i componenti dinamici (componenti e connettori, C&C views and styles) che si sviluppano nel sistema?
Come si relazionano i componenti con l’ambiente di esecuzione (Allocation views and styles)?
Attenzione: non c’è traccia di scelte tecnologiche specifiche, ne Java, ne dotNet e ne altro!
Detto questo, vediamo di analizzare alcune delle definizioni più interessanti esistenti in letteratura, partendo da quella di Shaw e Garlan tratta dal testo Software Architecture: Perspective on Emerging Discipline:
The Architecture of a software system defines that system in terms of computional components and interactions among the component.
Arricchita da un'altra affermazione, sempre degli stessi autori:
In addition to specifying the structure and topology of the system, the Architecture shows the intended correspondence between the system requirements and elements of the constructed system. It can additionally address system-level properties such as capacity, throughput, consistency, and component compatibility.
La prima definizione abbraccia fortemente la relazione dinamica tra i componenti e le loro interazioni, di interesse del Component and Connection Style (C&C Styles), mentre la seconda evidenza gli aspetti relativi all’organizzazione statica (Module Styles) e l’importanza di soddisfare le proprietà non funzionali. Manca invece un riferimento all’allocazione dei componenti nell’ambiente di esecuzione (Allocation Styles).
Una definizione più forte è quella data da Bass-Clements-Kazman in Software Architecture in Practice:
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. By -externally visible properties- we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on.”
Questa definizione, probabilmente la più completa, è più ampia, perché oltre a considerare i componenti e le relazioni richiama direttamente le “proprietà visibili dall’esterno” che, ancora una volta, non sono quelle funzionali, bensì quelle qualitative: performance, tolleranza i problemi, condivisione delle risorse, e altri SLA di rilievo. Conoscendo tali caratteristiche è possibile valutare l’efficienza dell’Architettura e la sua efficacia nel contesto in cui si intende utilizzarla, permettendo di definire appositi Hot Spot (punti) di estendibilità.
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relations among them. By “externally visible properties,” we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on.”
(Bass, Clements, and Kazman 2003)
Questa definizione riassume in poche righe l’essenza e il significato stesso di [Intentional] Architettura. Nessun riferimento a tecnologie specifiche o scelte di design, ma solo una vista di insieme del sistema, enfatizzando i moduli, le relazioni tra essi e verso i fruitori del sistema stesso.
Utilizzando i Workflow Service, nonostante lo stack di attivazione del servizio sia quello di WCF, esiste una grossa differenza nel caso si abbia la necessità di recuperare l’identity del chiamante, ad esempio se si utilizza WIF per l’autenticazione Claim Based.
Normalmente in un servizio WCF si accede all’identity tramite il context:
ClaimsIdentity claims = ((ClaimsIdentity)System.Threading.Thread.CurrentPrincipal.Identity);
nel caso dei Workflow, bisogna invece accedere al SecurityContext:
OperationContext.Current.SecurityContext.PrimaryIdentity
Il problema è che, di default, l’OperationContextScope non è disponibile per l’utilizzo diretto.
Le mie moltissime ricerche in rete mi hanno portato a trovare tre possibilità per risolvere il problema:
- Realizzare una custom activity seguendo quanto riportato su MSDN (http://msdn.microsoft.com/en-us/library/aa395196.aspx)
- Utilizzare il WF Security Pack, ed in particolare l’activity OperationContextScope (http://wf.codeplex.com ) il cui stadio di sviluppo è però ancora CTP 1 da orami un anno
- Utilizzare il Neovolve Toolkit (http://www.neovolve.com/ ) attraverso l’activity ReceiveIdentityInspector
Quest’ultima soluzione consente di “catturare” l’identity e salvarla in una variabile del WF.
Il linea di massima le soluzioni 2 e 3 (pronte per l’uso) sembrano abbastanza equivalenti, ma nell’utilizzo pratico del WF Security Pack, si sono verificate delle anomalie attivando la funzionalità di persistenza di AppFabric.
Sostanzialmente il workflow resta legato all’owner di sistema che si occupa della sua creazione e non è più possibile invocare le operation successive a quelle di init (createinstance).
L’activity di Neovoleve, invece, funziona correttamente ed ha il vantaggio di salvare l’identity senza la necessità di rendere le activity che devono utilizzarla, figlie di una parent activity.
Consiglio inoltre di spulciarvi l’intero Neovoleve Toolkit, che contiene diverse activity interessanti, come quella che consente di prende l’Id di persistenza legato all’istanza (GetWorkflowInstanceId), particolarmente utile in fase di debug, che, come tutti i dev WF4 sanno, non è proprio il massimo.
Utilizzando il designer di WF4 può capitare che il reference a tipi terzi sia impostato come segue:
xmlns:local="clr-namespace:MioNamespace.MiaClass.Classi"
questo può comportare (dipende dalla configurazione dell’ambinete) un errore a runtime del tipo “type not found”.
Per risolvere il problema è sufficiente aggiungere il riferimento all’assembly che contiene il tipo:
xmlns:local="clr-namespace:MioNamespace.MiaClass.Classi;assembly=
MioNamespace.MiaClass.Classi "
