Guide du Développeur - Services Internet hébergés · 2012-01-12 · G u i d e d u D é v e l o p p e u r V 1.1 Administration des Services Internet Page 1 Information réservée

G u i d e d u D é v e l o p p e u r V 1.1

Administration des Services Internet Page 1

Information réservée aux clients de SFR pour les Services Internet hébergés 1 / 41

Guide du Développeur pour l’hébergement WWW

sur la plate-forme de Services Internet hébergés

Espace Administration Services Internet




SOMMAIRE

1 TERMINOLOGIE............................................................................................................4

2 INTRODUCTION ............................................................................................................5

3 PRESENTATION DE LA PLATE FORME ..........................................................................6

3.1 DESCRIPTION GENERALE.............................................................................................6 3.2 ARCHITECTURE GLOBALE DE L‟HEBERGEMENT WINDOWS ....................................................6

3.2.1 Déploiement d’un site web ....................................................................................6 3.2.2 Les services disponibles .......................................................................................8 3.2.3 Typologie des applications ....................................................................................8 3.2.4 Application ASP ................................................................................................ 10 3.2.5 Application ASP Base de données ....................................................................... 12 3.2.6 Qu'est-ce que ASP.NET ? .................................................................................... 13 3.2.7 Liste des composants COM disponibles sur la plate-forme....................................... 16 3.2.8 Conventions de nommage .................................................................................. 17 3.2.9 Méthodologie de développement ......................................................................... 19 3.2.10 Fiabilité ........................................................................................................ 21 3.2.11 Performances ............................................................................................... 22 3.2.12 Sécurité ....................................................................................................... 23

3.3 GUIDE DE PROGRAMMATION ASP................................................................................ 24 3.3.1 Utilisation de variables privées ............................................................................ 24 3.3.2 Utilisation d’« Option Explicit »............................................................................. 24 3.3.3 Mélanges de code client et serveur ...................................................................... 24 3.3.4 Utilisation d’« includes » efficace ......................................................................... 25 3.3.5 Gestion du cache .............................................................................................. 25 3.3.6 Session et montée en charge .............................................................................. 25 3.3.7 Session_OnEnd ................................................................................................ 25

3.4 COMPOSANTS COM ............................................................................................ 26 3.4.1 Généralités ....................................................................................................... 26 3.4.2 Compatibilité des composants COM ..................................................................... 27 3.4.3 Types d’”Apartment” .......................................................................................... 27 3.4.4 Modèle de Threading ......................................................................................... 28 3.4.5 Portée des composants....................................................................................... 28

3.5 MODE OPERATOIRE ET TESTS..................................................................................... 30 3.5.1 Description du cycle projet .................................................................................. 30 3.5.2 Etapes du cycle projet ........................................................................................ 31 3.5.3 Téléchargement des fichiers ............................................................................... 31 3.5.4 Tests de l’application en pré-production ................................................................ 31 3.5.5 Demande de mise en production ......................................................................... 32 3.5.6 Mise en production ............................................................................................ 32 3.5.7 Outils de développement et mise en place de l’application ....................................... 32 3.5.8 Description des tests.......................................................................................... 33 3.5.9 Mise en conformité ............................................................................................ 33 3.5.10 Suivi des versions.......................................................................................... 33

4 ARCHITECTURE GLOBALE DE L’HEBERGEMENT LAMP .............................................. 34

4.1.1 Déploiement d’un site web .................................................................................. 34 4.1.2 Schéma d’architecture de l’hébergement LAMP ..................................................... 34 4.1.3 Les applications PHP ......................................................................................... 35 4.1.4 Application PHP et Base de données ................................................................... 36 4.1.5 Liste des composants CGI .................................................................................. 37 4.1.6 Convention de nommage.................................................................................... 37




5 CONCLUSION ............................................................................................................. 40

6 ANNEXE ..................................................................................................................... 41

LISTE DES FIGURES

Figure 1 : Schéma du processus de déploiement d‟un site web Windows .......................................7 Figure 2 : Schéma des types de services d‟une application client ..................................................9 Figure 3 : Schéma des services ASP....................................................................................... 11 Figure 4 : Schéma des services ADO & OLE ............................................................................ 12 Figure 5 : Schéma des services OLE DB ................................................................................. 13 Figure 6 : L‟architecture Microsoft Windows DNA ...................................................................... 20 Figure 7 : L‟architecture des services COM .............................................................................. 26 Figure 8 : L‟architecture des threads ASP................................................................................. 28 Figure 9 : Description du cycle de projet .................................................................................. 30 Figure 10 : Description du cycle de déploiement pré-production/production .................................. 31 Figure 11 : L‟architecture d‟hébergement LAMP ........................................................................ 34 Figure 12 : Le fonctionnement de l‟architecture PHP.................................................................. 35

LISTE DES TABLEAUX

Tableau 1 – Liste des applications types .................................................................................. 10




1 TERMINOLOGIE

ASP : Active Server Page ASP.NET : Active Server Page .net Client : Entreprise cliente de SFR. COM : Component Object Model est un standard et une architecture qui régit la réutilisation

