Architecture de stockage des données avec SQL Server 2005 Compact Edition

Paru le 02 avril 2007

Brian Noyes
IDesign, Inc.

**Réviseurs techniques
**Sitaram Raju, Sachin Sinha
Microsoft Corp.

S'applique à :
SQL Server 2005 Compact Edition
Architecture de stockage des données

**Résumé :**SQL Server 2005 Compact Edition (SSCE) fournit un moteur de stockage de données puissant et léger pour le développement d'applications de différents types. Ce document présente certains aspects problématiques du stockage des données pour les applications clientes et les applications serveur à petite échelle. Il aborde l'ensemble des fonctionnalités SSCE et explique comment cet ensemble de fonctionnalités résout les problèmes de stockage de données. Il traite des différentes architectures d'application adaptées à SSCE en soulignant les attributs des types d'application et la façon dont SSCE peut répondre aux exigences de chaque type d'application. (17 pages imprimées)

Cliquez ici pour télécharger la version document Word de cet article, DataArchSSCE.doc.

Data Storage Architecture with SQL Server 2005 CE 

Sur cette page

Introduction
Difficultés liées au stockage de données
Présentation du stockage de données
Applications de stockage des données
Options de stockage de données
Vue d'ensemble de SQL Server 2005 Compact Edition (SSCE)
Architecture de solutions avec SSCE
Conclusion

Introduction

La sélection d'une architecture de stockage de données adaptée à vos applications peut apparaître comme une tâche impressionnante. Le choix de technologies sur le marché est vaste et en pleine expansion. La technologie de stockage de données que vous choisissez dépend de plusieurs facteurs. Vous devez analyser les compromis entre les exigences de plate-forme, la taille, les performances, la facilité de déploiement, la facilité d'accès aux données et la capacité de stockage.

Pour les applications serveur desservant de nombreux utilisateurs, le choix est clair : utilisez SQL Server 2005. Le choix de la version serveur de SQL Server 2005 dépend de l'échelle et de la cible de votre application, et la liste des fonctionnalités vous aide à choisir la version la mieux adaptée à votre cas. De plus, le passage à une autre version se limite à une simple décision de licence et ne nécessite généralement aucune modification de l'architecture.

En ce qui concerne les applications côté client ou les applications serveur à petite échelle, la sélection d'une technologie de stockage de données est plus délicate. Pour les applications clientes, il est inutile de placer une instance complète de SQL Server 2005 sur chaque ordinateur client en raison du coût, de la complexité, des exigences de plate-forme et divers autres facteurs. Pour les applications serveur à petite échelle, les performances accrues de SQL Server 2005 ne sont sans doute pas nécessaires, et le coût de la licence risque d'être trop élevé pour les petits projets. Pour les applications de périphériques mobiles, une version complète de SQL Server n'est pas prise en charge par la plate-forme.

Ce livre blanc traite des difficultés liées à l'architecture de stockage de données, des scénarios et des solutions d'utilisation du nouveau SQL Server 2005 Compact Edition (SSCE). Il couvre les ressemblances et les différences entre SSCE, les autres versions de SQL Server 2005 et les autres technologies de base de données relationnelles, notamment le moteur de base de données intégré EDB sur les périphériques mobiles.

Difficultés liées au stockage de données

Pour les applications clientes ou les applications serveur à petite échelle, vous devez résoudre un certain nombre de difficultés liées au stockage de données :

• Emplacement du stockage de données Si vous créez une application cliente distribuée et que pouvez vous permettre de stocker vos données sur un serveur principal et de les récupérer via le réseau, vous pouvez simplement utiliser SQL Server 2005 sur le serveur. Si vous créez une application de périphérique mobile ou une application cliente, vous aurez probablement besoin d'une banque de données locale sur le client pour mettre en cache les données lorsque vous êtes hors ligne. Vous pouvez également avoir besoin de mettre en cache sur le client pour éviter l'extraction répétées de gros DataSets, tels qu'un catalogue de produits, sur le réseau. Pour les applications clientes, les données peuvent n'être requises que localement, auquel cas leur stockage sur un serveur principal n'est pas justifié.

• Facilité d'accès aux données. La productivité représente un élément extrêmement important de la capacité à commercialiser les applications conformément au calendrier et au budget établis. Votre technologie de stockage de données doit faciliter la lecture et l'écriture de données depuis votre emplacement de stockage.

• Facilité d'interrogation. Une technologie de stockage de données robuste vous permet de rechercher et sélectionner facilement et rapidement des enregistrements individuels ou des collections d'enregistrements.

• Capacité de synchronisation des banques de données. Pour les applications clientes mobiles, les données hors ligne stockées localement doivent être synchronisées avec les banques de données principales. L'écriture de toutes pièces de mécanismes de synchronisation est source d'erreurs et demande beaucoup de temps. La technologie de stockage de données doit prendre en charge la synchronisation de banques de données multiples.

• Sécurité. Dans le cas des périphériques mobiles ou des ordinateurs clients portables en particulier, la sécurité est très importante en termes de protection des données stockées : en cas de vol de l'ordinateur, les données sont inaccessibles à un utilisateur non autorisé. De même, lorsque vous synchronisez les données, vous devez protéger les données en transit.

• Intégrité des données. Lorsque vous lisez et écrivez des données à partir de votre banque, vous devez vous assurer que les données sont enregistrées de manière cohérente et qu'aucune corruption de données ne survient. Les banques de données transactionnelles fournissent des mécanismes pour assurer ceci, et doivent être préférées aux banques de données non-transactionnelles.

• Facilité de déploiement. Pour les applications clientes, un faible encombrement et un processus d'installation aisé sont critiques pour la prise en charge et la facilité de gestion. La configuration requise dans l'application cliente doit également être réduite pour lier l'application à la banque de données.

Présentation du stockage de données

Un large éventail d'options est disponible pour le stockage de données. Il n'y a pas si longtemps, un grand nombre d'applications sérialisaient les données dans des formats propriétaires dans des fichiers plats sur disque. Le format XML fournit une solution plus structurée et facile à utiliser pour stocker les données arbitraires dans des fichiers, mais ne résout pas toutes les difficultés décrites à la section précédente. Les technologies de base de données relationnelles sont vraiment les seules technologies largement répandues qui répondent à tous les défis présentés par un stockage de données robuste.

