Webサービスとは何ですか？

さまざまな書籍やさまざまな組織が、Webサービスにさまざまな定義を提供しています。それらのいくつかはここにリストされています。

Webサービスは、インターネット上で利用できるようにするソフトウェアであり、標準化されたXMLメッセージングシステムを使用します。 XMLは、Webサービスへのすべての通信をエンコードするために使用されます。たとえば、クライアントはXMLメッセージを送信してWebサービスを呼び出し、対応するXML応答を待ちます。すべての通信はXMLで行われるため、Webサービスは1つのオペレーティングシステムやプログラミング言語に関連付けられていません。JavaはPerlと通信できます。 Windowsアプリケーションは、Unixアプリケーションと通信できます。
Webサービスは、製品、プロセス、およびサプライチェーンを作成するために、ネットワーク経由で記述、公開、検索、または呼び出すことができる自己完結型のモジュール式の分散動的アプリケーションです。これらのアプリケーションは、ローカル、分散、またはWebベースにすることができます。 Webサービスは、TCP/IP、HTTP、Java、HTML、XMLなどのオープン標準に基づいて構築されています。
Webサービスは、XMLベースの情報交換システムであり、インターネットを使用してアプリケーション間の直接のやり取りを行います。これらのシステムには、プログラム、オブジェクト、メッセージ、またはドキュメントを含めることができます。
Webサービスは、アプリケーション間またはシステム間でデータを交換するために使用されるオープンプロトコルおよび標準の集まりです。様々なプログラミング言語で書かれ、様々なプラットフォーム上で実行されるソフトウェアアプリケーションは、単一のコンピュータ上のプロセス間通信と同様に、インターネットのようなコンピュータネットワークを介してデータを交換するためにウェブサービスを使用することができる。この相互運用性（たとえば、JavaとPython、またはWindowsとLinuxアプリケーションの間）は、オープンスタンダードの使用によるものです。

要約すると、完全なWebサービスは、したがって、すべてのサービスです-

インターネットまたはプライベート（イントラネット）ネットワーク経由で利用可能
標準化されたXMLメッセージングシステムを使用する
1つのオペレーティングシステムまたはプログラミング言語に縛られていない
一般的なXML文法による自己記述的
単純な検索メカニズムを介して検出可能です

Webサービスのコンポーネント

基本的なWebサービスプラットフォームはXML＆plus;です。 HTTP。すべての標準的なWebサービスは、次のコンポーネントを使用して動作します-

SOAP（簡易オブジェクトアクセスプロトコル）
UDDI（ユニバーサルディスクリプション、ディスカバリおよびインテグレーション）
WSDL（Webサービス記述言語）

これらのコンポーネントはすべて、リンク：/webservices/web_services_architecture [Webサービスアーキテクチャ]の章で説明されています。

Webサービスはどのように機能しますか？

Webサービスは、HTML、XML、WSDL、SOAPなどのオープンスタンダードを使用して、さまざまなアプリケーション間の通信を可能にします。 Webサービスはの助けを借ります-

データにタグを付けるXML
メッセージを転送するSOAP
サービスの可用性を記述するWSDL。

Windows上で実行されるVisual Basicプログラムからアクセス可能なJavaベースのWebサービスをSolaris上で構築できます。

C＃を使用して、JavaServer Pages（JSP）に基づいてLinux上で実行されるWebアプリケーションから呼び出すことができる新しいWebサービスをWindows上で構築することもできます。

例

簡単なアカウント管理および注文処理システムを検討してください。経理担当者は、Visual BasicまたはJSPで構築されたクライアントアプリケーションを使用して、新しいアカウントを作成し、新しい顧客の注文を入力します。

このシステムの処理ロジックはJavaで記述され、Solarisマシン上に存在します。Solarisマシンはデータベースとも対話して情報を保存します。

この操作を実行する手順は次のとおりです-

クライアントプログラムはアカウント登録情報をSOAPメッセージにまとめます。
このSOAPメッセージは、HTTP POST要求の本文としてWebサービスに送信されます。
WebサービスはSOAPリクエストをアンパックし、それをアプリケーションが理解できるコマンドに変換します。
アプリケーションは必要に応じて情報を処理し、その顧客の新しい一意のアカウント番号で応答します。
次に、Webサービスは別のSOAPメッセージに応答をパッケージ化し、HTTP要求への応答としてクライアントプログラムに送り返します。
クライアントプログラムは、アカウント登録プロセスの結果を取得するためにSOAPメッセージを解凍します。

