Web Services versus Other Technologies

Webサービスは、CORBA, DCOM, EJBのような伝統的な分散処理技術のようなものではなく、基礎となっているHTMLやHTTPのWebサーバのようなものである。Webサービスは、基本的には、実行可能なソフトウェアプログラムに対応付けられた一方向の非同期メッセージである。Webサービスは、プログラミング言語、オペレーティングシステム、ネットワーク輸送、データ記憶メカニズムに独立してデータ形式を定義する。それゆえ、独立した形式の中や外から対応付けられなければならない。データ型やデータ構造は、基礎となるサービスの実装から抽象化されている。Webサービスはよく、遠隔手続き呼出し又は、ソフトウェアコンポーネントに例えられます。しかしながら、Webサービスは、企業アプリケーション統合アダプターに例えるのが、より適切です。Webサービスは、MQSeries, TIBCO, NEON, VitriaやIONA's Orbix E2AのようなEAIソフトウェアシステムのような正統なメッセージ形式を定義しているのであって、データが、基礎アプリケーションに対応付けられたり、送信されたりする事を通して、サービスインタフェイスにメッセージが向けられる方法を定義するのではない。言い換えれば、基礎となるメッセージをソフトウェアプログラムにどう対応付けるかはCORBA, J2EEとDCOM、サービス名と起動するプログラムをしっかりと連結するRPC概念に基づいているもの全てのようなものはインターフェイス自体には含まれていない。むしろ、その情報はメッセージを消費し、メッセージの解析やデータをWebサービスを実装するどんなプログラムにでも関連づけるやり方について関連した指示に従うXMLプロセッサー内には含まれていない。更に、Webサービスは、コミュニケーションパス両端上の同様のソフトウェアシステムの存在を必要としたり、仮定したりしない。EAIアダプターは、同様に正規のメッセージ形式を受け入れ、メッセージ上の情報をエンタープライズリソースプランニング（ERP）ないしは、企業アプリケーションの他のタイプに対応付ける。Webサービスは同様の抽象レベルで定義されている。そしてその事が、同じメッセージタイプが多数のアプリケーションに対応付けられるのを許し、RPCに基づいたコンポーネントに制限されません。Webサービスは同期、エミュレーションを通じてRPC型通信の典型である要求／返答パラダイムを支援し、すなわち要求と応答が相互に関連したプロトコルというより、XMLプロセッサーです。例えば、SOAPのHTTPのマッピングはプロトコルレベルの要求／返答の相互関係を支援しません。RPCのWebサービスエミュレーションは容易にCORBA,EJB,やDCOMのような伝統的なRPCに基づいたシステムに容易に対応付けられ、けれどもQOS（安全性、処理や例外処理）の特徴は伝統的な分散処理技術において利用可能なものとは異なり、トランスポート層や各技術に特有な層に頻繁に緊密に結び付けられたりする。なぜならWebサービスの相互作用Webサービスが対応付けられたプログラムやデータベースを通して遂行されました、ユーザーの経験は伝統的なブラウザに基づいた経験とはとても異なるらしい。Webサービスはブラウザのようなものというよりもより伝統的なアプリケーションである。もちろんブラウザは使用されるかもしれないが。(先に述べたように、Webサービス自体は実行可能ではなく、その代わりにプログラム、オブジェクト、ミドルウェアシステム又はデータベース管理システムに対応付けられなければならない。)

Additional Technologies

