パート 1: 直感的な概要
Web サービスのいくつかの概念:
HTTP プロトコルに基づく、XML を介したクライアント/サーバー通信用のフレームワーク/コンポーネント
2 つの重要なポイント:
1.サーバーが提供する関数はxmlで記述されます
2.最初のステップで記述された関数はHTTPプロトコルに埋め込まれており、HTTPプロトコル[いわゆるSOAP]を介した通信が可能になります
画像を使用して表現することができます。
図 1: WebService の概要
これら 2 つのテクノロジーを使用する主な目的は次のとおりです:
1. HTTP プロトコルをサポートするクロスプラットフォームのホストとサーバーは通信接続を確立できます。そして、ほとんどのホストとサーバー (99.999% 以上) が HTTP プロトコルをサポートします。一般に、異なるターゲット ホスト間の通信はファイアウォールを通過し、特定のポートを開く必要があります。HTTP プロトコルの利点は、通常、ファイアウォールがポート 80 をブロックしないため、通信が便利で安全であることです。
2. あらゆる言語での XML テキスト解析をサポートします。この目的は、異なる言語間の通信を実現することです。そのため、この方法での通信は言語の壁を越えることができます。つまり、サーバーは Java で開発され、クライアントは C を使用してサーバーにアクセスでき、クライアントは Java、VB などを使用してアクセスでき、またその逆も可能です。
パート 2: 基本原則とアーキテクチャ
もちろん、上記の図は 1 対 1 の通信を示しているだけです。実際の状況では、次のことが必要です。次の質問について考えてください。図を参照してください。
1. サーバー (プロバイダー) は、統一された標準化されたサービスを提供します。会社 (サーバー プロバイダー) を設立するのと同じように、会社の住所と性質を工商管理局に登録します。その目的は、他人が同社のサービスを利用したい場合に、工商行政局からあなたの住所を知られてしまうことです。このような統一されたアプローチは、すべての企業と、その企業が提供するサービスを必要とするすべての顧客にとって便利です。そして、この情報は可能な限り最大限に開示されます。
2. クライアント(依頼者)は登録センター(レジストリ)に行き、企業の基本情報を取得し、企業を見つけて、その企業が提供するサービスを利用します。
図 2: 基本的な WebService アーキテクチャのフローチャート
上の図の基本ステップのラベルに注目してください。 説明は次のとおりです
1. プロバイダー ノードがサービスを提供した後。 、最初にノード Registry
に登録します2 と 3。リクエスター ノードは情報を確認するために Registry ノードに行き、必要なプロバイダーとそれが提供するサービスを見つけます
4 リクエスターはプロバイダー
によって提供されるサービスを使用します。
より具体的な紹介については、参考文献 [2] を参照してください。以下は基本的にこの参考文献から翻訳されたものです:
図 3: 詳細なステップのフローチャート
上記の図は、WebService の原理プロセス全体を完全に示しています。 :
1. クライアントにはニーズがあり、サービスを呼び出したいと考えていますが、どこで呼び出せばよいかわかりません。ただし、UDDI レジストリで見つかることはわかっています。
2. 案の定、UDDI には Web サーバー A というサーバーがそのようなサービスを提供できることが記録されています。
3. したがって、クライアントは Web サーバー A にアクセスし、正確な呼び出しメソッドを要求します。
4. Web サーバー A は、クライアントによって提案された「正確なメソッド クエリ」を確認すると、クライアントがこれを理解した後、WSDL によって記述された XML ドキュメントを直ちに返します。これらの XML インターフェイス メソッドを HTTP 要求にカプセル化し、Web サーバー A に送信します。これらのカプセル化メソッドは標準 SOAP メソッドを使用します。これは、基本的に HTTP プロトコルを満たすいくつかの SOAP メッセージ メッセージです。
6. Web サーバー A も HTTP プロトコルの SOAP パッケージに応答します。このようにして、双方のリクエストと応答は完全にスムーズになります。
上にあるのは、アプリケーションの概略図です。さらに深く進むと、次のプロトコル アーキテクチャ図が見つかります。
図 4: プロトコル構造
多くの時間を費やして、サービスの検出 (UDDI)、サービスによって提供されるインターフェイスの記述 (WSDL)、サービスの呼び出し (SOAP)、および送信 (HTTP) のプロセス全体を紹介します。したがって、紹介は行われません。このテクノロジーの中核は SOAP です。
パート 3: Web サービスの実践
上の図が非常に複雑であることがわかりますが、実際、SOAP+HTTP プロトコルは十分に成熟しており、 XML を介して SOAP を生成する HTML スクリプトの変更を実装するのに役立つツールが多数あります。実際、開発は非常に簡単です。
状況 A: Web サービスが存在することがわかっており、クライアントは次の手順で開発できます:
1. UDDI を通じて、クライアント プログラムに必要な Web サービスの場所を見つけます
2. WebService、WSDL インターフェース記述ファイルを見つけます
3. ツールを使用して、ステップ 2 で取得した WSDL ファイルからクライアント スタブを生成します。これは本質的にコード、つまりスタブです。このスタブ コードをクライアント プログラムにマージします。
4. クライアントは WebService を呼び出す必要があるたびに、ステップ 4 で生成されたスタブ インターフェイスを直接呼び出して、サーバー側への呼び出しを実現します。
状況 B: サーバーサイド開発でも、SOAP の解析などの面倒なことを行う必要はなく、フレームワークが代わりにやってくれます。一般的な手順は次のとおりです:
1. Web サーバーが提供する必要があるすべての機能を実装します
2. WSDL ファイル (または IDL) を使用してサーバー スタブを生成します。これらのコードは、外部からのリクエストの受信と転送を担当します。それらを Web サーバーのサービスに実装します (実装コード)。サービス実装コードが処理されて結果が生成されると、その結果はサーバー スタブに渡され、サーバー スタブは SOAP 応答を生成できます。サーバー スタブとサーバー実装は組み合わされて Web サービス コンテナーと呼ばれます。これは、WebService に送信された HTTP リクエストがサーバー スタブに直接送信されるようにすることです。
図 5: 実際のアプリケーションでの呼び出し
WebService の紹介、原理、および使用法関連の記事の詳細については、PHP 中国語 Web サイトに注目してください。