Uzyskiwanie informacji o nas

 

Mary Kirtland
Microsoft Corporation

3 stycznia 2001 r.

Witamy w twojej usłudze— nowa kolumna poświęcona usługom internetowym.

Usługi sieci Web zapewniają aplikacjom informacje i usługi za pośrednictwem dobrze zdefiniowanych interfejsów programowych opartych na standardowych protokołach internetowych. Są one kluczową częścią platformy Microsoft .NET. Oczywiście w witrynie MSDN myśleliśmy, że powinniśmy zrozumieć, jak je zbudować. Nie tylko jak naciskać przyciski w programie Visual Studio, ale jak tworzyć skalowalne, wysoce dostępne, bezpieczne, niezawodne usługi sieci Web.

Nasz zespół zyskał cenne doświadczenie w tworzeniu aplikacji internetowych, takich jak Duwamish Online. Co różni się od kompilowania usług sieci Web? Jakie problemy są uruchamiane, gdy inni deweloperzy chcą korzystać z usług sieci Web w swoich aplikacjach — aplikacje hostowane w różnych systemach operacyjnych, napisane w różnych językach i korzystając z różnych implementacji kluczowych specyfikacji, takich jak SOAP?

Uważamy, że jedynym sposobem, aby dowiedzieć się, jest zbudowanie niektórych usług. W ciągu najbliższych kilku miesięcy zespół wskazówek usług sieci Web będzie kompilować, wdrażać i obsługiwać niektóre przykładowe usługi sieci Web. Naszym celem: aby zilustrować problemy, które należy wziąć pod uwagę podczas projektowania, implementowania, wdrażania i obsługi własnych usług sieci Web. (Przyjrzymy się też używaniu usług sieci Web!) Mamy nadzieję, że co trzy miesiące wydamy jedną usługę internetową.

Trzy miesiące to długi czas, aby poczekać na nowe informacje. Tak więc w wielkiej tradycji Diary Duwamish będziemy używać tej kolumny do naśladowania każdego przykładowego projektu od koncepcji poprzez projektowanie, implementację i wdrażanie. Co najmniej raz na dwa tygodnie opublikujemy wpis w pamiętniku, aby móc śledzić z nami. Po ukończeniu każdego projektu opublikujemy tutaj nasze specyfikacje, źródła i inne artefakty projektu w witrynie MSDN. Zawsze będziesz mieć dostęp do wszystkich tych informacji z naszego nowego Centrum deweloperów usług internetowych.

Poznaj zespół

Zespół wskazówek dotyczących usług internetowych obecnie składa się z sześciu osób:

• Ja, Mary Kirtland, jestem głównym kucharzem i wąskim gardłem — mam na myśli, architekta i menedżera programu — dla zespołu. Robię większość wszystkich elementów, ale kod, testowanie lub obsługę naszych przykładowych usług. Niektórzy z was mogą znać mnie od moich dni jako menedżer programu z OLE/COM/DCOM/MTS/COM+/whatever-you-want-to-call-it zespołu. Potem zniknąłem w stożku ciszy wokół platformy .NET. Około roku temu dowiedziałem się, że lubię pisać o tym, jak używać technologii do tworzenia aplikacji o wiele więcej niż lubię tworzyć same technologie. Więc w kwietniu przeniosłem się do MSDN, aby pracować nad tym, co stało się zespołem wskazówek dotyczących usług internetowych. Większość mojego czasu poświęcona jest pisaniu tej kolumny i zawartości na stronie zasobów usług sieci Web. Reszta jest wydana, starając się zachować aktualność specyfikacji projektu i śledzić nowe technologie, które chcemy pokryć w dół drogi.
• Matt Powell i Scott Seely tworzą nasz zespół programistyczny. Matt dołączył do zespołu w październiku z działu pomocy technicznej dla deweloperów. Matt napisał odbiornik ISAPI w zestawie narzędzi SOAP Toolkit for Visual Studio 6.0, coauthored Running Microsoft Information Server 4.0 for Microsoft Press, i napisał kilka artykułów dla MSDN Magazine i jego poprzedników, MSJ i MIND.
  Scott dołączył do firmy Microsoft i naszego zespołu w grudniu po spędzeniu ostatnich pięciu lat w świecie rzeczywistym tworzenia rzeczywistych aplikacji z produktami firmy Microsoft. W swoim żmudnym wolnym czasie napisał artykuły dla Windows Developer's Journal , a także książkę zatytułowaną Windows Shell Programming. Kiedy nie pracuje nad naszą usługą przykładową, pracuje nad książką o soap.
  Możesz się spodziewać, że Matt i Scott piszą artykuły o stronie deweloperów rzeczy w nadchodzących miesiącach.
• Nasz zespół testowy składa się z Jan McCollum i Jim Francisco. Jan dołączył do nas w październiku jako nasz lider testowy i był trudny w pracy nad planem testowym dla naszego pierwszego projektu. Jim dołączył do nas w grudniu i pracuje nad testami jednostkowym i automatyzacją testów. Jim pracował nad zespołem testowym systemu Windows 98 Networking i zespołem testowym kompilacji/wydania programu Microsoft Host Integration Server. Przyszedł do naszego zespołu po przejściu w świecie dot-com opracowując narzędzia wdrażania i administrowania dla aplikacji sieci Web n-warstwowej. Spróbujemy je uzyskać, aby napisać kilka artykułów na temat testowania usług internetowych, gdy jesteśmy nieco dalej.
• Bronwyn Calsyn jest naszym menedżerem operacyjnym. Bronwyn rozpoczął się w listopadzie i był zajęty próbą ustalenia, jaki sprzęt musimy wdrożyć nasze przykładowe usługi na żywo w Internecie, wraz z procedurami operacyjnymi, które musimy zachować sprawnie. Spróbujemy ją również napisać kilka artykułów o stronie wdrażania i operacji.