なぜWebサービスなのか？

Webサービスを使用する利点は次のとおりです-

ネットワーク上の既存の機能を公開する

Webサービスは、HTTPを使用してリモートで呼び出すことができるマネージコードの単位です。つまり、HTTP要求を使用してアクティブ化できます。 Webサービスを使用すると、既存のコードの機能をネットワーク経由で公開できます。ネットワークに公開されると、他のアプリケーションがプログラムの機能を使用できるようになります。

相互運用性

Webサービスを使用すると、さまざまなアプリケーションが相互に通信し、アプリケーション間でデータとサービスを共有できます。他のアプリケーションでもWebサービスを使用できます。たとえば、VBまたは.NETアプリケーションはJava Webサービスと通信でき、その逆も可能です。 Webサービスは、アプリケーションプラットフォームとテクノロジーを独立させるために使用されます。

標準化されたプロトコル

Webサービスは、通信に標準化された業界標準プロトコルを使用します。 4つのレイヤー（サービストランスポート、XMLメッセージング、サービス記述、およびサービス検出レイヤー）はすべて、Webサービスプロトコルスタックで明確に定義されたプロトコルを使用します。このプロトコルスタックの標準化は、幅広い選択肢、競争によるコストの削減、品質の向上など、ビジネスに多くの利点をもたらします。

低コストのコミュニケーション

WebサービスはSOAP over HTTPプロトコルを使用するため、既存の低コストのインターネットを使用してWebサービスを実装できます。このソリューションは、EDI/B2Bのような独自のソリューションに比べてはるかに安価です。 SOAP over HTTPに加えて、WebサービスはFTPなどの他の信頼できるトランスポートメカニズムに実装することもできます。

Webサービス-特性

Webサービスには、次の特別な動作特性があります-

XMLベース

Webサービスは、データ表現およびデータ転送レイヤーでXMLを使用します。 XMLを使用すると、ネットワーク、オペレーティングシステム、またはプラットフォームのバインドが不要になります。 Webサービスベースのアプリケーションは、コアレベルで高度に相互運用可能です。

疎結合

Webサービスの消費者は、そのWebサービスに直接結び付けられていません。 Webサービスインターフェイスは、クライアントのサービスとの対話能力を損なうことなく、時間の経過とともに変化する可能性があります。密結合システムとは、クライアントとサーバーのロジックが互いに密接に結びついていることを意味し、一方のインターフェースが変更された場合、他方を更新する必要があることを意味します。疎結合アーキテクチャを採用すると、ソフトウェアシステムがより管理しやすくなり、異なるシステム間の統合が簡単になります。

粗粒

Javaなどのオブジェクト指向テクノロジーは、個々のメソッドを介してサービスを公開します。個々の方法は、企業レベルで有用な機能を提供するには操作が細かすぎます。 Javaプログラムをゼロから構築するには、いくつかのきめ細かいメソッドを作成する必要があります。これらのメソッドは、クライアントまたは別のサービスによって消費されるきめの粗いサービスに合成されます。

ビジネスとそれらが公開するインターフェイスは、粗粒度である必要があります。 Webサービステクノロジは、適切な量のビジネスロジックにアクセスする粗粒度サービスを定義する自然な方法を提供します。

同期または非同期の機能

同期性とは、クライアントをサービスの実行にバインドすることです。同期呼び出しでは、クライアントはブロックして、サービスが操作を完了するのを待ってから続行します。非同期操作により、クライアントはサービスを呼び出して、他の機能を実行できます。

非同期クライアントは後の時点で結果を取得しますが、同期クライアントはサービスの完了時に結果を受け取ります。非同期機能は、疎結合システムを実現するための重要な要素です。

リモートプロシージャコール（RPC）をサポート

Webサービスにより、クライアントは、XMLベースのプロトコルを使用して、リモートオブジェクトのプロシージャ、関数、およびメソッドを呼び出すことができます。リモートプロシージャは、Webサービスがサポートする必要がある入力および出力パラメーターを公開します。

エンタープライズJavaBean（EJB）および.NETコンポーネントを介したコンポーネント開発は、過去数年間でますますアーキテクチャおよびエンタープライズ展開の一部になっています。両方のテクノロジーは、さまざまなRPCメカニズムを介して配布され、アクセス可能です。