Après avoir réduit votre choix de technologies de base de données, vous devez considérer un certain nombre d'options disponibles. Vous devez utiliser d'autres critères pour sélectionner la technologie appropriée et sélectionner la bonne technologie de base de données en fonction de la manière dont chaque option résout les difficultés abordées à la section précédente. De plus, vous devez déterminer si la base de données s'exécutera comme une base de données cliente utilisateur unique ou une base de données serveur multi-utilisateur.

Pour les applications clientes, vous devez limiter votre investigation à deux options différentes selon qu'il s'agit d'une application de bureau ou d'une application de périphérique mobile. Pour les applications de bureau (s'exécutant sur un poste de travail de bureau, un portable, ou Tablet PC), concentrez-vous sur SQL Server 2005 Compact Edition (SSCE) ou SQL Server 2005 Express Edition (SSE). Pour les périphériques mobiles exécutant Microsoft Windows CE ou des systèmes d'exploitation Mobile, vous pouvez choisir SSCE ou le moteur de base de données intégré EDB.

Pour plusieurs raisons abordées plus en détail plus loin dans ce livre blanc, SSCE offre une solution solide et facile à utiliser pour la plupart des applications professionnelles clientes. SSE n'est nécessaire que pour les applications côté client spécialisées, mais constitue un bon choix pour les applications serveur à petite échelle qui prennent en charge un chargement utilisateur modéré et qui demandent une architecture plus évolutive et robuste. EDB peut s'avérer un bon choix si vous a besoin d'une prise en charge native sur le périphérique et si vous êtes inquiet de l'impact disque et mémoire de l'installation de SSCE sur le périphérique, mais il convient comparer ces inconvénients à la productivité et aux fonctionnalités accrues de SSCE.

Pour les applications côté serveur à petite échelle et les besoins de mise en cache, SSCE ou SSE peuvent tous deux convenir. Pour une application Web à potentiel de croissance et d'évolution illimité, SSE constitue un meilleur choix, car il prend en charge un éventail de fonctionnalités plus large par rapport SSCE.

Applications de stockage des données

Il existe des applications de toutes les tailles et de toutes les formes. Comme mentionné précédemment, les applications serveur à grande échelle nécessitent véritablement les versions SQL Server 2005 Workgroup ou Enterprise, et elles ne sont pas traitées dans ce livre blanc. Pour les applications clientes et les applications serveur à petite échelle, vous pouvez classer les applications en un certain nombre de types d'applications. Ces types incluent notamment :

• Applications de terrain. Il s'agit d'applications clientes utilisées par les travailleurs mobiles sur le terrain. Ces applications s'exécutent généralement sur les ordinateurs portables ou Tablet PC, mais elles peuvent également s'exécuter sur des périphériques mobiles. Elles offrent une présentation de données interactive et une interaction permettant travailler avec des clients ou des équipements distribués.

• Applications de gestion des informations personnelles. Il s'agit d'applications clientes utilisées pour stocker et accéder à des collections d'éléments d'informations, tels que les contacts, les plannings, les tâches, les notes, et ainsi de suite. Elles peuvent s'exécuter sur les ordinateurs de bureau, les ordinateurs portables ou les périphériques client mobiles, mais ces applications sont de plus en plus développées pour une installation de faible encombrement sur les périphériques mobiles.

• Applications Web à petite échelle. Il s'agit d'applications clientes simples de présence Web pour présenter des informations dynamiques via le Web à un petit groupe d'utilisateurs, et peuvent par exemple être utilisées par les petites entreprises, les communautés et les organisations à but non lucratif ou les clubs. Elles nécessitent l'exposition d'un serveur Web, mais peuvent être exécutées depuis un système d'exploitation de bureau, tel que Windows Vista ou Windows XP Professionnel.

• Mise en cache des applications. Qu'une application cliente soit conçue ou non pour travailler hors ligne, il n'est généralement pas utile d'effectuer un aller-retour complet à la base de données chaque fois que vous avez besoin de rechercher des informations de consultation telles qu'une ville, une région, un code postal, des listes de catalogue de produits, etc. L'implémentation d'un cache de données du client peut améliorer les performances de manière significative pour la présentation de listes ou la recherche dans des tableaux qui ne changent que rarement. De plus, certaines applications peuvent être conçues avec une architecture distribuée composée d'un client intelligent, d'un périphérique mobile ou d'applications clientes Web qui communiquent avec un serveur d'applications principal centralisé. Le serveur d'applications peut avoir besoin de mettre en cache des données localement pour éviter des allers-retours au serveur de base de données. La nécessité de mettre en cache des données sur l'ordinateur local ne justifie pas l'achat ou les coûts d'installation d'une instance complète de SQL Server localement sur le serveur d'applications.

Options de stockage de données

Pour prendre les bonnes décisions en matière d'architecture, envisagez la solution de façon objective en examinant toutes les options disponibles. Pour répondre aux besoins de stockage de données de votre architecture, plusieurs options sont disponibles. N'oubliez pas que ce document se concentre sur le stockage de données côté client ou serveur à petite échelle. Pour ces parties de votre architecture, vos principales options sont le stockage de fichiers, EDB, SSCE et SSE. Pour une sélection correcte, vous devez examiner les capacités et les restrictions de chaque option et les comparer à vos besoins.

Fichiers plats ou XML

L'utilisation de fichiers plats ou de fichiers XML peut paraître intéressante au premier abord en raison de leur simplicité : la plupart des développeurs savent déjà utiliser Microsoft .NET ou la sérialisation XML pour lire et écrire des données à partir de fichiers, ou savent utiliser les fonctionnalités d'un DataSet pour le lire et l'écrire au format XML à partir d'un fichier. Toutefois, les fichiers présentent des problèmes de cohérence et de fiabilité. Si une application est interrompue ou s'arrête sans terminer correctement les opérations d'E/S et fermer le fichier, les données contenues peuvent être endommagées, et le verrouillage du fichier peut empêcher le comportement correct de l'application. Ces problèmes peuvent être résolus par un codage et une gestion des erreurs disciplinés, mais au détriment de la simplicité initiale des fichiers plats.

Il n'existe pas non plus de fonctionnalité d'interrogation des fichiers inhérente, et vous devez généralement lire tout ou la plupart du fichier dans les structures de données de mémoire pour rendre les données utilisables. Par conséquent, les fichiers plats et les fichiers XML ne sont pas appropriés pour les données qui seront interrogées, lues et écrites par l'exécution de l'application. Pour les données simples, telles que les paramètres de configuration et les préférences, les fichiers de configuration XML sont appropriés. Il peut également être préférable de stocker les documents et les fichiers volumineux, tels que les fichiers plats avec métadonnées, dans la base de données, en fonction des modèles d'accès. Toutefois, la plupart des données en lecture/écriture à accès aléatoire pour vos applications doivent être stockées et accessibles par l'intermédiaire d'un moteur de base de données.

EDB

Le moteur de base de données intégré EDB est un composant natif des systèmes d'exploitation Windows CE 5.x, 6.x et Mobile 6.x. EDB est un moteur de données relationnelles simple qui vous permet de stocker des données de tableau avec un système de type limité et des fonctionnalités d'interrogation limitées. EDB est une option à envisager lorsque vous recherchez une fonctionnalité native sur un périphérique, ou qui peut être installée avec un encombrement et un coût réduits sur le périphérique. Le moteur EDB peut être plus rapide que SSCE pour certains types d'extraction de données simple, mais risque d'être plus lent si des requêtes complexes sont nécessaires. L'un des inconvénients majeurs de l'utilisation du moteur EDB est que vous ne pouvez y accéder qu'en utilisant une API de bas niveau dans Microsoft Visual C++. Si vous écrivez votre application à l'aide de .NET Compact Framework pour tirer parti des avantages de productivité associés au développement de code géré, vous devez écrire un composant d'accès aux données séparé qui fonctionne avec la base de données EDB à l'aide de C++, puis vous devez interagir avec ce composant depuis votre code géré. La complexité de ces opérations annule les avantages d'utilisation d'EDB. Envisagez l'utilisation d'EDB uniquement si vous écrivez déjà votre application en intégrant du code C++, et que votre but est de réduire l'encombrement et d'optimiser les performances de l'application.

SQL Server 2005 Compact Edition (SSCE)

SSCE est un moteur de base de données relationnelles léger (< 2 Mo), que vous pouvez installer gratuitement sur les systèmes d'exploitation Windows récents. SSCE faisant l'objet principal de ce livre blanc, le jeu de fonctionnalités complet est décrit plus loin. À un niveau supérieur, SSCE prend en charge les tableaux, les relations, les contraintes, le traitement de requêtes complexes, les transactions, la réplication, ainsi que la sécurité des données. Pour programmer sur SSCE, vous utilisez un fournisseur géré ADO.NET avec des modèles de codage d'accès aux données similaires à ceux que vous utilisez pour les autres fournisseurs gérés, tels que le fournisseur géré SQLClient de SQL Server. Vous pouvez également accéder à SSCE à partir de clients non gérés en utilisant OLE DB. SSCE s'exécute intra-processus en tant qu'ensemble de bibliothèques référencées par l'application d'utilisation et peut être facilement déployé avec vos bibliothèques d'application ou en tant qu'installation MSI séparée. SSCE peut être facilement déployé avec les applications ClickOnce ou à l'aide de Xcopy sur des périphériques mobiles. SSCE sera installé en natif sur Windows Mobile 6.0 ou version ultérieure.

Le système de type SSCE est un sous-ensemble du système de type SQL Server 2005 et ne prend pas en charge toutes les fonctionnalités qui sont prises en charge par une instance complète de SQL Server. Les fonctionnalités SQL Server couramment utilisées pour les applications serveur qui ne sont pas présentes dans SSCE incluent les procédures stockées, les déclencheurs, les vues, les fonctions, les types de données définis par l'utilisateur, ainsi que la possibilité de participer à la messagerie SQL Server Service Broker.

SQL Server 2005 Express Edition (SSE)

SSE est un service de moteur de base de données léger (< 55 Mo), que vous pouvez installer gratuitement sur un ordinateur de bureau ou un système d'exploitation Windows récents. Étant donné que SSE s'exécute en tant que service Windows, il nécessite une installation Windows Installer (MSI) sur l'ordinateur cible. SSE peut être déployé par le programme d'amorçage ClickOnce et utilisé par les applications à déploiement ClickOnce. SSE prend en charge l'isolation des instances utilisateur, ce qui peut faciliter le déploiement ClickOnce en garantissant la protection des données d'un utilisateur des données d'un autre.

SSE prend en charge la plupart des fonctionnalités d'une instance complète de SQL Server, y compris les tableaux, les vues, les procédures stockées, les déclencheurs, les fonctions et SQL CLR. Vous accédez aux données dans une instance SSE à partir de code géré comme vous le faites à partir d'une instance SQL Server complète, via le fournisseur géré SQLClient. Vous pouvez également y accéder à partir d'applications non gérées via un fournisseur OLE DB.

Les restrictions de SSE par rapport à une instance complète de SQL Server sont relativement faciles à comprendre. SSE utilise seulement un processeur sur l'ordinateur même si plusieurs sont présents ; ce service utilise seulement 1 Go de mémoire et n'autorise l'expansion des bases de données que jusqu'à 4 Go. De plus, SSE peut être un abonné mais pas un éditeur pour tous les types de réplication ; il peut envoyer et recevoir des messages de SQL Server Service Broker tant que les messages sont transmis par une instance complète de SQL Server (c'est-à-dire, pas de messagerie d'égal à égal entre des instances de SSE sans une instance complète dans la chaîne).

Vue d'ensemble de SQL Server 2005 Compact Edition (SSCE)

À un niveau conceptuel, vous pouvez considérer SSCE comme une version considérablement réduite du moteur de base de données SQL Server 2005. Cependant, il s'agit d'un moteur de base de données séparé conçu pour optimiser les fonctionnalités clés requises pour le stockage de données relationnelles transactionnel tout en réduisant les exigences en termes de disque, de mémoire et d'installation pour l'application d'hébergement.

Historique SSCE

L'héritage de SSCE remonte à SQL Server CE 1.0, publié en 2001. Il s'agissait alors du premier moteur de données relationnelles de Microsoft pour les systèmes d'exploitation de périphériques mobiles et il était basé sur les fonctionnalités de base de données de SQL Server 2000. Les versions 1.1 et 2.0 ont suivi pour améliorer l'expérience utilisateur, la version 2.0 fournissant l'intégration avec les applications .NET Compact Framework. Avec .NET 2.0 et SQL Server 2005, SQL Server 2005 Mobile Edition représentait le moteur de base de données mobile de nouvelle génération. SQL Server 2005 Mobile Edition présentait de nombreuses nouvelles fonctionnalités, y compris une meilleure fiabilité et des performances optimisées, des options de synchronisation améliorées et une intégration plus poussée avec SQL Server 2005 et Microsoft Visual Studio 2005.

À la première annonce de SSCE, lors de la conférence TechEd 2006, le nom de cette version était SQL Server 2005 Everywhere Edition. Ce nom n'a subsisté que peu de temps jusqu'à la finalisation des fonctionnalités SSCE et l'annonce du nouveau nom par Microsoft lors de la conférence TechEd Europe 2006 en novembre 2006. Par conséquent, si vous rencontrez encore des références à SQL Server 2005 Everywhere Edition ou à SQL Everywhere sur le Web, vous pouvez les traiter comme des synonymes de SSCE. Il est important de noter que SSCE est un moteur de données entièrement différent et considérablement amélioré par rapport aux versions SQL Server CE précédentes, et de faire la différence.

Fonctionnalités de base de SSCE

La fonctionnalité de base de SSCE consiste à faciliter l'accès et le stockage transactionnel et sécurisé des données relationnelles. Vous pouvez exécuter des requêtes SQL incluant des requêtes de langage de définition de données (LDD) et de langage de manipulation de données (DML) via le moteur SSCE. À l'aide de SSCE, vous créez une instance de base de données comme un fichier .sdf unique. Dans cette base de données, vous pouvez définir des tableaux avec des clés primaires et des contraintes. SSCE prend en charge l'intégrité référentielle complète par l'intermédiaire de contraintes de clé étrangère et de suppressions et mises à jour en cascade.

De plus, SSCE prend en charge les fonctionnalités suivantes :

• Connexions simultanées multiples pour l'accès aux données multi-thread

• Protection par mot de passe et chiffrage 128 bits du fichier de données .sdf de SSCE

• Large éventail de types de données de colonne

• Curseurs défilants et actualisables pour l'accès rapide et facile aux données connectées

• Bases de données à expansion jusqu'à 4 Go

• Synchronisation avec SQL Server par réplication de fusion et accès aux données distant

Nouvelles fonctionnalités de SSCE

Toutes les fonctionnalités de base de SSCE faisaient partie de la version SQL Server 2005 Mobile Edition, publiée avec SQL Server 2005 et .NET 2.0 en octobre 2005. SSCE ajoute plusieurs fonctionnalités périphériques qui la distinguent de Mobile Edition comme suit :

• SSCE peut désormais s'exécuter sur tous les systèmes d'exploitation Windows pris en charge, y compris les périphériques mobiles, Tablet PC, les ordinateurs portables, les ordinateurs de bureau et les serveurs.

• SSCE peut être mis à jour avec Microsoft Update, Systems Management Server ou Microsoft Windows Server Update Services.

• SSCE peut être déployé à l'aide de ClickOnce.

Synchronisation de données avec SSCE

Lorsque SSCE est utilisé comme un cache de données local pour une application cliente ou de niveau intermédiaire dans une architecture d'application distribuée, vous devez en général synchroniser la base de données SSCE avec un serveur de base de données principal. Au départ, vous devrez peut-être remplir les tableaux des bases de données SSCE à partir d'une base de données principale, et vous devrez peut-être aussi placer des enregistrements mis à jour ou nouveaux du client vers la base de données serveur.

SSCE présente plusieurs options de synchronisation. Deux options sont incorporées : la réplication de fusion et l'accès RDA. Ces deux fonctions vous permettent de synchroniser des données dans les deux sens : d'une base de données SSCE vers SQL Server 2005 ou d'une base de données SQL Server 2000 sur HTTP. Outre ces fonctionnalités, vous pouvez implémenter une solution de synchronisation personnalisée en établissant des appels à vos points de terminaison de service Web exposés, ce qui vous permet de transmettre les données par des couches de logique métier personnalisées dans les deux sens, côté serveur. Dans la prochaine version de Visual Studio (nom de code « Orcas »), un nouveau sous-système de synchronisation appelé infrastructure de synchronisation de systèmes connectés occasionnellement (OCS) sera disponible.

La réplication de fusion représente l'option de synchronisation incorporée la plus puissante, car elle permet la mise à jour autonome et indépendante des enregistrements sur les bases de données clientes (SSCE) et serveur (SQLServer ) en même temps. SSCE participe à la réplication de fusion en tant qu'abonné, et peut s'abonner aux publications de réplication de fusion exposées de SQL Server 2000 ou SQL Server 2005. La réplication de fusion gère de nombreux clients facilement, car elle prend également en charge la détection de conflit et la résolution, côté serveur. La réplication de fusion est un peu plus compliquée à configurer et nécessite des fonctionnalités de conception de base de données et de configuration spécifiques côté serveur.

L'accès RDA est l'option de synchronisation incorporée la plus facile à utiliser. Avec RDA, il n'existe aucune exigence spécifique sur la base de données côté serveur. Pour synchroniser des données avec RDA, vous extrayez un ensemble de résultats dans la base de données SSCE du côté serveur pour initialiser un tableau avec les données actuelles du serveur. Vous pouvez ensuite diffuser les modifications (insertions, mises à jour et suppressions) sur le serveur lorsque vous choisissez de synchroniser. Pour obtenir les modifications apportées côté serveur depuis l'extraction initiale des données, vous devez à nouveau extraire le même ensemble de résultats (après avoir diffusé vos modifications dans vos données extraites). RDA ne dispose pas de fonctions de détection de conflit ou de résolution simultanées. Ainsi, si vous l'utilisez avec une application sur laquelle plusieurs clients peuvent modifier des enregistrements différents en même temps, le dernier client apportant des modifications à un enregistrement peut remplacer les modifications apportées par le client précédent.

L'infrastructure de synchronisation OCS, une fois publiée, vous permettra de choisir entre des fonctionnalités de synchronisation de base de données à base de données similaires à RDA et à la réplication de fusion, et une approche plus orientée service dans laquelle vous intégrez vos propres points de terminaison dans le pipeline de synchronisation. La première approche est plus simple à configurer, car elle requiert moins de code personnalisé. La seconde approche est un peu plus complexe, mais vous permet d'insérer la logique métier entre le client et le serveur ; elle vous permet également de cibler d'autres sources de données qui peuvent être encapsulées dans un service de synchronisation approprié. La figure 1 illustre l'architecture de la nouvelle infrastructure de synchronisation OCS.

Figure 1. Infrastructure de synchronisation OCS

L'infrastructure OCS fournit une solution prête à l'emploi pour la synchronisation de données orientée service, ainsi que de nombreux points d'extensibilité pour un contrôle plus explicite du processus de synchronisation. Le client appelle via un fournisseur de synchronisation pour effectuer la synchronisation des données. Le fournisseur peut faire appel à la logique personnalisée, par exemple, la logique de validation, si nécessaire. Le fournisseur de synchronisation appelle ensuite via un agent de synchronisation le service de synchronisation sur le serveur. Le service exposé peut être un service fourni avec l'infrastructure ou un service personnalisé que vous exposez. Le service appelle via un fournisseur de synchronisation côté réception, qui peut également faire appel à une logique personnalisée. La synchronisation est distribuée via un adaptateur de synchronisation approprié et ses commandes de base de données associées. Les adaptateurs et les commandes suivent une architecture similaire à celle de TableAdapters associée aux DataSets typés ADO.NET 2.0.

Simultanéité SSCE

SSCE permet des connexions multiples à la même base de données (fichier .sdf) à partir d'une même application ou de plusieurs applications sur un même ordinateur. Vous disposez ainsi de plus de liberté pour structurer votre application en fonction des besoins, par exemple, pour permettre à l'utilisateur de continuer à interagir avec des données tout en effectuant la synchronisation à une base de données principale, ou pour permettre à plusieurs applications sur une même machine de partager une banque de données SSCE. Les verrouillages de simultanéité transactionnelle sont effectués par le moteur de base de données pour empêcher des connexions simultanées d'accéder aux mêmes enregistrements en même temps. La limite technique sur les connexions simultanées pour une base de données unique est de 256, mais 70 à 80 est une limite plus pratique du point de vue des performances.

Sécurité SSCE

La sécurité et les autorisations basées sur les rôles ne sont pas prises en charge dans SSCE. Les bases de données SSCE sont destinées à être utilisées comme un simple mécanisme de stockage de données pour le stockage de données local et l'accès sur un ordinateur client, ou pour la mise en cache simple de données permanentes sur un serveur d'applications. Par conséquent, la sécurité et les autorisations basées sur les rôles n'ont pas été incluses afin de conserver le moteur de base de données aussi petit et rapide que possible. Le contrôle d'accès à la base de données dans son ensemble peut être appliqué par un accès protégé par mot de passe. La protection des données stockées sur le disque peut facilement être assurée en chiffrant la base de données.

Accès SSCE par code non géré

SSCE vous permet également d'accéder facilement à la banque de données depuis des applications non gérées. SSCE inclut un fournisseur OLE DB de sorte que les applications utilisant Microsoft Access, Microsoft Visual Basic 6, C++ ou d'autres formes de code non géré puissent accéder et utiliser des données qui ont été placées dans une base de données SSCE. Cela peut faciliter la migration incrémentielle depuis des applications non gérées et des banques de données héritées vers SSCE et vers du code géré, par exemple.

Performances SSCE

Les performances SSCE sont adaptées à l'utilisation des scénarios décrits dans ce document. Si vous comparez les performances SSCE avec SSE, EDB ou Microsoft Access, vous ne constaterez pas de grandes différences dans les scénarios. Pour chaque combinaison de taille de requête, de modèle de stockage et d'autres variables, les performances d'un produit peuvent paraître meilleures que les autres, mais quelques tendances peuvent être mesurées systématiquement.

Si vous comparez SSCE à SSE, plusieurs modèles émergent des tests de performances. Les transactions sont légèrement plus rapides à lancer et valider dans SSCE que dans SSE, mais seulement d'une fraction de pourcentage (20 %). SSCE est plus rapide que SSE pour les requêtes paramétrées qui insèrent de grands nombres de lignes (> 100), mais SSE est plus rapide pour les lignes seules ou les petits nombres d'insertions de lignes. SSCE est deux fois plus lent que SSE pour une sélection de ligne seule et est comparable pour 100 lignes ou plus, avec le modèle connecté de SqlCeResultSet. Cependant, avec l'API SqlCeConnection, la première ouverture et la dernière fermeture sont considérablement plus lentes dans SSCE que dans SSE (> 1 000 fois dans certains cas) en raison des surcharges importantes de démarrage et d'arrêt du moteur de stockage. Une optimisation pour de meilleures performances consiste à ouvrir une connexion SqlCeConnection avant les transactions et à la fermer à la fin. Dans ce cas, les performances sont comparables à celles de l'API SqlCeResultSet.

Si vous comparez les performances de SSCE à celles d'EDB sur un périphérique, EDB peut être considérablement plus rapide (100 % ou plus) pour certains scénarios, tels que la détermination de la taille de la base de données et l'exécution d'insertions ou de mises à jour. Cependant, la plupart des opérations de recherche et de requête favorisent SSCE de 20 à 30 % et sont à peu près égales en matière de performances.

Architecture de solutions avec SSCE

Pour comprendre comment intégrer SSCE dans votre architecture d'application, il convient d'examiner son utilisation dans le contexte des quatre types d'application résumés plus haut dans ce livre blanc : applications de terrain, applications de gestion des informations personnelles, applications clientes Web à petite échelle et mise en cache de serveur d'applications.

Applications de terrain

Les applications de terrain sont généralement des applications clientes conçues pour l'exécution sur périphériques mobiles, Tablet PC ou ordinateurs portables dans le cadre d'un système distribué plus grand, composé de plusieurs niveaux, services, bases de données et autres éléments architecturaux. Les applications de terrain partagent en général un ou plusieurs des attributs suivants :

• Elles permettent aux utilisateurs d'exécuter leur travail tout en étant déconnectés du réseau principal, sur site sur un chantier client, en déplacement, dans un aéroport ou chez eux. Ces applications sont en général conçues pour une connexion occasionnelle, ce qui signifie que lorsque les utilisateurs exécutent l'application client, ils n'ont pas besoin de connexion réseau.

• Les applications de terrain impliquent souvent plusieurs clients pouvant accéder et utiliser simultanément des données de la base de données principale, en mode connecté et déconnecté.

• Elles doivent être capables de répliquer les données de la base de données principale vers les bases de données clientes pour la prise en charge hors ligne. Elles doivent également être capables de répliquer les enregistrements de données modifiés, ajoutés ou supprimés du client vers le serveur lorsque l'application se connecte au réseau.

• Elles doivent être déployables à l'aide de ClickOnce, autoriser des mises à jour fréquentes des fonctionnalités ainsi que de la base de données utilisée pour le stockage local.

Exemples d'applications de terrain :

• Applications de ventes POC (point de contact) pour le détail, les assurances, l'immobilier, la gestion financière et de nombreux autres secteurs.

• Applications de gestion de la relation client (CRM) avec portée étendue aux équipes distribuées par périphériques mobiles, ordinateurs portables et Tablet PC.

• Applications pour fournisseurs de services de santé qui offrent l'accès aux dossiers médicaux complets, la conservation des archives avec interaction entre patients et professionnels, le tri des ordonnances de médicaments, les laboratoires et les diagnostics, ainsi que la collecte de données à partir des périphériques de mesure.

• Applications de gestion d'inventaire pour les entrepôts, les services d'expédition, les services de gestion des bureaux d'affaires, les fournitures de nettoyage et entretien et autres applications impliquant l'enregistrement et le suivi d'articles, et disponibles sur le terrain.

• Applications de collecte et de mesure de données, telles que les applications des fournisseurs d'eau, de gaz et d'électricité, et des entreprises de télécommunications, de sondage, de recensement et de vote.

Les architectures de solution d'applications de terrain peuvent varier largement en fonction du nombre et du type de plates-formes clientes et de l'échelle de l'application. Une architecture type est décrite à la figure 2. Les applications de terrain se composent en général de plusieurs clients impliquant des plates-formes PDA ou de téléphone, des Tablet PC, des ordinateurs portables ou une combinaison. Elles se connectent en général aux services principaux via des services Web sécurisés ou des connexions sur réseau privé virtuel (VPN) afin d'effectuer la synchronisation avec les données principales d'une connexion Internet disponible, au lieu de revenir au réseau domestique. La première partie exposée est souvent placée dans un réseau de périmètre (également connu sous les noms DMZ, zone démilitarisée et sous-réseau filtré) pour limiter le nombre et le type de ports ouverts, et les connexions au réseau principal sont limitées. Pour les applications à plus grande échelle, le serveur Web de réseau de périmètre peut être connecté à un serveur d'applications exécutant la logique métier et les composants d'accès aux données ; ce serveur d'application communique directement avec la base de données principale.

Figure 2. Architecture d'applications de terrain

Pour des raisons de synchronisation de données, un itinéraire plus direct est souvent pris pour limiter la complexité de l'application. Lors de l'utilisation de l'accès RDA ou de la réplication de fusion, l'architecture de synchronisation ressemble davantage à la figure 3. Dans ce cas, les applications clientes se connectent via HTTP à la base de données principale, et les services IIS exposent le point de terminaison HTTP par lequel les communications de synchronisation sont effectuées.

Figure 3. Architecture de synchronisation des applications de terrain

Pour effectuer l'accès aux données côté client, les approches d'accès aux données ADO.NET déconnecté normales peuvent être utilisées, par exemple, en utilisant des DataSets typés et leurs adaptateurs de tableau associés pour lire et écrire les données d'une banque de données SSCE Northwind locale, comme illustré dans l'exemple de code suivant. Comme vous le constatez, le DataSet typé élimine tous les détails de la banque sous-jacente, et ce code consommateur de données n'est pas différent de ce qu'il serait si les données étaient dans SQL Server, SSE ou une autre banque de données accessible par l'intermédiaire d'un fournisseur ADO.NET géré pris en charge. Dans CustomersTableAdapter, les objets SqlCeConnection et SqlCeCommand sont définis par le Concepteur Visual Studio ils effectuent toutes les tâches d'extraction et de mise à jour des données dans la base de données SSCE à l'aide de modèles d'accès aux données ADO.NET normaux.

Exemple de code : Accès aux données en lecture/écriture avec des DataSets typés

        private NorthwindDataSet LoadDataSet()
        {
        NorthwindDataSet nwData = new NorthwindDataSet();
        CustomersTableAdapter adapter = new CustomersTableAdapter();
        adapter.Fill(nwData.Customers);
        return nwData;
        }

        private void SaveChanges(NorthwindDataSet nwData)
        {
        CustomersTableAdapter adapter = new CustomersTableAdapter();
        adapter.Update(nwData);
        }
      

Le groupe SqlCeResultSet permet également un modèle d'accès aux données connecté, comme illustré dans l'exemple de code suivant. Dans cette méthode, une connexion SqlCeConnection et une commande SqlCeCommand sont créées pour extraire une ligne de données (cela fonctionne également avec des groupes de résultats multiligne). Nous ouvrons ensuite la connexion, exécutons la commande pour extraire le groupe SqlCeResultSet et effectuons une mise à jour des enregistrements par son intermédiaire. Dans cet exemple simple, la connexion est fermée par le bloc d'utilisation, mais normalement vous utiliseriez un groupe SqlCeResultSet si vous envisagiez une étendue de code plus longue, et souhaitiez lire et écrire dans la base de données sans devoir ouvrir et fermer la connexion. Dans ce cas, vous ne fermeriez pas la connexion immédiatement après l'utilisation de l'ensemble de résultats : vous la laisseriez ouverte et fermeriez le groupe SqlCeResultSet à la fin de la tâche.

Exemple de code : Accès aux données en lecture/écriture avec SqlCeResultSet

        private void UpdateCompanyName(string custId, string companyName)
        {
        // Set up connection, just need path to sdf file
        SqlCeConnection conn =
        new SqlCeConnection(
        @"Data Source ='.\Northwind.sdf'");

        // Set up select query that brings rows into the result set
        string selQuery =
        "SELECT * FROM Customers WHERE [Customer ID] = @CustID";
        SqlCeCommand getCustCmd = new SqlCeCommand(selQuery, conn);
        getCustCmd.Parameters.Add("@CustID", custId);

        using (conn)
        {
        conn.Open();
        // Pull the row into the result set,
        // using options to allow connected, random, read-write access
        SqlCeResultSet resultSet =
        getCustCmd.ExecuteResultSet(
        ResultSetOptions.Scrollable |
        ResultSetOptions.Updatable);
        // Move to first record
        if (resultSet.ReadFirst())
        {
        // Get the column position
        int ordinal = resultSet.GetOrdinal("Company Name");
        // Set the value
        resultSet.SetString(ordinal, companyName);
        // persist
        resultSet.Update();
        }
        else // No match
        {
        throw new ArgumentException("Customer not found");
        }
        }
        }
      

Applications de gestion des informations personnelles

Les applications de gestion des informations personnelles sont des applications de données simples qui s'exécutent sur des banques de données locales sur les plates-formes mobiles pour faciliter l'accès et le stockage des informations personnelles. Ces applications partagent en général un ou plusieurs des attributs suivants :

• Exécution sur les plates-formes mobiles, y compris les téléphones, PDA, Tablet PC et ordinateurs portables.

• Entrée et recherche de données d'application simples dans les banques de données locales.

• Encombrement minimal pour la disponibilité sur les périphériques mobiles.

Exemples d'applications de gestion des informations personnelles :

• Courrier électronique, messagerie instantanée, contacts, tâches, saisie de notes, stockage et extraction.

• Client de news, agrégation RSS.

• Comptage de calories, gestion du temps, journalisation d'exercice.

• Méthode d'apprentissage de langue, lexique terminologique, dictionnaire, dictionnaire des synonymes.

• Liste d'achat, collection de CD/DVD.

L'architecture de solution pour les applications de gestion des informations personnelles est très simple, comme l'illustre la figure 4. Elle suit un modèle classique de serveur client dans lequel le serveur est un moteur de base de données local sur le périphérique ou sur l'ordinateur portable. Vous pouvez utiliser EDB pour les périphériques mobiles, mais SSCE offre une option simple à utiliser, puissante et légère pour les plates-formes Windows, y compris les périphériques mobiles. Par exemple, SSCE propose une prise en charge de requêtes plus riche qu'EDB, et le développement d'applications est plus facile avec SSCE dans du code géré.

Figure 4. Architecture d'applications de gestion des informations personnelles

Une application de gestion des informations personnelles utilisant SSCE pour un moteur de base de données utilisera probablement l'API SqlCeResultSet pour simplifier l'extraction et le stockage de données. Le code ressemblerait au code du second exemple dans la section précédente.

Applications Web à petite échelle

Pour les sites Web simples avec des prévisions de trafic peu élevé, il n'est pas nécessaire d'acheter des logiciels serveur coûteux ou des contrats d'hébergement plus onéreux impliquant une instance de base de données dans le seul but de disposer d'un site Web dynamique piloté par les données. SSCE et SSE fournissent tous deux une option de stockage dynamique de données simple et gratuite que vous pouvez utiliser pour l'affichage de contenus sur des pages Web. Que le site Web utilise la technologie ASP.NET ou une autre technologie Web capable d'offrir l'accès aux données par un fournisseur OLE DB, les données alimentant les pages du site peuvent être proposées par SSCE ou SSE.

Les applications Web adaptées à SSCE ou SSE sont celles dont la base d'utilisateurs est réduite, c'est-à-dire que le nombre total d'utilisateurs peut être élevé, mais que le nombre de requêtes simultanées par seconde doit être assez réduit.

Exemples d'applications Web adaptées à SSE ou SSCE :

• Sites de clubs ou de loisirs spécialisés avec un faible nombre de membres.

• Petites organisations de groupes d'utilisateurs.

• Applications Web internes pour les petites entreprises.

À moins que l'utilisation prévue de l'application Web soit extrêmement faible avec peu de potentiel d'expansion du nombre d'utilisateurs, SSE constitue en général un meilleur choix pour les applications Web à petite échelle. Si l'application reste une application Web à processus unique avec un nombre très faible de requêtes par heure (< 300 à 500, par exemple), SSCE ou SSE sont capables de gérer le débit nécessaire.

Cependant, à mesure que la complexité de l'application augmente et/ou que le nombre de requêtes par seconde s'accroît, SSE offre de meilleures options d'expansion incrémentielle de l'application pour répondre à l'augmentation des demandes. Comme décrit plus haut dans ce document, SSE prend en charge les procédures stockées, les fonctions et d'autres fonctionnalités de niveau d'entreprise capables de fournir une architecture plus stratifiée et découplée pour les applications complexes. De plus, SSE s'exécutant en tant que service, l'accès simultané des processus d'application Web multiples est mieux pris en charge depuis un même ordinateur ou des ordinateurs différents. SSE propose davantage d'options pour la sécurité basée sur les rôles, et le chemin de mise à niveau vers une version complète de SQL Server est transparent, c'est-à-dire qu'aucune modification du code d'accès aux données n'est requise, car SSE et SQL Server utilisent le même fournisseur de données. Par ailleurs, les formats de fichier pour SSE et SQL Server sont les mêmes : la base de données SSE peut ainsi être connectée à une instance complète de SQL Server, et tout est prêt à l'emploi. La commutation de SSCE à SSE ou à une version complète de SQL Server nécessite une migration des données, ainsi qu'un certain degré de recodage de la logique de données, car SSCE utilise un fournisseur de données différent de SSE ou de SQL Server.

Si vous choisissez d'utiliser SSCE pour les applications Web, un certain degré de configuration est requis pour permettre l'hébergement de SSCE dans le processus d'application Web.

Mise en cache des applications

La mise en cache s'applique aux applications côté client ou aux applications de serveur d'applications qui doivent maintenir un cache de données local des valeurs de recherche ou des données rarement modifiées pour éviter les allers-retours inutiles à la base de données principale. La mise en cache est utilisée pour permettre à l'application d'extraire les données nécessaires de l'ordinateur local afin d'améliorer les performances et de réduire le trafic réseau. La mise en cache des applications inclut l'accès fréquent aux listes d'enregistrements de données relativement statiques utilisées pour les présentations (listes de sélection déroulantes ou listes de référence) ou pour les recherches de serveur d'applications dans la logique métier.

Pour l'extraction de données la plus rapide, les données sont mises en cache en mémoire et directement renvoyées lorsque les valeurs en cache sont requises. Cependant, il se peut que vous ne souhaitiez ou ne puissiez pas actualiser le cache à partir du serveur à chaque redémarrage de l'application, auquel cas une banque de données locale pour les valeurs en cache peut s'avérer nécessaire. De plus, si les listes de valeurs que vous mettez en cache sont très volumineuses, par exemple, un catalogue de produits, vous ne souhaiterez peut-être pas conserver le catalogue entier dans la mémoire d'application car l'accès aux éléments dans la collection n'est que sporadique. Ces raisons peuvent justifier l'utilisation de SSCE en tant qu'emplacement de stockage du cache de données local pour votre architecture.

Les données en cache doivent être initialisées depuis le serveur la première fois que l'application est exécutée ; de même, les données en cache ont souvent une date ou heure d'expiration associée pour l'actualisation de la source. L'expiration associée au cache est déterminée par les exigences de l'application, la fréquence de modification des données et la latence des données en cache pouvant être tolérée par l'application et les utilisateurs.

Lors de la conception d'un cache de données dans une application, vous devez choisir une stratégie de mise en cache des données passive ou active. Avec la mise en cache passive , l'application tente d'obtenir les données nécessaires à partir cache de données local. Si les données ne sont pas présentes, la logique d'application extrait les données du serveur et stocke les résultats dans le cache pour les extractions suivantes. Lorsque le cache devient invalide en raison d'une expiration ou pour une autre raison, l'application doit actualiser le cache depuis la source. Avec la mise en cache active, le cache est actualisé de façon active en fonction de certains critères, tels qu'une actualisation planifiée à partir du serveur. Lorsque vous utilisez une stratégie de mise en cache active, le code d'application est plus simple, car qu'il peut toujours simplement faire référence au cache local pour rechercher ses données. Toutefois, du code supplémentaire est requis pour initialiser le cache actif et le maintenir à jour.

Pour une application de mise en cache, vous souhaiterez peut-être utiliser deux niveaux de mise en cache. Vous souhaiterez peut-être mettre en cache les données dans une banque permanente, telle que SSCE, pour permettre au cache de résider sur l'ordinateur local afin de survivre aux redémarrages d'application ou d'éviter le chargement en mémoire de toutes les données en cache. Cependant, vous pouvez également mettre en cache certaines données du cache permanent dans la mémoire pour fournir l'extraction la plus rapide possible lorsque les données sont requises (par exemple, pour contrôler la logique de saisie semi-automatique dans les zones de texte ou les commandes d'entrée dans les listes déroulantes). Pour ces deux niveaux de mise en cache, vous pouvez utiliser les mêmes stratégies ou des stratégies différentes (actives ou passives).

La figure 5 propose un exemple d'architecture d'application de mise en cache, avec les caches existants dans l'application cliente et le serveur d'applications de niveau intermédiaire. L'application cliente met en cache les données dans la banque SSCE permanente et en mémoire, car la consommation de mémoire est en général moins problématique dans une application cliente. Le cache de serveur d'applications stocke de façon permanente les grandes listes de recherche, telles qu'un catalogue de produits, pour éviter la consommation de mémoire pour des raisons d'évolutivité, mais il évite l'impact sur les performances des allers-retours au serveur de base de données lorsqu'une recherche de catalogue de produits est requise pour localiser les produits dans une certaine fourchette de prix, par exemple. La différence principale entre une application de mise en cache et une application de synchronisation (telle qu'une application de terrain) réside dans le fait que les données ne sont extraites du serveur vers le cache de données locales que dans l'application de mise en cache. Avec la synchronisation, les données du cache sont également synchronisées dans l'autre sens avec les bases de données principales, après l'apport de modifications.

Figure 5. Architecture d'application de mise en cache

Conclusion

De nombreuses applications nécessitent une banque de données fiable, transactionnelle, permanente et efficace, mais ne nécessitent pas nécessairement la gamme complète des fonctionnalités offertes par SQL Server 2005. SSCE fournit un moteur de base de données gratuit, puissant et facile à utiliser que vous pouvez appliquer à un large éventail de scénarios et d'architectures. Il peut être utilisé pour les applications de terrain, les applications de gestion des informations personnelles, les petites applications Web ou la mise en cache des données d'application. Il fournit plusieurs options de synchronisation de données existantes et émergentes lui permettant de faire partie d'une architecture d'application distribuée plus vaste comprenant des bases de données SQL Server 2005 principales. SSCE est l'une des technologies de base de données que vous devez envisager pour toute application requérant une banque de données relationnelles légère.

À propos de l'auteur

Brian Noyes est l'architecte principal d'IDesign (http://www.idesign.net/), une société proposant des services de formation de consultation et de formation sur la conception et l'architecture .NET. Il est directeur régional de Microsoft et MVP Microsoft ; il jouit en outre d'une réputation internationale en tant qu'auteur et conférencier. Son dernier livre, Smart Client Deployment with ClickOnce, qui appartient à la série de développement .NET Addison Wesley, a été publié en décembre 2006. Son livre précédent Data Binding with Windows Forms 2.0 , figure toujours dans les listes des meilleures ventes. Vous pouvez le contacter à l'adresse suivante : brian.noyes@idesign.net ou via son blog à l'adresse :http://www.softinsight.com/bnoyes.

Pour plus d'informations :

https://www.microsoft.com/sql/editions/compact/default.mspx

© Microsoft Corporation. Tous droits réservés.