ウェブサービス

Webサービス( WS ) は次のいずれかです。

• インターネットを介して相互に通信する電子機器から他の電子機器に提供されるサービス、または
• コンピュータデバイス上で実行され、ネットワーク上の特定のポートでリクエストをリッスンし、Web ドキュメント ( HTML、JSON、XML、画像)を提供するサーバー。 ^{[引用が必要]}

Web サービスでは、XMLや JSON などの機械可読ファイル形式を転送するために、HTTPなどの Web テクノロジが使用されます。

実際には、Web サービスは一般に、オブジェクト指向のWeb ベースのインターフェイスをデータベース サーバーに提供します。このインターフェイスは、たとえば別の Web サーバーや、エンド ユーザーにユーザー インターフェイスを提供するモバイル アプリによって使用されます。フォーマットされた HTML ページでデータを提供する組織の多くは、そのデータを XML または JSON としてサーバー上で提供し、多くの場合、シンジケーションを可能にするために Web サービスを介して提供されます。エンド ユーザーに提供される別のアプリケーションは、マッシュアップである可能性があります。マッシュアップでは、Web サーバーが複数のマシンで複数の Web サービスを利用し、そのコンテンツを 1 つのユーザー インターフェイスにコンパイルします。

非同期 JavaScript および XML (AJAX) は、Web サービスの主要なテクノロジです。HTTP サーバー、JavaScript クライアント、およびPlain Old XML ( SOAPおよび W3C Web サービスとは異なります) の組み合わせから開発された AJAX は、現在ではXML だけでなく、または XML の代わりに JSONとともに頻繁に使用されています。

Representational State Transfer (REST) は、インターネット規模で機能できる、適切に動作する Web サービスのアーキテクチャです。

2004 年の文書で、W3C は Web サービスの主な特徴として次の REST を設定しました。

Web サービスには、主に次の 2 つのクラスがあります。

• REST準拠のWebサービス。サービスの主な目的は、統一された一連のステートレス操作を使用してWebリソースのXML表現を操作することです。
• 任意の Web サービス。このサービスでは、任意の操作セットを公開できます。
  —  W3C、Webサービスアーキテクチャ^[1]

マークアップ言語を使用する Web サービスは多数あります。

• JSON-RPC。
• JSON-WSP
• 表現状態転送(REST) とリモート プロシージャ コール(RPC)
• シンプルオブジェクトアクセスプロトコル
• Web サービス会話言語(WSCL)
• W3Cによって開発されたWebサービス記述言語（WSDL）
• Web サービス フロー言語(WSFL)、BPELに置き換えられました
• ウェブテンプレート
• WS-メタデータ交換
• XML Interface for Network Services (XINS) は、POXスタイルの Web サービス仕様フォーマットを提供します。

Web APIは、Webサービスの開発において、よりシンプルなREST（Representational State Transfer ）ベースの通信に重点が移ったものです。 ^{[2] RESTful APIでは、インターフェースをサポートするためにXMLベースのWebサービスプロトコル（} SOAPおよびWSDL） は必要ありません。

W3C Web サービスに関して、W3C はWeb サービスを次のように定義しています。

Web サービスは、ネットワーク上で相互運用可能なマシン間のインタラクションをサポートするように設計されたソフトウェア システムです。マシンが処理可能な形式 (具体的にはWSDL ) で記述されたインターフェイスがあります。他のシステムは、SOAP メッセージを使用して、その記述で規定された方法で Web サービスと対話します。SOAP メッセージは通常、他の Web 関連標準と組み合わせてXMLシリアル化によるHTTPを使用して伝達されます。

—  W3C、Webサービス用語集^[3]

W3C Web サービスでは、SOAP over HTTP プロトコルを使用することで、EDI/B2B などの独自のソリューションよりも低コスト (より効率的) でインターネットを介したやり取りが可能になります。SOAP over HTTP 以外にも、Web サービスはFTPなどの他の信頼性の高いトランスポート メカニズムで実装することもできます。2002 年の文書では、Web サービス アーキテクチャ ワーキング グループが Web サービス アーキテクチャを定義し、「Web サービス」の標準化された実装を要求しました。

