XMLHTTP と SOAP:
XML はWeb サービスの中核となる基本テクノロジであり、SOAP 実装の鍵となります。XMLHTTP は XML に基づいて設計されています。実装に関しては、XMLHTTP はブラウザーをベースとしており、IE さえあれば XML 文字列をサーバーに転送できるため、汎用性が高くなります。ただし、XMLHTTP は一般ユーザーが閲覧するためのブラウザーではありません。XML を使用してさまざまな操作を実行できる場合、ユーザーへの影響は避けられません。たとえば、msxml の以前のバージョンに対応するブラウザは、クライアント XML ドキュメント (当初は XMLHTTP 用に設計されたもの) にアクセスできます。これは、XMLHTTP テクノロジを通じてローカル ファイル システムにアクセスできることを意味します。その後、Microsoft はこれを脆弱性として定義しましたが、現在では定義できなくなりました。もちろん、クライアント プログラムを作成することもできますが、msxml で API を呼び出すことができるのは Visual シリーズ プログラムに限られます。ただし、サーバーは asp、jsp/サーブレットにすることができ、これらはすべて XML 文字列を XML ドキュメントオブジェクトに変換します。
SOAP は、XML 形式の通信プロトコルです。SOAP エンベロープは、メッセージの内容を記述するための規則を定義し、メッセージ処理方法を意味します。下位レベルのプロトコルを介して SOAP エンベロープを送信するための一連の一般的なメカニズムを提供します。さまざま アプリケーションのデータ型をタグベースの XML表現にマッピングするための規則。RPC メカニズムは、リモート プロシージャ コールとその戻り値を表現する方法を提供します。それと他の協定との間に明確な関係はありません。 http.stmp、tcp、その他のプロトコルにバインドできます。 SOAP メッセージは XML ドキュメントであり、W3C で定義された API に基づいて SOAP メッセージを生成できます。もちろん、Microsoft の .net プラットフォームも SOAP をサポートします。 SOAP+HTTP は、分散協調通信において、より優れた強力な実装機能、拡張性、多用途性を提供するという点で XMLHTTP に似ています。さらに重要なのは、SOAP+HTTP が Web サービスと回線通信の主要なテクノロジになっているということです。
SOAP と RMI、CORBA、COM
RMI と COM はすべて分散アプリケーションの実装であり、コンポーネント間の通信を定義します。これらは、システム内のプログラム ( Javaで書かれた一連のプログラムなど) 間の単なる通信規約であり、通信には特定のプラットフォームのサポートが必要であるため、このシステム内の通信が効率的である場合を除き、他のシステムでは使用できません。
この通信の問題を解決するために、CORBA は相互に通信できるようにプロキシ リクエスト モデルを設計しました。しかし、これはパッチのようであり、システムはますます複雑になります。また、CORBA の使用は、古いシステムの価値を回復する場合にのみ効果的です。どれもファイアウォールを通過できません。 SOAP+HTTP はファイアウォールに適したプロトコルであり、ファイアウォールを通過できます。
SOAP は、特定の実装とは関係のないプロトコルであり、XML 形式に基づいており、XML 形式でデータを送信するため、システムは緩いものになります。このように、XML の可読性をアプリケーションで使用して XML ドキュメントを解析し、アプリケーションを実装することで、システムの相互運用性 (異なるシステムとの通信) が大幅に向上します。さらに、システム内の各ユニットのビジネス ロジックが明確であるため、移植性と再利用性が高くなります。
UDDI と JNDI
UDDI は、サービスの登録管理プロトコルです。ユーザーは、UDDI 登録センターでサービスを検索して WSDL ドキュメントを取得し、WSDL に基づいてアクセスを取得します。 SOAP を使用してサービスと通信するためのサービスのメソッド。これはデータベースを通じて実装することも、オープンソースまたは企業 ( IBMなど) XML を使用して表現することもできます。ユーザーがクエリを実行すると、その詳細を XML 形式の情報で返すことができます。アクセス手順は階層的な検索プロセスにすぎません。登録されるサービスはユニバーサルでプラットフォームに依存せず、登録方法はユニバーサル XML 形式です。さまざまなサービスをさまざまなユーザーに提供するために、 インターネット指向またはインターネットを使用することができます。
JNDI は Java サービスの名前付けディレクトリであり、EJB と DataSource のアクセス ディレクトリをツリー形式で記録し、プログラムは JDNI と RMI を通じてサービスを見つけることができます。具体的には、サーバーの起動時に、デプロイメント ファイルを通じて、デプロイメント ファイルに基づいて JNDI が自動的に確立され、RMI およびネーミング サービス クエリ (サーバー自体によって実装される) がサポートされます。 RNI はこれらのコンポーネントにアクセスできるようになります。その考え方は基本的に UDDI と似ていますが、特定のシステム プラットフォームに束縛され、サービス (プログラムに関連しており、厳密にはサービスとは呼ばれず、コンポーネントと呼ばれます) に完全に束縛されており、その実装は簡単です。したがって、UDDI は JNDI よりも動的で操作が簡単です。WSDD
と EJB の構成ファイルは
CMP エンティティ Bean と類似していますが、データとデータベース間のマッピングを記述し、メソッドは必要ありません。サーバー システムの基盤となる実装アクセス メソッドが存在します。 WSDD はサービスのアクセス インターフェイスを定義し、Web サービスをサポートする基盤となるシステムがインターフェイスを識別し、データを送信するなどします。