Webサービスとは何ですか? Archi構造、種類、例

ウェブサービスとは?

ウェブサービス WWW (World Wide Web) 上のクライアント アプリケーションとサーバー アプリケーション間の通信を伝播するための標準化された媒体です。 Web サービスは、特定の一連のタスクを実行するように設計されたソフトウェア モジュールです。

  • クラウド コンピューティングの Web サービスは、ネットワーク経由で検索でき、それに応じて呼び出すこともできます。
  • Web サービスは、呼び出されると、その Web サービスを呼び出すクライアントに機能を提供できます。

Webサービスはどのように機能するのか?

Webサービスの仕組み
Webサービスの仕組み

上の図は、Web サービスが実際にどのように動作するかを非常に単純化して示しています。 クライアントは、実際の Web サービスをホストするサーバーへのリクエストを介して、一連の Web サービス呼び出しを呼び出します。

これらのリクエストは、いわゆるリモート プロシージャ コールを通じて行われます。 リモート プロシージャ コール (RPC) は、関連する Web サービスによってホストされるメソッドに対して行われる呼び出しです。

一例として、 Amazon amazon.comでオンライン販売される商品の価格を提供するWebサービスを提供します。フロントエンドまたはプレゼンテーション層は.Netまたは Java ただし、どちらのプログラミング言語も Web サービスと通信する機能を備えています。

Web サービス設計の主なコンポーネントは、クライアントとサーバーの間で転送されるデータ、つまり XML です。 XML (拡張マークアップ言語) は HTML に相当するもので、多くのプログラミング言語で理解できる理解しやすい中間言語です。

したがって、アプリケーションが相互に通信するときは、実際には XML で通信します。 これにより、さまざまなプログラミング言語で開発されたアプリケーションが相互に通信できる共通のプラットフォームが提供されます。

Web サービスは、アプリケーション間で XML データを送信するために SOAP (Simple Object Access Protocol) として知られるものを使用します。 データは通常の HTTP 経由で送信されます。 Webサービスからアプリケーションに送信されるデータはSOAPメッセージと呼ばれます。 SOAP メッセージは単なる XML ドキュメントです。 ドキュメントは XML で記述されるため、Web サービスを呼び出すクライアント アプリケーションは任意のプログラミング言語で記述できます。

なぜ Web サービスが必要なのでしょうか?

現代のビジネスアプリケーションでは、Webベースのアプリケーションを開発するためにさまざまなプログラミングプラットフォームが使用されています。一部のアプリケーションは、 Java、その他は .Net で、その他は Angular JS、Node.js などで。

多くの場合、これらの異種アプリケーション間では何らかの通信が必要になります。異なる開発言語を使用して構築されているため、アプリケーション間の正確な通信を確保することは非常に困難になります。

ここで Web サービスが登場します。Web サービスは、さまざまな上に構築された複数のアプリケーションを可能にする共通のプラットフォームを提供します。 プログラミング言語 お互いにコミュニケーションをとる能力を持つこと。

Webサービスの種類

Webサービスには主にXNUMX種類あります。

  1. SOAP Web サービス。
  2. RESTful Webサービス.

Web サービスが完全に機能するには、所定のコンポーネントが必要です。 これらのコンポーネントは、Web サービスのプログラミングに使用される開発言語に関係なく、存在する必要があります。

これらのコンポーネントをさらに詳しく見てみましょう。

SOAP(シンプルオブジェクトアクセスプロトコル)

SOAP は、トランスポートに依存しないメッセージング プロトコルとして知られています。 SOAP は、XML データを SOAP メッセージとして転送することに基づいています。 各メッセージには、XML ドキュメントと呼ばれるものがあります。 XML ドキュメントの構造のみが特定のパターンに従いますが、コンテンツはに従いません。 Web サービスと SOAP の最も優れた点は、すべてが標準の Web プロトコルである HTTP 経由で送信されることです。

SOAP メッセージの構成要素は次のとおりです

  • 各 SOAP ドキュメントには、 要素。 ルート要素は、XML ドキュメントの最初の要素です。
  • 「封筒」はさらに 2 つの部分に分割されます。 最初はヘッダー、次は本文です。
  • ヘッダーにはルーティング データが含まれています。これは基本的に、XML ドキュメントをどのクライアントに送信する必要があるかを伝える情報です。
  • 本文には実際のメッセージが含まれます。