binaire de composants. Les spécifications de COM sont disponibles sur le site web de Microsoft (http://www.microsoft.com/com/resources/comdocs.asp).

COMPOSANTS : Ce terme représente en réalité le fichier dans lequel sont implémentées les

différentes classes COM. Le composant contient donc le code de création de chaque classe qui le compose. Ainsi chaque classe est incorporée dans un composant (plusieurs classes peuvent être implémentées dans un composant unique). Les composants sont également appelés des serveurs COM.

DLL : Dynamic Linked Library. Bibliothèque de liens dynamiques. Ensemble de routines

extraite d'un programme principal, pour être partagées par plusieurs programmes, ou pour optimiser l'occupation de la mémoire (les DLL pouvant être chargées et déchargées à volonté).

FTP : File Transfer Protocol. Protocole de transfert de fichier. Par extension, nom de

l'utilitaire d'Unix utilisant le protocole TCP/IP pour télécharger des fichiers dans un sens ou dans l'autre

HTTP : HyperText Transfer Protocol. Protocole de transmission dédié aux clients et aux

serveurs du web. HTTPS : Protocol http sécurisé. Pré Production : idem : Pré déploiement, idem Pré visualisation Pré déploiement : Environnement à l‟identique de la production servant à valider les sites web

Windows des clients avant déploiement en production. ISAPI : Internet Server Application Programming Interface. Spécification des DLL pouvant

être utilisées par les serveurs web de Microsoft. URL : Uniform Resource Locator XML : eXtensible Mark-up Language. Norme d'échange de documents informatisés issue de

SGML, grâce au travail de l'ERB (Editorial Review Board), sous l'égide du W3C. XML intègre l'idée de métadonnée, et permet de définir les balises que l'on veut en fonction de ses besoins.

http://www.microsoft.com/com

http://www.tout-savoir.net/lexique.php?rub=definition&code=4277













http://www.linux-france.org/prj/jargonf/P/protocole.html

http://www.linux-france.org/prj/jargonf/W/web.html

http://www.linux-france.org/prj/jargonf/S/speaccification.html

http://www.linux-france.org/prj/jargonf/D/DLL.html

http://www.linux-france.org/prj/jargonf/W/web.html













2 INTRODUCTION

L‟objectif de ce document est de fournir, aux développeurs d‟applications Web qui souhaitent héberger leur application sur la plate-forme mutualisée de SFR, des préconisations en termes de conformité et d‟optimisation. L‟organisation de ce document s‟articule selon les deux environnements techniques supportés par la plate forme à savoir : Windows et LAMP. Pour chacun de ces environnements, seront abordés les chapitres adéquats ci-dessous :

Présentation de l‟architecture globale de plate-forme ainsi que les types d‟applications supportées sur la plate-forme d‟hébergement.

Description des conventions de nommage adoptées afin de garantir la compatibilité de l‟application avec la configuration mise en place sur la plate-forme.

Méthodologie de développement Web / base de données fournissant des conseils en terme de fiabilité, performances, et sécurité.

Guide de programmation ASP

Utilisation des composants COM Guide de programmation PHP Utilisation du CGI Mode opératoire permettant aux développeurs de sites et Webmasters de tester leur

application sur la plate-forme et de la mettre en ligne sur la plate-forme Internet.




3 PRESENTATION DE LA PLATE FORME

3.1 Description générale

La plate-forme permet de mutualiser les applications Web de différents clients au sein d‟un environnement unique fondé sur une architecture de serveurs Windows 2003 Web Edition et Linux Redhat AS. Afin de garantir la sécurité des applications hébergées :

Chaque application Web d‟un client est cloisonnée vis -à-vis des autres applications client.

Certains composants COM présents sur les systèmes Microsoft sont volontairement rendus inopérants. Néanmoins, la plate-forme met à disposition des développeurs un certain nombre de composants standard de l‟architecture COM qui sont présentés dans ce document.

La liste des CGI a été réduite à son strict minimum dans l‟environnement LAMP, à savoir uniquement le CGI « Formmail » est autorisé.

Les bases de données disponibles sont SQL Server pour Windows et MySQL pour l‟environnement Linux.

Un environnement de pré production ou encore de pré déploiement est disponible pour l‟hébergement Windows et permet aux clients de valider la conformité de leur site par rapport à l‟environnement de production.

L‟ensemble des services proposés reposent sur une architecture hautement sécurisée et disponible.

3.2 Architecture globale de l’hébergement Windows

3.2.1 Déploiement d’un site web

3.2.1.1 Les étapes de la mise en ligne de votre site Web La démarche de déploiement d‟un site Web Windows sur la plate-forme de services est la suivante :

Etape 1 : Téléchargement des sources du site sur votre compte FTP

Etape 2 : Création ou restauration éventuelle de votre Base de Données SQL

Etape 3 : Test du site sur l‟environnement de pré déploiement

Etape 4 : Déploiement du site sur l‟environnement de production

Ces différentes étapes sont plus ou moins illustrées dans le schéma de déploiement présenté dans la suite du document. La description détaillée de chacune ces étapes est effectuée d‟une part dans le document intitulé : « Guide d‟utilisateur » disponible sur l‟extranet client ou envoyé au client et d‟autre part dans la suite de ce document.




3.2.1.2 Schéma du processus de déploiement d‟un site web

Zone de développement

chez le client

Zone de pré production

(Tests)

Zone de production

(Hébergement)

Serveurs de production

Serveurs de pré production

Serveurs de développement

Transfert

FTP

Publication

Figure 1 : Schéma du processus de déploiement d‟un site web W indows Zone de développement client : Cette zone représente le réseau de l‟équipe de développement d‟un client sur laquelle les applications du client sont développées et préalablement testées. Zone de Pré production ou pré déploiement : Cette zone représente le réseau de tests pour les développeurs et administrateur du site du client sur le réseau d‟hébergement qui permet de vérifier le bon fonctionnement des applications dans un environnement simulant l‟environnement de production avant passage en environnement réel mutualisé : chaque application d‟un client n‟est modifiable à distance que par le client ou ses équipes de développement. La modification d‟un site se fera par FTP ou via Microsoft FrontPage™. Zone de Production : La zone de production représente la zone d‟hébergement où sont répliquées les applications de la zone de pré production et où elles seront accessibles pour les utilisateurs de l‟application en d‟autres termes, l‟ensemble de la communauté Internet. Répertoire Exclude : La zone de pré production ainsi que la zone de production comportent un répertoire Exclude. L‟ensemble des données figurant dans les répertoires Exclude de la pré-production comme de la production ne sont pas mises à jour lors de l‟opération de Publish. Le dépôt de fichier dans le répertoire EXCLUDE doit passer par le Support Technique Client car il inaccessible en écriture directe par l‟administrateur du site web. Le répertoire Exclude de pré production peut être par exemple utilisé pour stocker des données que l‟on ne veut pas publier (versions futures du site….).




Le répertoire Exclude de production peut être par exemple utilisé pour stocker des données générées par le site web de production et qui ne doivent pas être effacées lors d‟une mise à jour du site.

3.2.2 Les services disponibles

Les serveurs de la zone de production (zone d‟hébergement) aussi bien que ceux de la zone de pré production comprennent une série de services qui offrent des possibilités assez étendues en terme d‟architecture applicative. Les services offerts par la plate-forme d‟hébergement sont les suivants :

Windows 2003 Server : le système d‟exploitation fournit les services essentiels à toute la plate-forme et notamment :

o Le support des composants serveurs au sein de l‟architecture Component Objet Model (COM +)

o La gestion intégrée de la sécurité (NTFS) IIS 6 : le serveur Web fournit notamment les services

o ASP : les « Active Server Pages » permettent d‟exécuter des applications réalisées en Script sur le serveur et de générer des pages dynamiquement

o ASP.Net (Version 1.1.4322): est une infrastructure de programmation intégrée au

CLR (Common Language Runtime) et utilisable sur un serveur pour générer des applications Web puissantes. Ce service est en option et activable à la demande du client.

o ISAPI : des filtres et applications ISAPI permettent d‟exécuter des traitements dynamiques compilés sur le serveur Web

SQL Server 2000 : le système de gestion de bases de données relationnelles

3.2.3 Typologie des applications

3.2.3.1 Définition d‟une application client Une application client, est un ensemble d‟objets statiques et actifs intégrés dans un environnement de services communs (authentification, fichiers, base de données...) constituant une solution répondant à l‟activité du client. Les applications client sont exécutées dans un contexte isolé grâce à l‟utilisation d‟un processus spécifique pour l‟ensemble de ses applications. Si une application d‟un client présente des contraintes spécifiques incompatibles avec les règles édictées dans ce guide, le client pourra soumettre à SFR l‟architecture de son application pour un examen particulier. Il appartiendra alors à SFR d‟orienter le client vers une solution de type OSM (Offre Sur Mesure). Le schéma suivant illustre les services les plus fréquemment utilisés dans la mise en œuvre des applications des clients.




Administrateur

client

Utilisateur

Présentation HTTP

ASP

Administration client

HTTP

Persistence Session

COM

NTFSSQL

Application d’un client

Figure 2 : Schéma des types de services d‟une application client Les composants Actifs et Passifs fournissent la logique et la présentation de l‟application :

3.2.3.2 Liste des applications types Les applications hébergées par SFR seront de plusieurs natures. Afin d‟identifier la cible et les éléments techniques à mettre en œuvre, il convient de définir des catégories d‟applications.

Technologie Description Pages statiques HTML Pages statiques au format HTML standard. + CSS Pages statiques utilisant des feuilles de style (CSS). + Scripts client Pages statiques utilisant des scripts client pour effectuer des

traitements au sein de la page. + DHTML Pages statiques utilisant le “Document Object Model » (DOM) avec

du script client afin de gérer dynamiquement l‟affichage des éléments de la page.

+ XML Pages statiques utilisant le langage de description de page étendu (XML) pour afficher des pages.

+ Composants COM clients (Active-X)

Les contrôles ActiveX autorisent l‟exécution de traitements au sein de l‟explorateur client (OCX, DLL)

+ Applets Java Les applets Java permettent l‟exécution de traitements sous forme de petite application autonome au sein de l‟explorateur sans passage par le serveur




+ Plug-ins Les plug-ins sont des extensions au navigateur qui doivent être installées pour être lancés au sein de pages HTML

+ Pages dynamiques ASP

Il s‟agit de pages dynamiques utilisant du scripting serveur (VBScript ou JScript) au sein du format HTML à l‟aide du filtre ISAPI « ASP.DLL » intégré à IIS 6.0.

+ Server-side COM Components (DLL)

Il s‟agit d‟éléments compilés intégrables au sein de scripts ASP pour réaliser des traitements fonctionnels. Seuls les composants standards sélectionnés par SFR sont disponibles sur la plate-forme. La plate-forme n’offre pas l’hébergement de composant COM spécifiques dans un contexte mutualisé.

+ Composants COM+ Il s‟agit de composants COM du côté serveur qui sont gérés dans l‟environnement COM+.

+ Data Access (ADO) Il s‟agit de pages ASP qui interrogent des bases de données (SQL Server) au travers de composants COM nommés « Active Data Objects »

+ Structure de données Structure relationnelle des tables SQL Server

Tableau 1 – Liste des applications types

3.2.4 Application ASP

Les Active Server Pages (ASP) constituent un environnement de développement qui permet de mêler HTML, script client et serveur, ainsi que des composants qui permet d‟exécuter des applications Internet sur un serveur Web Internet Information Server (IIS). Une page ASP contient en particulier du script serveur qui permet d‟affecter des valeurs à des variables, de récupérer l‟information envoyée vers le serveur et de combiner l‟ensemble dans des procédures et fonctions. Le principe des ASP est le suivant :

1. Le navigateur Web émet une requête HTTP vers la page ASP,

2. Le script serveur s‟exécute au travers du filtre ISAPI ASP.DLL qui est optimisé pour les traitements multi-threads,

3. Le moteur ASP traite la requête séquentiellement de haut en bas et exécute les scripts contenus dans le fichier avant de renvoyer une page HTML au navigateur,

4. La page HTML est renvoyée au navigateur.




Active Server PagesActive Server Pages

Internet InformationInternet Information

ServerServer

JScriptJScriptVBScriptVBScript

ActiveXActiveX

ScriptingScriptingJScriptJScript

VBScriptVBScriptActiveXActiveX

ScriptingScripting

Bases de

données

Client Serveur

HTTP

HTTP

Composant d’accès

aux données

Invocation des

composants (COM)

Interprétation

des pages

Pages ASP

OLE-DB

Figure 3 : Schéma des services ASP La version ASP 3.0 fournie avec IIS 6.0 est la version supportée sur la plate-forme.

En standard, les ASP fournissent un modèle objet intrinsèque constitué des 6 objets principaux suivants :

Request : permet de récupérer de l„information envoyée par l‟utilisateur au travers des méthodes POST ou GET d‟un formulaire

Response : permet d‟envoyer de l‟information vers l‟utilisateur (pour produire la page HTML)

Server : permet de contrôler IIS et certaines variables d‟environnement

Session : permet de stocker de l‟information spécifique à un contexte de sess ion utilisateur

Application : permet de stocker de l‟information spécifique au contexte applicative (application ASP)

ObjectContext : permet de manipuler des pages transactionnelles (SetComplete ou SetAbort) en utilisant COM+

Il convient d‟utiliser au mieux chacun de ses objets en exploitant au préalable leurs méthodes et propriétés pour produire des pages HTML interactives où les traitements serveur sont les plus pertinents.




3.2.5 Application ASP Base de données

Figure 4 : Schéma des services ADO & OLE ActiveX Data Objects (ADO) est l‟interface de développement qui permet d‟accéder à des données au travers de fournisseurs de données OLE-DB (providers), y compris les sources ODBC. La technologie OLE-DB et sa couche d‟interface de programmation ADO permettent d‟accéder à n‟importe quel type de données, aussi bien une base relationnelle que d‟autres mécanismes de stockage. Cette technologie repose sur l‟utilisation d‟un « Provider » spécifique pour la couche de stockage concernée. Basés sur Automation, tous les traitements sont effectués sur le serveur en invoquant des méthodes des composants ADO depuis des pages ASP. La version des composants d‟accès aux données installée et supportée sur la plate-forme est la version MDAC 2.8 (Microsoft Data Access Components) qui comprend les dernières versions des fournisseurs de services OLE-DB et composants ADO. Comme ADO fournit une couche d‟accès aux données, il suffit d‟utiliser les propriétés et d‟invoquer les méthodes du composant ADO pour accéder à une Base de données.

OLE DB peut accéder aussi bien à des sources de type SQL que non-SQL : il conviendra d‟utiliser dans la mesure du possible les providers OLE-DB natifs.




Figure 5 : Schéma des services OLE DB

Sur la plate-forme SFR, on accèdera donc à SQL Server 2000 préférentiellement par OLE-DB et on effectuera la programmation à l‟aide du modèle ADO (ActiveX Data Objects). Il existe également un provider OLE-DB générique pour ODBC qui permet d‟accéder à toute base disposant d‟un driver ODBC. Cette méthode présente l‟avantage de fonctionner pour toutes les bases disposant d‟un driver ODBC, mais ne sera pas retenue .

3.2.6 Qu'est-ce que ASP.NET ?

ASP.NET est une infrastructure de programmation intégrée au Common Language Runtime et utilisable sur un serveur pour générer des applications Web puissantes. ASP.NET offre plusieurs avantages importants par rapport aux modèles de développement Web précédents : Amélioration des performances. ASP.NET est du code Common Language Runtime compilé qui s'exécute sur le serveur. Contrairement à ses prédécesseurs interprétés, ASP.NET peut immédiatement profiter de la liaison anticipée, de la compilation juste-à-temps, de l'optimisation native et des services de mise en cache. Cela permet d'améliorer considérablement les performances avant même d'écrire une ligne de code. Prise en charge d'un outil de haute tenue. L'infrastructure ASP.NET comprend une boîte à outils variée et un concepteur dans l'environnement de développement intégré Visual Studio. L'édition WYSIWYG, le glisser-déplacer des contrôles serveur et le déploiement automatique ne sont qu'une partie des fonctionnalités proposées par cet outil puissant. Puissance et souplesse. Comme ASP.NET est fondé sur le Common Language Runtime, la puissance et la souplesse de la totalité de cette plate-forme sont mises à la disposition des développeurs d'applications Web. La bibliothèque de classes .NET Framework, la messagerie et des solutions d'accès aux données sont toutes parfaitement accessibles sur le Web. ASP.NET est également indépendant du langage. Vous pouvez donc choisir le langage le mieux adapté à votre application ou diviser votre application entre plusieurs langages. En outre, l'interopérabilité du Common Language Runtime garantit la pérennité de l'investissement déjà consenti dans le développement COM, lors de la migration vers ASP.NET. Simplicité. ASP.NET facilite l'exécution de tâches courantes, allant du simple envoi de formulaires et authentification des clients au déploiement et à la configuration du site. Par exemple, l'infrastructure de page ASP.NET vous permet de générer des interfaces utilisateur qui séparent proprement la logique d'application du code de présentation et gèrent les événements dans un modèle de traitement des formulaires simple de type Visual Basic. En outre, le Common Language Runtime simplifie le




développement avec des services de code managé, tels que le décompte automatique de références et le garbage collection. Gestion aisée. ASP.NET utilise un système de configuration hiérarchique basé sur du texte, qui simplifie l'application de paramètres à votre environnement serveur et à vos applications Web. Comme les informations de configuration sont enregistrées sous la forme de texte brut, de nouveaux paramètres peuvent être appliqués sans recourir aux outils d'administration locaux. Cette philosophie d'absence d'administration locale s'étend également au déploiement des applications ASP.NET Framework. Pour déployer une application ASP.NET Framework sur un serveur, il suffit de copier les fichiers nécessaires sur ce dernier. Aucun redémarrage du serveur n'est nécessaire, même pour déployer ou remplacer le code compilé en cours d'exécution. Évolutivité et disponibilité. ASP.NET a été conçu pour évoluer, grâce à des fonctionnalités spécialement adaptées à l'amélioration des performances dans des environnements ordonnés en clusters et multiprocesseurs. Par ailleurs, les processus sont étroitement supervisés et managés par le runtime d‟ASP.NET, de sorte que si l'un d'eux a un comportement anormal (fuites, blocages), un nouveau processus peut être créé pour le remplacer, ce qui permet à votre application d'être constamment disponible pour le traitement des demandes. Personnalisation et extensibilité. ASP.NET propose une architecture bien organisée permettant aux développeurs d'insérer leur code au niveau approprié. En réalité, il est possible d'étendre ou de remplacer n'importe quel sous-composant du runtime d‟ASP.NET à l'aide du composant que vous avez écrit personnellement. L'implémentation d'une authentification ou de services d'état personnalisés n'a jamais été plus simple. Sécurité. Avec l'authentification Windows intégrée et la configuration par application, vous pouvez être certain que vos applications sont sécurisées.

3.2.6.1 Qu'est-ce qu'une application ASP.NET ? ASP.NET définit une application comme la somme de tous les fichiers, pages, gestionnaires, modules et codes exécutables pouvant être appelés ou exécutés dans la portée d'un répertoire virtuel donné (et de ses sous-répertoires) sur un serveur d'application Web. Par exemple, une application « order » peut être publiée dans le répertoire virtuel « /order » sur un ordinateur serveur Web. Pour IIS, le répertoire virtuel peut être configuré dans le Gestionnaire des services Internet. Ce dernier contient tous les répertoires, à moins que les sous-répertoires eux-mêmes soient des répertoires virtuels. Chaque application ASP.NET Framework d'un serveur Web s'exécute dans un domaine d'application .NET Framework unique, ce qui garantit l'isolation des classes (sans gestion de version ou conflit de nom), l‟isolation (sandboxing) de sécurité (empêchant l'accès à certains ordinateurs ou ressources réseau) et l'isolation des variables statiques. ASP.NET gère un pool d'instances de HttpApplication tout au long de la durée de vie d'une application Web. ASP.NET assigne automatiquement l'une de ces instances au traitement de chaque demande http entrante reçue par l'application. L'instance de HttpApplication assignée est responsable de la gestion de toute la durée de vie de la demande et n'est réutilisée qu'au terme de celle-ci. Cela signifie que le code utilisateur au sein de HttpApplication ne doit pas être réentrant.

3.2.6.2 Création d'une application Pour créer une application ASP.NET Framework, vous pouvez utiliser un répertoire virtuel existant ou en créer un. En plaçant une page .aspx simple, telle que la suivante, dans le répertoire virtuel et en y accédant à l'aide du navigateur, vous déclenchez la création de l'application ASP.NET.




<%@Page Language="VB"%> <html> <body> <h1>Bonjour, <% Response.Write(DateTime.Now.ToString()) %></h1> </body> </html>

À présent, vous pouvez ajouter le code approprié pour utiliser l'objet Application, afin d'enregistrer des objets ayant une portée d'application, par exemple. Si vous créez un fichier global.asax, vous pouvez également définir différents gestionnaires d'événements (pour l'événement Application_Start, par exemple).

3.2.6.3 Durée de vie d'une application Une application ASP.NET Framework est créée lors du lancement initial d'une demande au serveur. Avant cela, aucun code ASP.NET ne s'exécute. Lorsque la première demande est lancée, un pool d'instances de HttpApplication est créé et l'événement Application_Start est déclenché. Les instances de HttpApplication traitent cette demande ainsi que les suivantes, jusqu'à la dernière instance, et l'événement Application_End est déclenché. Remarquez que les méthodes Init et Dispose de HttpApplication sont appelées par instance et peuvent donc être appelées plusieurs fois entre Application_Start et Application_End. Seuls ces événements sont partagés entre toutes les instances de HttpApplication dans une application ASP.NET. Remarque sur les threads multiples Si vous utilisez des objets avec une portée d'application, n'oubliez pas qu‟ASP.NET traite les demandes simultanément et que plusieurs threads peuvent accéder à l'objet Application. Par conséquent, le code suivant est dangereux et peut ne pas donner le résultat escompté, s i la page est demandée simultanément à plusieurs reprises par des clients différents.

<%

Application("counter") = CType(Application("counter") + 1, Int32)

%>

Pour que ce code soit threadsafe, sérialisez l'accès à l'objet Application à l'aide des méthodes Lock et UnLock. Cependant, cette opération implique une réduction considérable des performances :

<%

Application.Lock()

Application("counter") = CType(Application("counter") + 1, Int32)

Application.UnLock()

%>

Une autre solution consiste à transformer l'objet enregistré avec une portée d'application en objet threadsafe. Par exemple, remarquez que les classes de collection dans l'espace de noms System.Collections ne sont pas threadsafe pour des raisons de performances.




3.2.7 Liste des composants COM disponibles sur la plate-forme

3.2.7.1 Composant « Ad rotator » Ce composant permet d‟afficher des bannières ou des images dans une page. Se basant sur un fichier de configuration, il peut afficher différentes images, rediriger le click sur cette image vers le lien adéquat et compter le nombre de Click pour chacune des images.

3.2.7.2 Composant « Browser Capabilities » Ce composant se base sur la chaîne « userAgent » envoyé par le browser au serveur à la connexion. Il permet de connaître ses capacités, comme l‟acceptation des cookies, le support du scripting ou de Java.

3.2.7.3 Composant « Content Linking » Ce composant est utile pour créer un ensemble de pages dont l‟évolution des l iens ne nécessite pas l‟édition de chacune de ces pages. Il se base sur un fichier texte qui contient les adresses des pages et leur ordre d‟affichage.

3.2.7.4 Composant « Content Rotator » Ce composant se base sur un fichier de configuration pour spécifier des portions de texte, de code ou de code HTML qui sera inséré dans d‟autres pages.

3.2.7.5 Composant « Counter » Ce composant met à disposition les méthodes et propriétés nécessaire à la manipulation d‟un compteur à travers le script.

3.2.7.6 Composant « MyInfo » Ce composant fournit le stockage de noms/valeurs qui sont accessibles depuis l‟intégralité du site. Les données sont stockées dans un fichier texte au format XML.

3.2.7.7 Composant « Permission Checker » Ce composant est utile pour prévenir les erreurs de scripts causés par les utilisateurs qui tentent d‟accéder à des ressources auxquelles ils n‟ont pas droit.

3.2.7.8 Composant « Tools » Ce composant fournit les méthodes utiles pour vérifier l‟existence d‟un fichier, traiter un formulaire HTML, et générer un entier aléatoire.

3.2.7.9 Composant « FileSystem » Ce composant fournit les méthodes utiles pour manipuler des fichiers, des répertoires dans l‟arborescence dédiée et restreinte au client. L‟utilisation de l‟option « AllowParent Path Disabled » sur le serveur interdit la navigation hors de l‟espace client.




3.2.7.10 Composant « CDONTS » Ce composant fournit les méthodes utiles pour envoyer les mails vers Internet .

3.2.7.11 Composant « CDO.SYS » Ce composant fournit les méthodes utiles pour envoyer les mails vers Internet pour les sites en ASP.NET.

3.2.8 Conventions de nommage

Cette partie décrit les règles de nommage devant être respectées afin de permettre la mutualisation des applications des différents clients sur un système commun. Ces règles sont indispensables pour permettre le partage des ressources sans conflits. Elles concernent aussi bien l‟ensemble des briques logicielles utilisées que les développements spécifiques effectués par SFR.

3.2.8.1 Nommage du serveur SQL Le nom du serveur (pré-production ou production) imposé est le suivant :

SQL

3.2.8.2 Nommage des bases de données Afin de garantir le cloisonnement entre les bases de données de chaque client, le nom de la base (pré-production ou production) imposé est le suivant :

db_NomOrganisation Par exemple : Pour l‟organisation sfrbusinessteam.fr, le principe est de remplacer les « . » par des « _ », ce qui donne comme nom de base : db_sfrbusinessteam_fr.

3.2.8.3 Nommage des Logins SQL Server Un utilisateur est créé au niveau de la base lors du provisioning du domaine du client sur la plate forme. Cet utilisateur est créé à l‟identique (même login, même mot de passe) que l‟utilisateur d‟administration du site web. Modèle de login : Le nommage imposé est le suivant :

[email protected] Les valeurs admin et domaine.tld sont données à titre indicatif.

Valeur Rôle applicatif Admin Compte DBO pour l’administration de la base

L‟administrateur du client peut venir créer des ut ilisateurs supplémentaires de la base de données.

3.2.8.4 Dépendances vis-à-vis de la plate-forme Afin de rendre le code indépendant de la plate-forme, tous les chemins virtuels de l‟application doivent être relatifs (pas de http://NomDeServeur/NomApplication dans le code).

http://nomdeserveur/NomApplication




3.2.8.5 Règles de nommage ASP Définir une convention de nommage garantit :

La standardisation du codage du style d‟une application La production d‟un code source lisible et sans ambiguïté La facilitation de la coordination d‟une équipe de développeurs travaillant ensemble sur la

même application L’important n’est pas de suivre cette convention à la lettre mais de la définir et de la respecter. La convention proposée n‟est pas contraignante et repose essentiellement sur deux axes :

L‟utilisation systématique de préfixe indiquant le type de la variable ou s‟il agit d‟un objet. L‟utilisation d‟une description indiquant la nature de la variable ou de l‟objet

3.2.8.6 Variables

Préfixe Type de donnée Exemple b Boolean bIsLoggedOn dat Date and Time datHire err Error errPurchase l Long-32bit signed lNumberOfMembers i Integer iAgeOfUser s String SUserName

3.2.8.7 Objets ADO

Préfixe Type d’objet Exemple oCnx Connection oCnxGetDepartments oCmd Command oCmd GetNames oPrm Parameter oPrmGetNames oRs RecordSet oRsUsersByID s+Qry Query sUsersByIdQry s+Cnx Connection string sStoreCnx oFld Field oFldUserName

3.2.8.8 Objets divers

Préfixe Type d’objet Exemple oFso File System Object oFsoConfigFile oTxs Text Stream oTxsConfig oErr Error oErrConfig

3.2.8.9 Constantes Les constantes sont déclarées en majuscules avec des « soulignés ( _ ) » entre chaque mot. Il n‟est pas utile de préfixer les constantes. Exemple : SERVER_NAME




3.2.8.10 Commentaries Toutes les procédures et fonctions devraient débuter avec un bloc de commentaire décrivant les attributs et blocs de commentaires décrivant les attributs de la fonction ou la procédure.

'=============================================================================

' FUNCTION: CheckSaleStatus

' ARGUMENTS:

'

' RETURNS:

'

' DESCRIPTION:

'

' EDITS:

' Auteur - Date

'=============================================================================

La première section contient FUNCTION ou PROCEDURE en fonction du type de la fonction. La section ARGUMENTS définit les arguments qui sont passes avec une explication de leur rôle. La section RETURNS définit le retour de la fonction. La section DESCRIPTION donne une description fonctionnelle de la procédure. La section EDITS fournit un historique des versions de la fonction et du but des modifications.

Les sections logiques du code doivent être segmentées avec des blocs de commentaires.

„=====================================================

„ Create Cache of Departments for Drop-Down

„=====================================================

3.2.9 Méthodologie de développement

3.2.9.1 Généralités Web Toutes les applications Web ne présentent pas le même niveau de complexité mais elles nécessitent toute une phase initiale de conception et d‟architecture. Dans le cadre des applications dynamiques, cette phase d‟architecture doit être menée comme tout projet de développement applicatif tout en tenant compte des spécificités du développement Web :

Une architecture répartie (client léger, serveur HTTP, et sources de données) Une intégration graphique assez forte (charte graphique, positionnement des écrans) Une problématique de compatibilité et de fiabilité spécifique (plusieurs versions de

navigateurs sur Internet notamment)

Une problématique particulière de performances (versions de navigateurs, contraintes de réseau sur Internet notamment, montée en charge rapide côté serveur …)

Des contraintes de sécurité majeures (en phase 1, l‟accès aux applications est cependant ouvert à l‟ensemble de la communauté internet).




En terme de méthodologie, le développement Web applicatif nécessite de suivre une approche spécifique :

Une approche par maquettage particulièrement adaptée (RAD)

Une approche par tiers applicatif (l‟architecture Windows DNA décrit en particulier l‟approche 3-tiers : interface de présentation, processus de gestion, et accès aux données)

Une approche par risque pour identifier très tôt les points sensibles de l‟application (problèmes de sécurité, de performances potentiels …)

Figure 6 : L‟architecture Microsoft Windows DNA Enfin il convient d‟utiliser chaque technologie à bon escient :

Les feuilles de style harmonisent l‟ensemble les traitements graphiques Les scripts client ne remplacent pas les traitements métier mais complètent l‟interface

utilisateur

DHTML est particulièrement adapté pour améliorer l‟ergonomie Les composants COM client et applets Java doivent être utilisés seulement en cas de

nécessité pour réaliser des traitements spécifiques non réalisables avec d‟autres technologies

Les ASP doivent être dédiés à l‟échange d‟information entre le client et le serveur, produire du HTML, et appeler les composants COM identifiés par SFR.

L‟appel à des composants existants doit respecter leurs contraintes spécifiques (ADO, Scripting.FIleSystemObject…)

Le moteur de Bases de Données doit traiter tous les traitements du tiers « accès aux données » (procédures stockées …)

Conformément à l‟architecture 3-tiers du modèle Windows DNA, il convient de déterminer au préalable une architecture globale d‟application ASP en privilégiant le script serveur pour les traitements d‟affichage et d‟échange d‟informations avec l‟utilisateur. Il est primordial de construire une architecture de site qui tient compte des spécificités d‟ASP et des objets intrinsèques dont certains peuvent être initialisés dans le fichier GLOBAL.ASA En effet, chaque application ASP comprend un fichier GLOBAL.ASA à la racine du site qui est exécuté à la première page ASP appelée et qui doit contenir des informations globales à l‟application ou à une session utilisateur.




Il est recommandé d‟autre part de séparer les pages de saisie des pages de traitement afin d‟améliorer la productivité et la maintenabilité du code.

Base de données Le processus consistant à planifier, concevoir et développer des bases de données se caractérise par deux types de conception, logique et physique :

La conception logique englobe les règles de travail et montre comment elles sont mises en œuvre. Au niveau de la base de données, elle transforme des scénarios conceptuels en relations unissant des entités, puis en un schéma de base de données. A ce stade, la normalisation aide à produire un schéma de base de données bien structuré.

La conception physique convertit la conception logique en tables, lignes et index de base de données. Durant cette phase, l'optimisation et la mise au point des performances peuvent aider à valider la conception logique de la base de données.

A l'instar de la conception d'application, le processus de conception de base de données est itératif. Le modèle logique utilisé pour la mise en œuvre physique n'est pas nécessairement achevé ; il doit parfois être retravaillé en fonction des problèmes rencontrés durant la conception physique et liés notamment aux performances ou à la mise en œuvre. La conception logique doit être clairement séparée de la conception physique. La conception logique doit nécessairement comprendre les phases d‟identification des entités (stocke les informations), des attributs (caractéristiques d‟une entité), et des relations entre entités. Le modèle physique de données fait quant à lui apparaître les tables et champs et c‟est à cette étape qu‟intervient en général la dénormalisation. En effet, la conception de base de données optimale est le résultat d'un compromis entre normalisation et dé normalisation, lequel permet d'obtenir des performances accrues. Il est ensuite particulièrement important de veiller aux points suivants :

Index primaires, et secondaires

Relations d‟intégrité référentielle Rôles des acteurs qui accéderont à la Base de données

3.2.10 Fiabilité

Web La fiabilité des applications demeure le point le plus critique pour la plate-forme à la fois pour des contraintes de disponibilité de l‟application hébergée elle-même que pour préserver la disponibilité des autres applications. En effet, malgré l‟isolation mise en place pour chaque application d‟un client qui évite à une application de mettre en péril les autres applications hébergées, la fiabilité de certaines applications peut cependant dans certains cas nuire au bon fonctionnement des autres si elle génère trop d‟événements indésirables (temps processeur utilisé et mémoire consommée). Afin de garantir à la fois la maintenabilité des applications, tout en assurant de manière préventive la traçabilité des événements générés pour l‟équipe de développement, il est recommandé de porter une attention particulière aux points suivants :

D‟une manière générale, il est recommandé de ne pas charger inutilement le contenu des pages d‟une application (par exemple, séparer la page de saisie d‟un formulaire de la page de résultats).

La gestion des erreurs doit être systématique et centralisée dans l‟application La mise à jour d‟un fichier de trace doit être utilisée pour les événements sensibles (en

tenant compte également des contraintes de performances)




Il est recommandé de veiller à respecter les conseils suivants : Bien respecter le standard HTML dans les pages HTML générées Ne pas trop mélanger le code ASP avec le code HTML mais plutôt utiliser des fonctions

de script pour générer du code HTML

Bien commenter les scripts serveur et inclure systématiquement pour chaque page et chaque fonction des informations d‟identification (date de dernière modification / Identité de l‟intervenant / objet de la fonction ou de la page)

Utiliser « Option Explicit » en VBScript pour garantir que toutes les variables sont correctement déclarées (maintenabilité et fiabilité)

Déterminer par avance le « goulot d‟étranglement» de l‟application en phase d‟architecture afin d‟optimiser les traitements à cet endroit de l‟application

Base de données L‟intégrité référentielle est un premier facteur de fiabilité des données stockées dans la Base mais il convient de veiller également à une construction homogène du modèle de données (éviter la duplication d‟informations). Il peut donc s‟avérer très pratique d‟utiliser des triggers mais il faudra les employer avec précaution (relations d‟intégrité s‟appliquant à de nombreuses tables).

3.2.11 Performances

3.2.11.1 Web D‟une manière générale, il est particulièrement recommandé de suivre les conseils d‟optimisation de performances suivants :

Concernant l‟activation des composants, il est particulièrement important de fermer tout composant instancié après utilisation (« set oMonObjet = nothing »). IIS 5.0 libère le composant dès l‟exécution de cette ligne.

Veiller à ne pas utiliser trop d‟opérations lourdes telles que les éécritures systématiques sur disque.

Utiliser la logique de l‟architecture Windows DNA afin d‟optimiser tout traitement (généraliser les procédures stockées)

Afin de garantir les performances des pages ASP pures, certaines recommandations sont à suivre :

Ne pas développer de pages trop longues (attention notamment aux inclusions multiples) Utiliser le fichier GLOBAL ASA à bon escient : utiliser notamment les événements

« Session_onStart » et « Application_onStart » pour affecter des variables et déclencher des traitements communs

Utiliser l‟objet « Session » avec précaution stocker des variables en session est très consommateur en ressources

Enlever les commentaires HTML (laisser les commentaires ASP)

Utiliser l‟objet « Dictionary » plutôt que l‟objet « Array » pour stocker des données Eviter de redimensionner les tableaux Utiliser des variables locales aux fonctions serveur car elles sont calculées lors de la

compilation alors que les variables globales sont calculées lors de l‟exécution

Utiliser le chemin exact relatif plutôt que d‟utiliser la propriété « Mappath » de l‟objet Server qui est consommatrice de ressources

De manière générale, ne pas trop utiliser les fonctions de l‟objet « Server » (coûteuses) Reporter les validations du côté du client afin d‟éviter des allers-retours inutiles

Copier les collections de variables côté client si elles sont fréquemment utilisées Dans la mesure du possible, ne pas stocker de composants COM en session ni

application




3.2.11.2 Base de données Le “Connection pooling” activé sur la plate-forme (SQL Server) permet de maintenir des connexions ouvertes sur une Base de données et gère des connexions partagées entre différents utilisateurs afin d‟optimiser les performances. A chaque tentative de connexion, le pool de connexion détermine au préalable s‟il existe une connexion active sur le Base de données. C‟est pourquoi il est recommandé de fermer les connexions et Recordset ouverts par utilisateur. Il est par ailleurs recommandé de suivre les conseils suivants afin d‟optimiser l‟utilisation des composants ADO :

Utiliser des commandes SQL au lieu de certaines méthodes de la classe RecordSet (par exemple utiliser la commande INSERT de SQL au lieu de la méthode Update du RecordSet) pour des volumes importants

Manipuler efficacement la taille d‟un RecordSet (ne pas stocker le RecordSet en mémoire mais stocker simplement l‟index de l‟enregistrement courant)

Appeler des procédures stockées pour mettre à jour des données sur le serveur de Bases de Données

Il est recommandé de prêter une attention particulière à la construction des index. SQL Server dispose de 2 types d‟index: les index « clustered » et « nonclustered ». Un index « clustered » conserve index de données dans le même ordre que les tables (index unique) alors que les index « nonclustered » contiennent un autre ordre. Il est recommandé de garder des index les plus compacts possibles (taille). Il est par ailleurs préférable d‟effectuer des transactions courtes : afin de réduire la quantité de données transférées et d‟éviter des problèmes d‟accès concurrents entre utilisateurs, il est recommandé d‟utiliser des transactions courtes. Il vaut mieux lors des transactions au sein d‟une application effectuer des « commit » le plus tôt possible.

3.2.12 Sécurité

La sécurité vis-à-vis des autres applications hébergées est garantie par l‟architecture de la plate-forme. Néanmoins, il est utile de conserver à l‟esprit les principes suivants :

La vérification des données doit être réalisée sur le client (garantir que l‟ensemble des champs obligatoires est rempli, et que le format des données saisies est correct).

Il faut veiller aux informations qui sont véhiculées du client vers le serveur et notamment les

mots de passe et autres informations confidentielles (numéros de cartes bancaires).

Par défaut les fichiers d‟extension « .inc » n‟ont pas d‟association avec une application. Une requête directe sur le nom d‟un fichier inclus permet l‟affichage en clair du code source. Pour cette raison, il faut toujours utiliser l‟extension « .asp » pour les fichiers inclus.




3.3 Guide de programmation ASP

3.3.1 Utilisation de variables privées

Même si une fonction d‟une page ASP n‟a de portée que sur la page, il est préférable d‟avoir recours à des variables locales.

Function CheckSaleStatus(sSalePrice, datSaleStart, datSaleEnd)

Dim bSaleStatus

Dim datNow

bSaleStatus = False

If sSalePrice<> "" And IsDate(datSaleStart) And IsDate(datSaleEnd) Then

If Not (datSaleStart = "1/1/75" Or datSaleEnd = "1/1/75") Then

'===We have Sale Info===

datNow = Now()

If datNow > datSaleStart And datNow < datSaleEnd Then

bSaleStatus = True

End If

End If

End If

CheckSaleStatus = bSaleStatus

End Function

3.3.2 Utilisation d’« Option Explicit »

L‟utilisation de “Option Explicit” indique à l‟interpréteur que toutes les variables doivent être déclarées avant d‟être utilisées. Cela permet :

d‟éviter les erreurs de logique ou de saisie d„améliorer la lisibilité du code

3.3.3 Mélanges de code client et serveur

Le code compris entre délimiteurs est analysé avant d‟être exécuté. Alterner de façon permanente du script serveur et du script client réduit les performances de l‟interpréteur. Les partie de code serveur sont mises en cache de sorte que la performance ne soit affectée que la première fois que la page est chargée. If faut donc préférer :

Response.Write “Hello, “ & strUsername & “<br>” & vbCrLf

Response.Write “The date is “ & now() & “<br>” & vbCrLf

à : Hello, <%=strUsername%>.<br>

The date is <%=now()%>.<br>




3.3.4 Utilisation d’« includes » efficace

Utilisés correctement les « include » sont très utiles. Il est néanmoins nécessaire de veiller à :

Ne pas inclure des fichiers contenant des fonctions ou des constantes inutiles dans la page ASP. Lorsqu‟IIS analyse pour la première fois une page ASP, il crée un modèle prétraité et le place dans son cache. Ce modèle contient la page et tous les fichiers d‟include. Un exemple typique est le fichier « Adovbs.inc » qui inclue 286 déclarations de constantes. Cela consomme inutilement de la mémoire étant donné que la plupart des pages utilisent seulement quelques constantes. Il est donc préférable de créer un include avec uniquement les constantes nécessaires (sans oublier de lui associer une extension .ASP).

Ne pas gérer de multiples niveaux d‟include (pas plus de deux niveaux de profondeur).

3.3.5 Gestion du cache

Il y a deux types de cache : serveur et client. Côté serveur la page est caché sois dans le cache des modèles prétraités, soit dans le cache du moteur de script. Le développeur n‟a aucun contrôle sur ce cache. Il y a uniquement trois cas où la page est retirée du cache :

Notification de changement de la page. Le cache se remplit et la page en est chassée. Le cache est complètement désactivé.

Le développeur a le contrôle du cache côté client. Le cache côté client inclut le cache du browser et/ou du proxy. Si le client ou le proxy cache la page, une modification des informations dynamique contenue dans cette dernière, n‟a pas d‟incidence sur le contenu de la page. Pour forcer une nouvelle requête pour ces pages dont le contenu évolue au fil du temps, les différentes commandes suivantes peuvent être utilisées.

Response.Expires = -10000 „Use NEGATIVE number

Response.AddHeader “Pragma”,”no-cache” Response.AddHeader “cache-control”,”no-store”

3.3.6 Session et montée en charge

Plus les données stockées au niveau de la session sont importantes, plus IIS consomme de la mémoire. Sur les serveurs fortement sollicités avec une TimeOut de Session à 20 minutes, l‟impact est loin d‟être négligeable. Il faut donc veiller à ne pas imposer un TimeOut trop long si les données sont volumineuses.

3.3.7 Session_OnEnd

Si la fonction « Session_OnEnd » n‟est pas utilisée, il faut la supprimer.




3.4 COMPOSANTS COM

3.4.1 Généralités

Un composant COM est une unité de code compilé qui fournit des fonctionnalités spécifiques au travers d‟interfaces. Lorsque le code et la logique applicative sont mises en œuvre dans un composant, cela garantit une plus grande efficacité et offre des possibilités de réutilisation plus importantes. Les notions suivantes constituent les bases de l‟approche par composants :

Objet : Combinaison de code et de données qui peuvent être traités comme une unité. C'est par exemple le cas d'un contrôle, d'une feuille ou d'une application. Un objet peut aussi être défini comme une instance de classe combinant des données avec des procédures.

Classe : Modèle qui implémente les méthodes et les propriétés d'un objet. Un composant COM unique peut contenir de multiples classes. Au moment de l'exécution, vous créez un objet en créant une instance de classe.

Interface : Groupes de fonctions offrant une fonctionnalité qui établit la communication entre les clients et les composants COM. Les interfaces fournissent un accès standardisé aux méthodes et aux propriétés disponibles auprès des composants. En outre, elles jouent le rôle de contrat entre l'auteur du composant et le client développeur qui assure un accès cohérent à la fonctionnalité.

Composant : Ensemble de classes COM rassemblées dans une unité exécutable, comme un DLL ou un EXE. Les composants ne dépendent pas d'un langage spécifique, en d'autres termes, ils ne sont pas définis par le langage d'implémentation mais par les interfaces qu'ils gèrent. Le langage utilisé pour implémenter un composant et son client n'entre pas en ligne de compte.

COM fournit une compatibilité ascendante et COM+ permet de mieux utiliser des composants ActiveX développés dans l‟architecture COM.

Figure 7 : L’architecture des services COM

ClientServeur

Navigateur Web Internet Information Server 4

ASP + COM serveur

Requête

Résultat HTTP

Text TextTraitement

ASP

<HTML>

<% set objTest =

Server.CreateObject

("component.class")

...%>

...

</HTML>

HTML

<HTML>

...

...

</HTML>

ASP.DLL

Composant

COM

spécifiqueInstanciation

Text TextTraitement




3.4.2 Compatibilité des composants COM

Afin de garantir la compatibilité des applications développées avec les composants disponibles sur la plate-forme mutualisée, il faudra porter une attention particulière aux versions de composants utilisés. La gestion des versions supportées sur la plate-forme mutualisée implique d‟utiliser scrupuleusement la version courante supportée car même si les composants supportent la compatibilité ascendante, certains problèmes secondaires pourraient apparaître si des composants plus anciens étaient utilisés (fonctionnement différent d‟une méthode d‟un composant par exemple). Afin de fournir des recommandations les plus détaillées possibles sur les problèmes de compatibilité, les versions de chaque type d‟application seront détaillées plus loin. Cependant, d‟une manière générale, les applications ne devront pas faire apparaître dans le code de références directes aux versions utilisées. Par exemple, il faudra éviter de référencer directement les versions de composants utilisés comme ci-dessous : Set oConnection = Server.CreateObject("ADODB.Connection.2.8")

… mais plutôt d‟utiliser une syntaxe générique dans la mesure du possible à laquelle il est recommandé d‟ajouter une référence commentée aux versions de composants utilisés : „REM Version ADO 2.8 – Installée avec MDAC 2.8

Et à l‟appel du composant : Set oConnection = Server.CreateObject("ADODB.Connection")

3.4.3 Types d’”Apartment”

COM utilise le terme “apartment” pour designer l‟environnement dans lequel un composant COM évolue. Il y a trois différents types d‟ « apartments » COM : STA Single-Threaded Apartment – Ce type d‟ « apartment » garantit que deux appels ne

peuvent se produire sur le composant au même instant. Si deux threads tentent simultanément d‟accéder sur le composant, le STA assure la sérialisation des requêtes. Il peut y avoir 0 ou plusieurs STA par process.

MTA Multi-Threaded Apartment – Ce type d‟ « apartment » autorise de multiple threads à exécuter le composant de façon simultané. Il peut y avoir 0 ou 1 MTA par process.

NA Neutral Apartment – Ce type d‟ « apartment » autorise les composants à être soit sérialisés (single-threaded) soit non-sérialisés (multi-threaded). Il exécute également le composant sur le même thread que l‟appelant, ce qui élimine le changement de contexte de thread et le marshalling. Il peut y avoir 0 ou 1 NA par process.

Chaque « apartment » peut contenir de multiples composants tant que les types d‟ « apartment » des composants sont compatibles. Ainsi chaque appel inter-apartment résulte généralement dans la création d‟une paire proxy/stub et un marshalling d‟interface qui peut pénaliser l‟application. L‟exception à cette règle est l‟utilisation d‟un composant d‟un modèle “free-threaded” (ou Both) qui avec le support du Free-Threaded Marshaler peut passer directement des pointeurs d‟interface et élimine la nécessité d‟un proxy dans les transactions intra-processus.




Figure 8 : L’architecture des threads ASP

3.4.4 Modèle de Threading

Chaque objet COM peut indiquer dans quel type d‟« apartment » il peut être placé, en spécifiant dans la base de registre son modèle de thread : Single Le composant peut uniquement s‟exécuter dans le premier STA du process

S‟il n‟y a pas d‟entrée dans la base de registre, c‟est le modèle par défaut. Apartment Le composant peut s‟exécuter dans n‟importe quel STA. Free Le composant peut uniquement s‟exécuter dans le MTA du process. Both Le composant peut s‟exécuter soit dans le STA, soit dans le MTA. Le type

d‟« apartment » dans lequel le composant est créé dépend du type d « apartment » auquel le thread créant l‟objet participe.

Neutral Le composant peut uniquement s‟exécuter dans un NA.

3.4.5 Portée des composants

Le choix de la portée d‟un objet (Page, Session ou Application) doit tenir compte du modèle de threading du composant.

3.4.5.1 Portée de niveau Page Single A proscrire. Le composant est créé dans un STA séparé, ce qui génère une

paire proxy/stub pair et du marshaling. En outre, cela limite l‟application à une seule instance du composant au sein du process « dllhost.exe ».

Apartment Modèle parfaitement adapté. La page ASP s‟exécute su sein du STA. Free Modèle acceptable. Cependant, comme le composant créé s‟exécute dans le

MTA, tous les appels impliquent un changement de contexte de threads. Both Modèle parfaitement adapté. Le composant est créé soit dans le MTA (si

l‟objet existe déjà dans le process), soit dans le STA qui exécute la page. Neutral Modèle parfaitement adapté. Il permet au STA de la page ASP d‟accéder au

composant sans marshalling ou changement de contexte de threads.




3.4.5.2 Portée de niveau Session Single A proscrire. Le composant est créé dans un STA séparé, ce qui génère une


Apartment A proscrire. Placer un composant apartment threadé au niveau de la Session verrouille chaque page ASP de l‟utilisateur courant sur le thread qui a créé initialement le composant. En fait, IIS devient « single-threaded » vis-à-vis de chaque utilisateur.

Free Modèle adapté. Un changement de contexte de threads se produira lorsque la page ASP (dans le STA) appelle le composant (résidant dans le MTA).

Both Modèle parfaitement adapté. Neutral Modèle parfaitement adapté. Il permet au STA de la page ASP d‟accéder au


3.4.5.3 Portée de niveau Application De façon générale, il est préférable d‟éviter de stocker des composants au niveau de l‟application. Single A proscrire. Le composant est créé dans un STA séparé, ce qui génère une


Apartment A proscrire. Placer un composant apartment threadé au niveau de la l‟Application verrouille chaque page ASP de l‟ensemble des utilisateurs sur le thread qui a créé initialement le composant. En fait, IIS devient « single-threaded ».

Free Modèle adapté. Un changement de contexte de threads se produira lorsque la page ASP (dans le STA) appelle le composant (résidant dans le MTA).

Both Modèle parfaitement adapté. Neutral Modèle parfaitement adapté. Il permet au STA de la page ASP d‟accéder au


3.4.5.4 Synthèse

Modèle de threading

Port

ée Single Apartment Free Both Neutral

Page Jamais Oui Oui Oui Oui

Session Jamais Non Oui Oui Oui

Application Jamais Non Oui Oui Oui




3.5 Mode opératoire et tests

3.5.1 Description du cycle projet

Le schéma suivant illustre le cycle d‟un projet de développement d‟application mutualisée sur la plate-forme SFR :

Client Client Server Server

HTTP request

HTTP request HTTP request

HTTP request

Active Server Pages Active Server Pages

default.asp default.asp

Interprets Interprets

page page

default.asp default.asp

Interprets Interprets

page page

Internet Information Internet Information

Server Server

JScript JScript VBScript VBScript

ActiveX ActiveX Scripting Scripting

JScript JScript VBScript VBScript

ActiveX ActiveX Scripting Scripting

HTTP response

HTTP response HTTP response

HTTP response

Invokes Invokes

component component

(COM) (COM)

Data access Data access

component component

Invokes Invokes

component component

(COM) (COM)

Data access Data access

component component

OLE-DB

Figure 9 : Description du cycle de projet




3.5.2 Etapes du cycle projet

Logical View

Production Pré-Production DéveloppementAdministration

MAJ version N+1

Mise

en Production

Tests Client

Demande Mise en Production

1

2

345

Déroulement du cycle de déploiement de préproduction en production

Figure 10 : Description du cycle de déploiement pré-production/production

3.5.3 Téléchargement des fichiers

Les développeurs ou le Webmestre du client mettent à disposition la nouvelle version de l‟application avec différents outils de téléchargement.

3.5.4 Tests de l’application en pré-production

Les développeurs ou l‟administrateur client utilisent l‟application sur le serveur de pré-production.




3.5.5 Demande de mise en production

Les développeurs demandent à l‟administrateur client de mettre l‟application en activité sur le serveur de production.

3.5.6 Mise en production

L‟administrateur Client utilise l‟interface Web Admin pour piloter le ddéclenchement de la réplication de la version de pré-production vers la production Au terme de ce cycle, les versions de pré-production sont identiques.

3.5.7 Outils de développement et mise en place de l’application

Trois modes d‟accès sont prévus pour les fichiers des applications : Extensions FrontPage FTP Mode Web Interactif pour le schéma et le contenu de la base de données (scripts dans un

environnement Web et un contexte utilisateur identifié)

3.5.7.1 Téléchargement FTP Le téléchargement sur le site de pré-production est réalisé avec la commande ftp (et plus généralement avec les dizaines de produits compatibles FTP) fournie avec le système d‟exploitation (ex : Windows 2000) sous le compte administrateur client fourni par SFR. Une fois connecté, l‟administrateur client voit deux répertoires :

Database : C‟est le répertoire dans lequel doivent être déposés le fichier de backup SQL, les fichiers de mise à jour SQL

Wwwroot : C‟est le répertoire dans lequel doivent être déposés les fichiers de l‟application Web

3.5.7.2 Exploitation des extensions FrontPage L‟administrateur client a à sa disposition les outils standards de Windows NT et/ou produits compatibles, soit :

Web Folders Frontpage 98 ou FrontPage 2000 : seule la fonctionnalité de publication des extensions Front

Page est installée. Les composants Front Page sont inutilisables sur les serveurs de pré-production et de production.

Visual Interdev Web Publishing Wizard Et plus généralement, toute application Windows dans la mesure où Internet Explorer 5 est

installé sur le système client. La mise à jour s‟effectue par copie ou publication de site.




3.5.7.3 Modification Base de données SQL Server La modification du schéma ou du contenu de la base de données s‟effectue en plusieurs phases. Les développeurs et administrateurs client ont la poss ibilité d‟importer des données dans la base de données de pré-production ou de production par plusieurs moyens :

De façon interactive depuis l‟interface d‟administration de l‟application client (MyLittleAdmin)

Téléchargement d‟un script SQL exécutable puis lancement depuis l‟interface d‟administration de l‟application client

3.5.8 Description des tests

Il est recommandé d‟effectuer des tests en plusieurs étapes : Tests unitaires et fonctionnels et éventuellement de performances sur la plate-forme de

développement

Tests unitaires, fonctionnels sur la plate-forme de pré-production Tests fonctionnels sur la plate-forme de production

Après une mise à jour, il est recommandé d‟utiliser un jeu de tests afin de tester l‟application en zone de pré-production : ce jeu de tests pourra comprendre l‟ensemble des données exploitables sur la plate-forme mais ces données ne seront disponibles qu‟en zone de pré-production (fichiers, données de la base de données …). L‟environnement de pré-production est dédié aux tests fonctionnels afin de valider que l‟application développée dans l‟environnement client reste compatible dans l‟environnement de pré-production, et donc de production (Url relatives, source OLE-DB générique …). Cet environnement est mis en place pour simuler l‟environnement de production mais il ne présente pas les mêmes caractéristiques techniques en termes d‟infrastructure que l‟environnement de production.

3.5.9 Mise en conformité

Afin de mettre en conformité l‟application, la démarche recommandée est la suivante :

Respecter les spécificités de nommage imposées (SQL …) Utiliser les liens relatifs dans toute l‟application Déterminer les spécificités de l‟application en terme d‟environnement (source OLEDB …)

et définir une liste de modifications à supporter (si possible les concentrer dans un seul fichier ASP).

Suivre dans la mesure du possible les recommandations présentées dans ce document.

Il convient ensuite de télécharger l‟application et de la tester sur l‟environnement de pré-production afin d‟apporter les modifications en conséquence selon le modèle de test décrit plus haut.

3.5.10 Suivi des versions

La plate-forme SFR n‟assure pas la gestion des versions des applications clients. Il est fortement recommandé aux clients d‟assurer cette gestion côté développement, avec un outil comme Microsoft Visual Source Safe.




4 Architecture globale de l’hébergement LAMP

4.1.1 Déploiement d’un site web

4.1.1.1 Les étapes de la mise en ligne de votre site Web La démarche de déploiement d‟un site Web Windows sur la plate-forme de services est la suivante :

Etape 1 : Téléchargement des sources du site sur votre de production en

utilisant le compte FTP communiqué

Etape 2 : Création ou restauration éventuelle de votre Base de Données

MySQL

Ces différentes étapes sont plus ou moins illustrées dans le schéma de déploiement présenté dans le chapitre ci-dessous.

4.1.2 Schéma d’architecture de l’hébergement LAMP

Zone de développement

chez le client

Zone de production

(Hébergement)

Serveurs de production

Serveurs de développement

Transfert FTP

+

Publication

Figure 11 : L‟architecture d‟hébergement LAMP




Zone de développement client : Cette zone représente le réseau de l‟équipe de développement d‟un client sur laquelle les applications du client sont développées et préalablement testées. Zone de Production : La zone de production représente la zone d‟hébergement où sont publiées les applications de la zone de développement du client. Les données publiées dans cette zone sont directement accessibles pour les utilisateurs de l‟application c'est-à-dire, l‟ensemble de la communauté Internet. Remarque : Dans l‟environnement LAMP, il n‟existe pas de zone de pré production. Donc l‟environnement de développement du client doit respecter les préconisations définies dans ce document.

4.1.3 Les applications PHP

PHP (PHP Hypertext Processor) est un langage de script pour les serveurs web. Il permet de générer des pages web dynamiques tout comme le fait l‟ASP. En fait PHP est le concurrent direct d‟ASP. C'est un langage procédurale et objet mais on n'est pas obligé de développer en objet contrairement à Java. PHP bénéficie d'une très large communauté de développeurs sur internet et est en constante progression pour le développement d'applications web. Une page web PHP (extension .php ou .php3, etc.) est comme pour l‟ASP, une page html contenant du code PHP encadré par des balises spéciales (< ?[php] et ?>). Le fonctionnement d'une page web php est relativement simple comme présenté ci-dessous :

1) Le navigateur effectue sa requête vers le serveur en demandant une page php 2) le serveur reconnaît qu'il s'agit d'un fichier php (extension .php ou php3, etc.) puis le

transmet à l‟interpréteur PHP. 3) Dès que l‟interpréteur rencontre une balise php, il exécute le code et transmet au

serveur les sorties html éventuelles. 4) A la fin du script, le serveur transmet la page html dépourvu de code PHP au