「Web サービス」という用語は、インターネット プロトコルバックボーン上でXML、SOAP、WSDL、UDDI オープン スタンダードを使用して Web ベースのアプリケーションを統合する標準化された方法を表します。XML は、データを格納し、その周囲にメタデータを提供するために使用されるデータ形式です。SOAP はデータを転送するために使用され、WSDL は利用可能なサービスを記述するために使用され、UDDI は利用可能なサービスをリストします。

Web サービスは、ネットワークを介して 2 つの電子デバイス間で通信する方法です。これは、ユーティリティ コンピューティングの概念のように、 常時オンのサービスで Web 上のネットワーク アドレスに提供されるソフトウェア機能です。

多くの組織では、管理のために複数のソフトウェア システムを使用しています。^[要出典]異なるソフトウェア システム間でデータを交換する必要が生じることが多く、Web サービスは 2 つのソフトウェア システムがインターネット経由でこのデータを交換できるようにする通信方法です。データを要求するソフトウェア システムはサービス リクエスタと呼ばれ、要求を処理してデータを提供するソフトウェア システムはサービス プロバイダーと呼ばれます。

ソフトウェアによって使用するプログラミング言語が異なる場合があるため、特定のプログラミング言語に依存しないデータ交換方法が必要になります。ただし、ほとんどの種類のソフトウェアは XML タグを解釈できます。したがって、Web サービスではデータ交換に XML ファイルを使用できます。

次のような異なるシステムとの通信ルールを定義する必要があります。

• あるシステムが別のシステムにデータを要求する方法。
• データ要求に必要な特定のパラメータ。
• 生成されるデータの構造はどのようなものになりますか。(通常、データは XML ファイルで交換され、XML ファイルの構造は .xsd ファイルに対して検証されます。)
• トラブルシューティングを容易にするために、通信に関する特定のルールが遵守されていない場合に表示するエラー メッセージ。

通信に関するこれらのルールはすべて、拡張子を持つWSDL (Web Services Description Language)と呼ばれるファイルで定義されています.wsdl。(自律型 Web サービス( AWS ) の提案は、厳格なルールに依存しない、より柔軟な Web サービスの開発を目指しています。^[a] )

UDDI (Universal Description, Discovery, and Integration)と呼ばれるディレクトリは、どのタイプのデータを取得するためにどのソフトウェア システムに接続するかを定義します。したがって、あるソフトウェア システムが特定のレポート/データを必要とする場合、UDDI にアクセスして、そのデータを受信するために接続できる他のシステムを検索します。ソフトウェア システムは、接続する他のシステムを見つけると、SOAP (Simple Object Access Protocol) と呼ばれる特別なプロトコルを使用してそのシステムに接続します。サービス プロバイダー システムは、まず WSDL ファイルを参照してデータ要求を検証し、次に要求を処理して SOAP プロトコルでデータを送信します。

自動化ツールは、Web サービスの作成に役立ちます。WSDL を使用するサービスの場合、既存のクラスの WSDL を自動的に生成するか (ボトムアップ モデル)、既存の WSDL に基づいてクラス スケルトンを生成するか (トップダウン モデル) のいずれかが可能です。

• ボトムアップモデルを使用する開発者は、最初に実装クラスを（何らかのプログラミング言語で）作成し、次にWSDL生成ツールを使用してこれらのクラスのメソッドをWebサービスとして公開します。この方法は開発が簡単ですが、元のクラスが頻繁に変更される場合は保守が難しくなる可能性があります。^[5]
• トップダウン モデルを使用する開発者は、まず WSDL ドキュメントを作成し、次にコード生成ツールを使用してクラスのスケルトンを作成し、必要に応じて完成させます。このモデルは一般的に難しいと考えられていますが、よりクリーンな設計を作成でき、一般的に変更に対する耐性が高くなります。送信者と受信者の間のメッセージ形式が変更されない限り、送信者と受信者自体の変更は Web サービスに影響しません。この手法は、WSDL (または送信者と受信者の間の契約) が開始点であるため、契約ファーストとも呼ばれます。 ^[6]
• サブセットWSDL（SWSDL）^[7]（つまり、元のWSDLにサブセット操作が含まれるWSDL）を使用する開発者は、Webサービスのテストとトップダウン開発を実行できます。