Wprowadzenie do usługi Ulubione

Naszym pierwszym projektem jest usługa Ulubione. Jako zapaleni użytkownicy sieci Web wiemy, że jednym z problemów, z którymi borykają się użytkownicy końcowi, jest lokalizowanie stron, które wcześniej odwiedziły — szczególnie w witrynach dynamicznych, takich jak MSDN Online, lub w witrynach informacyjnych, w których artykuły nie są dostępne z pierwszej strony przez ponad kilka dni. Chociaż możesz użyć ulubionych przeglądarki, aby śledzić ulubione strony, ulubione przeglądarki są lokalne dla określonej maszyny. Ale co zrobić, jeśli używasz wielu maszyn lub urządzeń? Czy nie byłoby miło, gdyby ulubione mogły być przechowywane na serwerze gdzieś, łatwo uzyskiwany dostęp z niezależnie od tego, której maszyny używasz?

Jest to dokładnie to, co robi usługa Ulubione. Umożliwia ona witrynom sieci Web przechowywanie linków do ulubionych stron sieci Web użytkownika końcowego. Teraz możesz pomyśleć, że nie brzmi to jak bardzo skomplikowana usługa. A z perspektywy logiki biznesowej nie jest. Oznacza to, że nie będziemy musieli poświęcać dużo czasu na wyjaśnienie logiki biznesowej i nie będziesz mieć dużo kodu specyficznego dla aplikacji, aby poznać techniki, których można użyć we własnych usługach sieci Web. Napotkaliśmy jednak wiele interesujących problemów z usługą — problemy, z którymi rozmawialiśmy wielu innych deweloperów, którzy rozmawialiśmy, są również uruchomione w usłudze .

W pierwszych kilku kolumnach skupimy się na problemach, które napotkaliśmy w fazie projektowania projektu. Niektóre tematy, które rozważamy:

• Ochrona prywatności użytkowników. Czy każda aplikacja na świecie powinna mieć możliwość wykonywania zapytań lub edytowania ulubionych każdego użytkownika końcowego, niezależnie od tego, która aplikacja zapisała ulubione w pierwszej kolejności?
• Licencjonowania. Jeśli każda aplikacja nie może uzyskać dostępu do wszystkich ulubionych użytkownika końcowego, jak kontrolować dostęp do usługi? Czy powinniśmy pobierać opłaty za usługę? Które modele biznesowe mają sens?
• Uwierzytelnianie i autoryzacja. Jeśli ograniczymy dostęp do usługi, w jaki sposób uwierzytelniamy aplikacje klienckie i decydujemy o tym, co są autoryzowane? Jak mimo to identyfikować użytkowników końcowych?
• Szacowanie wymagań dotyczących wydajności. Jak ustalić, jakiego rodzaju obciążenie usługi zostanie poddane? Czy możemy użyć tych samych metod, których będziemy używać do szacowania obciążenia w witrynie sieci Web? Jak określić, jakiego rodzaju czasy odpowiedzi i dostępność będą wymagać nasi klienci?
• Wymagania licencyjne dotyczące programowania, testowania i operacji. Jeśli ograniczamy dostęp do usługi, może pobieramy pieniądze na podstawie użycia, jak deweloperzy aplikacji klienckich i testerzy wypróbowywują aplikacje, które opierają się na naszej usłudze? Jak można uniknąć wpływu na produkcyjne magazyny danych? Jakiego rodzaju narzędzia muszą pomóc pracownikom ds. testów i operacji naszych klientów, aby rozwiązać problem, czy problem znajduje się w swoich aplikacjach, czy w naszej usłudze? Jakiego rodzaju dokumentację należy dostarczyć?
• Globalizacji. Co musimy zrobić, aby zapewnić, że aplikacje klienckie na całym świecie mogą korzystać z naszej usługi internetowej?
• Możliwości zarządzania. Jakiego rodzaju informacje potrzebują nasi pracownicy operacyjni, aby zarządzać naszą usługą internetową? Jak zbierać te informacje i przedstawiać je narzędziom do zarządzania?

Jeśli istnieją inne tematy, które chcesz zobaczyć, wyślij nam wiadomość e-mail na adres wsgmsdn@microsoft.com. Należy pamiętać, że w tej chwili nie możemy odpowiedzieć za pośrednictwem komentarzy użytkownika na tej stronie. Regularnie czytamy jednak komentarze. Jeśli możemy dowiedzieć się, jakie komentarze mają do czynienia z naszą zawartością, zobaczymy, co możemy zrobić, aby rozwiązać Twój problem w przyszłej kolumnie.

W przyszłym tygodniu przyjrzymy się problemom, które napotkaliśmy podczas definiowania wizji projektu usługi Ulubione. Zobacz cię wtedy!