navigateur qui l‟interprète et l‟affiche.

PHP

Apache

ServerServer

Client Serveur

HTML

PHP

Interprétation

des pages

Pages PHP

PHP HTML

Figure 12 : Le fonctionnement de l‟architecture PHP




Remarque : On peut constater que le code PHP s‟exécute côté serveur. Il n‟y a aucune trace du code PHP lorsque l‟utilisateur regarde le code source de la page dans son navigateur. Remarque : Le mode « safe_mode » est activé.

4.1.4 Application PHP et Base de données

Dans de nombreux cas, le langage PHP peut être associé à une base de données permettant de profiter d'un maximum de fonctionnalités et de puissance.

1) Connexion en perl

use DBI;

my $dsn = 'dbi:mysql.psie.local: NOM DE LA BASE :mysql:3306';

my $user = LOGIN;

my $pass = MOT DE PASSE;

my $dbh = DBI->connect ($dsn,$user,$pass) or die "cannot connect to the db";

$dbh->disconnect();

2) Connexion en php

<?php

/* Connexion et sélection de la base */

$link = mysql_connect("mysql.psie.local", " LOGIN ", " MOT DE PASSE ")

or die("Could not connect");

echo "Connexion réussie";

mysql_select_db(" NOM DE LA BASE ") or die("Could not select database");

