Sessione dedicata a SOA (Service Oriented Architecture) di cui non esiste una definizione precisa. Quella che preferisco e' senza dubbio la seguente: "SOA e' una architettura distribuita flessibile e resiliente ai cambiamenti". Che cosa significa questo ?

Immaginate una classica applicazione basata su Web Services o Remoting. Abbiamo un client ed un server. Immaginate di aggiornare la parte server con una versione 2. Solitamente che succede, si aggiorna anche il client con la versione 2, punto ! Invece no, se prendiamo alcuni accorgimenti possiamo usare il client v1 con il servizio v2 o il client v2 con il servizio v2 ecc. (fate voi gli incroci).

Per raggiungere questo obiettivo dobbiamo considerare alcuni punto all'interno della nostra architettura:
1. Iniziare dal contratto (nel caso dei Web Services dallo schema)
2. Concentrarci sui dati e non sui tipi
3. Non condividiere fra client e server i tipi (per quanto possibile) ma i dati
4. Concentrarsi sui processi e non le funzioni
5. Pensare piu' ai messaggi invece che agli oggetti

Che cosa significa concentrarsi sui dati e non sui tipi ? Considerando il caso del Remoting solitamente dobbiamo linkare sia il client che il server alla libreria che contiene le interfacce. Questo e' un limite, perche' sia il client che il server sono fortemente connessi dal tipo (in questo caso l'interfaccia). Se pensiamo invece di passare un messaggio (XML, SOAP o altro) diventa il tutto piu' flessibile. I Web services giocano un ruolo fondamentale in quanto il meccanismo usato per la serializzazione/deserializzazione e' decisamente molto resiliente.

E' un argomento molto interessante che merita ulteriori approfondimenti....