Jiri's Shared IT knowledge

dimanche, janvier 07, 2007

Architecture logique SharePoint 2007

Introduction
La technologie SharePoint a atteint une véritable maturité technologique dans sa version 2007.
3eme version après SPS 2001 et SPS 2003, elle est devenue un des piliers incontournables de l'offre Office System ainsi que le pilier technologique des nouveaux Office Servers comme Excel Service, InfoPath Forms Server et Performance Point.
Elle peut être résumée rapidement comme une « Site Factory » basée sur la notion de modèle. SharePoint 2007 peut ainsi gérer aussi aisément un site institutionnel, quelques blogs/Wiki, une hiérarchie de GED jusqu'à une infinité d'espace de projet ou d'équipe. Et le tout basé sur une seule et unique infrastructure !

Mais avant de parler de conception, développement, ou même infrastructure, il est impératif de bien comprendre les tenants et aboutissants de la technologie SharePoint 2007.

Les principes fondamentaux de l'architecture de SharePoint 2007
Principe 1 : Une architecture logique hiérarchique

Quand on parle d'architecture logique, la notion de machine physique est clairement absente. Dans le cas de la technologie SharePoint, c'est encore plus une réalité.
Qu'il s'agisse d'un serveur « standalone » ou même une infrastructure reliée de 5 machines, l'ensemble se réduira toujours à la notion de ferme SharePoint. Il n'existe ainsi pas de différence entre toutes les configurations physiques possibles, il ne s'agit que de rôle serveur et de volumétrie de gestion. Evidemment, une ferme composée de plusieurs serveurs SharePoint gère bien plus de sites, de portails et d'utilisateurs simultanés qu'un simple serveur. Cependant, il n'y a aucune impact sur la conception même et l'organisation des contenus d'un site web SharePoint : ce seront les mêmes.

Mais quels sont donc les éléments de base de toute architecture SharePoint ?

Simple, il s'agit en fait d'une architecture très hiérarchisé et interdépendante.

La ferme SharePoint héberge donc différentes Web Applications (WA). Ce sont des instances de Sites Web IIS qui ont été « étendus » par SharePoint. Comprenez des sites IIS sur lesquels, l'applicatif SharePoint gère le traitement de ses informations grâce à ASP.Net 2.0.

Les Web Applications gèrent aussi le stockage de l'information en associant diverses bases de contenus sous SQL Server.

  • Les Web Applications sont, en fait, le support logique de SharePoint 2007


Il vient ensuite la notion de Site Collection (SC ou SPSite). Elles représentent le conteneur principal de SharePoint. Elles contiennent et gèrent le cycle de vie des sites web de contenu (WS ou SPWeb). Soit le site Web SharePoint que tout à chacun peut observer via son navigateur.

Pour mieux comprendre, sachez que le Site Web est le premier type de contenu de SharePoint 2007 et qu'il n'existe qu'à travers une Site Collection. Un peu comme un contenant et son conteneur.

Prenons l'exemple d'une chaine d'hôtel. Les chambres d'hôtel appartiennent toujours à un hôtel et plusieurs hôtels peuvent exister dans la même région comme dans le cas des Formule1, Ibis, Parking ou autre.


Ainsi, si le contenu est lié au SPWeb, la gestion, la volumétrie et les diverses galeries de permission, droits ou de WebParts sont liés au SPSite mais mis en commun pour tous les SPWeb. C'est une structure arborescente classique et sachez que le site de racine ou site de haut niveau est toujours le premier site obtenu à la création de la collection de Site.