/* Exécuter des requêtes SQL */

$query = "SELECT * FROM my_table";

$result = mysql_query($query) or die("Query failed");

/* Afficher des résultats en HTML */

echo "<table>\n";

while ($line = mysql_fetch_assoc($result)) {

echo "\t<tr>\n";

foreach ($line as $col_value) {

echo "\t\t<td>$col_value</td>\n";

}

echo "\t</tr>\n";

}

echo "</table>\n";

/* Libération des résultats */

mysql_free_result($result);

/* Fermeture de la connexion */

mysql_close($link);

?>




4.1.5 Liste des composants CGI

4.1.5.1 FormMail A présenter si nécessaire.

4.1.6 Convention de nommage

Cette partie décrit les règles de nommage devant être respectées afin de permettre la mutualisation des applications des différents clients sur un système commun. Ces règles sont indispensables pour permettre un partage de ressources sans conflits.

4.1.6.1 Nommage du serveur MySQL Le nom du serveur imposé est le suivant :

mysql.mondomaine.tld

4.1.6.2 Nommage des bases de données Afin de garantir le cloisonnement entre les bases de données de chaque c lient, le nom de la base imposé est le suivant :

<nom de domaine (en remplaçant les « . » par des « _ »)>_<nom de la base>

Par exemple : Pour l‟organisation « sfrbusinessteam.fr » avec une base « users », le principe est de remplacer les « . » par des « _ », ce qui donne comme nom de base : sfrbusinessteam_fr_users.

