Webサービス関連の概念-PHP开发-php.cn

1. はじめに

誰もが多かれ少なかれ WebService (Web サービス) について聞いたことがあるでしょう。多くのコンピューター雑誌、書籍、Web サイトで、多くの自慢や宣伝が含まれ、WebService テクノロジーについて言及され、宣伝されてきました。しかし、WebService が実際には新興の有望なテクノロジであることを認めなければなりません。それでは、WebService とは一体何なのでしょうか?いつ使用する必要がありますか?

現在のアプリケーション開発は、徐々に 2 つのまったく異なる傾向を示しています。1 つはブラウザベースのシンクライアントアプリケーション、もう 1 つはブラウザベースのリッチクライアントアプリケーション (RIA)、そしてもちろんもう 1 つはブラウザベースのシンクライアントアプリケーションです。このテクノロジーは比較的ファッショナブルなものであり (現在人気の Html5 テクノロジーなど)、ここでは主に前者について説明します。

ブラウザベースのシンクライアントアプリケーションは、シンクライアントがより優れたユーザーインターフェースを提供できるからではなく、デスクトップアプリケーションの公開にかかる高額なコストを回避できるからです。デスクトップアプリケーションの公開にはコストがかかります。その理由の 1 つはアプリケーションのインストールと構成の問題、もう 1 つはクライアントとサーバー間の通信の問題です。従来の Windows リッチクライアントアプリケーションは、DCOM を使用してサーバーと通信し、リモートオブジェクトを呼び出します。大規模なネットワークで適切に動作するように DCOM を構成することは非常に困難な作業であり、多くの IT エンジニアにとって悪夢でもあります。実際、多くの IT エンジニアは、LAN 上で DCOM を実行するよりも、ブラウザによってもたらされる機能制限に耐えることを望んでいます。クライアントとサーバー間の通信の問題に関しては、HTTP プロトコルを使用して通信するのが完全な解決策です。これは、Web ブラウザを実行しているマシンはすべて HTTP プロトコルを使用しているためです。同時に、現在のファイアウォールの多くは HTTP 接続のみを許可するように構成されています。多くの商用プログラムが直面するもう 1 つの問題は、他のプログラムとの相互運用性です。すべてのアプリケーションが COM または .NET 言語を使用して記述され、すべて Windows プラットフォームで実行されれば、世界は平和になるでしょう。しかし、実際には、ほとんどのビジネスデータは依然としてメインフレーム上に非リレーショナルファイル (VSAM) の形式で保存されており、COBOL 言語で記述されたメインフレームプログラムによってアクセスされます。さらに、多くの商用プログラムは、引き続き C++、Java、Visual Basic、およびその他のさまざまな言語で作成されています。現在、最も単純なプログラムを除くすべてのプログラムは、他の異種プラットフォームで実行されているアプリケーションとデータを統合し、交換する必要があります。このようなタスクは通常、ファイル転送と分析、メッセージキュー、IBM の Advanced Program to Program Communication (APPC) などの特定の状況にのみ適した API などの特殊な方法によって実行されます。以前は、プラットフォーム、コンポーネントモデル、プログラミング言語に依存しないアプリケーション通信標準は存在しませんでした。 Web サービスを通じてのみ、クライアントとサーバーは、2 つのプログラムのプラットフォームやプログラミング言語に関係なく、HTTP を使用して自由に通信できます。

2. WebService とは正確には何ですか? 一言で言えば、WebService はクロスプログラミング言語およびクロスオペレーティングシステムプラットフォームのリモート呼び出しテクノロジです。

いわゆるクロスプログラミング言語とクロスオペレーティングプラットフォームとは、サーバープログラムを Java で記述し、クライアントプログラムを他のプログラミング言語で記述でき、その逆も可能であることを意味します。クロスオペレーティングシステムプラットフォームとは、サーバープログラムとクライアントプログラムが異なるオペレーティングシステム上で実行できることを意味します。

いわゆるリモート呼び出しは、あるコンピューター A 上のプログラムが別のコンピューター B 上のオブジェクトに呼び出すことができるメソッドです。たとえば、UnionPay がモールに提供する POS カードスワイプシステム、POS によって呼び出される転送メソッドなどです。モール内の機械送金コードは実際には銀行サーバー上で実行されます。別の例として、Amazon、天気予報システム、淘宝網、Xiaonei.com、Baidu などは、自社のシステムサービスを Web サービスサービスの形式で公開し、サードパーティの Web サイトやプログラムがこれらのサービス機能を呼び出すことを可能にし、その結果、市場シェアを拡大しています。より大きな概念で言えば、効率とはいわゆる SOA アプリケーションです。

