メアリー カートランド
Microsoft Corporation
2001 年 1 月 3 日
Web サービスに特化した新しい列である At Your Service へようこそ。
Web サービスは、標準的なインターネット プロトコルに基づいて構築された明確に定義されたプログラム インターフェイスを使用して、アプリケーションに情報とサービスを提供します。 これらは Microsoft .NET の重要な部分です。 当然ながら、MSDN ではそれらを構築する方法を理解する必要がある、と考えたのです。 Visual Studio でボタンをプッシュする方法だけでなく、スケーラブルで高可用性、セキュリティで保護された信頼性の高い Web サービスを構築する方法。
私たちのチームは、Duwamish OnlineなどのWebアプリケーションを構築する貴重な経験を得ました。 Web サービスの構築の違い 他の開発者がアプリケーションで Web サービス (異なるオペレーティング システムでホストされ、異なる言語で記述され、SOAP などの主要な仕様のさまざまな実装を使用するアプリケーション) で使用したい場合、どのような問題が発生しますか?
見つける唯一の方法は、自分でサービスを構築することです。 そのため、今後数か月間、Web サービス ガイダンス チームはサンプル Web サービスの構築、展開、運用を行う予定です。 目的: 独自の Web サービスを設計、実装、展開、運用する際に考慮する必要がある問題を示します。 (Web サービスの使用も見ていきます)。3 か月ごとに 1 つの Web サービスをリリースしたいと考えています。
しかし、3ヶ月は新しい情報を待つのに長い時間です。 そのため、Duwamish Diary の壮大な伝統では、この列を使用して、概念から設計、実装、デプロイまでの各サンプル プロジェクトに従います。 少なくとも2週間に1回、私たちはあなたが私たちと一緒に従うことができるように日記のエントリを投稿します。 各プロジェクトを完了したら、MSDN に仕様、ソース、その他のプロジェクト成果物をここに投稿します。 また、新しい Web サービス デベロッパー センターからいつでもこの情報にアクセスできます。
チームに会う
Web サービス ガイダンス チームは現在、次の 6 人で構成されています。
- 私、メアリー・カートランドは、チームの最高料理人であり、ボトルネックです。つまり、建築家とプログラムマネージャーです。 サンプル サービスのコード、テスト、運用以外のほとんどの処理を行います。 OLE/COM/DCOM/MTS/COM+/what-you-want-to-call-it チームでプログラム マネージャーとして私を知っている人もいます。 その後、私は.NETを取り巻く沈黙の円錐形に消えました。 1年ほど前に、テクノロジ自体の構築を楽しむよりも、テクノロジを使用してアプリを構築する方法について書くのが楽しいと思いました。 そこで 4 月に MSDN に移り、Web サービス のガイダンス チームになった作業に取り組みます。 私の時間の多くは、Web サービス リソース ページのこの列とコンテンツの記述に専念しています。 残りは、プロジェクトの仕様を最新の状態に保ち、今後カバーする新しいテクノロジを追跡するために費やされます。
- Matt Powell と Scott Seely が開発チームを構成します。 Matt は 10 月に開発者サポートからチームに参加しました。 Matt は、SOAP Toolkit for Visual Studio 6.0 で ISAPI リスナーを作成し、 Microsoft Information Server 4.0 for Microsoft Press の共同編集を行い、 MSDN Magazine とその前身である MSJ と MIND に関するいくつかの記事を執筆しました。
Scott は、過去 5 年間 Microsoft 製品を使用して実際のアプリを構築した後、12 月に Microsoft と Microsoft チームに参加しました。 彼の豊富な空き時間に、 彼はWindows開発者のジャーナル だけでなく、 Windowsシェルプログラミングというタイトルの本のための記事を書いている。 サンプル サービスに取り組まないとき、彼は SOAP に関する本に取り組んでいます。
数か月後には、Matt と Scott が開発側に関する記事を書いているのを見ることができます。 - テスト チームは、Jan McCollum と Jim Francisco で構成されています。 Jan は 10 月にテスト リーダーとして参加し、最初のプロジェクトのテスト計画を立てるのに苦労してきました。 Jim は 12 月に参加し、単体テストとテストの自動化に取り組んでいます。 Jim は、Windows 98 ネットワーク テスト チームと Microsoft Host Integration Server ビルド/リリース テスト チームで作業してきました。 彼は、n 層 Web アプリケーションの展開と管理ツールを開発する dot-com の世界で、私たちのチームに来ました。 もう少し離れているときに、Web サービスのテストに関するいくつかの記事を書いてみてください。
- Bronwyn Calsyn は、運用マネージャーです。 Bronwyn は 11 月に開始され、サンプル サービスをインターネットにライブでデプロイするために必要な機器と、スムーズに動作し続けるために必要な操作手順を把握するために忙しくなってきました。 展開と運用の側面に関する記事もいくつか書いていきます。
お気に入りサービスの概要
最初のプロジェクトは、お気に入りサービスです。 Web の熱心なユーザーとして、エンド ユーザーが直面する問題の 1 つは、以前にアクセスしたページ (特に MSDN Online などの動的サイトや、数日間以上フロント ページから記事にアクセスできないニュース サイト) を見つけることです。 ブラウザーのお気に入りを使用して、お気に入りのページを追跡できますが、ブラウザーのお気に入りは特定のコンピューターに対してローカルです。 しかし、複数のマシンまたはデバイスを使用する場合はどうでしょうか。 お気に入りをどこかのサーバーに保存し、使用していたマシンから簡単にアクセスできればいいのではないでしょうか?
これはまさにお気に入りサービスの機能です。 これにより、Web サイトはエンド ユーザーのお気に入りの Web ページへのリンクを格納できます。 今、あなたはこれが非常に複雑なサービスのように聞こえないと思うかもしれません。 また、ビジネス ロジックの観点からは、そうではありません。 つまり、ビジネス ロジックの説明に多くの時間を費やす必要はなくなり、独自の Web サービスで使用できる手法を見つけるために使用するアプリケーション固有のコードは多くなくなります。 しかし、サービスに関して興味深い問題が多数発生しました。この問題は、他の多くの開発者にも提供されています。
最初のいくつかの列では、プロジェクトの設計フェーズで発生した問題に焦点を当てます。 検討しているトピックの一部:
- ユーザーのプライバシーの保護。 最初にどのアプリケーションでのお気に入りを保存したかに関係なく、世界中のどのアプリケーションでも、すべてのエンド ユーザーのお気に入りを照会または編集できる必要がありますか?
- ありがとうございます。 すべてのアプリケーションがエンド ユーザーのお気に入りにアクセスできない場合、サービスへのアクセスを制御するにはどうすればよいですか? サービスに対して料金を請求する必要がありますか? 意味のあるビジネス モデルはどれですか?
- 認証と認可。 サービスへのアクセスを制限する場合、クライアント アプリケーションを認証し、何を行う権限があるかを決定するにはどうすればよいですか? エンド ユーザーを特定するにはどうすればよいでしょうか。
- パフォーマンス要件の見積もり。 サービスに適用される負荷の種類を把握するにはどうすればよいでしょうか。 Web サイトの負荷を見積もるために使用するのと同じ方法を使用できますか? クライアントが要求する応答時間と可用性の種類を判断するにはどうすればよいでしょうか。
- 開発、テスト、および操作からのライセンス要件。 サービスへのアクセスを制限している場合、使用量に基づいて課金する可能性があります。クライアント アプリケーション開発者とテスト担当者は、サービスに依存するアプリをどのように試しますか? 運用データ ストアへの影響を回避するにはどうすればよいですか? クライアントのテストおよび運用スタッフは、アプリケーションまたはサービスに問題があるかどうかのトラブルシューティングに役立つツールの種類を示します。 どのような種類のドキュメントを提供する必要がありますか?
- グローバリゼーション。 世界中のクライアント アプリケーションで Web サービスを使用できるようにするには、何を行う必要がありますか?
- 管理の容易さ。 Web サービスを管理するために運用スタッフはどのような情報を必要としますか? その情報を収集し、管理ツールに提示するにはどうすればよいですか?
その他のトピックが記載されている場合は、 に電子メールでお wsgmsdn@microsoft.com問い合わせください。 現時点では、このページのユーザー コメントを通じて応答できないことに注意してください。 ただし、コメントは定期的に読みます。 コンテンツに対してコメントが何を行う必要があるかを把握できれば、今後の列で問題に対処するために何ができるかがわかります。
来週、お気に入りサービス プロジェクトのビジョンを定義する際に発生した問題について説明します。 それでは、お会いしましょう。