Webサービス関連の概念

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 サイトに注目してください。