Web サービスは、Web 上のデータ交換のために定義された標準です。これは、Web サービスがインターネットに公開されるということではなく、多くの製品がサポートする合意された「Web 標準」のセットが存在するというだけです。どの標準を採用するかを決定する際に考慮すべき最も重要なことは、多くの場合、技術スタッフのアドバイスです。
彼らは、実装が最も簡単で、製品に対する最も広範な技術サポートがあり、お客様の環境で適切に動作する可能性が最も高い標準を順番に推奨する場合があります。時の試練に耐え、将来的に拡張し続ける SOA 実装を成功させるには、これら 3 つの要素すべてが非常に重要です。
WS-I
Web Services Interoperability Organization (WS-I) は、さまざまなオペレーティング システム、プラットフォーム、またはプログラミング言語間での相互運用性を確保するための Web 標準のベスト プラクティスの開発を専門としています。 WS-I は、Web サービスのセキュリティや Web サービス処理の技術仕様などのベスト プラクティス文書を定義する責任を負います。このドキュメントは、開発者や企業が、ユーザーの操作性を確保するために他の企業が使用している慣行に準拠するのに役立ちます。
WS-I は、これらのプロトコルの導入方法に関する技術仕様、テスト スイート、サンプルも公開しています。実際、WS-I は Microsoft や IBM などの多くの組織によって形成された統括団体であり、その使命は相互運用可能な Web サービスを促進することです。
利用規約
Web サービスは、通信が意味のあるものであることを保証するためにプロトコルに依存します。サービス間で送信されるデータのコンテンツは、双方がどのようなコンテンツを受信するかを確実に把握できるように、事前に合意する必要があります。 SOAP は、データ交換時に最も広く使用されているプロトコルの例です。 SOAP は XML プログラミング言語を使用するため、双方が送信内容をデコードし、送受信される情報をフォーマットすることができます。
説明する
すぐにいくつかのアーキテクチャについて説明し、いくつかの Web サービス プロトコルについても言及します。これら 2 つのことを混同しないことが重要です。それでは以下に簡単に紹介していきます。
REST や RPC などのソフトウェア アーキテクチャはプロトコルではありません。これらは、合意がどのように実施されるかを指定するメソッドです。
WSDL (Web サービス記述言語) は、アプリケーションがサービスを解析できるように、特定の Web サービスをフォーマットされた方法で記述するために使用される言語です。 WSDL 自体は、Web サービス対話の形式で機能を提供しません。
SOAP、XML-RPC、DCOM などのプロトコル自体は、メッセージがどのように配信されるか、またプログラムが受信したデータをどのように理解するかを正確に定義します。
SOA には、RPC ファミリのプロトコルと Representational State Transfer (REST) アプローチという 2 つの主なタイプのアーキテクチャがあります。
RPC
リモート プロシージャ コール (RPC) メソッドを使用すると、プログラマは、システム上でプログラミングするときにローカル リソースを「呼び出す」のと同じように、リモート システムのリソースを呼び出すことができます。 RPC スタイルのサービスの欠点は、ユーザーが特定のプラットフォームのプログラミング言語に精通しているかのようにサービスを使用する傾向があることです。ローカル プロシージャと同じであれば、リモート プロシージャを呼び出すことも簡単です。
このロジックは「疎結合」の概念に違反します。疎結合の概念は、実際には、リモート プロセスが特定のオペレーティング システムやプログラミング言語に依存すべきではないことを意味します。
SOAP は XML-RPC の後継プロトコルであり、その情報を XML で含む単なるリモート プロシージャ コールです。 SOAP は HTTP プロトコルを使用してデータを送信します。これはシンプルで優れていますが、いくつかの欠点があります。それにもかかわらず、最近のほとんどの Web サービスは SOAP プロトコルを使用して構築されているため、依然として通信に HTTP プロトコルを使用しています。
休む
Representational State Transfer (REST) アプローチは、異なるレベルで動作するため、リモート プロシージャ コールとは根本的に異なります。 REST 呼び出しは HTTP プロトコルを介した他の Web リクエストと同じように見えますが、RPC 呼び出しは標準の関数呼び出しのように見えます。 REST の焦点は、個別のメッセージではなく安定したリソースを使用して動作することであり、その結果、HTTP プロトコル自体と同様に、より標準的で広く理解されている対話方法が実現します。 REST は単純なデータのチャンクの転送を処理しますが、RPC は複雑なプロセスを転送します。
REST または RPC を使用する必要がありますか?
REST を使用するかどうかという問題は、確かに良い問題です。それは未来のやり方のように思えます。ただし、SOA は現在使用しているすべてのソフトウェアに統合されている必要があります。 REST の導入は、主に Web サービスのサポートが原因で遅れています。 REST システムは WSDL を使用して HTTP 経由で SOAP メッセージを記述することができますが、それを実際に使用するためのサポートは十分ではありません。たとえば、Apache は、プラグイン モジュールをインストールせずに REST を使用するために必要なメソッドさえサポートしていません。
Web サービス ファミリの一部ではない他の標準もあります。ただし、ご想像のとおり、これらの標準は広くサポートされていません。例としては、Jini、WCF、CORBA があります。ベンダーが上記のテクノロジーのいずれか 1 つだけをサポートする製品を提供したら、立ち去るのではなく、逃げ出したくなるでしょう。 Web サービスは現在広くサポートされています。 Web サービスの利用は今後も増えるでしょう。 SOA自体は新しく、不安定で、リスクがあると言われています。ただし、広範な技術サポートが提供される適切な Web サービス標準を選択すれば、これらのリスクを大幅に軽減できます。
最後に、現在、Web サービスを使用して SOA を構築するための実行可能なメカニズムは、ある種の RPC スタイルのシステムではなく昔ながらの SOAP に固執することです。これを行うと、ベンダー ロックインの可能性が大幅に減少します。