Apprendre à nous connaître

 

Mary Kirtland
Microsoft Corporation

3 janvier 2001

Bienvenue dans At Your Service, une nouvelle colonne consacrée aux services web.

Les services web fournissent des informations et des services aux applications par le biais d’interfaces programmatiques bien définies basées sur des protocoles Internet standard. Ils sont un élément clé de Microsoft .NET. Naturellement, chez MSDN, nous avons pensé que nous devrions comprendre comment les créer. Non seulement comment appuyer sur les boutons dans Visual Studio, mais également comment créer des services Web évolutifs, hautement disponibles, sécurisés et fiables.

Notre équipe a acquis une expérience précieuse dans la création d’applications web telles que Duwamish Online. Qu’est-ce qui est différent dans la création de services Web ? Quels problèmes rencontrez-vous lorsque d’autres développeurs souhaitent utiliser vos services web dans leurs applications , des applications hébergées sur des systèmes d’exploitation différents, écrites dans différents langages et utilisant différentes implémentations de spécifications clés, telles que SOAP ?

Nous pensons que la seule façon de le savoir est de créer certains services nous-mêmes. Par conséquent, au cours des prochains mois, l’équipe de conseils sur les services web va créer, déployer et exploiter certains exemples de services web. Notre objectif : illustrer les problèmes que vous devez prendre en compte lors de la conception, de l’implémentation, du déploiement et de l’exploitation de vos propres services web. (Nous allons également examiner la consommation de services web!) Nous espérons publier un service web tous les trois mois.

Trois mois, c’est long pour vous faire attendre de nouvelles informations. Ainsi, dans la grande tradition du Journal Duwamish, nous allons utiliser cette colonne pour suivre chaque exemple de projet de la conception à la conception, à l’implémentation et au déploiement. Au moins une fois toutes les deux semaines, nous publierons une entrée de journal afin que vous puissiez suivre avec nous. À mesure que nous terminerons chaque projet, nous publierons nos spécifications, sources et autres artefacts de projet ici sur MSDN. Et vous serez toujours en mesure d’accéder à toutes ces informations à partir de notre nouveau Centre de développement des services web.

Rencontrez l’équipe

L’équipe d’aide aux services web se compose actuellement de six personnes :

• Moi, Mary Kirtland, je suis la cuisinière en chef et goulot d’étranglement ( je veux dire, architecte et gestionnaire de programme) pour l’équipe. Je fais tout sauf coder, tester ou exploiter nos exemples de services. Certains d’entre vous me connaissent peut-être en tant que responsable de programme avec l’équipe OLE/COM/DCOM/MTS/COM+/whatever-you-want-to-call-it. Puis j’ai disparu dans le cône de silence entourant .NET. Il y a environ un an, j’ai compris que j’aime écrire sur la façon d’utiliser les technologies pour créer des applications beaucoup plus que j’aime créer les technologies elles-mêmes. En avril, je suis donc passé à MSDN pour travailler sur ce qui est devenu l’équipe de conseils des services web. Une grande partie de mon temps est consacrée à l’écriture de cette colonne et du contenu pour la page de ressources Services Web. Le reste est consacré à essayer de maintenir les spécifications du projet à jour et à suivre les nouvelles technologies que nous voulons couvrir en cours de route.
• Matt Powell et Scott Seely composent notre équipe de développement. Matt a rejoint l’équipe en octobre à partir du support aux développeurs. Matt a écrit l’écouteur ISAPI dans le kit de ressources SOAP pour Visual Studio 6.0, co-écrit Exécuter Microsoft Information Server 4.0 pour Microsoft Press, et a écrit plusieurs articles pour MSDN Magazine et ses prédécesseurs, MSJ et MIND.
  Scott a rejoint Microsoft et notre équipe en décembre après avoir passé les cinq dernières années dans le monde réel à créer des applications réelles avec des produits Microsoft. Dans son temps libre copieux, il a écrit des articles pour le Windows Developer’s Journal ainsi qu’un livre intitulé Windows Shell Programming. Quand il ne travaille pas sur notre service d’exemple, il travaille sur un livre sur SOAP.
  Vous pouvez vous attendre à voir Matt et Scott écrire des articles sur le côté dev des choses dans les mois à venir.
• Notre équipe de test se compose de Jan McCollum et Jim Francisco. Jan s’est joint à nous en octobre en tant que responsable du test et a travaillé dur à la création d’un plan de test pour notre premier projet. Jim nous a rejoints en décembre et travaille sur les tests unitaires et l’automatisation des tests. Jim a travaillé au sein de l’équipe de test de mise en réseau de Windows 98 et de l’équipe de test de mise en production de Microsoft Host Integration Server. Il est arrivé dans notre équipe après un passage dans le monde des points-com en développant des outils de déploiement et d’administration pour des applications web à n niveaux. Nous allons essayer de les amener à écrire des articles sur le test des services web lorsque nous serons un peu plus loin.
• Bronwyn Calsyn est notre responsable des opérations. Bronwyn a commencé en novembre et a été occupé à essayer de déterminer l’équipement dont nous avons besoin pour déployer nos exemples de services en direct sur Internet, ainsi que les procédures opérationnelles dont nous avons besoin pour assurer le bon fonctionnement des choses. Nous allons essayer de lui faire écrire des articles sur le côté du déploiement et des opérations.

