SharePoint Conference 2011 : C’est fini !

Voilà qui conclut cette semaine à la SharePoint Conference 2011 à Anaheim. Celle-ci aura été intéressante dans l’ensemble même si comme de plus en plus souvent sur ces évènements à forte population (7500 personnes rappelons-le), le niveau des sessions est assez déséquilibré avec des choses formidables et d’autres plus que moyennes voir médiocres.

Vivement l’année prochaine à Las Vegas avec l’annonce du probable SharePoint 2013   ;–)

Le programme de l’après-midi va être un peu de tourisme à Los Angeles (Venice Beach, Santa Monica, Beverly Hills…) avant de reprendre l’avion demain dans la journée pour enchainer sur 11h de vol (mais ça le vaut bien).

Quelques photos souvenirs …

How Microsoft Built Academy, it’s social Video Platform

Session animée par Austin Winters

La session va aborder un sujet qui intéresse de plus en plus de monde aujourd’hui: comment intégrer un « Youtube » dans mon entreprise ?

On va pour ça prendre l’exemple d’Academy, la plateforme de partage de vidéos mise en place par Microsoft.

On commence par visionner une vidéo amusante sur notre sujet, histoire de détendre un peu l’atmosphère pour cette dernière session de la SharePoint Conference 🙂 .

Nous allons parler patterns, architecture et intégration de fonctionnalités sociales puis montrer que SharePoint 2010 peut parfaitement répondre à ce besoin.

Quelques composants clés d’une plateforme de partage vidéo dans SharePoint :

  • Les fonctionnalités communautaires et sociales
  • Le stockage de documents, l’affichage (ici les documents sets), la gestion
  • La taxonomie
  • Le moteur de recherche FAST
  • Le design de portail
  • Windows Media Services

On décrit maintenant le pattern d’un portail.

D’abord le publishing site. Sa gestion est faite côté client.

Puis le document center et l’intégration des documents sets offerte par SharePoint 2010.

Puis le stockage des données,  elles peuvent être stockées dans SharePoint ou utiliser le RBS.

Puis les services partagés, avec la taxonomie, la recherche, …

On reparle des documents sets et des fonctionnalités sociales offertes par SharePoint : tagging, rating, commentaires, my sites, …

Ensuite on aborde le sujet FAST qui permet de faire des recherches poussées sur les vidéos.

La WebPart de recherche FAST permet d’afficher des résultats de type vidéos liés au contexte de la page.

Un lab est disponible, pour ceux qui veulent se lancer dans l’aventure: http://aka.ms/podcasting .

On passe maintenant à une démo.

La collection de sites présentée reprend le pattern évoqué plus haut.

On voit un publishing site, un document center avec des documents sets, …

La Home Page des documents sets est customisée pour permettre l’affichage de la vidéo.

Ils ont fait le choix de supprimer le ribbon afin de simplifier la contribution pour les utilisateurs et de ne pas les  perdre dans une multitude de fonctionnalités dont ils n’ont pas besoin. L’un des seuls boutons présents est le bouton d’upload.

L’upload de vidéo déclenche la création d’un document set.

La home page du document set est complètement customisée. Elle ressemble à s’y méprendre à la page de visualisation d’une vidéo sur Youtube 🙂

On a un lecteur de vidéo, l’affichage d’informations comme son hauteur, sa durée, … les actions classiques comme l’envoi à un ami, une zone de commentaires, …

Un bouton visible uniquement par le contributeur permet de créer un aperçu de la vidéo à un moment précis. L’aperçu de la vidéo est stocké dans une bibliothèque est utilisé notamment dans les résultats de recherche. La vidéo est également stockée dans SharePoint mais le speaker insiste sur le fait qu’il s’agit d’une démo et que le chargement de vidéos depuis une base de données est  lourd.

Sur un environnement de production il faut absolument la stocker sur un serveur dédié. Ca permet par exemple le streaming.

On voit ensuite les différentes modifications apportées à l’affichage des résultats de recherche.

On définit les éléments utiles pour la gestion de vidéos : les metadonnées, l’encoding live, le transfert, la contribution des utilisateurs…

Un graphe présente le process depuis l’arrivée des vidéos vers SharePoint jusqu’à la sortie vers les supports tels que tv, xbox, dvd, ipad, …