Webサービスは、従来のコンポーネントのサービスと同等の独自のサービスを提供するか、着信呼び出しをEJBまたは.NETコンポーネントの呼び出しに変換することにより、RPCをサポートします。

ドキュメント交換をサポート

XMLの主な利点の1つは、データだけでなく複雑なドキュメントを表す一般的な方法です。これらの文書は、現在の住所を表すのと同じくらい単純な場合もあれば、書籍全体または見積依頼（RFQ）を表すのと同じくらい複雑な場合もあります。 Webサービスは、ドキュメントの透過的な交換をサポートして、ビジネス統合を促進します。

Webサービス-アーキテクチャ

Webサービスのアーキテクチャを表示するには2つの方法があります-

1つ目は、各Webサービスアクターの個々の役割を調べることです。
2番目は、新しいWebサービスプロトコルスタックを調べることです。

Webサービスの役割

Webサービスアーキテクチャには3つの主要な役割があります-

サービスプロバイダー

これは、Webサービスのプロバイダーです。サービスプロバイダーはサービスを実装し、インターネットで利用できるようにします。

サービス依頼者

これは、Webサービスの消費者です。リクエスターは、ネットワーク接続を開いてXML要求を送信することにより、既存のWebサービスを利用します。

サービスレジストリ

これは、論理的に集中化されたサービスのディレクトリです。レジストリは、開発者が新しいサービスを公開したり、既存のサービスを見つけたりできる中心的な場所を提供します。したがって、企業とそのサービスのための集中化された情報センターとして機能します。

Webサービスプロトコルスタック

Webサービスアーキテクチャを表示する2番目のオプションは、新しいWebサービスプロトコルスタックを調べることです。スタックはまだ進化していますが、現在4つの主要な層があります。

サービス輸送

この層は、アプリケーション間でメッセージを転送します。現在、このレイヤーには、ハイパーテキストトランスポートプロトコル（HTTP）、簡易メール転送プロトコル（SMTP）、ファイル転送プロトコル（FTP）、およびブロック拡張可能交換プロトコル（BEEP）などの新しいプロトコルが含まれています。

XMLメッセージング

この層は、メッセージを両端で理解できるように、共通のXML形式でメッセージをエンコードします。現在、このレイヤーにはXML-RPCとSOAPが含まれています。

サービスの説明

この層は、特定のWebサービスへのパブリックインターフェイスを記述する役割を果たします。現在、サービスの説明は、Webサービス記述言語（WSDL）を介して処理されます。

サービス発見

この層は、サービスを共通レジストリに集中化し、簡単な公開/検索機能を提供します。現在、サービスの検出は、ユニバーサル記述、検出、統合（UDDI）を介して処理されます。

Webサービスが進化するにつれて、追加のレイヤーが追加され、各レイヤーにテクノロジーが追加される場合があります。

次の章では、Webサービスのコンポーネントについて説明します。

サービストランスポートに関するいくつかの言葉

Webサービスプロトコルスタックの一番下は、サービストランスポートです。この層は、実際に2台のコンピューター間でXMLメッセージを転送する役割を果たします。

ハイパーテキスト転送プロトコル（HTTP）

現在、HTTPはサービストランスポートの最も一般的なオプションです。 HTTPはシンプルで安定しており、広く展開されています。さらに、ほとんどのファイアウォールはHTTPトラフィックを許可します。これにより、XMLRPCまたはSOAPメッセージがHTTPメッセージになりすますことができます。これは、リモートアプリケーションを統合する場合に適していますが、いくつかのセキュリティ上の問題が発生します。

拡張可能交換プロトコル（BEEP）をブロックします

これは、HTTPの有望な代替手段です。 BEEPは、新しいプロトコルを構築するための新しいインターネットエンジニアリングタスクフォース（IETF）フレームワークです。 BEEPはTCPに直接階層化され、初期ハンドシェイクプロトコル、認証、セキュリティ、エラー処理などの多くの組み込み機能が含まれています。 BEEPを使用すると、インスタントメッセージング、ファイル転送、コンテンツシンジケーション、ネットワーク管理など、さまざまなアプリケーション用の新しいプロトコルを作成できます。

SOAPは特定のトランスポートプロトコルに関連付けられていません。実際、HTTP、SMTP、またはFTP経由でSOAPを使用できます。したがって、有望なアイデアの1つは、SOAP over BEEPを使用することです。

Webサービス-コンポーネント

