Freigeben über

Kennenlernen

  • Artikel

 

Mary Kirtland
Microsoft Corporation

3. Januar 2001

Willkommen bei At Your Service, einer neuen Spalte, die den Webdiensten gewidmet ist.

Webdienste stellen Informationen und Dienste für Anwendungen über klar definierte programmgesteuerte Schnittstellen bereit, die auf Standard-Internetprotokollen basieren. Sie sind ein wichtiger Bestandteil von Microsoft .NET. Natürlich dachten wir von MSDN, dass wir verstehen sollten, wie sie erstellt werden. Nicht nur, wie Sie die Schaltflächen in Visual Studio drücken, sondern auch, wie Sie skalierbare, hochverfügbare, sichere und zuverlässige Webdienste erstellen.

Unser Team hat wertvolle Erfahrung beim Erstellen von Webanwendungen wie Duwamish Online gesammelt. Was ist anders beim Erstellen von Webdiensten? Welche Probleme führen Sie aus, wenn andere Entwickler Ihre Webdienste in ihren Anwendungen verwenden möchten– Anwendungen, die auf unterschiedlichen Betriebssystemen gehostet werden, in verschiedenen Sprachen geschrieben sind und unterschiedliche Implementierungen von Schlüsselspezifikationen wie SOAP verwenden?

Wir finden die einzige Möglichkeit, dies herauszufinden, darin, einige Dienste selbst zu erstellen. Daher wird das Leitfadenteam für Webdienste in den nächsten Monaten einige Beispielwebdienste erstellen, bereitstellen und betreiben. Unser Ziel: Veranschaulichung der Probleme, die Sie beim Entwerfen, Implementieren, Bereitstellen und Betreiben Ihrer eigenen Webdienste berücksichtigen müssen. (Wir sehen uns auch die Nutzung von Webdiensten an!) Wir hoffen, alle drei Monate einen Webdienst zu veröffentlichen.

Drei Monate sind jedoch eine lange Zeit, um auf neue Informationen zu warten. In der großen Tradition des Duwamish Diary werden wir diese Spalte verwenden, um jedes Beispielprojekt von der Konzeption über das Design, die Implementierung und die Bereitstellung zu verfolgen. Mindestens einmal alle zwei Wochen posten wir einen Tagebucheintrag, damit Sie uns folgen können. Während wir jedes Projekt abschließen, veröffentlichen wir unsere Spezifikationen, Quellen und andere Projektartefakte hier auf MSDN. Und Sie werden immer in der Lage sein, auf all diese Informationen aus unserem neuen Web Services Developer Center zuzugreifen.

Lernen Sie das Team kennen

Das Leitfadenteam für Webdienste besteht derzeit aus sechs Personen:

  • Ich, Mary Kirtland, bin der Chefkoch und Engpass – ich meine, Architekt und Programmmanager – für das Team. Ich mache vor allem alles, außer coden, testen oder betreibe unsere Beispieldienste. Einige von Ihnen kennen mich vielleicht aus meiner Zeit als Programmmanager mit dem OLE/COM/DCOM/MTS/COM+/whatever-you-want-to-call-it-Team. Dann verschwand ich in dem Kegel der Stille um .NET. Vor etwa einem Jahr habe ich herausgefunden, dass ich viel mehr spaße, über die Verwendung von Technologien zum Erstellen von Apps zu schreiben, als dass ich die Technologien selbst gerne erstelle. Daher bin ich im April zu MSDN gewechselt, um an dem zu arbeiten, was zum Leitfadenteam für Webdienste geworden ist. Ein Großteil meiner Zeit widmet sich dem Schreiben dieser Spalte und des Inhalts für die Web Services-Ressourcenseite. Der Rest wird damit verbracht, die Projektspezifikationen auf dem neuesten Stand zu halten und den Überblick über neue Technologien zu behalten, die wir auf dem Weg abdecken möchten.
  • Matt Powell und Scott Seely bilden unser Entwicklungsteam. Matt trat dem Team im Oktober vom Entwicklersupport bei. Matt schrieb den ISAPI-Listener im SOAP-Toolkit für Visual Studio 6.0, schrieb zusammen mit Ausführen von Microsoft Information Server 4.0 für Microsoft Press und hat mehrere Artikel für MSDN Magazine und seine Vorgänger msj und MIND geschrieben.
    Scott kam im Dezember zu Microsoft und unserem Team, nachdem er die letzten fünf Jahre damit verbracht hatte, echte Apps mit Microsoft-Produkten zu entwickeln. In seiner freizeit hat er Artikel für Windows Developer es Journal sowie ein Buch mit dem Titel Windows Shell Programming geschrieben. Wenn er nicht an unserem Beispieldienst arbeitet, arbeitet er an einem Buch über SOAP.
    Sie können erwarten, dass Matt und Scott in den kommenden Monaten Artikel über die Entwicklungsseite von Dingen schreiben.
  • Unser Testteam besteht aus Jan McCollum und Jim Francisco. Jan kam im Oktober als Testleiter zu uns und hat hart daran gearbeitet, einen Testplan für unser erstes Projekt zu erstellen. Jim kam im Dezember zu uns und arbeitet an Komponententests und Testautomatisierung. Jim arbeitete im Windows 98-Netzwerktestteam und im Build-/Releasetestteam von Microsoft Host Integration Server. Er kam zu unserem Team, nachdem er in der dot-com-Welt bereitstellungs- und Verwaltungstools für n-tier-Webanwendungen entwickelt hatte. Wir versuchen, sie dazu zu bringen, einige Artikel zum Testen von Webdiensten zu schreiben, wenn wir etwas weiter entfernt sind.
  • Bronwyn Calsyn ist unser Betriebsleiter. Bronwyn begann im November und war damit beschäftigt herauszufinden, welche Ausrüstung wir benötigen, um unsere Beispieldienste live im Internet bereitzustellen, zusammen mit den Betriebsabläufen, die wir benötigen, um den reibungslosen Ablauf zu halten. Wir werden versuchen, sie dazu zu bringen, auch einige Artikel über die Bereitstellungs- und Betriebsseite zu schreiben.

