XML Web サービスは、インターネット上の分散コンピューティングの基本的な構成要素です。オープン スタンダードと、ユーザーとアプリケーション間の通信とコラボレーションへの重点により、XML Web サービスがアプリケーション統合のプラットフォームとなる環境が生まれました。アプリケーションは、場所や実装方法に関係なく連携して動作する、複数の異なるソースからの XML Web サービスを使用して構築されます。
XML Web サービスを構築している企業の数と同じくらいの数の XML Web サービス定義があります。ただし、ほとんどすべての定義には次のような共通点があります。
XML Web サービスは、標準の Web プロトコルを通じて Web ユーザーに便利な機能を提供します。ほとんどの場合、SOAP プロトコルが使用されます。
XML Web サービスはインターフェイスを詳細に指定できるため、ユーザーはクライアント アプリケーションと通信するためのクライアント アプリケーションを作成できます。この説明は通常、Web サービス記述言語 (WSDL) ドキュメントと呼ばれる XML ドキュメントに含まれています。
XML Web サービスは、潜在的なユーザーが簡単に見つけられるように登録されます。これは、Universal Discovery, description, and Integration (UDDI) によって実現されます。
この記事ではこれら 3 つのテクノロジを紹介しますが、その前に、なぜ XML Web サービスに注目する必要があるのかを説明する必要があります。
XML Web サービス アーキテクチャの主な利点の 1 つは、異なるプラットフォーム上で異なる言語で記述されたさまざまなプログラムが標準ベースの方法で相互に通信できることです。この業界についてある程度知っているユーザーは、すぐにこう言うかもしれません。「ちょっと待って、CORBA と以前の DCE は同じ取り組みをしていませんでしたか? これとそれらの違いは何ですか? 最も重要な違いは、SOAP が以前より優れているということです。」このアプローチははるかに単純であるため、標準に準拠した SOAP の実装に対する障壁ははるかに少なくなります。 Paul Kulchenko は、SOAP 実装のリストをhttp://www.soapware.org/directory/4/implementations (英語) で提供しています。最後に数えたところ、リストには 79 個の項目が含まれていました。ご想像のとおり、ほとんどの大手ソフトウェア会社が SOAP 実装を提供していますが、個々の開発者によって作成および保守されている実装も多数あります。以前のソリューションに対する XML Web サービスのもう 1 つの大きな利点は、標準 Web プロトコル (XML、HTTP、TCP/IP) を使用できることです。多くの企業はすでに Web インフラストラクチャを確立しており、従業員はそれを維持するための知識と経験を持っています。したがって、XML Web サービスの導入コストは、以前のテクノロジーを導入するよりもはるかに低くなります。
XML Web サービスは、SOAP を介して Web 上で提供され、WSDL ファイルを使用して記述され、UDDI を介して登録されるソフトウェア サービスとして定義されます。 「XML Web サービスで何ができるの?」と疑問に思うかもしれません。元の XML Web サービスは、多くの場合、株価、天気予報、スポーツのスコアなど、アプリケーションに簡単に組み込むことができる情報のソースでした。関心のある情報を分析して要約し、その情報をさまざまな方法で利用できるようにするアプリケーションのクラス全体を想像するのは簡単です。たとえば、Microsoft® Excel スプレッドシートを使用してすべての財務状況を要約することができます。情報 - 株式、401K、銀行預金、ローンなどこの情報が XML Web サービスを通じて利用できる場合、Excel は継続的に情報を更新できます。この情報の中には無料のものもありますが、対応するサービスを利用するには購読が必要な場合もあります。この情報の多くはすでに Web 上で入手可能ですが、XML Web サービスを使用すると、プログラムによるアクセスがより簡単かつ確実になります。
既存のアプリケーションは XML Web サービスとして利用できるようになり、XML Web サービスを構成要素として使用して、より強力な新しいアプリケーションを構築できます。たとえば、ユーザーは、さまざまなサプライヤーから価格情報を自動的に取得する購入アプリケーションを開発して、サプライヤーを選択し、注文を送信し、商品が到着するまで商品の出荷を追跡できるようにすることができます。サプライヤーのアプリケーションは、Web 上でサービスを提供するだけでなく、XML Web サービスを使用して顧客の信用を確認し、代金を回収し、運送会社との貨物手続きを処理することもできます。
将来的には、XML Web サービスを利用した最も興味深いアプリケーションのいくつかが Web を活用して、現在不可能なタスクを実行できるようになるでしょう。たとえば、カレンダー サービスは、Microsoft .NET My Services (英語) プロジェクトによってサポートされるサービスの 1 つです。歯科医や整備士がこの XML Web サービスを通じてスケジュールを提供している場合、必要に応じて Web 上で歯科医師や整備士との予約をスケジュールすることができます。また、歯科医師や整備士がカレンダー上で直接クリーニングや定期メンテナンスの日程をスケジュールすることもできます。 Web をプログラミングできれば、何百ものアプリケーションを作成できることは容易に想像できます。
XML Web サービスと構築できるアプリケーションの詳細については、MSDN Web サービス (英語) のホームページを参照してください。
SOAP
SOAP は、XML Web サービスの通信プロトコルです。 SOAP を通信プロトコルとして説明するとき、ほとんどの人は DCOM または CORBA を思い浮かべ、「SOAP はどのようにオブジェクトをアクティブにするのですか?」または「SOAP はどのようなネーミング サービスを使用しますか?」などの質問をします。 SOAP 実装にはこれらの要素が含まれる場合がありますが、SOAP 標準では指定されていません。 SOAP メッセージの XML 形式を定義する仕様。これは仕様の必須部分です。 1 対の SOAP 要素内に含まれる整形式の XML セグメントが SOAP メッセージです。これは簡単ではありませんか？
SOAP 仕様の他の部分では、プログラム データを XML として表現する方法と、SOAP をリモート プロシージャ コール (RPC) に使用する方法について説明します。仕様のこれらのオプションの部分は、RPC スタイルのアプリケーションを実装するために使用されます。このアプリケーションでは、クライアントが SOAP メッセージ (呼び出し可能な関数と、関数に渡されるパラメーターを含む) を発行し、サーバーは結果を含むメッセージを返します。関数の実行。現在、COM または CORBA アプリケーションの開発に慣れているプログラマは RPC 形式に精通しているため、ほとんどの SOAP 実装は RPC アプリケーションをサポートしています。 SOAP は、SOAP メッセージが XML ドキュメントの単なるラッパーであるドキュメント スタイルのアプリケーションもサポートします。ドキュメントベースの SOAP アプリケーションは非常に柔軟であり、多くの新しい XML Web サービスはこの機能を利用して、RPC を使用して実装するのが難しいサービスを構築します。
SOAP 仕様の最後のオプション部分は、SOAP メッセージを含む HTTP メッセージのスタイルを定義します。現在のほとんどすべての OS (および以前の多くの OS) が HTTP をサポートしているため、この HTTP バインディングは重要です。 HTTP バインディングはオプションですが、SOAP の唯一の標準プロトコルであるため、ほとんどすべての SOAP 実装でサポートされています。このため、SOAP は HTTP を使用する必要があると誤解されることがよくあります。実際、一部の実装では MSMQ、MQ シリーズ、SMTP、または TCP/IP トランスポートもサポートされていますが、HTTP は非常に普及しているため、現在のほとんどすべての XML Web サービスでそれが使用されています。 HTTP は Web の中核プロトコルであるため、ほとんどの組織のネットワーク インフラストラクチャは HTTP をサポートしており、従業員はその管理方法をすでに知っています。現在、HTTP セキュリティ、監視、負荷分散のためのインフラストラクチャが確立されています。
SOAP を使い始めるときに最も混乱するのは、SOAP 仕様とその多くの実装の違いです。 SOAP のほとんどのユーザーは、SOAP メッセージを直接作成せず、SOAP ツールキットを使用して SOAP メッセージを作成および分析します。これらのツールキットは通常、言語からの関数呼び出しを SOAP メッセージに変換します。たとえば、Microsoft SOAP Toolkit 2.0 は COM 関数呼び出しを SOAP に変換し、Apache Toolkit は JAVA 関数呼び出しを SOAP に変換します。関数呼び出しのタイプとサポートされるパラメーターのデータ型は SOAP 実装ごとに異なるため、あるツールキットで機能する関数が別のツールキットでは機能しない場合があります。これは SOAP の制限ではなく、使用される特定の実装の制限です。
これまでのところ、SOAP の最も魅力的な機能は、SOAP をさまざまなソフトウェアおよびハードウェア プラットフォームに実装できることです。これは、SOAP を使用して企業内外の異なるシステムをリンクできることを意味します。システム統合に使用できる共通の通信プロトコルを考案するために、これまでさまざまなアプローチが試みられてきましたが、SOAP ほど広く受け入れられるものはありませんでした。なぜ？ SOAP は、以前の多くのプロトコルよりも小さく、実装が簡単であるためです。たとえば、DCE と CORBA は実装に何年もかかったため、リリースされた実装はわずか数個だけです。 SOAP は既存の XML パーサーと HTTP ライブラリを利用してほとんどの困難な作業を実行できるため、SOAP の実装は数か月で完了できます。そのため、現在 70 を超える SOAP 実装が存在します。もちろん、SOAP は DCE や CORBA のすべての機能を備えているわけではありません。機能は削減されていますが、その複雑さは大幅に軽減されています。
HTTP の人気と SOAP のシンプルさにより、ほぼすべての環境からこれらを呼び出すことができるため、XML Web サービスの理想的な基盤となっています。 SOAP の詳細については、MSDN SOAP (英語) ホームページを参照してください。
どれくらい安全ですか?
多くの場合、SOAP を初めて使用するユーザーが最初に抱く質問は、SOAP がセキュリティ問題をどのように解決するかということです。開発の初期段階では、SOAP は HTTP に基づくプロトコルとみなされていたため、HTTP のセキュリティは SOAP にとって十分であると考えられていました。結局のところ、現在 HTTP セキュリティを使用している Web アプリケーションは数千あるため、SOAP にはこれで十分です。したがって、現在の SOAP 標準では、セキュリティはトランスポートの問題であると想定されており、セキュリティの問題として扱われません。
SOAP がより一般的なプロトコルに拡張され、多数のトランスポート上で実行されるにつれて、セキュリティの問題がより顕著になります。たとえば、HTTP では、SOAP 呼び出しを行うユーザーを認証する方法がいくつか提供されていますが、メッセージが HTTP から SMTP トランスポートにルーティングされるときに、その ID はどのように伝播するのでしょうか? SOAP はビルディング ブロック プロトコルとして設計されたため、幸いなことに、SOAP に基づいた Web サービスに追加のセキュリティ機能を提供する仕様が整備されています。 WS-Security 仕様 (英語) は完全な暗号化システムを定義し、WS-License 仕様 (英語) は呼び出し元の身元を保証し、許可されたユーザーのみが Web サービスを使用できるようにする対応するテクノロジを定義します。
WSDL
WSDL (Web サービス記述言語) は、Web サービス記述言語の略です。この記事では、WSDL ファイルを、一連の SOAP メッセージとその交換方法を記述した XML ドキュメントとして考えることができます。言い換えれば、SOAP にとっての WSDL は、CORBA や COM にとっての IDL と同じものです。 WSDL は XML ドキュメントであるため、読み取りや編集が簡単ですが、ほとんどの場合、ソフトウェアによって生成され、使用されます。
WSDL の値を表示するには、ビジネス パートナーの 1 つが提供する SOAP メソッドを呼び出したいと想像してください。いくつかのサンプル SOAP メッセージを要求し、サンプルと同様のメッセージを生成して使用するアプリケーションを作成することもできますが、これは間違いを犯しやすくなります。たとえば、顧客 ID 2837 を見て、実際には文字列であるにもかかわらず、それが整数であると想定する場合があります。 WSDL は、要求メッセージに何を含める必要があるか、および応答メッセージがどのようなものであるべきかを明示的な表記を通じて指定します。
メッセージ形式を記述するために WSDL ファイルで使用される表記法は、XML スキーマ標準に基づいています。つまり、プログラミング言語に依存せず、標準ベースであるため、さまざまなプラットフォームやさまざまなプログラミングでアクセスできる XML Web サービスを記述するのに適しています。言語。 WSDL は、メッセージの内容の記述に加えて、サービスの場所と、サービスとの通信に使用される通信プロトコルも定義します。つまり、WSDL ファイルは、XML Web サービスを使用するプログラムを作成するために必要なすべてを定義します。 WSDL ファイルを読み取り、XML Web サービスとの通信に必要なコードを生成できるツールがいくつかあります。最も強力なツールの一部は、Microsoft Visual Studio® .NET にあります。
現在、多くの SOAP ツールキットには、既存のプログラム インターフェイスから WSDL ファイルを生成するツールが含まれていますが、WSDL を直接記述するためのツールはほとんどなく、WSDL のツール サポートは不完全です。しかし、すぐに WSDL ファイルを作成するためのツールが登場し、続いてプロキシとスタブを生成するツール (COM IDL ツールとよく似た) が登場し、これらのツールはほとんどの SOAP 実装の一部になるでしょう。それまでは、WSDL が XML Web サービスへの SOAP インターフェイスを作成するための推奨される方法になるでしょう。
WSDL については、ここ (英語) で詳しく説明されています。また、http: //www.w3.org/TR/wsdl (英語) で WSDL 仕様を見つけることができます。
UDDI
Universal Discovery, description, and Integration (UDDI) は、Web サービスのイエロー ページです。従来のイエロー ページと同様に、必要なサービスを提供する企業を検索し、提供されているサービスについて読んで学習し、詳細について誰かに問い合わせることができます。もちろん、UDDI に登録せずに Web サービスを提供することもできます。これは、地下室で口コミに頼ってビジネスを行うようなものですが、市場を拡大したい場合は、ユーザーに見つけてもらえるように UDDI が必要です。顧客。
UDDI ディレクトリ エントリは、提供されるサービスとサービスを説明する XML ファイルです。 UDDI ディレクトリ エントリは 3 つの部分で構成されます。 「ホワイトページ」は、サービスを提供する企業の名前、住所、連絡先情報などを紹介します。「イエローページ」には、標準分類（北米産業分類システムや標準産業分類など）に基づいた産業カテゴリが含まれます。情報 ユーザーが Web サービスを利用するアプリケーションを作成できるように、サービスへのインターフェイスにアクセスします。サービスの定義は、タイプ モデル (または tModel) と呼ばれる UDDI ドキュメントを通じて実現されます。ほとんどの場合、tModel には XML Web サービスにアクセスするための SOAP インターフェイスを記述する WSDL ファイルが含まれていますが、tModel は非常に柔軟であり、ほぼすべての種類のサービスを記述することができます。
UDDI ディレクトリには、アプリケーションの構築に必要なサービスを検索するためのメソッドもいくつか含まれています。たとえば、特定の地理的位置にあるサービス プロバイダーを検索したり、特定の種類のビジネスを検索したりできます。 UDDI ディレクトリには、ニーズに合ったサービスを特定できるように、情報、連絡先詳細、リンク、技術データが提供されます。
UDDI を使用すると、必要な Web サービスを提供する企業を見つけることができます。ビジネスをしたい相手はすでにわかっているが、それ以外に何が提供できるかがまだわかっていない場合はどうすればよいでしょうか? WS-Inspection 仕様 (英語) を使用すると、特定のサーバーで利用可能な XML Web サービスのコレクションを参照して、必要なサービスを見つけることができます。
UDDI の詳細については、 http://www.uddi.org/about.html (英語) を参照してください。
その他のコンテンツ
これまで、XML Web サービス (SOAP) との通信方法、XML Web サービスの記述方法 (WSDL)、および XML Web サービス (UDDI) の検索方法について説明してきました。これらは、アプリケーションの統合と集約の基礎を提供する基本的な仕様セットを形成します。これらの基本仕様に基づいて、企業は実用的なソリューションを構築し、そこから利益を得ることができます。
XML Web サービスを実装するために多くの作業を行ってきましたが、やるべきことはまだたくさんあります。今日、人々は XML Web サービスを使用して成功を収めていますが、開発者にとっては改善すべき点がまだ多くあります。たとえば、セキュリティ、運用管理、トランザクション処理、信頼性の高いメッセージングなどです。グローバル XML Web サービス アーキテクチャは、モジュール式で拡張可能な方法で新しい高度な機能を XML Web サービスに追加するための一貫した共通モデルを提供することで、XML Web サービスが次の進化段階に入るのを支援します。
上記のセキュリティ モジュール (WS-Security [英語] および WS-License [英語]) は、Global Web Services Architecture 仕様の一部です。運用管理のニーズ (複数のサーバー間でメッセージをルーティングしたり、それらのサーバーを処理するように動的に構成したりするなど) も、WS-Routing 仕様 (英語) および WS-Referral 仕様 (英語) を通じて実現されるグローバル Web サービス アーキテクチャの一部です。グローバル Web サービス アーキテクチャが進化するにつれて、これらのニーズやその他のニーズに対応する仕様が導入されるでしょう。