Web サービスの仕組み
- 高洛峰オリジナル
- 2016-12-15 14:50:321390ブラウズ
Webサービスの基本概念
WebサービスはXML Webサービスとも呼ばれ、インターネットやイントラネット上の他のシステムから渡されるリクエストを受信できる軽量の独立した通信技術です。はい: SOAP を介して Web 上で配信され、WSDL ファイルを使用して記述され、UDDI を介して登録されるソフトウェア サービス。
XML: (拡張マークアップ言語) 拡張マークアップ言語。短期の一時的なデータ処理と World Wide Web にとって、これは Soap の基礎です。
Soap: (シンプル オブジェクト アクセス プロトコル) シンプル オブジェクト アクセス プロトコル。 XML Web Serviceの通信プロトコルです。ユーザーが UDDI を通じて WSDL 記述ドキュメントを見つけると、SOAP を通じて作成した Web サービス内の 1 つ以上のオペレーションを呼び出すことができます。 SOAP は、XML ドキュメントの形式でメソッドを呼び出すための仕様であり、HTTP(S) や SMTP などのさまざまな基礎となるインターフェイスをサポートできます。
WSDL: (Web サービス記述言語) WSDL ファイルは、一連の SOAP メッセージとその交換方法を記述する XML ドキュメントです。ほとんどの場合、ソフトウェアによって自動的に生成され、使用されます。
UDDI (Universal description, Discovery, and Integration) は、主に Web サービスプロバイダーとユーザーを対象とした新しいプロジェクトです。ユーザーが Web サービスを呼び出す前に、サービスにどのビジネス メソッドが含まれているかを判断し、呼び出されるインターフェイス定義を見つけて、サーバー側でソフトウェアをコンパイルする必要があります。UDDI は、システムがそれに基づいて対応するサービスを見つけるようにガイドするメカニズムです。説明文書。 UDDI は、SOAP メッセージング メカニズム (標準 XML/HTTP) を使用して、登録情報を公開、編集、参照、検索します。 XML 形式を使用してさまざまなタイプのデータをカプセル化し、それを登録センターに送信するか、登録センターが必要なデータを返します。
呼び出し原理:
Web サービスには 2 つの意味があります: 1. 単一のエンティティにカプセル化され、ネットワーク上に公開される関数コレクションを指します。 2. 関数コレクションが呼び出された後に提供されるサービスを指します。 。簡単に言うと、Web サービスは URL リソースであり、クライアントは、要求されたサービスがどのように実装されるかを知らなくても、プログラムによってそのサービスを要求できます。これは、従来の分散コンポーネント オブジェクト モデルとは異なります。
Web サービスのアーキテクチャは、Web サービスプロバイダー、Web サービスリクエスター、Web サービス仲介者の 3 つの役割と、公開、検出、バインドの 3 つのアクションに基づいて構築されます。簡単に言うと、Web サービス プロバイダーは Web サービスの所有者であり、独自の機能が他のサービスやユーザーに提供されるのを辛抱強く待ちます。Web サービス リクエスターは Web サービス機能のユーザーであり、SOAP メッセージを使用して提供します。 Web サービス: リクエスタはサービスを取得するためにリクエストを送信します。Web サービス仲介者の役割は、Web サービス リクエスタを適切な Web サービス プロバイダー (通常は UDDI) に接続することです。これら 3 つの役割は、論理関係に基づいて分割されます。実際のアプリケーションでは、役割が重複する場合があります。Web サービスは、Web サービス プロバイダー、Web サービス リクエスタ、またはその両方になります。 Web サービスの役割間の関係を示します。このうち、「公開」は、特定の Web サービスの存在と関連情報をユーザーまたは他のサービスに知らせることです。「検索 (検出)」は、適切な Web サービスを見つけることです。 」は、プロバイダーとリクエスターの間に何らかの接続を確立することです。
図 2-1 Web サービスのアーキテクチャ
完全な Web サービスの実装には、次の手順が含まれます。
◆ Web サービス プロバイダーは Web サービスを設計および実装し、正しくデバッグされた Web サービスを Web サービス仲介者に渡します。著者によって公開され、UDDI 登録センターに登録されます。(公開済み)
◆ Web サービス要求者は Web サービス仲介者に特定のサービスを要求し、仲介者はその要求に従って UDDI 登録センターに問い合わせて、条件を満たすサービスを見つけます。要求元への要求 (Discover)
◆ Web サービス仲介者は、条件を満たす Web サービス記述情報を Web サービス要求元に返します。記述情報は WSDL で記述され、Web サービスをサポートするさまざまなマシンで読み取ることができます。 (発見)
◆ Web サービスから利用 メディエーターから返された記述情報は、対応する SOAP メッセージを生成し、Web サービス プロバイダーに送信して、Web サービスの呼び出しを実現します (バインディング)
◆ Web サービス プロバイダーSOAPメッセージに従って対応するWebサービスを実行し、サービス結果をWebサービス要求元に送信します。 (バインディング)
呼び出し方法:
1. Net (C#) で GET/POST/SOAP メソッドを使用して WebService を動的に呼び出すシンプルで柔軟な方法
WebService を呼び出すには 3 つの方法があります
1)。 . httppost
3)。 httpsoap
ところで、soap は最終的に HTTP を使用して XM を送信します
メッセージ データの暗号化 (XML 暗号化) デジタル署名 (XML-DSIG)
基礎となるアーキテクチャ アプリケーション サービスのセキュリティ メカニズムを利用する
送信中のセキュリティは、既存の SSL および HTTPS プロトコルを使用して Web サービス アプリケーションに追加するのが最も簡単です。接続プロセス中にセキュリティを確保します。
しかし、このセキュリティ実装方法には 2 つの弱点があります。まず、データ送信のセキュリティのみが保証され、データ自体のセキュリティは保証されません。データが特定の場所に到達すると、誰でも閲覧できるようになります。 Web サービスでは、1 つのデータが複数の場所に到達する可能性がありますが、このデータはすべての受信者が閲覧できるわけではありません。 2 番目に、全か無かの保護が提供されます。データのどの部分を保護するかを選択することはできません。この選択性は Web サービスでもよく使用されます。
保護の 2 番目の層は、メッセージ自体の保護です。既存の XML セキュリティ拡張標準を使用してデジタル署名機能を実装し、メッセージが特定の当事者から送信され、変更されていないことを保証できます。 XML ファイルの暗号化技術により、Web サービスのセキュリティが大幅に強化され、送信後に受信者がデータを閲覧できるかどうかをカスタマイズできるため、業界では Web サービスのセキュリティ標準の策定も継続的に行われています。 . SAML や WS-Security など。
保護の最後の層は、基礎となるアーキテクチャのセキュリティに依存しており、オペレーティング システムと一部のミドルウェアの保護から得られます。たとえば、J2EE では、Web サービスをホストするアプリケーション サーバーです。現在、多くの J2EE アプリケーション サーバーは、最近 J2SE 1.4 に追加された Java Authentication and Authorization Service (JAAS) をサポートしています。 Web サービスをホストするサーバーを使用して、いくつかのセキュリティ メカニズムを実装するのは自然なことです。基礎となるアーキテクチャのセキュリティを活用するもう 1 つの方法は、セキュリティを担当する独立したサーバーを作成することです。Web サービスのユーザーと作成者は、このサーバーに対してセキュリティの信頼を得る必要があります。
特徴:
Web サービスの主な目標は、クロスプラットフォームの相互運用性です。この目標を達成するために、Web サービスは、XML (拡張マークアップ言語) や XSD (XML スキーマ) などのプラットフォームに依存せず、ソフトウェア ベンダーに依存しない標準に完全に基づいており、相互運用可能な分散アプリケーションを作成するための新しいプラットフォームです。したがって、Web サービスの使用には多くの利点があります:
1. ファイアウォールを越えた通信
アプリケーションに何千ものユーザーがいて世界中に分散している場合、クライアントとサーバー間の通信は厄介な問題になります。通常、クライアントとサーバーの間にはファイアウォールまたはプロキシ サーバーが存在するためです。従来のアプローチでは、ブラウザをクライアントとして使用し、多くの ASP ページを作成し、アプリケーションの中間層をエンド ユーザーに公開することを選択します。その結果、開発とプログラムの保守が困難になります。 クライアント側のコードが HTML フォームにあまり依存しなくなれば、クライアント側のプログラミングははるかに簡単になります。中間層コンポーネントを Web サービスに置き換えると、中間層コンポーネントをユーザー インターフェイスから直接呼び出すことができるため、ASP ページを作成する手順が不要になります。 Web サービスを呼び出すには、Microsoft SOAP Toolkit や .net などの SOAP クライアントを直接使用することも、独自に開発した SOAP クライアントを使用してアプリケーションに接続することもできます。開発サイクルが短縮されるだけでなく、コードの複雑さが軽減され、アプリケーションの保守性も向上します。同時に、アプリケーションは中間層コンポーネントを呼び出すたびに、対応する「結果ページ」にジャンプする必要がなくなりました。
2. アプリケーションの統合
エンタープライズレベルのアプリケーション開発者は皆、企業ではさまざまな言語で書かれ、さまざまなプラットフォームで実行されるさまざまなプログラムを統合する必要があり、この統合には多大な開発力がかかることを知っています。アプリケーションは多くの場合、ホスト上で実行されているプログラムからデータを取得したり、ホストまたは他のプラットフォーム アプリケーションにデータを送信したりする必要があります。同じプラットフォーム上であっても、異なるソフトウェア ベンダーが製造したさまざまなソフトウェアを統合する必要があることがよくあります。 Web サービスを通じて、アプリケーションは標準的な方法を使用して、他のアプリケーションで使用できる機能とデータを「公開」できます。
XML Web サービスは、疎結合環境で標準プロトコル (HTTP、XML、SOAP、WSDL) を使用してメッセージを交換する機能を提供します。メッセージは、構造化、型指定、または大まかに定義することができます。
3. B2B 統合
B2B は、企業が他の企業と取引する場合と同様に、企業間 (一般に企業を指します) から企業間の電子商取引、つまりインターネットや取引所を介した企業間の製品やサービスを指します。情報の。平たく言えば、電子商取引の供給側と需要側の両方が販売者（または企業、企業）であり、インターネット技術やさまざまなビジネスネットワークプラットフォームを使用して商取引のプロセスを完了することを意味します。
Web サービスは B2B 統合を成功させる鍵です。 Web サービスを通じて、企業は指定されたサプライヤーや顧客に主要なビジネス アプリケーションを単に「公開」することができます。Web サービスはインターネット上で実行され、世界中のどこでも簡単に実装でき、運用コストは比較的低くなります。 Web サービスは B2B 統合の重要な部分にすぎず、統合を実現するには他の多くの部分が必要です。 Web サービスを使用して B2B 統合を実装する最大の利点は、相互運用性を簡単に実現できることです。ビジネス ロジックが「公開」され、Web サービスになる限り、指定されたパートナーは、システムがどのプラットフォームで実行されているか、または使用している開発言語に関係なく、これらのビジネス ロジックを呼び出すことができます。これにより、B2B 統合にかかる時間とコストが大幅に削減されます。
4. ソフトウェアとデータの再利用
Web サービスでは、コードの再利用と同時に、コードの背後にあるデータも再利用できます。 Web サービスを使用すると、以前のようにサードパーティからソフトウェア コンポーネントを購入してインストールする必要がなくなり、アプリケーションからこれらのコンポーネントを呼び出すだけで済みます。ソフトウェアの再利用のもう 1 つの状況は、複数のアプリケーションの機能を統合し、Web サービスを通じてそれらを「公開」することです。これらすべての機能をポータル サイトに簡単に統合し、統一された使いやすいインターフェイスをユーザーに提供できます。 サードパーティの Web サービスが提供する機能をアプリケーションで使用したり、独自のアプリケーションの機能を Web サービスを通じて他のユーザーに提供したりできます。どちらの場合も、コードとその背後にあるデータは再利用できます。
上記の説明からわかるように、Web サービスは、Web を介して相互運用またはリモート呼び出しを実行する場合に最も役立ちます。ただし、Web サービスにはまったくメリットが得られない場合もあります。Web サービスには次のような欠点があります。
1. スタンドアロン アプリケーション
現在、企業や個人は依然として多くのデスクトップ アプリケーションを使用しています。それらの中には、マシン上の他のプログラムと通信するだけで十分なものもあります。この場合、Web サービスを使用せず、ローカル API を使用するのが最善です。 COM は小さくて高速であるため、この状況での作業に最適です。同じサーバー上で実行されているサーバー ソフトウェアについても同様です。もちろん、このような状況でも Web サービスを使用することはできますが、消費量が多すぎるだけでなく、何のメリットもありません。
2. LAN 上の一部のアプリケーション
多くのアプリケーションでは、すべてのプログラムが Windows プラットフォームで COM を使用し、同じ LAN 上で実行されます。これらのプログラムでは、SOAP/HTTP よりも DCOM を使用した方がはるかに効率的です。同様に、.net プログラムが LAN 上の別の .net プログラムに接続したい場合は、.net Remoting を使用する必要があります。実際、.net Remoting では、SOAP/HTTP を使用して Web サービス呼び出しを行うように指定することもできます。ただし、TCP 経由で直接 RPC 呼び出しを行う方がはるかに効率的です。
1.3. XML Web サービスのアプリケーション
1. オリジナルの XML Web サービスは、通常、株価、天気予報、スポーツのスコアなど、アプリケーションに簡単に組み込むことができる情報ソースです。
2. 既存のアプリケーションを XML Web サービスとして提供すると、より強力な新しいアプリケーションを構築し、XML Web サービスを構成要素として活用できます。
たとえば、ユーザーはさまざまなサプライヤーから価格情報を自動的に取得する調達アプリケーションを開発できます。これにより、ユーザーはサプライヤーを選択し、注文を送信し、商品を受け取るまで商品の出荷を追跡できるようになります。サプライヤーのアプリケーションは、Web 上でサービスを提供するだけでなく、XML Web サービスを使用して顧客の信用を確認し、代金を回収し、運送会社との運送手続きを行うこともできます。
SOAP メッセージ形式:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>Web サービスの動作原理に関連するその他の記事については、PHP 中国語 Web サイトに注目してください。