SOAP,WSDLやUDDIのようなコアWebサービスは異種の技術ドメインを橋渡ししたり、ビジネスプロセスフローに対するドキュメントに従うのに役立つ。しかしながらインターネット上でアプリケーション構築ブロックの使用を可能にさせるものとして、より多くのアプリケーションの型に役立ち、完全なWebサービスのビジョンを完成する為には、Webサービス技術は付加的な特徴、機能、QOSを包含するよう拡張されなければならない。より役に立つ技術基板の方へ発展している進行中の研究Webサービスは1990年代にOMGによって試みられた共通のオブジェクト要求ブローカーアーキテクチャーの発展にとても似通っています。OMGの研究は処理、非同期メッセージング、セキュリティー、フェイルオーバー、フォールトトレランス等に対する豊富な仕様書のセットを生み出した開放的で協力的な努力を導いた包括的なソフトウェア構築を定義した。同様のタイプの努力がWebサービスに対するW3Cで始められ、そして、同様のアーキテクチャーが発展している。Webサービスの世界では、主要な産業ソフトウェアベンダーは、中核基準に既に一致し、そして、それは、標準化の真のテストである。Microsoft、IBM、SunMicrosystems、 BEA Systems、 Oracle、 IONAと他のものはSOAP、WSDLとUDDIを実行する事において一致したが、ebXMLレジストリの役割について何らかの意見の食い違いがあるままである。しかしながら、基本的な標準に対するもの以外に提案は、頻繁にビジネスプロセスフロー定義についてのMicrosoftとIBMの意見の食い違いのように争われます、すなわちXLANG対WSFLとセキュリティ情況を扱う提案の争いです。付加的な技術は、第一に次の重要分野に焦点が当てられます。
・　セキュリティ
・　プロセスフロー
・　処理
・　メッセージング
最も重要なWebサービスに対する付加的な技術の中には、セキュリティー技術を含んでいます。セキュリティは、Webサービスのデータの信頼性や正当性を確認する為に重要である。意図されたデータの受け手以外は誰もメッセージの中身を調べたり、改ざんするのを認めてはならない。セキュリティは又、特に多数のWebサービスが共に利用される時に、意図したものしかWebサービスを利用する事が出来ないように、Webサービスへのアクセス制御をする為に必要である。提案された標準は認証と認可（SAML）や公開鍵暗号処理（XKMS）に存在する。もちろん、あらゆるインターネットセキュリティの基本は、SSLやHTTPに基づいたプロトコル、基礎的な暗号レベルのセキュリティに対するHTTPSである。HTTPSに加えて、ファイアーウォール、SAML、XKMS、デジタル署名の使用やXML暗号化、MicrosoftはWebサービスの相互作用に関連した資格であるWS-Licenseを提案した。プロセスフローはWeb上や企業内部のビジネスプロセス相互作用を自動化する為に、重要である。プロセスフローは購入要求、旅行の予約のプロセス又は、製造計画の実行のような与えられた目的を成し遂げる為に必要な一連の相互作用の関係を定義しているので、プロセスフローもまた頻繁に管弦楽編曲と呼ばれる。フローは与えられたビジネスプロセスの為に定義された段階の連続として設計された。一連の段階は、Webサービスが定義されうる機能の集合を生成する。自動化されたビジネスの運用の世界では、処理は、実行プラットフォームがソフトウェアやハードウェアフェイラーに関わらずデータについての一連の関連したオペレーションから一貫した結果を生み出す事を保証し、長い間実行の部分を演じてきた。これらの伝統的なプロトコルや技術は直接的にWebに対して適用可能ではない、しかしながら、それらは、データベースが処理結果の未決定な通知をロックするという事を考える事が可能でコネクション指向のプロトコルが送信失敗を自動的に検出するのに活用できるしっかり連結された環境に対して設計されている。OASISからのBTPは多数のWebサービスの相互作用の結果が正確に広められ、共有されているという事を保証する緩く連結されたプロトコルを定義することによってWebサービスに対するこの問題を解決する為に設計された。メッセージングプロトコルは非同期一方向、要求／返答、放送や会話ないしはピアツーピアのようなWebサービスの相互作用通信様式を実行します。付加的なWebサービス技術もまた信頼できるか保証された配達、セキュリティや通信情況の普及、そして1つないしは1つ以上の中継点を含む定義されたパスに沿って正確にメッセージを送信するようなあるQOSに対するメッセージング層に依存するかもしれない。IBMはこの分野で必要条件に取り組む為に信頼できるHTTP(HTTPR)を提案した。IBMとMicrosoftは特別なメッセージ対象で利用可能なWebサービスについての情報を発見する為のWS-検査提案を合作した。Microsoftもまたいくつかの中継点を含んでいるWebサービスに対する特定のメッセージパスや指定されたルートに沿って前後にメッセージを送信する仕方を定義する為にWS-照会やWS-ルーチングを提案した。IETFからBEEPはコネクション指向のIPを定義する。BEEPに対するSOAPの対応は定義されていて、この場合は、SOAPメッセージは送り手や受け手側のセション情況を維持する為のBEEPから付加的なQOSを継承する。その情況はより大きな送信のより大きな単位へ多数のメッセージに関連づけたり、同じ発信元や同じ対象に対する意図された発信元からきているものとして多数のメッセージに関連するために用いられる。セキュリティーや処理の情況もまたコネクションと結び付けられる事が出来る。他の関連した標準や技術は次の構成によって定義されるものの多くを含む。
・　OASIS、進行中のebXMLとBTPやSAMLのような他の関連したXML提案を主催
・　RosettaNet、インターネット上のB2Bビジネスフロー相互作用に対する電子工学のベンダーのグループによって発達されたWebサービスの概念の影響者
・　UserLand、XML-RPCの開発者、SOAPの先駆者
・　OAGI、ビジネスや産業に対する正統なXMLドキュメント形式を定義している。
これらや他のグループの仕事は頻繁に電子工学、金融、ヘルスケアや他の産業に対するドキュメント形式やプロトコルを定義する為の基礎基準を置くような特定のビジネス目的に対するXMLの採用の促進に集中する。WebサービスがXMLに基づくので、インターネットビジネスの為のXMLに関連した技術の使用を促進しているほとんど任意の標準集団ないしは、企業の仕事は適切です。BTBやSAMLのような他の仕事の中にはとして出現する。

The Long Road Ahead

セキュリティ、処理や信頼できるメッセージングのような付加的な技術は、一般に今構築される必要があるXMLやHTTPの構造を含む基本の変更の為に、Webサービスの為に再び定義されなければならない分散処理環境に存在している事が分かった。World Wide Web Consortiumは、CORBAに対して定義されているアーキテクチャーであるOMGのようなWebサービスアーキテクチャーを定義する為の努力を試みるでしょう。けれども、これは、非常に困難で威圧するタスクである可能性があるらしい。W3Cは、特にそれらの食い違いが財界側によって動機付けられる時に、そのメンバー間の意見の重要な食い違いを解決する為に、設置されない。これは、実際多くの標準努力の没落である。そのWebサービスアーキテクチャー内のW3Cによって採用の為の候補の技術