過去数年間で、3つの主要な技術が、今日のWebサービス技術の中核を構成する世界標準として浮上しています。これらの技術について以下で説明します。

XML-RPC

これは、コンピューター間で情報を交換するための最も単純なXMLベースのプロトコルです。

XML-RPCは、XMLメッセージを使用してRPCを実行する単純なプロトコルです。
要求はXMLでエンコードされ、HTTP POSTを介して送信されます。
XML応答は、HTTP応答の本文に埋め込まれます。
XML-RPCはプラットフォームに依存しません。
XML-RPCにより、さまざまなアプリケーションが通信できます。
Javaクライアントは、XML-RPCをPerlサーバーと通信できます。
XML-RPCは、Webサービスを開始する最も簡単な方法です。

XML-RPCの詳細については、リンク：/xml-rpc/index [XML-RPCチュートリアル]をご覧ください。

SOAP

SOAPは、コンピューター間で情報を交換するためのXMLベースのプロトコルです。

SOAPは通信プロトコルです。
SOAPは、アプリケーション間の通信用です。
SOAPは、メッセージを送信するための形式です。
SOAPは、インターネット経由で通信するように設計されています。
SOAPはプラットフォームに依存しません。
SOAPは言語に依存しません。
SOAPはシンプルで拡張可能です。
SOAPを使用すると、ファイアウォールを回避できます。
SOAPはW3C標準として開発されます。

SOAPの詳細については、リンク：/soap/index [SOAPチュートリアル]をご覧ください。

WSDL

WSDLは、Webサービスとそれらへのアクセス方法を記述するためのXMLベースの言語です。

WSDLは、Webサービス記述言語の略です。
WSDLは、MicrosoftとIBMが共同で開発しました。
WSDLは、分散環境および分散環境での情報交換のためのXMLベースのプロトコルです。
WSDLは、Webサービスを記述するための標準形式です。
WSDL定義は、Webサービスにアクセスする方法と、それが実行する操作を記述します。
WSDLは、XMLベースのサービスとのインターフェイス方法を記述するための言語です。
WSDLは、XMLベースの世界的なビジネスレジストリであるUDDIの不可欠な部分です。
WSDLは、UDDIが使用する言語です。
WSDLは「wiz-dull」と発音され、「W-S-D-L」と綴られます。

WSDLの詳細については、リンク：/wsdl/index [WSDLチュートリアル]をご覧ください。

UDDI

UDDIは、Webサービスを記述、公開、および検索するためのXMLベースの標準です。

UDDIはUniversal Description、Discovery、およびIntegrationの略です。
UDDIは、Webサービスの分散レジストリの仕様です。
UDDIは、プラットフォームに依存しないオープンフレームワークです。
UDDIは、SOAP、CORBA、およびJava RMIプロトコルを介して通信できます。
UDDIはWSDLを使用して、Webサービスへのインターフェースを記述します。
UDDIは、Webサービスの3つの基本標準の1つとしてSOAPとWSDLで見られています。
UDDIは、企業がお互いを発見し、インターネットを介した相互作用を定義できるようにするオープンな業界イニシアチブです。

UDDIの詳細については、リンク：/uddi/index [UDDIチュートリアル]をご覧ください。

Webサービス-例

Webサービスアーキテクチャに基づいて、Webサービス実装の一部として次の2つのコンポーネントを作成します-

サービスプロバイダーまたはパブリッシャー

これは、Webサービスのプロバイダーです。サービスプロバイダーはサービスを実装し、インターネットまたはイントラネットで利用できるようにします。

サービス要求者または消費者

NET SDKを使用して、簡単なWebサービスを作成して公開します。.

これは、Webサービスの消費者です。リクエスターは、ネットワーク接続を開いてXML要求を送信することにより、既存のWebサービスを利用します。

また、2つのWebサービスリクエスターを作成します。1つはWebベースのコンシューマー（ASP.NETアプリケーション）、もう1つはWindowsアプリケーションベースのコンシューマーです。

以下は、サービスプロバイダーとして機能し、アプリケーションが使用するWebサービスとして2つのメソッド（addおよびSayHello）を公開する最初のWebサービスの例です。これは、Webサービスの標準テンプレートです。 .NET Webサービスは.asmx拡張子を使用します。 Webサービスとして公開されるメソッドにはWebMethod属性があることに注意してください。このファイルをIIS仮想ディレクトリにFirstService.asmxとして保存します（IISの構成で説明されているように、たとえばc：\ MyWebSerces）。

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

