Bene, fatta questa breve premessa, vediamo come si presenta questo nuovo modello e quali sono le tipologie di App che possiamo sviluppare all'interno di SharePoint 2013:
- SharePoint-hosted Apps: applicazioni che vengono installate fisicamente su SharePoint, all'interno di un nuovo sito (SPWeb) isolato dal resto dei contenuti del sito padre in cui l'applicazione viene installata, che possono sfruttare le potenzialità del provisioning per creare site columns, content types, liste, pagine, ecc.., che sfruttano HTML/CSS per la composizione del layout grafico e Javascript per l'accesso ai dati (tramite Client Object Model o tramite REST). Questa tipologia di applicazioni eredita dall'architettura di SharePoint tutte le funzionalità di isolamento rispetto al resto del contesto, di gestione della security e di gestione del concetto di multi-tenancy.
- Cloud-hosted Apps: che si dividono in:
- Provider-hosted Apps (o Self-Hosted, o Remote-Hosted): applicazioni che vengono rese disponibili da strutture totalmente al di fuori del contesto di SharePoint, per cui lo sviluppatore (o il provider) deve preoccuparsi da zero di tutte le tematiche di manutenzione, aggiornamento e disponibilità. Applicazioni la cui logica di business può essere sviluppata potenzialmente con qualsiasi tipo di linguaggio (sia client-side che server-side) e su qualsiasi tipo di piattaforma e che vedono la presenza di un token di sicurezza, assieme ad un singolo entry point su SharePoint (l'SPWeb citato prima, isolato dal resto ed opzionale) in grado di permettere la connessione con la piattaforma e l'utilizzo delle funzionalità enterprise da essa esposte, sempre tramite Client Object Model o tramite chiamate ai servizi REST. Utilizzando questa tipologia di App, lo sviluppatore è però incaricato di preoccuparsi da zero di garantire tutti i vari concetti di isolation, security e multi-tenancy.
- Azure auto-hosted Apps: applicazioni che, una volta scaricate dal Marketplace ed installate, creano in automatico un sito web Azure, con eventualmente un database SQL Azure a supporto, in un'istanza di Azure legata all'account Office 365 tramite cui l'applicazione stessa viene scaricata. Come avrete capito quindi, questa opzione è disponibile solamente sulla nuova versione di Office 365 e non su installazioni di SharePoint 2013 on premises. Questo non significa però che non potete usare gli Azure Websites come hosting per le vostre App SharePoint, anzi.
- Provider-hosted Apps (o Self-Hosted, o Remote-Hosted): applicazioni che vengono rese disponibili da strutture totalmente al di fuori del contesto di SharePoint, per cui lo sviluppatore (o il provider) deve preoccuparsi da zero di tutte le tematiche di manutenzione, aggiornamento e disponibilità. Applicazioni la cui logica di business può essere sviluppata potenzialmente con qualsiasi tipo di linguaggio (sia client-side che server-side) e su qualsiasi tipo di piattaforma e che vedono la presenza di un token di sicurezza, assieme ad un singolo entry point su SharePoint (l'SPWeb citato prima, isolato dal resto ed opzionale) in grado di permettere la connessione con la piattaforma e l'utilizzo delle funzionalità enterprise da essa esposte, sempre tramite Client Object Model o tramite chiamate ai servizi REST. Utilizzando questa tipologia di App, lo sviluppatore è però incaricato di preoccuparsi da zero di garantire tutti i vari concetti di isolation, security e multi-tenancy.
Quindi, tre modalità di sviluppo/deployment per la costruzione delle nostre App, da scegliere in base alla tipologia di applicazione che abbiamo intenzione di creare.
A mio parere, la modalità "SharePoint-hosted" è da scegliere per tutte quelle applicazioni che hanno poca logica di business e che intendono semplicemente visualizzare dati presenti su SharePoint tramite un'interfaccia con un alto livello di user-experience. Senza la potenza che ci può dare un linguaggio che viene eseguito server-side (senza nulla togliere a Javascript, fantastico per quanto riguarda l'interazione lato client), questa tipologia di App SharePoint è obbligata a limitarsi ad offrire funzionalità in cui non è presente (o in minima parte) della logica di business, sfruttando invece al massimo quello che SharePoint offre OOB in termine di liste, document library, pagine e tutto il resto.
Invece, per estensioni di SharePoint in cui la logica di business necessita un certo tipo di attenzione, il passo verso le "Self-hosted Apps" vedrete che sarà più che naturale. Infatti, abbiamo così la possibilità di gestire tale logica con la tecnologia server-side che più ci piace e che ci rende più produttivi, tenendo conto di un'integrazione visuale con SharePoint 2013 durante lo sviluppo della UI (a riguardo, vedremo quali sono le linee guida date da Microsoft per la composizione dell'interfaccia). L'unica preoccupazione sarà quella poi di mantenere la disponibilità dell'applicazione stessa, soprattutto a fronte dell'accesso di un certo numero di utenti. In ambienti intranet non lo vedo come un problema, ma se decidiamo di distribuire l'applicazione sul Marketplace allora forse si. Ma queste credo che siano considerazioni da fare poi.
Inoltre, grazie a questa nuova architettura App oriented, abbiamo anche la possibilità di far girare queste App su Office 2013 (la nuova versione di Office). Quindi arricchire i client Word, PowerPoint, Outlook, ecc.. con delle interfacce ricche, sviluppabili in HTML, assieme a delle funzionalità in grado di interagire con le caratteristiche, le strutture e i dati esposti da SharePoint. Parleremo a breve anche di questa opportunità, non preoccupatevi.
Nei prossimi post, cercheremo di andare avanti con questa panoramica entrando ancor più nel dettaglio di questo nuovo modello.
Vi ricordo invece che, se volete vedere tutte le novità di SharePoint 2013 per noi sviluppatori e non, potete iscrivervi alla SharePoint Future 2012. Che si terrà a Milano il 27 novembre 2012.