Einführung in den Favoritendienst

Unser erstes Projekt ist der Favoritendienst. Als begeisterte Webbenutzer erkennen wir, dass eines der Probleme, mit denen Endbenutzer konfrontiert sind, darin besteht, Seiten zu finden, die sie zuvor besucht haben – insbesondere auf dynamischen Websites wie MSDN Online oder Nachrichtenwebsites, auf denen Artikel seit mehr als ein paar Tagen nicht mehr von der Startseite aus zugänglich sind. Während Sie Browserfavoriten verwenden können, um favoriten nachzuverfolgen, sind Browserfavoriten lokal auf einem bestimmten Computer. Aber was ist, wenn Sie mehrere Computer oder Geräte verwenden? Wäre es nicht schön, wenn die Favoriten irgendwo auf einem Server gespeichert werden könnten, von welchem Computer Sie gerade verwendet haben?

Dies ist genau das, was der Favoritendienst tut. Es ermöglicht Websites, Links zu den bevorzugten Webseiten eines Endbenutzers zu speichern. Nun denken Sie vielleicht, dass dies nicht nach einem sehr komplizierten Dienst klingt. Aus sicht der Geschäftslogik ist dies nicht der Fall. Dies bedeutet, dass wir nicht viel Zeit damit verbringen müssen, die Geschäftslogik zu erläutern, und Sie haben nicht viel anwendungsspezifischen Code, um Techniken zu finden, die Sie in Ihren eigenen Webdiensten verwenden können. Wir haben jedoch eine Reihe von interessanten Problemen mit dem Dienst festgestellt– Probleme, mit denen viele andere Entwickler, mit denen wir gesprochen haben, ebenfalls auftreten.

Unsere ersten Spalten konzentrieren sich auf die Probleme, die während der Entwurfsphase des Projekts aufgetreten sind. Einige der Themen, die wir berücksichtigen:

  • Schutz der Privatsphäre von Benutzern. Sollte jede Anwendung weltweit in der Lage sein, die Favoriten jedes Endbenutzers abzufragen oder zu bearbeiten, unabhängig davon, welche Anwendung die Favoriten überhaupt gespeichert hat?
  • entschieden haben. Wie steuern wir den Zugriff auf den Dienst, wenn nicht jede Anwendung auf alle Favoriten des Endbenutzers zugreifen kann? Sollten wir Geld für den Dienst in Rechnung stellen? Welche Geschäftsmodelle sind sinnvoll?
  • Authentifizierung und Autorisierung: Wie authentifizieren wir Clientanwendungen, wenn wir den Zugriff auf den Dienst einschränken möchten, und wie entscheiden wir, wofür sie autorisiert sind? Wie identifizieren wir Endbenutzer trotzdem?
  • Schätzen der Leistungsanforderungen. Wie können wir herausfinden, welcher Art von Last unser Dienst ausgesetzt sein wird? Können wir die gleichen Methoden verwenden, die wir zum Schätzen der Auslastung einer Website verwenden würden? Wie bestimmen wir, welche Art von Antwortzeiten und Verfügbarkeit unsere Kunden verlangen werden?
  • Anforderungen des Lizenznehmers aus Entwicklung, Test und Betrieb. Wie testen Entwickler und Tester von Clientanwendungen, die auf unserem Dienst basieren, wenn wir den Zugriff auf den Dienst einschränken und ggf. Geld auf Grundlage der Nutzung berechnen? Wie können sie Auswirkungen auf Produktionsdatenspeicher vermeiden? Welche Art von Tools benötigen die Test- und Betriebsmitarbeiter unserer Kunden, um zu helfen, ein Problem in ihren Anwendungen oder unserem Dienst zu beheben? Welche Art von Dokumentation sollten wir bereitstellen?
  • Globalisierung. Was müssen wir tun, um sicherzustellen, dass Clientanwendungen auf der ganzen Welt unseren Webdienst verwenden können?
  • Verwaltbarkeit. Welche Informationen benötigen unsere Betriebsmitarbeiter, um unseren Webdienst zu verwalten? Wie sammeln wir diese Informationen und stellen sie den Verwaltungstools zur Verfügung?

Wenn es andere Themen gibt, die Sie behandelt sehen möchten, senden Sie uns eine E-Mail an wsgmsdn@microsoft.com. Beachten Sie, dass wir derzeit nicht über die Benutzerkommentare auf dieser Seite antworten können. Wir lesen die Kommentare jedoch regelmäßig. Wenn wir herausfinden können, was Ihre Kommentare mit unserem Inhalt zu tun haben, sehen wir in einer zukünftigen Spalte, was wir tun können, um Ihr Problem zu beheben.

Nächste Woche sehen wir uns die Probleme an, die beim Definieren der Vision für das Favorites Service-Projekt aufgetreten sind. Wir sehen uns an!