Service Application Framework in SharePoint 2010
Una delle novità architetturali più importanti di SharePoint 2010 è il nuovo modello di servizi (Service Application) che va a sostituire gli SharedService di MOSS2007/WSS3.
L’idea di una Service Application è avere un modello di programmazione aperto, che consenta di realizzare servizi infrastrutturali (cioè non specifici di una particolare applicazione, ma trasversali a N possibili applicazioni). Le Service Application sono servizi che erogano funzionalità a supporto delle applicazioni SharePoint che andiamo ad implementare, sfruttando un’architettura nativamente pensata per essere scalabile, ridondante, claim based e monitorabile/gestibile in modo rapido e comodo.
Nativamente SharePoint 2010 offre già molte Service Application, a seconda poi della versione di prodotto (SharePoint Foundation 2010, SharePoint Server 2010 Standard, SharePoint Server 2010 Enterprise, ecc.). Alcune delle più importanti Service Application sono ad esempio:
- Search Service
- Business Connectivity Services
- Managed Metadata Service
- Secure Store Service
- User Profile Service
- Web Analytics Service
In sostanza una Service Application non è altro che un servizio (tipicamente SOAP, in ottica SOA, realizzato con WCF – Ma potrebbe essere anche altro, persino un servizio Java o qualcosa “in the cloud”). Ogni servizio ha una parte di implementazione fisica (il service) e una parte di istanza che è appunto una istanza di quel servizio su una determinata macchina server, o su più macchine server in caso di Network Load Balancing (NLB). Vi è poi una Service Application che non è altro che la configurazione logica di un servizio, per astrarre dalla locazione fisica e dal numero di service instance che sono effettivamente esposti. Chi consuma una Service Application vede l’interfaccia logica, ignorando quali e quante istanze fisiche ci siano alle spalle. Per consumare una Service Application si utilizza un Service Application Proxy che di nuovo rende trasparente al Service Consumer (che è tipicamente una pagina, una web part o una workflow activity) dove e come si raggiunge la Service Application.
Per un riepilogo dell’idea, si veda la slide qui sotto.
Si sfrutta un disaccoppiamento forte anche tra consumer e servizio, via Service Application Proxy, perché potremmo avere delle Service Application esposte da una farm SharePoint e consumate da un’altra farm. Questo ha un senso quando si vogliono condividere servizi “critici” o onerosi da gestire, avendone una sola configurazione in un’unica farm, per poi condividerli tra N diverse farm.
Il modello è aperto, come ho detto in precedenza, perché possiamo creare delle nostre Service Application personalizzate, sfruttando il modello di programmazione offerto, fatto di classi base e interfacce reimplementabili. Si parla di SAF = Service Application Framework.
Trovo curioso considerare che una Service Application in particolare è preposta a gestire la localizzazione e il bilanciamento di carico delle altre Service Application. Si tratta del servizio “Application Discovery and Load Balancer Service Application”.
Se volete maggiori dettagli sul discorso, potrete a breve vedere anche il video della mia sessione introduttiva, tenuta allo SharePoint Community Tour del 29 giugno scorso. Il video sarà disponibile sul sito della SharePoint Community Italiana.