RESTfulでないWebサービスの批評家は、それらが複雑すぎること^{[8]や、典型的な}オープンソース実装ではなく、大規模なソフトウェアベンダーやインテグレーターに基づいていることをしばしば非難します。

また、Webサービスではメッセージ形式としてXMLを使用し、エンベロープと転送にはSOAP/HTTPを使用しているため、パフォーマンスに関する懸念もあります。^[9]

Web サービスの機能テストと非機能テストは、WSDL 解析を利用して行われます。回帰テストは、ソフトウェアのアップグレードに加えられた変更を識別することによって実行されます。Web サービスの回帰テストのニーズは、WSDL の変更、コードの変更、および操作の選択的な再テストの 3 つの方法に分類できます。上記の 3 つのニーズは、サブセット WSDL の 3 つの中間形式、つまり、それぞれ、差分 WSDL (DWSDL)、ユニット WSDL (UWSDL)、および縮小 WSDL (RWSDL) で捉えることができます^。これらの 3 つのサブセット WSDL は、Web サービスの回帰テストに使用される結合 WSDL (CWSDL) を形成するために結合されます。これは、関連するテスト ケースを選択して古いテスト スイートから縮小されたテスト スイートを構築することにより 、自動 Web サービス変更管理 (AWSCM) ^{[10]に役立ちます。 [11]}

Webサービスのテストは、 SoapUI、Oracle Application Testing Suite（OATS）、^{[12] [13]} Unified Functional Testing、Seleniumなど のいくつかのテスト自動化ツールを使用して自動化することもできます。

Webサービスに加えられた変更のキャプチャと視覚化に関連する作業。変更の視覚化と計算は、中間成果物（サブセットWSDL）の形式で行うことができます。^[7]変更の影響の計算に関する洞察は、テスト、トップダウン開発、回帰テストの削減に役立ちます。AWSCM ^[10]は、WSDLファイル内のサブセット操作を識別してサブセットWSDLを構築できるツールです。

UDDI はサービス ディレクトリとして機能し、Web サービスを発見する手段となることを目的としていましたが、Microsoft、SAP、IBM など多くのベンダーが 2005 年から 2008 年の間に UDDI ソリューションまたはリポジトリを廃止しました。^{[14] [15]} WWW2008 カンファレンス (中国、北京) ^[16]で発表された重要な調査では、SOAP ベースの Web サービスの状態が示され、調査時点で利用可能な SOAP ベースの Web サービスのうち、実際にアクティブであるか、呼び出すことができるのは 63% に過ぎないと結論付けられました。この調査では、設計の複雑さから、UDDI などのサービス レジストリと比較して、検索エンジンが Web サービスの検索に理想的なソースになりつつあることもわかりました。^[17]

• Webサービスフレームワークのリスト
• Web サービス プロトコルのリスト
• ウェブサービス仕様一覧
• ミドルウェア
• サービス指向アーキテクチャ(SOA)
• ウェブマップサービス
• ウェブAPI

ウィキメディア・コモンズには、 Web サービスに関連するメディアがあります。

WikiversityにはWebサービスに関する学習リソースがあります

• メッセージング デザイン パターンは、2018 年 10 月 9 日にWayback Machineの SOA パターンのドキュメントにアーカイブされました。
• W3Cの Web サービス アクティビティ ページ
• Web サービス アーキテクチャ、W3C ワーキング グループ ノート (2004 年 2 月 11 日)
• World Wide Web 上の Web サービスの調査、 WWW2008カンファレンスで発表された分析
• NISTのセキュア Web サービス ガイド (SP 800-95)