Webサービスをテストするには、公開する必要があります。 Webサービスは、イントラネットまたはインターネットで公開できます。ローカルマシンで実行されているIISでこのWebサービスを公開します。 IISの構成から始めましょう。

スタート→設定→コントロールパネル→管理ツール→インターネットサービスマネージャーを開きます。
デフォルトのWebサイトを展開して右クリックします。 New rarrを選択します。仮想ディレクトリ。仮想ディレクトリ作成ウィザードが開きます。 Nextをクリックしてください。
[仮想ディレクトリエイリアス]画面が開きます。仮想ディレクトリ名を入力します。たとえば、MyWebServices。 Nextをクリックしてください。
[Webサイトコンテンツディレクトリ]画面が開きます。
仮想ディレクトリのディレクトリパス名を入力します。たとえば、c：\ MyWebServices。 Nextをクリックしてください。
「アクセス許可」画面が開きます。要件に従って設定を変更します。この演習のデフォルト設定を保持しましょう。
[次へ]ボタンをクリックします。 IISの構成が完了します。
[完了]をクリックして構成を完了します。

IISが正しく構成されているかどうかをテストするには、上記で作成した仮想ディレクトリ（C：\ MyWebServices）にHTMLファイル（たとえば、xl）をコピーします。次に、Internet Explorerを開き、 http：//localhost/MyWebServices/xl と入力します。 xlファイルを開く必要があります。

注-動作しない場合は、localhostをマシンのIPアドレスに置き換えてみてください。それでも機能しない場合は、IISが実行されているかどうかを確認してください。 IISおよび仮想ディレクトリの再構成が必要になる場合があります。

このWebサービスをテストするには、上記で作成したIIS仮想ディレクトリ（C：\ MyWebServices）にFirstService.asmxをコピーします。 Internet Explorer（http：//localhost/MyWebServices/FirstService.asmx）でWebサービスを開きます。 Webサービスページが開きます。ページには、アプリケーションによってWebサービスとして公開される2つのメソッドへのリンクが必要です。おめでとうございます。最初のWebサービスを作成しました！

Webサービスのテスト

これまで見てきたように、Webサービスの記述は.NET Frameworkで簡単です。 .NETフレームワークでは、Webサービスコンシューマーの作成も簡単です。ただし、もう少し複雑です。前述のように、2つのタイプのサービスコンシューマーを作成します。1つはWebベースのコンシューマーで、もう1つはWindowsアプリケーションベースのコンシューマーです。最初のWebサービスコンシューマを作成しましょう。

Webベースのサービス利用者

以下のウェブベースのコンシューマーを作成します。 WebApp.aspxと呼びます。 ASP.NETアプリケーションであることに注意してください。これをWebサービスの仮想ディレクトリ（c：\ MyWebServices \ WebApp.axpx）に保存します。

このアプリケーションには、追加するユーザーから番号を取得するために使用される2つのテキストフィールドがあります。実行ボタンが1つあり、クリックするとAddおよびSayHello Webサービスが取得されます。

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>

   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4< /asp:TextBox>
         </p>

         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>

         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>

         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>

         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

コンシューマーを作成したら、使用するWebサービスのプロキシを作成する必要があります。この作業は、追加されたWebサービスを参照するときに、Visual Studio .NETによって自動的に行われます。従うべき手順は次のとおりです-

使用するWebサービスのプロキシを作成します。プロキシは、.NET SDKで提供されるWSDLユーティリティを使用して作成されます。このユーティリティは、Webサービスから情報を抽出し、プロキシを作成します。プロキシは、特定のWebサービスに対してのみ有効です。他のWebサービスを使用する必要がある場合は、このサービスのプロキシも作成する必要があります。 Visual Studio .NETは、Webサービス参照が追加されると自動的にプロキシを作成します。 .NET SDKで提供されるWSDLユーティリティを使用して、Webサービスのプロキシを作成します。現在のディレクトリにFirstSevice.csファイルを作成します。 WebサービスのFirstService.dll（プロキシ）を作成するためにコンパイルする必要があります。

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc/t:library FirstService.cs

