Informations de base : entités de contenu dans Windows SharePoint Services

Windows SharePoint Services 3

Cette rubrique décrit la hiérarchie des entités de contenu dans Windows SharePoint Services 3.0. Ces entités sont modelées par les classes de niveau supérieur dans la hiérarchie de contenu du modèle objet Windows SharePoint Services. Pour obtenir des informations de base sur les entités physiques et de service dans un déploiement de Windows SharePoint Services, voir Informations de base : objets physiques dans Windows SharePoint Services et Informations de base : entités de service dans Windows SharePoint Services.

Vue d'ensemble

Windows SharePoint Services crée un univers Web abstrait où les listes et les éléments de liste, au lieu des pages, constituent les principales entités de la population. Pour un navigateur, le Web (ou un intranet) est toutefois un univers de pages qui contiennent des liens entre elles, et ces pages existent sous forme de fichiers hébergés par des serveurs à des adresses URL spécifiques. Bien qu'un site Windows SharePoint Services doive se présenter aux utilisateurs (et même à certains types d'administrateurs de sites) comme un univers de listes, il doit être implémenté au-dessus d'un univers ancien qui date du début des années 1990 : un univers de pages rendues par navigateur.

Comme Windows SharePoint Services doit reposer sur un univers de pages, un site Web Windows SharePoint Services, représenté par la classe SPWeb, est un ensemble de fichiers (tout particulièrement de fichiers .aspx) et de données, utilisateurs et stratégies d'autorisation associés (bien que cela soit bien plus qu'un ensemble de fichiers). Le site Web peut posséder des sous-sites. (Les sous-sites sont également représentés par la classe SPWeb.) En outre, chaque déploiement de Windows SharePoint Services regroupe ses sites Web dans une ou plusieurs collections de sites, représentées dans le modèle objet par la classe SPSite. Les collections de sites sont elles-mêmes regroupées dans un ou plusieurs ensembles, appelés bases de données de contenu et représentées par la classe SPContentDatabase. Elles sont les filles d'une ou plusieurs applications Web dans Windows SharePoint Services. Une application Web est représentée par la classe SPWebApplication.

Remarque Remarque :

Une collection de sites était appelée simplement « site » dans la version d'origine de Windows SharePoint Services, Microsoft SharePoint Team Services, et c'est la raison pour laquelle la classe représentant une collection de sites est appelée SPSite. De même, un « site Web » (ou parfois simplement un « site ») dans Windows SharePoint Services 3.0 était appelé « Web » à l'origine, ce qui explique pourquoi la classe qui le représente est appelée SPWeb. Bien qu'un objet SPSite représente une collection d'éléments, la classe SPSite n'est pas une collection dans le sens d'une classe implémentant ICollection. Une classe SPSiteCollection implémente la dernière interface et elle représente une collection d'objets SPSite.

Dans Windows SharePoint Services, un site Web, une collection de sites, une base de données de contenu et une applications Web représentent donc, dans un certain sens, des partitions du contenu d'un déploiement de Windows SharePoint Services.

Sites Web Windows SharePoint Services