Le graphe en 3 mots :

Create -> Manage(SharePoint) -> Experience (medias)

On voie ensuite le process d’upload,  avec les bases de données etc…

Les medias sont stockés sur des serveurs, les metadonnées dans des bases de contenu. SharePoint fait le lien entre tout ça.

Le moteur d’encodage met à jour les métadonnées automatiquement à partir d’un fichier vidéo.

SharePoint ne gère pas directement l’affichage de la vidéo, il charge juste, par exemple, un contrôle SilverLight qui lui va rechercher la vidéo sur un serveur distant.

On peut même faire appel à une plateforme de streaming externe pour le stockage des vidéos.

Retour à une démo sur Academy…

On voit comment les pages sont construites.

Ils utilisent beaucoup la fenêtre modale fournie avec SharePoint 2010 pour la navigation et l’affichage des vidéos.

On voit les différentes fonctionnalités présentes sur la page du document set : I like it, génération du code html pour l’intégration dans un autre site, … pour faire simple, tout ce qu’il y a sur Youtube.

Il montre en détail les métadonnées du document set : la taxonomie est très utilisée !

Puis le process d’upload de la vidéo vers un dossier. C’est le champ DocumentID qui est utilisé pour nommer le fichier sur le file system.

L’aperçu de la vidéo est envoyé vers un serveur de fichiers et la vidéo vers un serveur de streaming.

Beaucoup de choses sont fournies OOTB comme le rating par exemple, les statistiques de consultations …

On peut pluger des outils du marché pour avoir des statistiques supplémentaires.

Les mysites sont également très customisés. Ils ressemblent à une page de profil Youtube.

On peut vraiment faire des choses très poussées avec la vidéo sous SharePoint si on met en place l’infrastructure qui va avec.

Je vous recommande d’aller voir le podcast car la session était très intéressante 🙂 .

Best practices for creating Publishing Page Layouts

Session animée par Geoffrey Edge

Nous allons aborder dans cette session les bonnes pratiques pour la création de page layouts dans SharePoint.

  • On commence par le sommaire :
  • Le moteur de rendu des pages publishing
  • Les différences entre masterpage et page layouts
  • Les composants d’un page layout
  • L’impact du contenu et du design du site sur les page layouts
  • Les exemples avec le site brembo ou sharepoint.microsoft.com
  • La création des page layouts
  • Le déploiement

Le moteur de rendu fonctionne de la manière suivante : le navigateur requête la page, le page layout est recupéré, la masterpage est récupérée, les contrôles présents dans le page layout génèrent le rendu des champs de la page.

On nous rappelle la différence entre la masterpage, qui constitue la structure commune à toutes les pages, du page layout, qui charge des contrôles dans les zones prévues (PlaceHolders).

Le contenu d’un page layout :

  • Les zones de webparts
  • Les contrôles des champs
  • Les div, …
  • Le css
  • Le code behind (parfois)
  • La navigation de contenu (différent de la navigation du site)
  • Les textes et images non éditables.

On commence la première démo.

On nous présente un exemple de page avec un branding très poussé. Ca ne ressemble pas vraiment à un site SharePoint.

Les éléments qui  n’appartiennent pas à un page layout :

  • La navigation de site
  • Le branding commun
  • Les éléments du head

Nous abordons ensuite l’impact du site.

Les besoins du site définissent les best practices.

Le type de site impacte les page layouts, le nombre de pages, l’audience cible du site, la templatisation.

On évoque différents types de sites : micro sites, les brochures, les knowledge bases, les sites de eCommerce, les sites corporate et bien d’autres…

L’emplacement des pages définit ce qui est dans le layout. Les pages « top level » on peut de champs en général.

Plus on descend dans la hiérarchie, plus les pages sont structurées.

Page d’accueil -> page de catégorie -> page de contenu

Une nouvelle démo nous permet de mettre en évidence tout ça.

On voit la structure de la home page d’un site, puis des pages de contenus (produits), …

Concernant la création des page layouts, on peut utiliser Visual Studio ou Sharepoint Designer.

On voit un autre exemple de site qui n’a aucun champ sur sa home, que des zones de webparts.