コンパイル済みプロキシをWebサービスの仮想ディレクトリのbinディレクトリ（c：\ MyWebServices \ bin）に配置します。インターネットインフォメーションサービス（IIS）は、このディレクトリでプロキシを探します。
すでに行ったのと同じ方法で、サービスコンシューマを作成します。 Webサービスプロキシのオブジェクトは、コンシューマでインスタンス化されることに注意してください。このプロキシは、サービスとの対話を処理します。
IEでコンシューマのURLを入力してテストします（たとえば、http：//localhost/MyWebServices/WebApp.aspx）。

WindowsアプリケーションベースのWebサービスコンシューマー

WindowsアプリケーションベースのWebサービスコンシューマを作成することは、他のWindowsアプリケーションを作成することと同じです。プロキシを作成するだけで（これは既に完了しています）、アプリケーションのコンパイル時にこのプロキシを参照するだけです。以下は、Webサービスを使用するWindowsアプリケーションです。このアプリケーションは、Webサービスオブジェクト（もちろんプロキシ）を作成し、SayHelloを呼び出して、そのメソッドを追加します。

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

`+ c：\> csc/r:FirstService.dll WinApp.cs +`を使用してコンパイルします。 WinApp.exeが作成されます。それを実行して、アプリケーションとWebサービスをテストします。

ここで疑問が生じます。このアプリケーションが実際にWebサービスを呼び出していることをどのようにして確認できますか？

テストは簡単です。 Webサービスに接続できないように、Webサーバーを停止します。次に、WinAppアプリケーションを実行します。ランタイム例外が発生します。次に、Webサーバーを再度起動します。それはうまくいくはずです。

Webサービス-セキュリティ

セキュリティはWebサービスにとって重要です。ただし、XML-RPC仕様もSOAP仕様も明示的なセキュリティまたは認証の要件を満たしていません。

Webサービスには3つの特定のセキュリティ問題があります-

守秘義務
認証
ネットワークセキュリティー

守秘義務

クライアントがサーバーにXML要求を送信する場合、通信の機密性を確保できますか？

答えはここにあります-

XML-RPCとSOAPは、主にHTTPの上で実行されます。
HTTPはSecure Sockets Layer（SSL）をサポートしています。
通信はSSLを介して暗号化できます。
SSLは実証済みのテクノロジーであり、広く展開されています。

単一のWebサービスは、一連のアプリケーションで構成されている場合があります。たとえば、1つの大きなサービスが他の3つのアプリケーションのサービスを結び付ける場合があります。この場合、SSLは適切ではありません。メッセージはサービスパスに沿った各ノードで暗号化する必要があり、各ノードはチェーン内の潜在的な弱いリンクを表します。現在、この問題に対する合意済みの解決策はありませんが、有望な解決策の1つはW3C XML暗号化標準です。この標準は、XMLドキュメント全体またはXMLドキュメントの一部のみを暗号化および復号化するためのフレームワークを提供します。 www.w3.org/Encryptionで確認できます。

認証

クライアントがWebサービスに接続する場合、ユーザーをどのように識別するのですか？ユーザーはサービスの使用を許可されていますか？

次のオプションを検討できますが、強力な認証スキームについて明確なコンセンサスはありません。

HTTPには基本認証およびダイジェスト認証の組み込みサポートが含まれているため、HTMLドキュメントが現在保護されているのとほぼ同じ方法でサービスを保護できます。
SOAPデジタル署名（SOAP-DSIG）は、公開鍵暗号化を利用してSOAPメッセージにデジタル署名します。これにより、クライアントまたはサーバーは、相手の身元を検証できます。 www.w3.org/TR/SOAP-dsigで確認してください。
構造化情報標準化推進機構（OASIS）は、セキュリティアサーションマークアップ言語（SAML）に取り組んでいます。

ネットワークセキュリティー

現在、この問題に対する簡単な答えはなく、多くの議論の対象となっています。現時点では、SOAPまたはXML-RPCメッセージを完全に除外する場合は、コンテンツタイプをtext/xmlに設定するすべてのHTTP POST要求を除外する可能性があります。

別の方法は、SOAPAction HTTPヘッダー属性をフィルタリングすることです。ファイアウォールベンダーは現在、Webサービストラフィックをフィルタリングするために明示的に設計されたツールも開発しています。

Webサービス-標準

この章では、Webサービスに関連する最新のすべての標準について説明します。

輸送

BEEP、Blocks Extensible Exchange Protocol（以前はBXXPと呼ばれていました）は、アプリケーションプロトコルを構築するためのフレームワークです。 IETFによって標準化されており、XMLがデータに対して行ったことをインターネットプロトコルに対して行います。