Un site Web Windows SharePoint Services, représenté par la classe SPWeb, est un site Web ASP.NET optimisé pour la gestion de contenu et la collaboration. Il diffère principalement des autres applications ASP.NET pour les raisons suivantes :

  • Il met l'accent sur les listes et les éléments de liste et non pas sur les pages. Par exemple, le volet Lancement rapide d'un site Windows SharePoint Services (du type STS) affiche une hiérarchie de sites, sous-sites et listes (y compris des listes de listes) plutôt que des pages. Si vous ajoutez une page à un tel site, cette page apparaît dans le volet Lancement rapide comme un nouvel élément de liste de documents partagés et non pas comme un nœud enfant en dessous de la page d'accueil ou de toute autre page.

  • Il permet aux utilisateurs d'effectuer des tâches d'administration. Les tâches pouvant être effectuées par un utilisateur donné dépendent des autorisations qui lui sont accordées. En règle générale, les utilisateurs finaux peuvent créer des sites Web (en tant que sous-sites d'un site Web existant) et ajouter du contenu et le modifier sur des sites Web existants.

  • Il correspond à l'un des quatre niveaux auxquels un Windows SharePoint Services Composant fonctionnel peut être activé. Les autres niveaux sont la collection de sites, l'application Web et la batterie de serveurs. (Pour plus d'informations sur le rôle de la batterie de serveurs dans le modèle objet Windows SharePoint Services, voir La hiérarchie des objets physiques de Windows SharePoint Services.)

Le fait qu'un site Web soit un sous-ensemble du contenu d'une collection de sites n'implique en aucun cas que le contenu de deux sites Web d'une collection donnée soit mutuellement exclusif : une liste donnée, par exemple, peut apparaître dans plusieurs sites Web.

Une hiérarchie de sites Web dans une collection de sites possède toujours un site Web de niveau supérieur. Pour plus d'informations sur le site Web de niveau supérieur, voir la section Collections de sites Windows SharePoint Services plus loin dans cet article.

Applications Web Windows SharePoint Services

Une application Web Windows SharePoint Services, représentée par la classe SPWebApplication, est un ensemble de bases de données de contenu, chacune contenant des collections de sites. Les sites de collections sont eux-mêmes des ensembles de sites Web, qui sont des ensembles de fichiers.

Une application Web Windows SharePoint Services ne se limite toutefois pas à un groupe de niveau supérieur de sites Web. Elle constitue également la couche à laquelle un déploiement de Windows SharePoint Services est visible pour IIS. Chaque application Web Windows SharePoint Services est exposée via un site Web IIS et apparaît dans l'arborescence des sites Web du Gestionnaire des services Internet. (Voir la figure 1.) Toutes les collections de sites et tous les sites Web (et les sous-sites) d'une application Web Windows SharePoint Services sont donc considérés comme un site Web volumineux par IIS.

Remarque Remarque :

La terminologie peut être ici source de confusion : ce que Windows SharePoint Services appelle « application Web » est servie par le biais d'un ou plusieurs « sites Web » IIS.

Figure 1. Le Gestionnaire des services Internet (IIS) juste après l'installation de Windows SharePoint Services 3.0 sur un serveur unique
Gestionnaire IIS après l’installation de WSS sur un serveur

IIS attribue automatiquement à chaque site Web IIS, dès qu'il est créé, son propre pool d'applications, et chaque pool d'applications possède son propre processus. Ainsi, chaque application Web Windows SharePoint Services s'exécute dans son propre processus. Si l'un de ces processus s'interrompt de façon inattendue, les autres continuent à s'exécuter. Il s'agit de la différence la plus importante entre une application Web Windows SharePoint Services et les couches inférieures de la hiérarchie du modèle objet. Les bases de données de contenu et les collections de sites ne font pas l'objet d'une isolation de processus, alors que c'est le cas des applications Web.

Remarque Remarque :

En réalité, la relation un-à-un entre les sites Web IIS et les pools d'applications ne doit pas être obligatoirement conservée. Dans le Gestionnaire des services Internet (IIS), les sites Web peuvent être déplacés d'un pool d'applications vers un autre. Ainsi, plusieurs applications Web Windows SharePoint Services peuvent être déplacées vers le même pool et partager le même processus. Dans certains cas, les améliorations des performances liées à ce type de partage de processus justifient toute perte de protection contre les incidents. Le partage de processus est toutefois peu fréquent. Cet article suppose donc que chaque application Web Windows SharePoint Services possède son propre processus.

Voici d'autres différences essentielles entre les applications Web Windows SharePoint Services et les collections de sites Windows SharePoint Services :

  • Chaque application Web possède une ou plusieurs de ses propres bases de données de contenu filles, mais chaque collection de sites n'appartient qu'à une seule base de données de contenu parente (qu'elle peut partager avec d'autres collections de sites qui sont incluses dans la même application Web).

  • Les stratégies de sécurité, telles que l'authentification et l'accès des utilisateurs anonymes, sont définies au niveau des applications Web Windows SharePoint Services.

La figure 1 illustre le Gestionnaire des services Internet (pour ISS 6.0) juste après l'installation de Windows SharePoint Services 3.0 sur un serveur unique. Vous pouvez remarquer que l'installation a créé deux sites Web IIS et que chacun d'entre eux possède son propre pool d'applications (et processus). L'un des sites Web IIS est destiné à une application Web Windows SharePoint Services principale qui fournit du contenu aux utilisateurs finaux et qui s'appelle « SharePoint - 80 ». (« 80 » représente le numéro de port du serveur via lequel proviennent les demandes de pages Windows SharePoint Services.) L'autre site Web, appelé « Administration centrale de SharePoint v3 », est utilisé par les informaticiens pour effectuer des tâches d'administration générales. Vous pouvez très certainement deviner pour quelles raisons ce site a été configuré comme une application Web Windows SharePoint Services distincte plutôt que comme une collection de sites ou un site Web dans « SharePoint – 80 ». L'isolation de processus des deux applications Web Windows SharePoint Services permet aux administrateurs réseau d'avoir accès à l'Administration centrale, et ce même si du code sur un site Web au sein de « SharePoint – 80 » entraîne le blocage de cette application Web après chaque démarrage. Faire de l'application d'administration une application Web distincte permet en outre aux administrateurs d'attribuer des stratégies distinctes en ce qui concerne l'authentification et les utilisateurs anonymes.

Si Windows SharePoint Services 3.0 est installé dans une batterie multiserveur et si la configuration fait la distinction entre les serveurs frontaux et les serveurs principaux (appelés serveurs d'applications dans Windows SharePoint Services), « SharePoint – 80 » s'exécute uniquement sur les serveurs frontaux. « Administration centrale de SharePoint » s'exécute sur un seul des serveurs d'applications. Pour plus d'informations sur les batteries de serveurs, ainsi que sur les différents types de serveurs et leurs rôles, voir La hiérarchie des objets physiques de Windows SharePoint Services et Hiérarchie des services de Windows SharePoint Services.

Les applications Web Windows SharePoint Services autres que l'application « Administration centrale de SharePoint v3 » sont appelées applications Web de publication de contenu.

Lorsque l'application Web initiale « SharePoint - 80 » est créée, et dès la création de toute application Web de publication de contenu, une base de données de contenu est créée pour celle-ci. Une collection de sites est à son tour créée pour la base de données, ainsi qu'un site Web de niveau supérieur pour la collection de sites.

Plusieurs applications Web de publication de contenu

Dans de nombreuses PME, les deux applications Web Windows SharePoint Services installées par défaut sont les seules à être créées, et ce même si l'utilisation intensive de l'application Web « SharePoint – 80 » demande une batterie de serveurs pour l'héberger. Il existe toutefois certains cas dans lesquels d'autres applications Web Windows SharePoint Services de publication de contenu sont nécessaires et, pour chacune d'entre elles, un site Web IIS et un pool d'applications correspondant. Voici des exemples de certaines de ces situations. (Il n'existe qu'une seule application Web « Administration centrale » Windows SharePoint Services pour une batterie de serveurs donnée.)

  • Lorsqu'une entreprise effectue une migration progressive de Windows SharePoint Services 2.0 vers Windows SharePoint Services 3.0, les deux applications peuvent être déployées sur le même serveur. Dans ce cas, chaque version possède une application Web Windows SharePoint Services distincte (ou un ensemble distinct d'applications Web).

  • Si une nouvelle solution Windows SharePoint Services est en cours de développement sur un serveur (ou un ensemble de serveurs frontaux) qui héberge également un déploiement Windows SharePoint Services de production, elle peut être implémentée dans une application Web Windows SharePoint Services distincte une fois qu'elle a été intégralement testée. Cette pratique permet de s'assurer que les applications Web Windows SharePoint Services de production ne s'interrompent pas en cas de blocage de la nouvelle solution. La base de données de contenu de l'application Web non testée est en outre séparée de celle de production. L'application Web non testée peut se voir attribuer un numéro de port autre que le numéro 80, afin de limiter tout accès non autorisé à l'application (en effet, à l'exception des sites Web qui utilisent le port 80, les numéros de port peuvent être inclus dans une URL Web afin qu'IIS trouve la page demandée).

  • Les entreprises qui offrent des services d'hébergement de Windows SharePoint Services à des petites entreprises donnent généralement à chacune d'entre elles sa propre application Web Windows SharePoint Services. Cette pratique permet de s'assurer que les sites Web du client ne sont pas interrompus par du code contenu dans une application Web Windows SharePoint Services d'un autre client. Elle garantit également que la base de données du client n'est pas accessible par d'autres clients. Elle permet enfin à chaque client d'avoir des stratégies distinctes en ce qui concerne l'authentification et les utilisateurs anonymes.

  • Les applications Web sont plus performantes lorsque tous les sites qu'elles contiennent ont des structures similaires. Une collection de « Mes sites » par exemple contiendrait de nombreux petits sites, tandis qu'une collection de sites d'équipes contiendrait un plus petit nombre de grands sites. En hébergeant la collection de sites d'équipes dans une application Web distincte, les performances des deux collections seraient améliorées.

  • Toute application Web donnée peut avoir cinq jeux distincts de stratégies de sécurité, un pour chacune des cinq zones d'où peuvent provenir les demandes : zone Internet, zone intranet, zone extranet, zone par défaut et zone personnalisée. Si d'autres jeux de stratégies sont nécessaires, il est possible de créer des applications Web supplémentaires (éventuellement avec du contenu identique à une application Web existante), chacune avec ses cinq jeux de stratégies.

  • Si un logiciel serveur de collaboration améliorée, tel que Microsoft Office SharePoint Server 2007, est installé en plus de Windows SharePoint Services 3.0, il peut regrouper logiquement les applications Web. Il peut par exemple procéder ainsi pour fournir des services communs au groupe ou pour isoler d'un point de vue administratif le groupe des autres applications Web. Dans ce cas, le logiciel peut demander la création d'une application Web spéciale faisant office de parent logique ou de conteneur du groupe. Le parent logique est appelé fournisseur de services partagés (SSP). (Un regroupement logique de ce type n'est toutefois pas reconnu par IIS 6.0 et n'est pas modelé dans le modèle objet Windows SharePoint Services 3.0 . Pour IIS, le fournisseur de services partagés représente uniquement un autre site Web, et pour Windows SharePoint Services 3.0, il constitue une autre application Web.)

Remarque Remarque :

Dans Windows SharePoint Services 3.0, les applications Web sont créées sous l'onglet Gestion des applications de l'Administration centrale et non pas dans IIS.

Bases de données de contenu Windows SharePoint Services

Chaque application Web Windows SharePoint Services possède au moins une base de données de contenu (représentée par la classe SPContentDatabase) qui est automatiquement créée lors de la création de l'application Web. D'autres bases de données de contenu peuvent être ajoutées, si nécessaire, à une application Web. Une base de données de contenu contient toutes les données (listes, éléments de liste, publications et commentaires de blogs, pages Wiki et documents des bibliothèques de documents) et la plupart des fichiers de pages qui constituent les collections de sites appartenant à la base de données.

Certains des fichiers appartenant à une collection de sites sont stockés dans le système de fichiers des serveurs frontaux du déploiement de Windows SharePoint Services. À première vue, cela peut faire penser que les collections de sites ne sont pas réellement des sous-ensembles de bases de données de contenu. Les fichiers qui ne sont pas stockés dans la base de données de contenu sont toutefois représentés par des lignes dans celle-ci. La ligne de la table qui représente un tel fichier fonctionne comme un alias pour celui-ci.

Collections de sites Windows SharePoint Services

Les collections de sites, représentées par la classe SPSite , existent à des fins d'administration pour les propriétaires de sites, les administrateurs de serveurs et les entreprises qui offrent des services d'hébergement de Windows SharePoint Services. Voici quelques caractéristiques les plus importantes des collections de sites Windows SharePoint Services :

  • Les collections de sites Windows SharePoint Services permettent une administration plus précise des déploiements de Windows SharePoint Services que les applications Web Windows SharePoint Services, bien que l'administration des sites Web incombe toujours aux propriétaires de sites qui ne sont généralement pas informaticiens.

  • Chaque collection de sites ne possède qu'un seul site Web de niveau supérieur. Pour certains types de tâches d'administration, la collection de sites et son site Web de niveau supérieur peuvent être considérés comme une seule entité. Par exemple, la page Paramètres de site du site de niveau supérieur contient une zone Administration de la collection de sites dans laquelle le propriétaire du site Web de niveau supérieur peut activer des fonctionnalités pour la collection de sites et restaurer le contenu supprimé de la collection à partir de la Corbeille. Vous pouvez également créer certaines entités personnalisées, telles qu'une colonne personnalisée, dans le site Web de niveau supérieur. Ces entités sont alors accessibles par tous les sites Web de la collection de sites.

  • Les collections de sites suppriment la frontière entre les responsabilités administratives des propriétaires de sites et celles des administrateurs de collections de sites, qui sont généralement informaticiens. Comme indiqué dans le paragraphe précédent, certaines tâches d'administration au niveau de la collection de sites sont gérées par le propriétaire du site Web de niveau supérieur. Les administrateurs de serveurs et réseau peuvent toutefois utiliser l'onglet Gestion des applications de l'Administration centrale pour créer et supprimer des collections de sites et définir les quotas de taille de celles-ci.

  • Une collection de sites (ou, plus précisément, son site Web de niveau supérieur) constitue l'objet de niveau le plus élevé dans l'exploration à l'aide de la barre de navigation. (Bien que les utilisateurs d'un sous-site n'aient pas obligatoirement accès à chaque site Web de niveau supérieur dans la hiérarchie, ils peuvent utiliser ces sites dans l'exploration à l'aide de la barre de navigation.)

  • Une collection de sites correspond au niveau auquel les pools d'applications des fonctionnalités, des types de contenu, des listes, des thèmes et des flux de travail étendus au site Web et à la collection sont gérés et accessibles par les sous-sites.

  • Une collection de sites correspond à l'un des quatre niveaux auxquels un Windows SharePoint Services Composant fonctionnel peut être activé. Les autres niveaux correspondent au site Web, à l'application Web et à la batterie de serveurs.

  • Une collection de sites correspond au niveau auquel les groupes d'utilisateurs sont gérés et auquel les droits par défaut leur sont affectés. (Ces droits peuvent être modifiés au niveau d'un site Web, d'une liste ou d'un élément de liste. Vous pouvez créer des groupes dans la page Paramètres du site de n'importe quel site Web. Toutefois, quel que soit le niveau auquel le groupe est créé, il existe au niveau de la collection de sites et il est accessible par tous les sites Web de la collection.)

  • Des pages maîtres et des composants WebPart peuvent être partagés dans une collection de sites mais pas entre collections de sites.

  • Une collection de sites constitue l'objet de niveau le plus élevé dans la hiérarchie pour lequel l'accès peut être analysé. Elle représente également le niveau auquel est géré la base de données d'analyses.

  • Une collection de sites représente le niveau le plus élevé qui peut être inclus dans une recherche.

Voir aussi

Afficher: