XML Web サービスの基本

[アーティクル]
04/03/2007

Roger Wolter
Microsoft Corporation

2001 年 12 月

概要： 開発者向けの XML Web サービスの価値の概要と、SOAP、WSDL、UDDI の概要。 (6ページ印刷)

内容

XML Web サービスとは
SOAP
WSDL
UDDI
残りは何ですか?

XML Web サービスとは

XML Web サービスは、インターネット上の分散コンピューティングへの移行における基本的な構成要素です。オープンな標準と、人とアプリケーション間のコミュニケーションとコラボレーションに重点を置いて、XML Web サービスがアプリケーション統合のプラットフォームになりつつあります。アプリケーションは、存在する場所や実装方法に関係なく連携するさまざまなソースの複数の XML Web サービスを使用して構築されます。

XML Web Service の定義は、企業が構築するのと同じ数だけ存在する可能性がありますが、ほとんどの定義には次の共通点があります。

XML Web サービスは、標準の Web プロトコルを使用して Web ユーザーに便利な機能を公開します。ほとんどの場合、使用されるプロトコルは SOAP です。
XML Web サービスは、ユーザーがクライアントアプリケーションを構築して通信できるように、インターフェイスを十分に詳しく記述する方法を提供します。この説明は、通常、Web サービス記述言語 (WSDL) ドキュメントと呼ばれる XML ドキュメントで提供されます。
XML Web サービスは、潜在的なユーザーが簡単に見つけられるように登録されます。これは、ユニバーサル探索の説明と統合 (UDDI) を使用して行われます。

この記事では、これらの 3 つのテクノロジについて説明しますが、まず、XML Web サービスを気にする理由について説明します。

XML Web サービスアーキテクチャの主な利点の 1 つは、異なるプラットフォーム上の異なる言語で記述されたプログラムが、標準ベースの方法で相互に通信できる点です。業界の周りにいる人たちは、今、「ちょっと待って! CORBA と DCE の前に、同じ約束を聞いていませんでしたか? これはどう違うのですか?1 つ目の違いは、SOAP が以前のアプローチよりも大幅に複雑でないため、標準に準拠した SOAP 実装のエントリの障壁が大幅に低くなることです。 Paul Kulchenko は、SOAP 実装の一覧を保持しています http://www.soapware.org/directory/4/implementations 。最後の数には 79 個のエントリが含まれていました。多くの大手ソフトウェア企業の SOAP 実装は予想どおり見つかりますが、1 人の開発者が構築および保守する多くの実装も見つかります。 XML Web サービスが以前の取り組みに比べて持っているもう 1 つの大きな利点は、XML、HTTP、TCP/IP という標準の Web プロトコルを使用することです。多くの企業が既に Web インフラストラクチャを持っており、その維持に関する知識と経験を持つユーザーは、XML Web サービスの参入コストが以前のテクノロジよりも大幅に少なくなります。

XML Web サービスは、SOAP を介して Web 上で公開されるソフトウェアサービスとして定義され、WSDL ファイルで記述され、UDDI に登録されています。次の論理的な質問はです。 "XML Web サービスでできることは何ですか?最初の XML Web サービスは、株価、天気予報、スポーツスコアなどのアプリケーションに簡単に組み込むことができる情報源である傾向があります。関心のある情報を分析して集計し、さまざまな方法で提示するために構築できるアプリケーションのクラス全体を想像するのは簡単です。たとえば、財務全体 (株式、401K、銀行口座、ローンなど) を要約した Microsoft® Excel スプレッドシートがあるとします。この情報が XML Web サービスを通じて利用できる場合は、Excel で継続的に更新できます。この情報の一部は無料であり、サービスのサブスクリプションが必要な場合もあります。この情報のほとんどは Web で利用できるようになりましたが、XML Web サービスを使用すると、プログラムによるアクセスがより簡単で信頼性が高くなります。

既存のアプリケーションを XML Web サービスとして公開すると、ユーザーは XML Web サービスを構成要素として使用する、より強力な新しいアプリケーションを構築できます。たとえば、ユーザーが購入アプリケーションを開発して、さまざまな仕入先から価格情報を自動的に取得し、ユーザーが仕入先を選択し、注文を送信し、受け取るまで出荷を追跡することができます。ベンダーアプリケーションは、Web 上でサービスを公開するだけでなく、XML Web サービスを使用して顧客のクレジットをチェックし、顧客のアカウントに課金し、出荷会社に出荷を設定する可能性があります。