Blocks Extensible Exchange Protocol（BEEP）

メッセージング

これらのメッセージング標準および仕様は、分散型の分散環境で情報を交換するためのフレームワークを提供することを目的としています。

説明と発見

Webサービスは、潜在的なユーザーが実行を許可するのに十分な情報を見つけることができる場合にのみ意味があります。これらの仕様と標準の焦点は、ビジネス、組織、およびその他のWebサービスプロバイダーの説明と発見をサポートする一連のサービスの定義です。利用可能にするWebサービス。そして、それらのサービスにアクセスするために使用できる技術的なインターフェース。

セキュリティ

これらのセキュリティ仕様を使用して、アプリケーションは、一般的なWebサービスフレームワークと連携するように設計された安全な通信を行うことができます。

Web Services Security 1.0
http://xml.coverpages.org/samll [セキュリティアサーションマークアップ言語（SAML）]

管理

Webサービスの管理容易性は、Webサービスアーキテクチャ内のWebサービスの制御と構成だけでなく、存在、可用性、正常性、パフォーマンス、使用状況を検出するための一連の機能として定義されます。 Webサービスが普及し、ビジネスオペレーションにとって重要になると、Webサービスの管理と実装のタスクはビジネスオペレーションの成功に不可欠です。

Webサービス分散管理

Webサービス-概要

このチュートリアルでは、Webサービスの使用方法を学習しました。ただし、Webサービスには、WSDL、UDDI、SOAPなどのコンポーネントが含まれており、これらのコンポーネントがアクティブになります。次のステップは、WSDL、UDDI、およびSOAPを学ぶことです。

WSDL

WSDLは、Webサービスとそれらへのアクセス方法を記述するためのXMLベースの言語です。

WSDLは、Webサービスのメッセージ形式とプロトコル詳細とともにWebサービスを記述します。

WSDLの詳細については、リンク：/wsdl/index [WSDLチュートリアル]をご覧ください。

UDDI

UDDIは、Webサービスを記述、公開、および検索するためのXMLベースの標準です。

UDDIの詳細については、リンク：/uddi/index [UDDIチュートリアル]をご覧ください。

SOAP

SOAPは、アプリケーションがHTTP経由で情報を交換できるようにする単純なXMLベースのプロトコルです。

SOAPの詳細については、リンク：/soap/index [SOAPチュートリアル]をご覧ください。 Webservices-web-services-questions-answers

Webサービス-便利なリソース

以下のリソースには、Webサービスに関する追加情報が含まれています。これについての詳細な知識を得るためにそれらを使用してください。

Webサービスの便利なリンク

Webサービス-Webサービスの公式サイト。
Web Services Wikipedia-Webサービスのウィキペディア

Webサービスに関する便利な本

このページにサイトを登録するには、 contact @ finddevguides.com にメールを送信してください。

Webservices-quick-guide

Webサービスとは何ですか？

Webサービスのコンポーネント

Webサービスはどのように機能しますか？

例

なぜWebサービスなのか？

ネットワーク上の既存の機能を公開する

相互運用性

標準化されたプロトコル

低コストのコミュニケーション

Webサービス-特性

XMLベース

疎結合

粗粒

同期または非同期の機能

リモートプロシージャコール（RPC）をサポート

ドキュメント交換をサポート

Webサービス-アーキテクチャ

Webサービスの役割

サービスプロバイダー

サービス依頼者

サービスレジストリ

Webサービスプロトコルスタック

サービス輸送

XMLメッセージング

サービスの説明

サービス発見

サービストランスポートに関するいくつかの言葉

ハイパーテキスト転送プロトコル（HTTP）

拡張可能交換プロトコル（BEEP）をブロックします

Webサービス-コンポーネント

XML-RPC

SOAP

WSDL

UDDI

Webサービス-例

サービスプロバイダーまたはパブリッシャー

サービス要求者または消費者

Webサービスのテスト

Webベースのサービス利用者

WindowsアプリケーションベースのWebサービスコンシューマー

Webサービス-セキュリティ

守秘義務

認証

ネットワークセキュリティー

Webサービス-標準

輸送

メッセージング

説明と発見

セキュリティ

管理

Webサービス-概要

WSDL

UDDI

SOAP

Webサービス-便利なリソース

Webサービスの便利なリンク

Webサービスに関する便利な本