実際、WebService は、表面的には、Web を通じて呼び出すことができる API を外部に公開するアプリケーションです。つまり、Web を通じてアプリケーションを呼び出すことができます。プログラミング手法を使用します。この WebService を呼び出すアプリケーションをクライアントと呼び、この WebService を提供するアプリケーションをサーバーと呼びます。より深い観点から見ると、WebService は相互運用可能な分散アプリケーションを構築するための新しいプラットフォームであり、一連の標準です。これは、アプリケーションが Web 上で相互運用性を実現する方法を定義します。Web サービス標準を通じてこれらのサービスにクエリおよびアクセスできる限り、任意の言語および任意のプラットフォームで Web サービスを作成できます。

WebService プラットフォームでは、分散アプリケーションの作成を実現するために一連のプロトコルが必要です。どのプラットフォームにも、そのデータ表現方法と型システムがあります。相互運用性を実現するには、WebService プラットフォームは、異なるプラットフォーム、プログラミング言語、およびコンポーネントモデルで異なる型システムを通信するための標準型システムを提供する必要があります。 Web サービスプラットフォームは、顧客が Web サービスを呼び出すのに十分な情報を取得できるように、Web サービスを記述するための標準を提供する必要があります。最後に、この Web サービスをリモートで呼び出す方法が必要です。このメソッドは実際にはリモートプロシージャコールプロトコル (RPC) です。相互運用性を実現するには、この RPC プロトコルがプラットフォームやプログラミング言語に依存しない必要もあります。

3. WebService プラットフォームテクノロジー

WebService プラットフォームを構成する 3 つの主要なテクノロジーは XML+XSD、SOAP、WSDL です。

3.1、XML + XML は、WebService プラットフォームでデータを表現するための形式です。 XML の主な利点は、作成と解析が簡単であることに加えて、プラットフォームとベンダーに依存しないことです。技術的な優位性よりも無関係性の方が重要です。ソフトウェアベンダーは競合他社が発明したテクノロジーを選択しません。