将来的には、最も興味深い XML Web サービスの中には、Web を使用して現在実行できないことを行うアプリケーションがサポートされる予定です。たとえば、XML Web サービスで可能になるサービスの 1 つは、カレンダーサービスです。歯科医師と整備士がこの XML Web サービスを通じて予定表を公開している場合は、予定をオンラインでスケジュールすることも、必要に応じて予定表でクリーニングや定期的なメンテナンスの予定を直接スケジュールすることもできます。少し想像力を持って、あなたは、Webをプログラムする能力を持っている後に構築することができるアプリケーションの数百を想像することができます。

XML Web サービスと、構築に役立つアプリケーションの詳細については、MSDN XML Web Services デベロッパーセンターを参照してください。

SOAP

Soap は、XML Web サービスの通信プロトコルです。 SOAP が通信プロトコルとして記述されている場合、ほとんどの人は DCOM または CORBA を考えて、「SOAP はどのようにオブジェクトのアクティブ化を行いますか?」や「SOAP で使用される名前付けサービス」などの質問を開始します。SOAP 実装にはこれらのものが含まれる可能性はありますが、SOAP 標準では指定されません。 SOAP は、メッセージの XML 形式を定義する仕様であり、仕様の必要な部分に関するものです。いくつかの SOAP 要素で囲まれた整形式の XML フラグメントがある場合は、SOAP メッセージが表示されます。単純ではありませんか?

SOAP 仕様には、プログラムデータを XML として表す方法と、SOAP を使用してリモートプロシージャ呼び出しを実行する方法を説明する他の部分があります。仕様のこれらの省略可能な部分は、呼び出し可能な関数を含む SOAP メッセージと関数に渡すパラメーターがクライアントから送信され、サーバーが実行された関数の結果を含むメッセージを返す RPC スタイルのアプリケーションを実装するために使用されます。 SOAP の最新の実装では、COM または CORBA アプリケーションの実行に慣れているプログラマが RPC スタイルを理解しているため、RPC アプリケーションがサポートされています。 SOAP では、SOAP メッセージが XML ドキュメントのラッパーであるドキュメントスタイルアプリケーションもサポートされています。ドキュメントスタイルの SOAP アプリケーションは非常に柔軟性が高く、多くの新しい XML Web サービスはこの柔軟性を利用して、RPC を使用して実装するのが困難なサービスを構築します。

SOAP 仕様の最後の省略可能な部分は、SOAP メッセージを含む HTTP メッセージの外観を定義します。 HTTP はほぼすべての現在の OS (および多くの最新ではない OS) でサポートされているため、この HTTP バインディングは重要です。 HTTP バインディングは省略可能ですが、SOAP の唯一の標準化されたプロトコルであるため、ほぼすべての SOAP 実装でサポートされています。このため、SOAP には HTTP が必要であるという一般的な誤解があります。一部の実装では MSMQ、MQ シリーズ、SMTP、または TCP/IP トランスポートがサポートされていますが、ほとんどの現在の XML Web サービスは、ユビキタスであるため HTTP を使用します。 HTTP は Web のコアプロトコルであるため、ほとんどの組織には、HTTP をサポートするネットワークインフラストラクチャと、それを既に管理する方法を理解しているユーザーがいます。現在、HTTP のセキュリティ、監視、負荷分散インフラストラクチャをすぐに利用できます。

SOAP の使用を開始するときの混乱の主な原因は、SOAP 仕様と SOAP 仕様の多くの実装の違いです。 SOAP を使用するほとんどのユーザーは、SOAP メッセージを直接書き込むのではなく、SOAP ツールキットを使用して SOAP メッセージを作成および解析します。これらのツールキットは通常、関数呼び出しを何らかの言語から SOAP メッセージに変換します。たとえば、Microsoft SOAP Toolkit 2.0 は COM 関数呼び出しを SOAP に変換し、Apache Toolkit は JAVA 関数呼び出しを SOAP に変換します。サポートされる関数呼び出しの種類とパラメーターのデータ型は、SOAP 実装ごとに異なるため、1 つのツールキットで動作する関数が別のツールキットで動作しない可能性があります。これは SOAP の制限ではなく、使用している特定の実装の制限です。

SOAP の最も魅力的な機能は、さまざまなハードウェアおよびソフトウェアプラットフォームに実装されていることです。つまり、SOAP を使用して、organizationの内外で異なるシステムをリンクできます。過去には、システム統合に使用できる一般的な通信プロトコルを考え出すために多くの試みが行われましたが、SOAP が広範に導入した人はいません。なぜですか? SOAP は、以前のプロトコルの多くよりもはるかに小さく、実装が簡単であるためです。たとえば、DCE と CORBA は実装に何年もかかったため、リリースされた実装はわずかでした。ただし、SOAP では、既存の XML パーサーと HTTP ライブラリを使用してほとんどのハードワークを実行できるため、SOAP の実装は数か月で完了できます。このため、70 を超える SOAP 実装を使用できます。 SOAPは明らかにDSEやCORBAが行うすべてを行うわけではありませんが、機能と引き換えに複雑さの欠如は、SOAPを非常に簡単に利用できるようにするためです。

