Partager via


Vue d'ensemble de Service Bus for Windows Server 1.1

Mis à jour: octobre 2013

S'applique à: Service Bus for Windows Server 1.1

Service Bus pour Windows Server est un ensemble de composants installables qui fournit les fonctionnalités de messagerie de Service Bus de Windows Azure dans Windows Server. Service Bus pour Windows Server vous permet de générer, de tester et d'exécuter des applications à couplage souple et pilotées par des messages dans des environnements auto-gérés et sur des ordinateurs de développement.

L'objectif de Service Bus pour Windows Server est de fournir des fonctionnalités similaires au sein de Windows Azure et de Windows Server, et d'assurer la flexibilité lors du développement et du déploiement d'applications. Il est basé sur la même architecture que le service nuage Service Bus et fournit des fonctionnalités de montée en charge et de résilience. Le modèle de programmation, la prise en charge de Visual Studio et les API exposées pour le développement d'applications sont similaires à ceux du service cloud, ce qui facilite le développement d'applications pour une utilisation locale ou dans le nuage, ou pour passer de l'une à l'autre. À l'avenir, l'expérience utilisateur en matière de gestion sur le portail de gestion Azure sera cohérente entre les versions locales et dans le nuage.

Scénarios pour Service Bus pour Windows Server

  • Développez en local, déployez dans le nuage. Ce scénario courant permet aux développeurs d'applications dans le nuage de développer et de tester des applications en local dans un environnement de développement pouvant être installé sur un ordinateur de bureau ou un ordinateur portable. Pour faciliter le travail des développeurs d'applications dans le nuage, Service Bus pour Windows Server peut être installé sur un système d'exploitation client (Windows 7 ou 8, 64 bits) et utiliser les éditions de SQL Express (SQL Express 2008 R2 SP1 ou versions ultérieures). En outre, Service Bus pour Windows Server peut être configuré pour utiliser des comptes locaux (plutôt que des comptes de domaine) afin de permettre d'effectuer le développement sur un ordinateur non associé au domaine ou en mode hors connexion.

  • Déploiement souple. Les fournisseurs de logiciels offrant leurs solutions à un grand nombre de clients souhaitent pouvoir déployer leurs solutions en tant qu'applications dans le nuage, ou les distribuer à leurs clients pour leur permettre de les déployer local. De la même façon, les entreprises souhaitent avoir le choix pour le déploiement de l'application. Pour prendre en charge ce scénario, Service Bus pour Windows Server offre une symétrie avec Service Bus de Windows Azure (l'offre Microsoft PaaS), ainsi qu'une prise en charge d'IaaS. La symétrie commence avec l'ensemble de fonctionnalités prises en charge (la messagerie répartie figure uniquement dans cette version), le même Kit de développement logiciel (SDK) et la prise en charge d'une chaîne de connexion configurable permettant aux clients de modifier leur option de déploiement sans avoir à générer à nouveau la solution.

  • Publication-abonnement sur site. Pour les entreprises développant des services et des applications, Service Bus pour Windows Server fournit une couche MOM (Messaging Oriented Middleware), avec un riche ensemble de fonctionnalités de publication et d'abonnement. Pour prendre en charge ce scénario, Service Bus pour Windows Server fournit des fonctionnalités telles qu'une disponibilité élevée, une évolutivité et une authentification Windows basée sur des jetons (prise en charge d'Active Directory).

Fonctionnalités de messagerie dans Service Bus pour Windows Server

Service Bus pour Windows Server prend en charge la même fonctionnalité de messagerie répartie que Service Bus de Windows Azure. Les files d'attente Service Bus offrent un stockage et une récupération des messages fiables avec un large choix de protocoles et d'API.

Files d'attente Service Bus

Les files d'attente Service Bus fournissent un nivellement de la charge en permettant aux destinataires des messages de traiter ceux-ci à leur propre rythme. En outre, les files d'attente Service Bus fournissent un équilibrage de la charge grâce aux multiples récepteurs concurrents acceptant des messages de la même file d'attente. Pour plus d'informations sur le sujet suivant Service Bus les files d'attentes, consultez la rubrique Utilisation des files d'attente Service Bus.

Rubriques Service Bus

En plus des fonctionnalités de files d'attente, les rubriques et abonnements Service Bus offrent de riches fonctionnalités de publication et d'abonnement permettant à plusieurs abonnés concurrents de récupérer de façon indépendante des vues filtrées ou non filtrées du flux de messages publiés. Pour plus d'informations sur le sujet suivant Service Bus les rubriques, consultez la rubrique Utilisation des rubriques et abonnements Service Bus.

Options de déploiement et de gestion dans Service Bus for Windows Server

Service Bus pour Windows Server prend en charge deux méthodes de déploiement, autorisant ainsi différents scénarios.

  • Service Bus version exécutable uniquement (autonome) : Dans ce scénario de déploiement, un administrateur unique déploie et gère la batterie de serveurs Service Bus, et crée les espaces de noms. Toutes les opérations de gestion sont prises en charge au moyen de commandes PowerShell et il n'y a pas d'interface utilisateur (à l'exception de l'Assistant Configuration Service Bus pour la configuration initiale).

  • Intégration de Service Bus à Windows Azure Pack : Dans ce scénario de déploiement, l'administrateur gère Service Bus au moyen du portail Windows Azure Pack, en déployant et gérant la batterie de serveurs réelle (nuage). Les locataires Service Bus utilisent également le portail pour créer des espaces de noms et des entités de messagerie. L'expérience du portail est similaire à celle dans Azure.

Utilisez le déploiement autonome Service Bus (pas de portail) lorsqu'un locataire unique gère les ressources Service Bus au moyen de cmdlets PowerShell et d'API Service Bus.

Utilisez l'intégration Service Bus avec Windows Azure Pack lorsque vous souhaitez une expérience de gestion similaire à celle offerte par le nuage, ou lorsque vous voulez faire bénéficier vos locataires d'une partie de l'expérience de gestion. L'intégration de Service Bus dans Windows Azure Pack permet également de prendre en charge la gestion de plusieurs batteries de serveurs Service Bus (nuages) à partir d'un portail unique. C'est parfois le cas pour les entreprises et hôtes de grande taille souhaitant offrir des ressources (messagerie) à plusieurs clients (différentes équipes dans une entreprise ou pour les hôtes, différentes entreprises).

La décision de déployer Service Bus dans un environnement géré ou non géré a un impact sur la procédure de déploiement. Pour plus d'informations, consultez le guide Premiers pas avec Service Bus for Windows Server 1.1.

Notes

Service Bus pour Windows Server 1.0 offrait uniquement une version non gérée de Service Bus. L'intégration de Windows Azure Pack est une nouvelle fonctionnalité de la version Service Bus pour Windows Server 1.1.

Pour plus d'informations sur le sujet suivant Windows Azure Pack, cliquez ici.

Le tableau suivant répertorie les principales différences entre les deux possibilités.

Zone Version exécutable de Service Bus uniquement Intégration de Service Bus à Windows Azure Pack

Service Bus déploiement

Configuration au moyen de WebPI.

Configuration au moyen de l'Assistant Configuration ou de PowerShell.

  • Configuration au moyen de WebPI

  • Configuration au moyen de l'Assistant Configuration ou de PowerShell.

  • Lors de la création d'une batterie de serveurs, spécifiez les informations d'identification utilisées par le portail de gestion.

Créer une offre Service Bus (un plan)

Non pris en charge.

  • Au moyen du portail d'administrateurs Windows Azure, créez un plan qui offre Service Bus (en plus d'autres ressources telles que la gestion de l'ordinateur virtuel).

Création d'espace de noms

L'administrateur de la batterie de serveurs crée des espaces de noms et affecte des propriétaires.

  • Une fois qu'un administrateur crée un plan, les locataires peuvent se connecter au portail locataire Windows Azure Pack et créer des abonnements au moyen du plan.

  • Une fois qu'un abonnement est créé, un locataire peut créer un espace de noms Service Bus au moyen du portail Windows Azure Pack.

Service Bus gestion des entités

Utilisation du Kit de développement logiciel Service Bus (basé sur .NET ou REST).

  • Une fois qu'un espace de noms est créé, les locataires peuvent utiliser le portail Windows Azure Pack pour créer des entités Service Bus (files d'attente, rubriques et abonnements), similaires à Azure.

  • Remarque : Vous pouvez également continuer à utiliser le Kit de développement logiciel (SDK) Service Bus.

Prise en charge de plusieurs batteries de serveurs

Chaque batterie de serveurs est gérée séparément.

  • Un portail Windows Azure Pack unique peut prendre en charge plusieurs batteries de serveurs Service Bus pour Windows Server.

  • Les locataires peuvent créer plusieurs abonnements au moyen de ressources provenant de plusieurs batteries de serveurs, figurant toutes au sein d'un portail locataire Windows Azure Pack unique.

Fonctionnalités de plate-forme dans Service Bus pour Windows Server

Service Bus pour Windows Server offre une plate-forme de messagerie pour les applications d'entreprise avec une topologie de batterie de serveurs à hôtes multiples fournissant à la fois une évolutivité et une haute disponibilité. La plate-forme est basée sur Windows Server et Microsoft SQL Server. Les développeurs souhaitant un environnement de développement léger peuvent installer Service Bus pour Windows Server sur des systèmes d'exploitation clients Windows (64 bits) et Microsoft SQL Express.

Vous pouvez déployer Service Bus pour Windows Server dans un environnement hébergé tels que des machines virtuelles Azure au moyen d'une base de données Microsoft SQL hébergée ou de Base de données SQL Windows Azure (IaaS). Pour plus d'informations sur le sujet suivant les plates-formes prises en charge, consultez la rubrique Supported Topologies.

Comparaison entre Service Bus pour Windows Server et Service Bus de Windows Azure

Bien qu'il y ait une symétrie entre Service Bus pour Windows Server et Service Bus de Windows Azure dans les API et les fonctionnalités de messagerie, il y a des différences entre les deux produits Service Bus.

  • En ce qui concerne la facilité de gestion, dans un environnement Platform As A Service (Windows Azure), le fournisseur PaaS (Microsoft) fournit la gestion. Avec Service Bus pour Windows Server, l'administrateur local déploie, sécurise, met à l'échelle et surveille la batterie de serveurs Service Bus pour Windows Server.

  • Aussi bien dans Windows Azure que dans Windows Server, Service Bus requiert des jetons d'accès autorisant l'accès aux entités de messagerie associées. Tous deux partagent le schéma d'authentification SAS (Shared Access Secrets) pour les espaces de noms Service Bus ainsi que pour les entités (files d'attente et rubriques). Toutefois, dans Windows Azure, Service Bus prend également en charge le Active Directory Access Control de Windows Azure (également appelé Access Control Service ou ACS), qui n'est pas disponible dans Windows Server. Toutefois, dans Windows Server, Service Bus prend en charge l'authentification intégrée Windows (les utilisateurs associés au domaine et les groupes d'utilisateurs Active Directory), qui ne sont pas disponibles dans Azure.

  • Bien que des quotas et d'autres paramètres d’exécution soient fixés dans Service Bus de Windows Azure, avec Service Bus pour Windows Server un administrateur peut modifier ces paramètres et personnaliser la batterie de serveurs Service Bus pour Windows Server.

  • Le schéma d'adressage est fixé dans Service Bus de Windows Azure. En d'autres termes, le suffixe Service Bus est ajouté à l'URL de tous les points de terminaison. Avec Service Bus pour Windows Server, vous pouvez utiliser le nom de domaine complet des hôtes ou une entrée DNS mappée représentant votre service.

Date de génération :

2014-04-18