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サービスは、アプリケーションまたはシステム間でデータを交換するために使用されるオープンなプロトコルと標準のコレクションです。さまざまなプログラミング言語で記述され、さまざまなプラットフォームで実行されるソフトウェアアプリケーションは、Webサービスを使用して、単一のコンピューターでのプロセス間通信と同様の方法で、インターネットなどのコンピューターネットワークを介してデータを交換できます。この相互運用性（たとえば、JavaとPythonの間、またはWindowsとLinuxアプリケーションの間）は、オープンスタンダードの使用によるものです。

要約すると、完全なWebサービスは、したがって、次のようなサービスです。

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

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

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

SOAP（シンプルオブジェクトアクセスプロトコル）
UDDI（Universal Description、Discovery and Integration）
WSDL（Webサービス記述言語）

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

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

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

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

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

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

例

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

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

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

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

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

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

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

相互運用性

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

標準化されたプロトコル

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

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

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

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

XMLベース

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

疎結合

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

粗視化

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

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

同期または非同期になる機能

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

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

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

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

Enterprise JavaBeans（EJB）および.NETコンポーネントを介したコンポーネント開発は、過去2年間で、アーキテクチャおよびエンタープライズ展開の一部になりつつあります。どちらのテクノロジーも分散されており、さまざまなRPCメカニズムを通じてアクセスできます。

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

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

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

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

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

Webサービスの役割

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

サービスプロバイダー

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

サービスリクエスター

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

サービスレジストリ

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

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

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

サービストランスポート

この層は、アプリケーション間でメッセージを転送する役割を果たします。現在、この層には、ハイパーテキストトランスポートプロトコル（HTTP）、SMTP（Simple Mail Transfer Protocol）、FTP（File Transfer Protocol）、およびBlocks Extensible Exchange Protocol（BEEP）などの新しいプロトコルが含まれています。

XMLメッセージング

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

サービスの説明

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

サービスディスカバリ

このレイヤーは、サービスを共通のレジストリに一元化し、簡単な公開/検索機能を提供する役割を果たします。現在、サービスディスカバリは、Universal Description、Discovery、and Integration（UDDI）を介して処理されます。

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

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

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

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

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

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

Extensible Exchange Protocol（BEEP）をブロックします

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

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

過去数年間で、今日のWebサービステクノロジのコアを構成する世界標準として、3つの主要なテクノロジが登場しました。これらのテクノロジーについては、以下で説明します。

XML-RPC

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

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

XML-RPCの詳細については、XML-RPCチュートリアルにアクセスしてください。

石鹸

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

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

SOAPの詳細については、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」と発音され、「WSD-L」と綴られます。

WSDLの詳細については、WSDLチュートリアルにアクセスしてください。

UDDI

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

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

UDDIの詳細については、UDDIチュートリアルにアクセスしてください。

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

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

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

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

サービスリクエスターまたはコンシューマー

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

以下に示すのは、サービスプロバイダーとして機能し、アプリケーションで使用されるWebサービスとして2つのメソッド（addとSayHello）を公開する最初のWebサービスの例です。これは、Webサービスの標準テンプレートです。.NET Webサービスは、.asmx拡張子を使用します。Webサービスとして公開されているメソッドにはWebMethod属性があることに注意してください。このファイルをFirstService.asmxとしてIIS仮想ディレクトリに保存します（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サービスは、イントラネットまたはインターネットのいずれかで公開できます。このWebサービスは、ローカルマシンで実行されているIISで公開します。IISの構成から始めましょう。

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

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

Note−それが機能しない場合は、ローカルホストをマシンのIPアドレスに置き換えてみてください。それでも機能しない場合は、IISが実行されているかどうかを確認してください。IISと仮想ディレクトリを再構成する必要がある場合があります。

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

Webサービスのテスト

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

Webベースのサービスコンシューマー

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

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

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サービスのプロキシを作成します。プロキシは、.NETSDKに付属の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サービスの仮想ディレクトリ（c：\ MyWebServices \ bin）の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サービスにとって重要です。ただし、XML-RPC仕様もSOAP仕様も、明示的なセキュリティまたは認証の要件を定めていません。

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

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

守秘義務

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

答えはここにあります-

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

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

認証

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

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

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

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

現在、この問題に対する簡単な答えはなく、多くの議論の対象となっています。今のところ、SOAPまたはXML-RPCメッセージを除外することに真剣に取り組んでいる場合、1つの可能性は、コンテンツタイプをtext / xmlに設定するすべてのHTTPPOSTリクエストを除外することです。

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

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

トランスポート

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

Extensible Exchange Protocol（BEEP）をブロックします

メッセージング

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

SOAP 1.1（注）
SOAP 1.2（仕様）
Webサービス添付ファイルプロファイル1.0
SOAPメッセージ送信最適化メカニズム

説明と発見

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

UDDI 3.0
WSDL 1.1（注）
WSDL 1.2（ワーキングドラフト）
WSDL 2.0（ワーキンググループ）

セキュリティ

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

Webサービスセキュリティ1.0
セキュリティアサーションマークアップ言語（SAML）

管理

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