XML はデータ表現の問題を解決しますが、標準データ型のセットを定義しておらず、ましてやこのデータ型のセットを拡張する方法も定義していません。たとえば、整数は正確に何を表すのでしょうか? 16ビット、32ビット、64ビット?これらの詳細は、相互運用性を実現するために重要です。 XML スキーマ (XSD) は、この問題を具体的に解決する一連の標準です。データ型の標準セットを定義し、このデータ型セットを拡張する言語を提供します。 WebService プラットフォームは、データ型システムとして XSD を使用します。特定の言語 (VB.NET や C# など) を使用して Web サービスを構築する場合、WebService 標準に準拠するために、使用するすべてのデータ型を XSD 型に変換する必要があります。使用しているツールによってこの変換が自動的に完了する場合もありますが、ニーズに合わせて変換プロセスを変更する可能性が高くなります。

3.2、SOAP

WebService が HTTP プロトコルを通じてリクエストを送信し、結果を受信する場合、送信されるリクエストのコンテンツと結果のコンテンツは XML 形式でカプセル化され、HTTP メッセージのコンテンツ形式を示すためにいくつかの特定の HTTP メッセージヘッダーが追加されます。これらの特定の HTTP ヘッダーと XML コンテンツの形式は SOAP プロトコルです。 SOAP は、Web サービスを呼び出すための標準 RPC メソッドを提供します。

SOAP プロトコル = HTTP プロトコル + XML データ形式

SOAP プロトコルは、SOAP メッセージの形式を定義します。SOAP プロトコルは、XML と XML のデータエンコード方式にも基づいています。石鹸。たとえて言えば、HTTP は通常の高速道路、XML は中央の緑色の隔離ベルトと両側のガードレール、SOAP は通常の高速道路に隔離ベルトとガードレールを追加して変形した高速道路です。

3.3, WSDL

私たちが何かを買うために店に行くときと同じように、まず店で何が入手できるかを知り、それから購入を行う必要があります。企業が行うことは広告ポスターを貼ることです。 WebService サービスを呼び出すには、WebService クライアントはまずサービスのアドレスと、サービス内でどのメソッドを呼び出すことができるかを知る必要があります。したがって、WebService サーバーは最初に WSDL ファイルを使用してそのホームを記述する必要があります。ページには、どのようなサービスを外部から呼び出すことができるか、そのサービスとは何か (そのサービスにはどのようなメソッドがあるか、そのメソッドでどのようなパラメータが受け入れられるか、戻り値は何か)、サービスのネットワークアドレスを表すためにどの URL アドレスが使用されるかが表示されます。、そしてそのサービスはどのように呼ばれるのでしょうか？

WSDL (Web Services description Language) は、Web サービスとその関数、パラメーター、戻り値を記述するために使用される XML ベースの言語です。これは、WebService クライアントとサーバーの両方が理解できる標準形式です。 WSDL は XML に基づいているため、機械でも人間でも判読可能であり、これには大きな利点があります。最新の開発ツールの中には、Web サービスに基づいて WSDL ドキュメントを生成できるだけでなく、WSDL ドキュメントをインポートして、対応する WebService を呼び出すプロキシクラスコードを生成することもできます。

WSDLファイルはWebサーバー上に保存され、URLアドレスを通じてアクセスできます。クライアントは、WebService サービスを呼び出す前に、サービスの WSDL ファイルのアドレスを知っている必要があります。 WebService サービスプロバイダーは、WSDL ファイルアドレスを次の 2 つの方法で公開できます。1. UDDI サーバーに登録して、見つけられるようにします。2. クライアントの呼び出し元に直接通知します。

4. WebService 開発

WebService 開発はサーバーサイド開発とクライアントサイド開発の 2 つの側面に分けられます

4.1. サーバーサイド開発

社内システムのビジネスメソッドをリモート向け WebService サービスに公開します協力ユニットと個人が移動します。 (一部の WebService フレームワークを利用すると、ビジネスオブジェクトを WebService サービスに簡単に公開できます。Java の典型的な WebService フレームワークには、axis、xfire、cxf などが含まれます。Java ee サーバーは、通常、JBoss などの WebService サービスの公開もサポートしています。)

4.2. クライアント開発

他者が公開した WebService サービスの呼び出しほとんどの人は、天気予報 WebService サービスの呼び出しなど、この分野の開発に従事しています。 (WSDL2Java などのメーカーのツールを使用して、静的に呼び出されるプロキシクラスコードを生成します。メーカーが提供するクライアントプログラミング API クラスを使用します。SUN の初期の標準 jax-rpc 開発キットを使用します。SUN の最新の標準 jax-ws 開発キットを使用します。もちろん SUN ORACLE によって取得されています)

4.3. WebService の動作原理

クライアントの場合、wsdl ファイルの URL アドレスをこれらのさまざまな WebService クライアント API に渡し、これらの API は基盤となるプロキシクラスを作成し、アクセスできます。これらのプロキシを呼び出して Webservice サービスを実行します。プロキシクラスは、クライアントのメソッド呼び出しをSOAP形式のリクエストデータにしてHTTPプロトコルで送信し、受信したSOAPデータを戻り値に返します。サーバーにとって、さまざまな Web サービスフレームワークの本質は、リモート呼び出しクライアントが http プロトコルを介して SOAP 形式でリクエストデータを送信すると、データを分析し、どの Java クラスを呼び出して、どのメソッドを呼び出すかを認識します。このオブジェクトを作成し、そのメソッドを呼び出し、メソッドから返された結果を SOAP 形式のデータにパッケージ化し、http 応答メッセージを通じてクライアントに送り返します。

5. 適用される場面

1. ファイアウォールを越えた通信

アプリケーションに何千ものユーザーがいて、世界中に分散している場合、クライアントとサーバー間の通信は厄介な問題になります。通常、クライアントとサーバーの間にはファイアウォールまたはプロキシサーバーが存在するためです。この場合、DCOM の使用はそれほど単純ではなく、クライアントプログラムを多数のユーザーに公開するのは通常は不便です。従来のアプローチでは、ブラウザをクライアントとして使用し、多くの ASP ページを作成し、アプリケーションの中間層をエンドユーザーに公開することを選択します。その結果、開発とプログラムの保守が困難になります。中間層コンポーネントが WebService に置き換えられた場合、中間層コンポーネントはユーザーインターフェイスから直接呼び出すことができます。ほとんどの人の経験から判断すると、ユーザーインターフェイスと中間層の間で多くの対話が行われるアプリケーションでは、WebService の構造を使用すると、ユーザーインターフェイスプログラミングに費やす開発時間を 20% 節約できます。

2. アプリケーションの統合

エンタープライズレベルのアプリケーション開発者は皆、企業ではさまざまな言語で書かれ、さまざまなプラットフォームで実行されるさまざまなプログラムを統合する必要があり、この統合には多大な開発力がかかることを知っています。アプリケーションは多くの場合、IBM メインフレーム上で実行されているプログラムからデータを取得したり、メインフレームまたは UNIX アプリケーションにデータを送信したりする必要があります。同じプラットフォーム上であっても、異なるソフトウェアベンダーが製造したさまざまなソフトウェアを統合する必要がある場合がよくあります。 WebService を通じて、異なる構造のアプリケーションを簡単に統合できます。

3. B2B 統合

WebService を使用してアプリケーションを統合すると、企業の内部業務処理をより自動化できます。しかし、取引がサプライヤーと顧客にまたがり、企業の境界を押し広げるとどうなるでしょうか?企業間のビジネス取引の統合は、B2B 統合と呼ばれることがよくあります。 WebService は B2B 統合を成功させる鍵です。 WebService を通じて、企業は主要なビジネスアプリケーションを指定されたサプライヤーや顧客に「公開」できます。たとえば、電子注文システムと電子請求システムを「公開」することで、顧客は注文を電子的に送信でき、サプライヤーは原材料購入請求書を電子的に送信できます。もちろん、これは新しい概念ではなく、EDI (Electronic Document Interchange) は昔からこのようなものでした。ただし、WebService の実装は EDI よりもはるかに簡単で、WebService はインターネット上で動作し、世界中のどこにでも簡単に実装できるため、運用コストが比較的低くなります。ただし、WebService は、EDI のようなドキュメント交換や B2B 統合のための完全なソリューションではありません。 WebService は B2B 統合の重要な部分にすぎず、統合を実現するには他の多くの部分が必要です。

WebService を使用して B2B 統合を実現する最大の利点は、相互運用性を簡単に実現できることです。ビジネスロジックが「公開」されて Web サービスになる限り、指定されたパートナーは、システムがどのプラットフォームで実行されているか、またはどの開発言語が使用されているかに関係なく、これらのビジネスロジックを呼び出すことができます。これにより、B2B 統合に費やす時間とコストが大幅に削減され、EDI を用意できない多くの中小企業が B2B 統合を実現できるようになります。

4. ソフトウェアとデータの再利用

ソフトウェアの再利用は大きなテーマであり、再利用にはさまざまな形式があり、再利用の程度も異なります。最も基本的な形式はソースコードモジュールまたはクラスレベルの再利用で、その 1 つの形式はバイナリ形式のコンポーネントの再利用です。 WebService アプリケーションは、標準的な方法を使用して、他のアプリケーションで使用できる機能とデータを「公開」し、ビジネスレベルの再利用を実現できます。

6. 適用されない場合

1. スタンドアロンアプリケーション

現在、企業や個人は依然として多くのデスクトップアプリケーションを使用しています。それらの中には、単にマシン上の他のプログラムと通信する必要があるものもあります。この場合、WebService を使用せず、ローカル API を使用するのが最善です。 COM は小さくて高速であるため、この状況での作業に最適です。同じサーバー上で実行されているサーバーソフトウェアについても同様です。アプリケーション間で呼び出しを行うには、COM またはその他のローカル API を直接使用するのが最善です。もちろん、このような状況でも WebService を使用することはできますが、消費量が多すぎるだけでなく、メリットもありません。

2. LAN 上の同型アプリケーション

多くのアプリケーションでは、すべてのプログラムは VB または VC で開発され、すべて Windows プラットフォームで COM を使用し、すべてが同じ LAN 上で実行されます。たとえば、相互に通信する必要がある 2 つのサーバーアプリケーションがあるか、LAN 上の別のサーバープログラムに接続したい Win32 または WinForm クライアントプログラムがあるとします。これらのプログラムでは、SOAP/HTTP よりも DCOM を使用した方がはるかに効率的です。同様に、.NET プログラムが LAN 上の別の .NET プログラムに接続する場合は、.NET リモート処理を使用する必要があります。興味深いことに、.NETremoting では、SOAP/HTTP を使用して WebService 呼び出しを行うように指定することもできます。ただし、TCP 経由で直接 RPC 呼び出しを行う方がはるかに効率的です。

WebService の概念に関連するその他の記事については、PHP 中国語 Web サイトに注目してください。