以下の図は、SOAP を介した通信の簡単な例を示しています。

SOAPプロトコル

SOAPプロトコル

SOAP については、この記事で詳しく説明します。 チュートリアル.

WSDL(Webサービス記述言語)

Webサービスが見つからないと利用できない。 Web サービスを呼び出すクライアントは、Web サービスが実際に存在する場所を知っている必要があります。

次に、クライアント アプリケーションは、適切な Web サービスを呼び出すことができるように、Web サービスが実際に何を行うのかを知る必要があります。 これは、Web サービス記述言語として知られる WSDL を利用して行われます。 WSDL ファイルも XML ベースのファイルであり、基本的に Web サービスが何を行うかをクライアント アプリケーションに伝えます。 WSDL ドキュメントを使用することにより、クライアント アプリケーションは Web サービスがどこにあるのか、どのように利用できるのかを理解できるようになります。

Web サービスの例

WSDL ファイルの Web サービスの例を以下に示します。

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

上記の Web サービスの WSDL 宣言の例に関して注意すべき重要な点は次のとおりです。

  1. – WSDL 定義のメッセージ パラメータは、Web サービスによって実行される各操作のさまざまなデータ要素を定義するために使用されます。したがって、上記の Web サービスの例では、Web サービスとクライアント アプリケーション間で交換できる 2 つのメッセージがあります。XNUMX つは「TutorialRequest」、もう XNUMX つは「TutorialResponse」操作です。TutorialRequest には、文字列型の「TutorialID」という要素が含まれています。同様に、TutorialResponse 操作には、やはり文字列型の「TutorialName」という要素が含まれています。
  2. – これは実際には、Web サービスによって実行できる操作を記述したもので、この場合は Tutorial と呼ばれます。この操作は 2 つのメッセージを受け取ることができます。XNUMX つは入力メッセージで、もう XNUMX つは出力メッセージです。
  3. – この要素には、使用されるプロトコルが含まれます。 したがって、私たちのケースでは、http (http://schemas.xmlsoap.org/soap/http)。また、名前空間やメッセージをエンコードするかどうかなど、操作本体のその他の詳細も指定します。

「WDSL」については、この記事で詳しく説明します。 チュートリアル.

ユニバーサル Descriptイオン、検出、統合 (UDDI)

UDDI は、特定のサービス プロバイダーが提供する Web サービスを記述、公開、および検出するための標準です。 これは、Web サービス上で情報をホストするのに役立つ仕様を提供します。

前回のトピックでは、WSDL と、Web サービスが実際に行う処理に関する情報がどのように含まれているかについて説明しました。しかし、クライアント アプリケーションは、Web サービスが提供するさまざまな操作を理解するために、どのようにして WSDL ファイルを見つけることができるのでしょうか。UDDI は、この答えであり、WSDL ファイルをホストできるリポジトリを提供します。そのため、クライアント アプリケーションは、すべての WSDL ファイルを含むデータベースとして機能する UDDI に完全にアクセスできます。

電話帳に特定の人の名前、住所、電話番号が含まれているのと同じように、UDDI レジストリに Web サービスの関連情報が含まれています。。 これにより、クライアント アプリケーションはそれがどこにあるかを知ることができます。

Web サービスの利点

Web サービスがそもそもなぜ生まれたのか、それは異なるアプリケーションが相互に通信できるようにするプラットフォームを提供するためだったということは、私たちはすでに理解しています。

しかし、Web サービスを使用することがなぜ重要なのかについて、Web サービスの利点のリストを見てみましょう。

  1. ビジネス機能をネットワーク上に公開する – Web サービスは、クライアント アプリケーションまたはエンド ユーザーに何らかの機能を提供するマネージ コードの単位です。 この機能は HTTP プロトコル経由で呼び出すことができます。つまり、インターネット経由でも呼び出すことができます。 現在では、すべてのアプリケーションがインターネット上に存在するため、Web サービスの目的はさらに便利になっています。 つまり、Web サービスはインターネット上のどこにでも配置でき、必要に応じて必要な機能を提供できます。
  2. アプリケーション間の相互運用性 – Web サービスを使用すると、さまざまなアプリケーションが相互に通信し、アプリケーション間でデータやサービスを共有できるようになります。 すべての種類のアプリケーションは相互に通信できます。 そのため、特定のアプリケーションのみが理解できる特定のコードを作成する代わりに、すべてのアプリケーションが理解できる汎用コードを作成できるようになりました。
  3. 誰もが理解できる標準化されたプロトコル – Webサービスは通信に業界標準のプロトコルを使用します。4つのレイヤー(サービストランスポート、XMLメッセージング、サービス Descriptイオンおよびサービス検出層) は、Web サービス プロトコル スタックで明確に定義されたプロトコルを使用します。
  4. 通信コストの削減 – Web サービスは SOAP over HTTP プロトコルを使用するため、既存の低コストのインターネットを Web サービスの実装に使用できます。

ウェブサービス Archi構造

あらゆるフレームワークは、フレームワーク全体が期待どおりに機能することを保証する何らかのアーキテクチャを必要とします。ウェブサービスでも同様です。 ウェブサービス Archi構造 以下に示す XNUMX つの異なる役割で構成されます。

  1. プロバイダー – プロバイダーは Web サービスを作成し、それを使用するクライアント アプリケーションがそれを利用できるようにします。
  2. リクエスター – リクエスターとは、Webサービスに接続する必要があるクライアントアプリケーションです。クライアントアプリケーションは.Netでも構いません。 Java、または Web サービス経由で何らかの機能を探すその他の言語ベースのアプリケーション。
  3. ブローカー – ブローカーは、UDDI へのアクセスを提供するアプリケーションに他なりません。 前のトピックで説明したように、UDDI を使用すると、クライアント アプリケーションが Web サービスを見つけることができます。

以下の図は、サービス プロバイダー、サービス リクエスタ、およびサービス レジストリが相互にどのようにやり取りするかを示しています。

ウェブサービス Archi構造

ウェブサービス Archi構造
  1. パブリッシュ – プロバイダーは、ブローカーの公開インターフェースを使用して Web サービスの存在をブローカー (サービス レジストリ) に通知し、クライアントがサービスにアクセスできるようにします。
  2. もう完成させ、ワークスペースに掲示しましたか? – リクエスタはブローカーに問い合わせて、公開された Web サービスを見つけます。
  3. バインド – ブローカー (サービス レジストリ) から取得した Web サービスに関する情報を使用して、リクエスタは Web サービスをバインドまたは呼び出すことができます。

Webサービスの特徴

Web サービスには、次のような特殊な動作特性があります。

  1. XML ベースです – Web サービスは、表現層とデータ転送層でデータを表現するために XML を使用します。XML はすべての人が理解できる共通言語であるため、XML を使用すると、ネットワーク、オペレーティング システム、またはプラットフォームなどの依存関係がなくなります。
  2. 疎結合 – 疎結合とは、クライアントと Web サービスが相互にバインドされていないことを意味します。つまり、Web サービスが時間の経過とともに変化しても、クライアントが Web サービスを呼び出す方法は変化しません。疎結合アーキテクチャを採用すると、ソフトウェア システムの管理が容易になり、異なるシステム間の統合が簡単になります。
  3. Sync非同期または非同期の機能 – Synchronicity は、クライアントとサービスの実行との結びつきを指します。同期操作では、クライアントは実際に Web サービスが操作を完了するまで待機します。この例としては、データベースの読み取りおよび書き込み操作が実行されるシナリオが考えられます。あるデータベースからデータを読み取り、その後別のデータベースに書き込む場合、操作は順番に実行する必要があります。非同期操作では、クライアントはサービスを呼び出してから、他の機能を並行して実行できます。これは、特定の操作の実行中に他のサービスが停止しないようにするための一般的な、おそらく最も好まれる手法の 1 つです。
  4. リモート プロシージャ コール (RPC) をサポートする機能 – Web サービスにより、クライアントは XML ベースのプロトコルを使用してリモート オブジェクトのプロシージャ、関数、およびメソッドを呼び出すことができます。 リモート プロシージャは、Web サービスがサポートする必要がある入力パラメータと出力パラメータを公開します。
  5. 文書交換をサポート – XML の主な利点の 1 つは、データだけでなく複雑なドキュメントも汎用的に表現できることです。これらのドキュメントは、現在の住所を表現するような単純なものから、本全体を表現するような複雑なものまでさまざまです。