Les collections de site ou SPSite sont eux reliés au Web Application via la notion de Chemin de gestion. Par défaut, une collection peut être créée soit en racine « / » (chemin explicite) ou en sous site de l'adresse « /Sites/* » (chemin générique). D'autre chemins peuvent être ajoutés afin de diversifier un peu plus les adresses comme :

  • Adresses génériques :
  • /Blogs (puis une SPSite par Blog de la société)
  • /Teams (pour le collaboratif)
  • /Projects (pour la création des sites de projet générés par Project Server par exemple)
    Adresses explicites :
  • /HR (Portail HR indépendant de l'intranet)
  • /Filiale (Nom de la filiale)
  • garder toujours la racine pour le site institutionnel, c'est usuel

Des entêtes http peuvent aussi être utilisés comme Teams.VotreDns.org mais il faut alors passer par les lignes de commandes.
En ce qui concerne le contenu, soit le SPWeb ou les sites web, ils sont composés de 2 éléments principaux :

  1. Les pages web : soit de simple page ASPX ou mieux encore de Pages à WebParts dans le pur style ASP.Net 2.0.
  2. Des Listes de contenus : SPList. Ce sont les gestionnaires d'information des SPWeb. Elles sont de divers types comme les bibliothèques documentaire, d'image ou même la gestion des taches avec vue Gantt.

Ces deux composants forment le c?ur des modèles de génération en XML « Site Definition », qui est utilisé lors de la création de ces sites.

Un dernier point à ne jamais négliger. Chaque SPWeb peut contenir des sous sites Web et ainsi de suite. Ce que l'on appelle communément une hiérarchie de contenu.

Le grand secret de la conception SharePoint ne dépend pas simplement des modèles de site, de contenu et des WebParts mais bien plus de l'agencement de divers « Site Collection » associé à la profondeur et la répartition des diverses arborescence de « Site Web ».

  • Un bon conseil : Privilégiez toujours 2,3 niveaux de SPWeb mais limitez l'utilisation de dossier dans les listes documentaires !

Principe 2 : Ce sont tous des Sites SharePoint.

Sous WSS v3, nous parlerons souvent de Team Site, Meeting Site ainsi que de Blog et de Wiki.

Sous MOSS 2007, l'accent sera plus sur la notion de portail communautaire, site institutionnel, site de publication ou Dashboard BI.

Quelques soient la License choisie et le modèle utilisé, il s'agit toujours et encore du trinôme :

  • Web Site
  • Site Collection
  • Web Application

Et bien sur, on n'oublie pas la notion de modèle de site Web, modèle de listes et les divers composants propres à chaque site.

Quoi que vous manipuliez sous SharePoint 2007, il y a de fortes chances qu'il s'agisse d'un SPWeb ou site web si vous préférez.

Sans rien trahir quelques secrets de polichinelle, sachez que même l'administration centrale de SharePoint 2007 repose sur une simple Site Collection avec son site web de racine et 3 pages applicatives : Home, Application et Operation.

Principe 3 : les services partagés.

Lors d'une analyse simple d'un portail de contenu, de nombreuses similitudes peuvent être identifiées rapidement comme :

  • La gestion de profile
  • Un moteur de recherche
  • La SSO
  • L'intégration avec des systèmes tiers comme les ERP de Gestion

Souvent, il s'agit de services de haut niveau utilisés directement via le portail ou d'autre intranet d'un système d'information.

SharePoint 2007 respecte ce design dans sa nouvelle conception via la notion de « Shared Services Provider » (SSP) ou «Fournisseur de Services Partagés ».

La plupart des services de haut niveau et/ou consommateurs de ressources sont ainsi regroupés à travers cette notion de SSP pour mieux être exploités via les différents sites de contenus.

Leur gestion est cependant devenue indépendant même du site web qui l'exploite. Ne cherchez donc plus le module des audiences dans un portail MOSS mais plutôt dans son SSP associé.

Cette externalisation permet en plus d'associer un site de gestion externe et accessible depuis l'administration centrale. Bonus non négligeable, leur gestion peut être facilement déléguée à des administrateurs tiers.

Fini les cumuls de rôles entre :

  • Gestionnaire de contenu
  • Administrateur réseau
  • Coordinateur SharePoint

Un dernier point, les SSP sont seulement accessibles pour une configuration MOSS et non WSS. Cependant des Sites Collection de Team Site WSS peuvent être aisément reconnectées à un SSP si un jour le moteur de recherche fédérateur était déployé.

Principe 4 : Les nouveaux portails MOSS

Sous SharePoint 2003 et 2001, on différenciait 2 types principaux de sites Web :

  • Les portails (SPS)
  • Les sites d'équipes (WSS)
  • SharePoint 2007 change complètement cette donne et unifie le tout en accord avec le second principe.




Un site MOSS donc soit portail communautaire ou site de publication est en fait une classique Site Collection WSS v3 utilisant un modèle portail le tout associé à un SSP pour ses services de haut niveau.

Désormais, les sites collaboratifs (WSS), les portails (MOSS Portal) ou le système de publication (MOSS WCM) partagent réellement les mêmes :

  • Couche applicative
  • Architecture
  • Infrastructure.

En ce qui concerne le modèle portail, il n'y pas plus d'inquiétudes. Il s'agit en fait d'un simple modèle XML décrivant directement la hiérarchie de SPWeb à créer et leur Site Definition comme le décrit bien le principe 1.

Attention : Il ne faut pas se tromper pour autant, MOSS transcende vraiment la plateforme SharePoint face à WSS en permettant bien plus que de simple site de projet/collaboration

La notion de SSP, le moteur de recherche fédérateur, les modèles de publication et ses composants orientés métiers donnent une plateforme encore plus riche tournée vers les notions d'Entreprise Content Management (ECM).

Pour exemple, la Gestion Electronique Documentaire (GED) n'est que l'un des ces scenarii d'utilisation les plus simple. En effet, associé au Record Management, aux polices de gestion et de rétention, le résultat est bien plus riche.

Principe 5 : plus de topologie

C'est peut être un des points les plus novateurs de SharePoint 2007 : la disparition purement et simplement de notion de topologie lors du déploiement de l'infrastructure.

Il existe désormais 3 types de rôles pour un serveur SharePoint :

  • Serveur web Front End
  • Serveur Applicatif
  • Serveur de Base de données

Vous pouvez ainsi composez n'importe quelle ferme de serveurs SharePoint avec tous types de serveurs exploitant l'un ou plusieurs de ces rôles.

  • Le rôle « Base de données » n'est en rien spécifique SharePoint, il s'agit purement d'une configuration SQL Server 2000, 2005 ou Express. En cas de besoins de scalabilité et haute disponibilité, des configurations en cluster 64 bits sont largement recommandées.
  • Le rôle « Web Front End » (WFE) est certainement le rôle le plus léger, car il ne consiste qu'à la transformation des données SharePoint en un site web via ASP.Net et IIS. Ces serveurs sont souvent mis en batterie afin d'utiliser la notion de balance de charge (NLB), somme toute classique, des technologies Windows Serveurs.

Petite remarque sur la notion de NLB, si un ensemble de deux serveurs assurent un bon niveau de fonctionnement de la couche WEB, elle n'est cependant pas idéale et donc peu recommandée. En effet, en cas de perte de l'un des deux serveurs, la continuité de service est assurée, cependant le dernier serveur se voit ainsi sur sollicité lors de cette période. Vous avez clairement une situation ou la performance et le risque est élevé, car votre dernier front end se retrouve en pleine charge. Il faut donc bien faire attention à vos critères de sélection et de calcul de vos serveurs. Privilégiez peut être plus une architecture de trois serveurs Front End Biprocesseur qu'un doublon de Quadriprocesseur.

Le dernier rôle consiste plus au rôle de « BackOffice ». Il assure les fonctions des « Shared Services » (SSP) comme par exemple, le fonctionnement de l'indexeur ou de requête. Tout les deux sont des bons exemples de services très consommateur de ressource en terme de pointe d'utilisation ou de puissance comme la mise à jour de l'ensemble des indexes. Via ce rôle, certains services peuvent être distribués sur des machines tierces pour ne pas ralentir le fonctionnement même du portail.


Conclusion

Comme vous pouvez le constatez, la plateforme SharePoint 2007 a été conçue selon des principes simples et efficaces :

  • Indépendance du rôle applicatif des serveurs physiques
  • Homogénéité de sa plateforme dans son utilisation
  • Factorisation des rôles.
  • Organisation hiérarchique

En tenant compte des différents principes évoqués dans cet article, vous pouvez désormais explorer sans crainte les 1001 possibilités offertes par SharePoint 2007, c'est-à-dire MOSS 2007, WSS V3 et toute la suite de serveur.