Présentation du service Favoris

Notre premier projet est le service Favoris. En tant qu’utilisateurs passionnés du Web, nous reconnaissons que l’un des problèmes auxquels sont confrontés les utilisateurs finaux est de localiser les pages qu’ils ont déjà visitées, en particulier sur des sites dynamiques tels que MSDN Online ou des sites d’actualités où les articles ne sont pas accessibles à partir de la première page pendant plus de quelques jours. Bien que vous puissiez utiliser les favoris du navigateur pour effectuer le suivi des pages favorites, les favoris du navigateur sont locaux sur un ordinateur spécifique. Mais que se passe-t-il si vous utilisez plusieurs machines ou appareils ? Ne serait-il pas agréable que les favoris puissent être stockés sur un serveur quelque part, facilement accessible à partir de n’importe quel ordinateur que vous utilisez ?

C’est exactement ce que fait le service Favoris. Il permet aux sites web de stocker des liens vers les pages Web favorites d’un utilisateur final. Maintenant, vous pourriez penser que cela ne ressemble pas à un service très compliqué. Et du point de vue de la logique métier, ce n’est pas le cas. Cela signifie que nous n’aurons pas à consacrer beaucoup de temps à expliquer la logique métier et que vous n’aurez pas beaucoup de code spécifique à l’application pour trouver des techniques que vous pouvez utiliser dans vos propres services Web. Mais nous avons rencontré un certain nombre de problèmes intéressants avec le service, des problèmes auxquels de nombreux autres développeurs que nous avons rencontrés sont également en cours d’exécution.

Nos premières colonnes se concentrent sur les problèmes que nous avons rencontrés pendant la phase de conception du projet. Voici quelques-unes des rubriques que nous examinons :

• Protection de la confidentialité des utilisateurs. Une application dans le monde doit-elle être en mesure d’interroger ou de modifier les favoris de chaque utilisateur final, quelle que soit l’application qui a enregistré les favoris en premier lieu ?
• Licences. Si chaque application ne peut pas accéder aux favoris de tous les utilisateurs finaux, comment contrôler l’accès au service ? Devons-nous facturer de l’argent pour le service? Quels sont les modèles d’entreprise qui ont un sens ?
• Authentification et autorisation. Si nous voulons restreindre l’accès au service, comment authentifier les applications clientes et décider de ce qu’elles sont autorisées à faire ? Comment identifier les utilisateurs finaux de toute façon ?
• Estimation des exigences de performances. Comment déterminer le type de charge auquel notre service sera soumis ? Pouvons-nous utiliser les mêmes méthodes que celles que nous utiliserions pour estimer la charge sur un site Web ? Comment déterminer le type de temps de réponse et de disponibilité que nos clients demanderont ?
• Exigences des titulaires de licence pour le développement, le test et les opérations. Si nous limitons l’accès au service, en facturant peut-être de l’argent en fonction de l’utilisation, comment les développeurs et testeurs d’applications clientes essaient-ils les applications qui s’appuient sur notre service ? Comment éviter d’affecter les magasins de données de production ? De quels types d’outils le personnel de test et d’exploitation de nos clients a-t-il besoin pour résoudre un problème dans leurs applications ou dans notre service ? Quel type de documentation devons-nous fournir ?
• Mondialisation. Que devons-nous faire pour nous assurer que les applications clientes du monde entier peuvent utiliser notre service web ?
• Facilité de gestion. De quel type d’information notre personnel des opérations a-t-il besoin pour gérer notre service Web ? Comment collectons-nous ces informations et les présentons aux outils de gestion ?

S’il y a d’autres sujets que vous souhaitez voir couverts, veuillez nous envoyer un e-mail à l’adresse wsgmsdn@microsoft.com. Notez qu’à l’heure actuelle, nous ne pouvons pas répondre par le biais des commentaires de l’utilisateur sur cette page. Toutefois, nous lisons régulièrement les commentaires. Si nous pouvons déterminer ce que vos commentaires ont à voir avec notre contenu, nous verrons ce que nous pouvons faire pour résoudre votre problème dans une prochaine colonne.

La semaine prochaine, nous examinerons les problèmes que nous avons rencontrés lors de la définition de la vision du projet de service Favoris. Rendez-vous alors !