4.1.6.3 Nommage des Logins MySQL La base de donnée est crée à la création du site web du client. Le compte de connexion à cette base sera de la forme admin_<siteID>. Le mot de passe rattaché à ce comptes sera le même que celui fourni dans le courrier client pour le compte FTP. Le login précis sera remonté au niveau de l‟extranet pour chaque site du client.

4.1.6.4 Dépendances vis-à-vis de la plate-forme Afin de rendre le code indépendant de la plate-forme, tous les chemins virtuels de l‟application doivent être relatifs (pas de http://NomDeServeur/NomApplication dans le code).

4.1.6.5 Règles de nommage PHP Définir une convention de nommage garantit :

La standardisation du codage du style d‟une application La production d‟un code source lisible et sans ambiguïté

La facilitation de la coordination d‟une équipe de développeurs travaillant ensemble sur la même application

L’important n’est pas de suivre cette convention à la lettre mais de la définir et de la respecter. La convention proposée n‟est pas contraignante et repose essentiellement sur deux axes :

L‟utilisation systématique de préfixe indiquant le type de la variable ou s‟il agit d‟un objet. L‟utilisation d‟une description indiquant la nature de la variable ou de l‟objet

http://nomdeserveur/NomApplication




4.1.6.6 Variables Préfixe Type de donnée Exemple b Boolean bIsConnected dt Date dtHire a Array aCollection l Long lMaxUsers i Integer iAgeOfUser s String sEmail d Digit dUsersProfiles o Object

4.1.6.7 Objets divers Le préfixe « o » peut être utilisé notamment pour la déclaration de nouveaux objets dépendants des classes diverses et variées comme les objets de type connexion (ex. oConn, oConnPrinc,...) ou encore oImgSrc (pour objectImageSource), oFrm (pour un objet formulaire). Le préfixe « o » peut être aussi utilisé pour tout ce qui ne correspond pas à ce qui a été défini précédemment.

Préfixe Type d’objet Exemple o Object oFsoConfigFile

4.1.6.8 Constantes Les constantes sont déclarées en majuscules avec des « soulignés ( _ ) » entre chaque mot. Il n‟est pas utile de préfixer les constantes. Exemple : SERVER_NAME

4.1.6.9 Fonctions Une fonction est précédée d'un cartouche (cf. ci-dessous), comme pour les fichiers, mais avec en plus une indication sur les paramètres en entrée et en sortie. Pas de méthode particulière. - mysql_query() comme en PHP, c'est à dire tout en minuscule, en séparant les mots par un "_". - FormSubmit() ou encore formSubmit(). D‟autres suggestions.

4.1.6.10 Commentaires Toutes les procédures et fonctions devraient débuter avec un bloc de commentaire décrivant les attributs et blocs de commentaires décrivant les attributs de la fonction ou la procédure. Pour ce faire, l‟utilisation de cartouche (nom de fichier, auteur, date de création, version + auteur de la modification + commentaire, descriptif du contenu) ainsi que des commentaires (pertinents pour ne pas surcharger la page) est recommandé. Cela donne ce qui suit : <? /*============================================= Nom : progNormes.php Arguments :




Returns : Desc. : - Présentation des normes de développement - Contenu du répertoire Projet - Règles de nommage Auteur : Olivier HAMY ([email protected]) EDITS : 2005-06-21 OHA 1.0.1 : Création du fichier 2005-06-22 LPI 1.0.2 : Ajout de la description du cartouche =============================================*/ ?> La première section contient le nom du programme en fonction du type de la fonction. La section ARGUMENTS définit les arguments qui sont passes avec une explication de leur rôle. La section RETURNS définit le retour de la fonction. La section DESCRIPTION donne une description fonctionnelle de la procédure. La section EDITS fournit un historique des versions de la fonction et du but des modifications.

Les sections logiques du code doivent être segmentées avec des blocs de commentaires .




5 Conclusion

Ce guide définit les recommandations à suivre afin de mette en œuvre une app lication Web dynamique performante sur la plate-forme d‟hébergement mutualisé de SFR. La liste des préconisations n‟a pas bien sûr la prétention d‟être exhaustive mais elle permet déjà de fournir des orientations de développement à suivre pour les futures applications à héberger. En effet, le modèle de recommandations sera amené à évoluer avec les nouvelles versions des technologies supportées (notamment ASP, stratégie .Net de Microsoft, les évolutions PHP et MySql) et la complexité des applications réalisables, mais il fournit déjà les fondements méthodologiques de la construction d‟applications Web. L‟objectif commun aux clients de la plate-forme comme à l‟hébergeur consistant à optimiser les performances, la fiabilité, et la sécurité des applications, ce guide est bien sûr ouvert à toutes suggestions en terme de contenu aussi bien que de forme afin de garantir le bon équilibre entre souplesse et structuration dans le mode d‟interaction développeur/plate-forme d‟hébergement.




6 ANNEXE

Cette partie regroupe les informations qui ne sont propres aux fonctions de la plateforme, mais qui appartiennent à sa collection d‟outils, et dont l‟utilisation n‟est pas sans impact. Non applicable. [Fin du document]

Documents

Guide du Développeur - Services Internet hébergés · 2012-01-12 · G u i d e d u D é v e l o p p e u r V 1.1 Administration des Services Internet Page 1 Information réservée