Sur la page de catégories, idem, il n’y pas de champs par contre sur les pages de produits, plein de champs.

Il est important de limiter ce que peuvent faire les contributeurs et de ne leur laisser l’accès qu’aux éléments qu’ils sont sensés modifier.

Un petit tour sur Brembo a présent.

On fait une démo avec quelques best practices.

Sur une page, on a beaucoup de jQuery et notamment un slide show. Les images sont stockées dans une librairie avec des métadonnées sur les images (temps d’affichage, ordre, ..)

Il conseil l’utilisation de la dataform webpart et de jQuery. La dataform webpart est capable d’agréger des données.

On aborde rapidement le framework de la modal dialog. Elle est uttilisée pour certains contenus. (natif ave SharePoint en appelant SP.UI.ShowModal().

On explique ensuite l’EditModePanel qui permet de gérer les metadonnées de la page non visibles (tags, titre, …). Par exemple, un DelegateControl peut être utilisé pour afficher les valeurs de la balise meta à partir de ces tags.

On voit également l’utilisation de la ContentQuery webpart qui requête certaines pages en fonction d’une metadonnée de l’EditModePanel.  Elle est recommandée pour l’affichage de news par exemple.

Puis on passe la home page du site sharepoint.microsoft.com en mode édition pour voir comment elle est construite.

Concernant les templates, il faut faire attention à en limiter le nombre disponible pour ne pas « perdre » le contributeur.

Pour terminer la session nous parlons de la création des types de contenu et des page layouts.

Il existe plusieurs techniques pour la création de types de contenu: SharePoint Designer, Visual Studio, code, Powershell…

Quelques plugins pour Visual Sudio : Comunity kit for SharePoint, caml.net.intellisense (pratique 🙂 )

Une dernière démo nous montre les différentes techniques.

Il existe aussi plusieurs techniques pour créer des page layouts : SharePoint Designer, Visual Studio , les 2 !

SharePoint Designer : facile, pour les non développeurs, peux flexible, pages déghostées

Visual Studio : plus flexible, réservé aux développeurs.

L’idéal est de designer la page dans Designer puis copier dans Visual Studio pour packager.

Cette session ne nous dévoile finalement pas grand-chose alors qu’il s’agissait d’une session niveau 300.

Localizing SharePoint Solutions

Session animée par Mike Ammerlaan

Nous allons parler ici de la localisation des solutions SharePoint et des éléments  utiles pour la mettre en place.

Le sommaire de la session : la localisation pour les utilisateurs, la localisation pour les solutions full trust, la localisation pour les solutions Sandbox.

SharePoint 2010 supporte la Multilangual User Interface (MUI). Les sites peuvent gérer autant de langues qu’il y a de language packs installés sur le serveur.

Par défaut,  la langue utilisée est celle du navigateur de l’utilisateur mais ce comportement pet être overridé.

On peut utiliser les variations pour les scénarios de sites internet multilingues.

On a langue principal du site, puis les langues additionnelles (en fonction des language packs installés).

Si le site ne supporte pas la langue préférée de l’utilisateur, SharePoint affiche la langue par défaut du site.
Certains éléments du site ne peuvent pas être localisés : les documents, les contenus, …

Après avoir décrit les différentes ressources présentes sur un site, on nous présente ceux pouvant être gérés par la MUI et ceux qui ne peuvent pas.

Les contrôles sont compatibles MUI par défaut.

Les titres des listes, des webparts, … sont compatibles MUI mais peuvent être modifiés par l’utilisateur.

Les contenus ne sont pas compatibles MUI.

Lorsque l’utilisateur choisit sa langue préférée, l’information est stockée dans la UserInfoList de la collection de sites. Il peut choisir une langue différente par collection.

Nous mettons en pratique tout ça en modifiant la langue courante. On constate que certains éléments ne sont pas traduits.

On nous présente la fonctionnalité « export translation » qui permet d’exporter un fichier resx .

On peut alors le modifier et le réimporter depuis l’interface du site pour localiser certains éléments.

Nous passons maintenant à la différence entre les solutions full trust et les Sandbox.

Pour chacune, nous voyons comment localiser les éléments suivants: les pages, les assemblies, les scripts et les fichiers xml.
D’abord, les solutions Full Trust.

Pour les pages :

  • On déploie les fichiers resx dans le dossier AppGlobalResources de la web application
  • On déploie les resources dans le dossier 14\Resources

Pour les assemblies :

  • On déploie dans AppGlobalResources et on utilise HttpContext.GetglobalResourceObject()

Pour les scripts :

  • On déploie les fichiers js dans les dossiers  1033-1036-10… dans le 14
  • Soit on fait 1 fichier js par langue pour les ressources + 1 fichier js pour les fonctions
  • Soit on fait 1 copie du fichier js pour chaque langue (moins recommandé)

Pour les fichiers xml :

  • On déploie les resources dans le dossier 14\Resources
  • On déploie les resources dans le dossier  Feature\Resources
  • On utilise la syntaxe suivante :  $Resources : …

Pour le packaging il y a 2 techniques :

  • 1 gros wsp qui contient tout
  • 1 core wsp + des wsp language packs

On met tout ça en pratique dans Visual Studio…

Après avec créé des fichiers de resx et montré leur appel, on  voit comment gérer les resources dans du Javascript avec l’utilisation de SP.ClientContext.WebLanguage.

On passe ensuite aux cas des solutions Sandbox.

Problèmes des solutions Sandbox, on ne peut pas déployer sur le file system du serveur, donc oubliez les fichiers resx dans 14\resources…

Pour les pages :

  • On déplace la logique coté client (js)
  • On utilise les resx OOTB
  • On fait une page différente par langue

Pour les assemblies :

  • On localise les assemblies

Pour les scripts :

  • Idem aux solutions full trust

Pour les fichiers xml

  • On déploie les fichiers resx dans le dossier de la feature

La session s’achève avec une démo de la solution Sandbox.

Il présente, entre autre, la création de dll localisées.

Advanced BI Visualizations using Visio Services

Session animée par A.J Briant (Product Manager) et Christopher Hopkins

La session démarre par un rappel sur ce qu’est Visio Services et qui permet d’afficher des diagrammes pouvant être connectés à des données et rafraichis.

Dans un contexte BI, les fonctions de « Data Linking » et « Data Graphics » offertes par Visio seront cruciales car ce sont elles qui vont permettre de se connecter et d’afficher des choses jolies.

1ère démo montrant un diagramme Visio affichant une carte des USA (composée de plusieurs formes), ou chaque élément de la carte peut être connecté à une source de données.

On voit comment connecter la carte à un classeur Excel qui est hébergé dans SharePoint. Une fois la source sélectionnée, un tableau apparaît dans Visio et il suffit de sélectionner la ligne qui nous intéresse, la glisser sur la forme (un état des USA dans l’exemple) voulue et automatiquement les 2 éléments sont liés. Cela signifie que si la ligne du classeur Excel change, le diagramme Visio sera mis à jour.

Plutôt que d’afficher les données sous forme de texte, on peut faire du color coding de la forme en fonction de valeurs. Cela est utile notamment pour la gestion de KPI.

D’autres formes sont ajoutés à la carte (des bulles de texte) pour afficher le libellé et la valeur (sous forme d’une gauge) des lignes associés à l’état à laquelle la forme est associée (on utilise les liens de formes de Visio). On continue de faire un peu de cosmétique en associant des formules de calcul.

On insère ensuite une légende au sein du diagramme pour indiquer à quoi correspondent les couleurs, les plages de valeurs de chaque couleur, etc…

Pour sauvegarder le document dans SharePoint, il suffit d’utiliser l’option du même nom dans le menu fichier en faisant attention à bien choisir « Web Drawing » comme type de fichier (sinon le fichier ne sera pas utilisable dans Visio Services).

Retour aux slides pour récapituler tout ce qui a été fait dans la démo.

Passons maintenant au rafraîchissement des données qui peut être fait sur le client ou sur le serveur. Sur le serveur, il faut noter que les données sont mises en cache pour chaque utilisateur (cela signifie que 2 utilisateurs pourraient voir des données différentes si les données ont été modifiées durant le temps ou le 1er et le 2ème utilisateur ont demandé au serveur d’afficher le fichier Visio).

Quand on utilise à la fois un schéma Visio et un classeur Excel, l’utilisateur a besoin d’avoir les droits de lecture sur les 2 fichiers pour que la solution fonctionne.

Un petit tour rapide sur l’architecture en place pour que tout cela fonctionne. La partie intéressante du schéma concerne la possibilité de développer des « Data Adapter » et d’utiliser un API quand on a besoin d’utiliser des sources de données non standard (comprendre pas SQL ou Excel).

2ème démo pour métro un l’add-in Visio nommé SharePoint Network Topology (celui là même envoyé par Emmanuel aujourd’hui à la liste de diffusion SharePoint).

Cet add-in consiste en un job SharePoint qui va récupérer des données sur la ferme SharePoint à intervalles réguliers, les compiler dans un schéma Visio et stocker le schéma dans une bibliothèque  de documents (la collection et la bibliothèque sont définies depuis l’administration centrale).

Il est aussi possible d’utiliser des listes SharePoint comme sources de données, ce que l’on nous montre en créant un nouveau schéma. Si l’on souhaite utiliser des listes externes (via BCS), c’est également possible et il existe un add-in pour cela (le speaker mettra le lien sur son blog si ce n’est pas déjà fait).

Retour aux slides pour évoquer l’API Visio Services qui se présente sous la forme « ECMAScript Object Model ». Ces API permettent de savoir tout ce que l’utilisateur fait comme interaction avec un schéma (clic, déplacement de la souris…) afin de pouvoir réagir en conséquence.

3ème démo montrant l’utilisation de l’API où dans un site SharePoint affichant un schéma de plans de bureaux, on peut sélectionner dans une WebPart des options, qui colorent les bureaux d’une certaine manière, superposent des éléments sur le schéma, etc…

Les démonstrations s’enchainent pour montrer les capacités de mise en forme (ex: gestion de la 3D) associées à l’utilisation de l’API.

Multi-Tenancy with SharePoint 2010

Session animée par Spencer Harbar (Entreprise Architect)

Nous commençons par introduire la notion de multi-tenancy qui revient à vouloir isoler les données, les services et la gestion de plusieurs clients mais sur un environnement mutualisé.

Si on comparait cela à la vie de tous les jours, ce serait un immeuble avec des parties communes (escaliers, portes…) et des éléments propres à chaque personne (l’appartement).

Office 365, des hébergeurs classiques et des Clouds privés proposent ce genre de service mais il est possible de le faire OnPremise (very risky indeed comme l’indique le speaker dans son slide).

La notion de multi-tenancy dans SharePoint 2010 a été implémentée pour être utilisée dans Office 365 à la base.

Le multi-tenancy n’est pas juste une Feature à activer mais beaucoup d’éléments sont impactés (authentification, abonnements, profils…).

Un premier concept qui existait déjà sur SharePoint 2007, les Host Named Site Collection, a été enrichi sur SharePoint 2010 pour supporter les chemins d’accès gérés, les certificats SSL, etc…

Pour séparer les collections des clients, il faut créer des groupes logiques (appelés des Subscriptions) qui ne peuvent être activés que via l’API ou Powershell. Chaque Subscription possède un identifiant unique de type GUID pour l’identifier dans le système.

Les services applicatifs de SharePoint peuvent être partitionnés pour gérer le multi-tenancy mais il faut le faire lors de la configuration de la ferme car cela ne peut être changé ultérieurement (sauf en détruisant et recréant les services).

Les services devant être partitionnés sont ceux stockant des données (recherche, profils…). Ceux ne stockant pas de données n’ont pas besoin d’être partitionnés voir ne supportent pas le partitionnement (cf. photo).

Dans la mesure du possible, il vaut mieux désactiver les développements spécifiques voir les interdire. Le mode sandbox est là pour couvrir certains besoins et tout ce qui ne rentre pas dans une sandbox pourra poser des soucis sur un environnement mutualité.

Les grandes étapes de configuration sont :

  • Configurer les pré-requis côté infrastructure
  • Créer les WebApplications
  • Provisionner les services Applications
  • Créer des lots de Features
  • Provisionner les tenants

1ère démo pour montrer comment configurer la ferme qui a été installée au préalable.

Pour cela on commence par passer en revue un script Powershell qui va se charger de créer une WebApplication avec tous les éléments nécessaires (authentification, base de données, collection de site racine…).

D’autres scripts Powershell finisse de créer les éléments avec dans l’ordre les services Applications, le BCS, le Secure Store et Word Automation.

On voit que depuis l’administration centrale, certains services applications ne sont pas administrantes via les menus classiques, il faut aller dans l’administration des tenants pour accéder aux infos (ex: BCS et Metadata Store).

On passe ensuite à la définition des permissions sur les services applications (toujours via Powershell), on démarre le service de profils utilisateurs et on fini par configurer la recherche.

Retour aux slides pendant que la recherche se configure car cela prend plusieurs minutes.

Les pré-requis côté infrastructure concernent le réseau, le DNS, ActiveDirectory (notamment une OU pour chaque client), la ferme SharePoint et les comptes de services.

Les slides montrent les extraits importants des scripts Powershell qui ont été exécutés dans la démo précédente (les slides seront sur le réseau MCNEXT dans le courant de la semaine prochaine).

Retour à la démo pour vérifier que la recherche a finie d’être configurée, ce qui est le cas vu que la démo a bien été préparée   😉

On créer maintenant un Feature Pack dans lequel on défini toutes les features qui seront disponibles pour le tenant auquel sera affecté le pack.

On termine la configuration par le provisioning du tenant en spécifiant le nom, le mail, le feature pack devant être utilisé, la WebApplication associée, les MySite, un Content Type Hub…

Une fois que tout est configuré, on voit que l’on peut accéder aux services sans soucis (le people picker ne fait apparaître que les gens de l’OU du tenant, le TermStore est vide et on peut commencer à créer des termes, etc…).

On voit notamment qu’un site a été créé lors du processus de configuration des tenants (1 site par client), pour accéder aux options d’administration propres à chaque société.

Retour aux slides pour donner quelques trucs et astuces.

Le mode multi-tenancy ayant été à la base pensé pour Office 365, il faut suivre les mêmes recommandations d’usage pour l’implémenter OnPremise sinon il y aura de gros soucis.

Parmi les choses à ne pas faire, utiliser le multi-tenancy parce qu’on a vu que ça existait que ça a l’air cool. Il faut en avoir l’utilité avant de le mettre en œuvre.

De fortes contraintes sont imposées pour installer le multi-tenancy donc il faut bien réfléchir aux éléments qui impacteront le réseau de l’entreprise (ex: la structure AD) avant de se lancer dans l’installation.

FAST, PerformancePoint et Project Server ne sont pas supportés.

L’utilisation du mode d’authentification par Claims et plus que recommandée (voir obligatoire).

Il faut aussi savoir que l’implémentation du multi-tenancy requiert souvent du développement additionnel pour par exemple créer des interfaces permettant d’administrer la solution (plutôt que de tout faire via Powershell).

Service Application Partitioning

Service Application Partitioning

Building Business Applications on Azure using Office 365 and Windows Azure AppFabric

Session animée par Tony Meleg (Microsoft)

En général une application est constituée d’entités et de données, de formulaires avec de la logique, d’informations, de contenus et de processus

Pour construire une application, on a besoin d’outils (Visual Studio), de langages (C#), de Frameworks (SharePoint est considéré comme tel) et des services (bases de données, rapports, messagerie, cache, workflow, planification…)

Qu’est-ce qu’Office 365 apporte pour répondre aux besoins exprimés ci-dessus ? Et bien il offre toutes les briques nécessaires pour construire une application (cf. la photo prise montrant les connexions entre les différentes briques)

La suite de la session va permettre d’entrer plus en détail sur les différents concepts exposés dans le slide précédent

Quelle est la stratégie sous-jacente ici pour construire les futures applications ?

On peut continuer à héberger les applications comme aujourd’hui (OnPremise) ou bien utiliser le Cloud. Il doit également être possible d’utiliser n’importe quel langage, de virtualiser les applications (pour les rendre facilement portable) et de viser le concept de PaaS (Platform as a Service) pour utiliser des Clous privés ou publics

Parlons maintenant de la virtualisation et de la différence de IaaS (Infrastructure as a Service) avec PaaS (Platform as a Service)

Une application nécessite beaucoup de briques fonctionnelles différentes, qui souvent sont découpées fonctionnellement pour pouvoir faire évoluer une brique indépendamment des autres. Ce signifie qu’un nombre très important de machines est requis pour mettre en œuvre une application, ce qui représente un coût important.

La virtualisation est là pour répondre à ces besoins en réduisant le coûts car un serveur correspond à 1 fichier VHD, ce serveur embarquant tous les composants nécessaires au fonctionnement de l’application

IaaS est du coup familier aux développeurs qui ont le contrôle sur ce qui est déployé, les machines virtuelles sont portables, il n’y a aucune différence avec le développement classique et SharePoint Online est là pour héberger des services tels que la collaboration

IaaS propose généralement une bibliothèque de machines virtuelles prêtes à l’emploi pour créer des serveurs web, des serveurs SQL… Il ne reste qu’à configurer les composants spécifiques à l’application (structure de base de données, binaires de l’application…), dupliquer les machines pour assurer une montée en charge importante, configurer de l’équilibrage de charge et le tour est joué (ça à l’air simple dit comme ça   ;-))

Oui mais la partie provisioning de base de données, gestion de la sécurité, gestion des contenus des sites web… est plutôt du ressort de PaaS donc comment faire cohabiter le 2 ?

PaaS propose différents rôles qui peuvent être utilisés en combinaison avec IaaS, notamment le rôle de stockage de données qui peut être partagé par plusieurs clients, dupliqué, sauvegardé et restauré, etc…

Dans le modèle PaaS, chaque service est multi-tenant (utilisé par client) et non dépendant de la machine sur laquelle s’exécute l’application. Les clients fournissent les éléments de l’application et ne s’occupent jamais de la partie infrastructure. Le fait de découper une application en différents rôles permet de maximiser les ressources utilisées et de pouvoir déplacer un bout de son application plus facilement.

Quelques règles doivent êtres respectées pour faire du PaaS :
– Les applications doivent être faiblement couplées aux services et pouvoir s’exécuter sur plusieurs machines en parallèle
– 2 instances ne doivent jamais être connectées l’une à l’autre directement
– Une instance peut planter sans prévenir et l’application doit gérer ce cas comme étant « normal » et continuer de fonctionner

Azure propose de faire du PaaS en proposant des rôles de type web, stockage, SQL et reporting pour créer des applications web. SharePoint Online propose les services de collaboration, site Internet… D’autres fonctionnalités comme les worker rôles, la gestion du trafic, le fourniture de contenus (CDN) et la connexion inter-applications sont également offerts par Azure.

Pour créer des applications avec des fonctionnalités avancées, on peut aussi utiliser les briques suivantes:
– Access Control pour gérer l’authentification et l’identité des utilisateurs
– Caching pour stocker des données en mémoire plutôt qu’en base de données (pour améliorer les performances)
– Service Bus pour interconnecter les applications, notamment faire un mix entre des applications Azure d’autres hébergées sur le système d’information de l’entreprise
– Integration (pas encore disponible à ce jour, en version CTP mais arrive prochainement)
– WebServices + Workflow (workflow en cours de développement, CTP à accès privé en cours)

On passe maintenant en revue le fonctionnement des briques décrites ci-dessus. Plutôt que de vous faire un long discours, je vous laisse vous référer aux articles MSDN/Technet sur le sujet qui seront beaucoup plus complets que ce que je pourrais écrire ici et les explications données par le speaker restent assez générales.

Enfin une démo alors que la session se termine dans 5mn. Une application Silverlight est hébergée dans SharePoint Online et utilise Service Bus pour soumettre des commandes à un service WCF hébergé le portable du speaker. Une application console fait office de service WCF et on voit que lorsqu’on interagit dans SharePoint avec l’application Silverlight, les commandes sont transmises à l’application console.

Même style de démonstration avec les Topics AppFabric pour montrer le principe de publish/subscribe de cette partie de AppFabric. Des commandes sont envoyées depuis l’application Silverlight, puis celles-ci sont récupérées depuis des applications console faisant office d’abonnés.

Une nouvelle fois et malgré un niveau 300, la session est restée assez généraliste et nous n’avons pas vu comment arriver aux résultats démontrés. Nous voyons juste que cela fonctionne sans plus de détails  😦