HTTP のユビキタスと SOAP のシンプルさは、ほぼすべての環境から呼び出すことができる XML Web サービスを実装するための理想的な基礎となります。 SOAP の詳細については、MSDN SOAP のホームページを参照してください。

セキュリティについて

SOAP の初心者が最初に尋ねる質問の 1 つは、SOAP がセキュリティにどのように対処するかです。開発の初期段階では、SOAP は HTTP ベースのプロトコルと見なされていたため、HTTP セキュリティが SOAP に適していると想定されていました。結局のところ、HTTP セキュリティを使用して現在何千もの Web アプリケーションが実行されているため、これは SOAP に適しています。このため、現在の SOAP 標準では、セキュリティはトランスポートの問題であり、セキュリティの問題についてはサイレントであると想定しています。

SOAP が拡張されて、多数のトランスポート上で実行されるより汎用的なプロトコルになると、セキュリティがより大きな問題になりました。たとえば、HTTP では、どのユーザーが SOAP 呼び出しを行っているかを認証するいくつかの方法が提供されていますが、メッセージが HTTP から SMTP トランスポートにルーティングされるときに、その ID はどのように伝達されますか? SOAP は構成要素プロトコルとして設計されているため、幸いにも、WEB サービスの追加のセキュリティ機能を提供するために SOAP 上に構築する作業に既に仕様があります。 WS-Security 仕様では、完全な暗号化システムが定義されています。

WSDL

WSDL (多くの場合、whiz-dull と発音されます) は、Web サービス記述言語の略です。ここでは、WSDL ファイルは、SOAP メッセージのセットとメッセージの交換方法を記述する XML ドキュメントであると言えます。言い換えると、WSDL は CORBA または COM に対して IDL とは何かを SOAP することです。 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 の優れた説明が用意されており、WSDL 仕様はにあります http://www.w3.org/TR/wsdl。

UDDI

ユニバーサル検出の説明と統合は、Web サービスの黄色のページです。従来の黄色いページと同様に、必要なサービスを提供する会社を検索し、提供されたサービスについて読み、詳細については他のユーザーに問い合わせてください。もちろん、地下室でビジネスを開いて口コミ広告に頼るのと同じように、UDDI に登録せずに Web サービスを提供できますが、重要な市場に到達するには UDDI が必要です。顧客が見つけられるように UDDI が必要です。

UDDI ディレクトリエントリは、ビジネスと、それが提供するサービスを記述する XML ファイルです。 UDDI ディレクトリ内のエントリには、3 つの部分があります。「ホワイトページ」では、サービスを提供する会社 (名前、住所、連絡先など) について説明します。"黄色のページ" には、北米産業分類システムや標準産業分類などの標準分類に基づく産業カテゴリが含まれます。 "緑のページ" は、Web サービスを使用するアプリケーションを記述するのに十分な詳細なサービスへのインターフェイスを記述します。サービスの定義方法は、Type Model または tModel と呼ばれる UDDI ドキュメントを使用することです。多くの場合、tModel には XML Web サービスへの SOAP インターフェイスを記述する WSDL ファイルが含まれていますが、tModel はほぼすべての種類のサービスを記述するのに十分な柔軟性を備えています。

UDDI ディレクトリには、アプリケーションをビルドするために必要なサービスを検索するいくつかの方法も含まれています。たとえば、指定した地理的な場所にあるサービスのプロバイダーや、指定した種類のビジネスのプロバイダーを検索できます。その後、UDDI ディレクトリから情報、連絡先、リンク、技術データが提供され、要件を満たすサービスを評価できます。

UDDI を使用すると、Web サービスの取得元となる可能性のある企業を検索できます。ビジネスを行う相手が既にわかっていても、どのようなサービスが提供されているかがわからない場合はどうすればよいでしょうか。 WS-Inspection 仕様を使用すると、特定のサーバーで提供される XML Web サービスのコレクションを参照して、ニーズを満たす可能性のある 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 は、グローバル Web サービスアーキテクチャの仕様の 1 つです。多くのサーバー間でメッセージをルーティングし、それらのサーバーを動的に処理するように構成するなどの運用管理のニーズもグローバル Web サービスアーキテクチャの一部であり、WS-Routing 仕様と WS-Referral 仕様で満たされています。グローバル Web サービスアーキテクチャが拡大するにつれて、これらのニーズやその他のニーズの仕様が導入されます。

詳細については、グローバル XML Web サービスアーキテクチャに関するページを参照してください。

次の方法で共有