リソース指向Webサービスとアクティビティー指向Webサービスを比較する

REST形式そしてSOAP形式のWebサービスの関係

最近公開されたBloglines API は、同じWebサービスであるREST(Representational State Transfer)とSOAP(Simple Object Access Protocol )の比較に関するまた新たな論議に拍車をかけています。しかしながら、一般的に信じられている通説とは異なり、これらの特殊なSOA(Service-Oriented Architecture )の設計パターンは互いに排他的なわけではありません。それでいて、片方がより優れていると言うわけでもありません。それぞれが異なるアプリケーションのシナリオに関連する相対的な長所と短所を持ち合わせ、どちらもが実在する消費者が直面する実際の問題を解決するうえで妥当なアプローチなのです。どちらのアプローチを使うべきかを判断するのが秘訣なのですが、多分解答は想像よりも簡単です。

James Snell, Software Engineer, IBM

James SnellJames Snell 氏はIBM Emerging Technologies Toolkit チームの一員であり、過去数年間にわたり新興のWebサービスの技術そして標準に焦点を合わせてきました。developerWorks にて、新興の技術に焦点を定めるウェブログ(http://www.ibm.com/developerworks/blogs/snell)を管理しています。


developerWorks 貢献著者レベル

2004年 10月 12日

開発者によるサービスとの統合を可能にするWebサービスAPIをWebアプリケーション・サービスのプロバイダーが提供するたびに、APIにより実装される相互作用の設計パターンに注目が集まります。APIがRest形式の相互作用を使えば、RESTのアプローチの提案者は(REST形式のサービスがSOAP形式のサービスよりも遥かに優れている決定的で反論の余地のない理由として)APIを賛美します。APIがSOAP形式のWebサービスのパターンを使用する場合にも、同様のことが言えます。主にパターンの選択が実装されるアプリケーションの種類に依存すると言う事実にあまり注目が集まらない模様です。ひとつのアーキテクチャーのアプローチへの特定的なこだわりよりも、特定の技術上の必要性と作成されているアプリケーションの特性を基に開発者たちは選択を行なうべきです。

リソースか、それとも、アクティビティーか?

根源的なレベルにて、REST形式のWebサービスとSOAP形式のWebサービスの相違点は、アプリケーションがリソース指向かそれともアクティビティー指向であるかによります。

リソース指向サービス(Resource-oriented services)は、一掴みの基本的で標準的な操作が実行される特殊なデータ・オブジェクトに焦点を合わせます。オブジェクト指向の設計パターンの概念に慣れている開発者から見れば、権威あるGang of Four(GoF)による書物Design Patterns にて説明されているとおり、リソース指向サービスは基本的なMementoのパターンと似通っています。本質的には、サービス・プロバイダーは以下のようなタスクを実行するために、リソースのコレクションを管理し基本的な操作のコレクションを公開します。

  • リソースを回収
  • リソースを修正
  • 新規リソースを作成
  • リソースを削除

定義上、REST形式のWebサービスはリソース指向のサービスです。URI(Universal Resource Identifier)でリソースを識別そして見付けられ、それらのリソースに対して実行されるオペレーションはHTTP仕様により定義されます。中核のオペレーションは、以下のものを含みます。

  • GET - このオペレーションは識別されたリソースの状態の表記を戻します。誰が要求を送信しているか、オペレーションの(HTTPヘッダーまたは照会ストリング・パラメーターとして受け渡される)パラメーターか、そしてサービス・プロバイダーにより管理されている現行セッション状況のような数々のコンテキストの要素により、状況を判断できます。
  • POST - このオペレーションは識別されたリソースへのアプリケーションに特化したアップデートの一形式を実行します。このオペレーションの振る舞いはそれを実装するサービスに完全に依存します。このオペレーションにより戻されるデータも完全にそのアプリケーション次第です。例として、それはGETオペレーションのように状態の表記を戻せますし、標準そして必須のHTTP応答以外にどんなデータをも戻さない道を選ぶかも知れません。
  • PUT - このオペレーションはURIに識別される場所にて新規のリソースを作成します。オペレーションの入力はリソースの状態の表記を含まなくてはなりません。その状態の表記を基にしたリソースを作成するかどうかは、サービス次第です。
  • DELETE - DELETEオペレーションは識別された位置(URI)にあるリソースを破棄します。

様々な意味で、REST形式のWebサービスはSQL、タプルスペース(tuple spaces)、そして簡素なメッセージ・キューなどのような技術と類似します。それらの全てが特殊なリソースに対して実行されるように一般的で単純なオペレーションを使用します。

  • SQL - SELECT、INSERT、DELETE、そしてUPDATEなど
  • タプルスペース - GET、PUT
  • メッセージ・キュー - SEND、RECEIVE

それぞれのケースにおいて、サービス・インターフェースの設計はリソースに関する情報を動かすことを可能にし、その情報を実際にそれがどのように処理するかの理解を要求者にゆだねます。

逆の見方として、アクティビティー指向サービス(activity-oriented services)があります。この種類のアプリケーションは、それが実行するときに使うリソースよりも実行するアクションに焦点を合わせます。アクティビティーのサービスの簡素な例として、消費者が預金を口座から口座へ振り替える場合の銀行取引があげられます。消費者は(お金、銀行口座などの)リソースに直接関わりたくはありません。彼らはただ単に何を銀行に求めているかを伝え、そして彼らに代わって銀行がリソースを取り扱うことを期待します。Gang of Four(GoF)の言葉を借りれば、以下の項目のアプリケーションについて述べているのです。

  • コマンド
  • 仲介者(Mediator)
  • ストラテジー(Strategy)
  • プロキシーの設計パターン

リソース指向サービス(実行されたオペレーションがリソースのタイプに関係なく相対的に一定)と異なり、アクティビティー指向サービスでのオペレーションは実行されたアクティビティーのタイプに完全に依存します。例えば、銀行のサービスは(その多種にわたる入力がサービスの基金振替能力に完全に特化される)transferFundsと呼ばれるオペレーションを公開するかも知れません。

リソース指向サービスでは、共通のオペレーションの一群は支援する役割を果たし、クライアントのリソースへの操作そしてアクセスを可能にします。この場合、下記の図1に示されるとおり、リソースは中心的存在です。

図1. リソース指向サービスとアクティビティー指向サービスの比較
図1. リソース指向サービスとアクティビティー指向サービスの比較
図2. リソース指向サービスとアクティビティー指向サービスの比較
図2. リソース指向サービスとアクティビティー指向サービスの比較

アクティビティー指向サービスでは、それぞれの(クライアントが実行を要求するかも知れない)アクティビティーに1つずつオペレーションがあり、オペレーションが中心的存在です。

SOAP形式のWebサービスは一般的にはアクティビティー指向です。WSDL文書はサービスに特化されたオペレーションを定義そして記述します。オペレーションはサービスに特化したメッセージの交換から構成されています。それぞれのオペレーションが、実行されるかも知れないアクティビティーなのです。何に対してそれらのオペレーションが実行されているかなど、どうでもいいのです。WS-Resource Framework の系統の仕様に記述されているようにリソースはアクティビティーにて暗黙指定されるかも知れませんが、そのような考慮点はアクティビティーの定義と直交関係にあり、アクティビティーが実行されているところにあるコンテキストをリファインするのみです。(リソースに対して実行されるアクティビティーがリソースにアクセスするのに使われるサービス・インターフェースに対して直交関係にあるような)リソース指向サービスとは対照的です。


コンテキストにて反映: Bloglines サービス

Bloglines とは、RSS(Really Simple Syndication)そしてAtom feedの形式で配信されるニュース配信のコンテントそしてウェブログへの多種にわたるサブスクリプション(subscriptions)を個人が追跡するのを可能にするWebベースのアプリケーション・サービスです。

Bloglines サービスは根源的にリソース指向です。ユーザーはサブスクリプションを作成、アップデート、そして削除し、サイトへの最近のアクセス以来どのようなアップデートが発生したかを調べるために定期的にサービスにアクセスします。REST形式のWebサービス・インターフェースを活用することにより、Bloglines APIは適切にこのリソース指向性を反映します。

具体的に言えば、Bloglines サービスの中心に存在するのは、一般的にblogrollとして知られるユーザーのサブスクリプションのコレクションです。単独のblogroll は多数の異なるサブスクリプションから構成されるかも知れません。サブスクリプションはRSSまたはAtom feedに向けられます。

Blogrolls そしてサブスクリプションは、両方ともリソースです。Bloglines API は基本的なHTTPオペレーションを使用し、ユーザーのblogroll そしてサブスクリプションのリソースに関する現行の状況情報を取得します。

例えば、ユーザーのblogrollの現行のスナップショットにアクセスするのに、ユーザーはHTTP GET 要求をURI(//rpc.bloglines.com/listsubs)に送信するかも知れません。厳密にRESTの用語で言えば、このAPIは全てのBloglines ユーザーのサブスクリプションを識別します。オペレーションを呼び出すとき、どのユーザーのサブスクリプションを回収するかに関する追加的なコンテキストをHTTP認証要求が収集します。オペレーションに戻される情報は、認証されたユーザーへの個別のサブスクリプションを全てリストするXML文書から構成されます。

特定のサブスクリプションの現行のスナップショットにアクセスするために、ユーザーはURI(http://rpc.bloglines.com/getitems?s={subid})にHTTP GET要求を送信するかも知れません。{subid} は、上記にて説明されるlistsubs オペレーションの結果にて表示される固有のサブスクリプションIDを割り当てられるBloglines です。追加的なパラメーターは定義され、(興味深いことに)GETオペレーターが『べき等』であるべき(つまり、それらがリソースの状態の変化を起こしてはならない)と言う根源的なRESTの掟を実際に破るものをも含みます。供給されれば、パラメーター(n=1)は以前に未読のサブスクリプションの入力を既読と記すようにBloglines に対して命令し、事実上リソースの状態を変更します。

ユーザーのblogrollにてどれだけの未読のサブスクリプションのアイテムがあるかのカウントを戻すのに、ユーザーはHTTP GET 要求をURI(http://rpc.bloglines.com/update?user={email}&ver=1)に送信できます。{email} とは、ユーザーのE-mailアドレスであり、そのアカウントにある未読のサブスクリプションの入力をチェックするべきなのです。

Bloglines API が唯一懸念をいだくのは、blogrolls とサブスクリプションのリソースへのプログラマチックなアクセスを許すことです。(一度そのアクセスが実行されれば)クライアントがblogrolls やサブスクリプションに対して何をするかなど、APIは気にも留めません。

対照的な例を示すために、病院での患者の記録へのアクセス、処方せんの書類、手術のスケジュールなどを自動化するWebサービスの使用を図解するためにIBMが実装した最近の(概念の証明(proof-of-concept)とも言える)プロジェクトと比較してみてください。(クライアントとの不開示の同意により保護される)詳細にあえて触れませんが、システムにてユーザーが実行できるアクティビティーに焦点を厳密的に合わせるのが、そのシステム用に作成されたサービス・インターフェースのコレクションの第一の目的です。例えば、患者の検査または手続きのスケジュール、そして(検査結果の入手可能性のような)イベントの非同期通知の要求があります。患者の記録(リソース)はシステムの重要な側面でありますが、一般的にそれらは総括的なアプリケーションにて脇役をつとめ、システムの中心的な焦点ではありません。逆に、病院のプロトタイプはアクティビティー指向サービスであり、それはそのSOAP形式のWebサービス・アーキテクチャーにて正確に反映されております。

これらの論点は簡単です。RESTにするかSOAPにするかの選択は、特定のアプリケーションにとって何が最重要であるかの基本的な理解にゆだねられます。(Bloglines サービスのように)情報リソースへのアクセス能力にアプリケーションが重点をおいているのでしたら、主にリソース指向サービスをいだくことになりREST形式の設計パターンをアプリケーションにて採用することを考えますでしょう。Amazon、del.icio.us、Flickr、Safari、そして他のサイト(参考文献を参照)に提供されるサービスAPIを考慮すれば、無視できない前例があるのがわかります。しかしながら、アプリケーションが主に(それらが実行するリソースに対して直交するように実行される)アクションに焦点を合わせられているのでしたら、サービスはアクティビティー指向であり、多分SOAP形式の設計パターンを活用することでしょう。


機能 vs. フォーム

RESTを基にしたパターンの支持者たちは、(SOAPと関連するWebサービス仕様の広範囲にわたるコレクションにて見受けられる複雑性と比較した場合に目立つ)構造上の簡素さを指摘し、それゆえにRESTが他よりも優れたアプローチであると主張します。すでに説明したとおりですが、これらのアプローチがそれぞれ異なる種類の問題の解決を試みると言う意味で、この論点は不毛です。Bloglines、Amazon、flikr、そしてdel.icio.usなどのようなWebベースのアプリケーション・サービスは、例えば(注文手続きや処方せんの作成などの内部プロセスの自動化を求めるがゆえに設計上のアプローチが異なる)病院などとは別物の論点に直面します。そうであるからこそ、異なる問題を解決する異なるアプローチとして、複数の設計パターンが存在するのです。

特定のビジネス要件のコンテキスト以外で比較される場合、業界にて活躍している無数のWS-* 仕様に定義されるSOAP Webサービス・アーキテクチャーよりも、RESTのアーキテクチャーは遥かに簡素に見えます。しかしながら、とある重要な領域では、それは遥かに機能の面で劣ります。高信頼性メッセージングはその顕著な例です。HTTPはあまり信頼性の高いプロトコルではありません。『ただ一度きりの』または『うまくいくまで何度でもする』と言ったセマンティックを使用して確実にHTTP要求を送信する内蔵されたメカニズムと言うものがとにかく存在しないのです。REST/HTTPにて提供されるメッセージ・ルーティングのセキュリティー・メカニズムは、基本的なHTTPプロキシーのメカニズム以外に存在しません。REST形式のサービスでのセキュリティー・コンテキストは、HTTPプロトコルに提供されるセキュリティー・メカニズムに一般的には限定されますが、外部的に定義されるセキュリティー・メカニズムを取り入れることをアプリケーションが選択すれば話は違ってきます。(例として、HTTP GET要求への応答として、ディジタル署名または暗号化されたSOAPメッセージをRESTサービスは実際に戻せます。)

Bloglinesのようなサービスでは、アプリケーションの必要とするものを満たすのにはHTTPに提供される基本的なオプションで十分ですので、これらの機能的な制限は致命的ではありません。とにかくAPIは以下の項目を必要としません。

  • 高信頼性メッセージング
  • ディジタル署名
  • メッセージ・ルーティング
  • リソースのライフ・サイクル管理
  • 非同期イベント通知
  • SOAP WS-*仕様に導入された他の機能

それだからと言い、他のアプリケーションがアクティビティー・ベースのアプローチにより提供される強化された機能を必要としないとは限りません。

ここで言わんとしていることを誤解しないでください。少なくとも理論上これらのことをREST形式のサービスでこなすのは十分に可能です。今までに誰もそうするために矛盾がなく標準化された方法を定義する作業をしたことがないのが厄介なだけです。それが実現するまでは、(例えば非同期イベント通知や高信頼性メッセージ配信のようなことをするために)REST形式のインターフェースにて誰でもが実行するアプローチは、一度きりのサービスに特定された(一般的には他のどのREST形式のサービスにもサポートされない)実装となります。しかしながら、ここでより重要で指摘すべきなのは、(これらの拡張された機能は一般的にはリソース指向サービスよりもアクティビティー指向サービスにて応用でき、それゆえにアクティビティー指向であるSOAP形式のサービスの領域にてはるかに多くの仕様そしてより高レベルな複雑性が存在する)事実は驚愕に値しないことです。

簡単な注釈: 適切に取り扱えば、複雑なのも悪くはありません。確かに沢山のWS-*仕様が存在し、それらの全てが広範囲にわたる技術的な論題を網羅します。全体的には、これらはかなりの程度の知覚可能な複雑性を象徴します。しかしながら、それらを定義する方法は、アプリケーションをイネーブルするのに絶対に必要なものだけを選別する贅沢を堪能できると言う事実を示唆しています。全てのWebサービスが常に全てのWS-*仕様を実装することなど、誰も期待しておりません。


結論: 要はサービスなのです

結局は、業界がSOA(Service-Oriented Architecture)の方向に向けて前進を続けることが非常に重要なのです。与えられたアプリケーション・コンポーネントの設計パターン(Command、Mediator、Observer、Strategy、またはVisitor)のうちのどれかを実装することを選ぶ場合と同様の配慮を、REST形式かSOAP形式のどちらかを選択するときにも採用すべきです。簡単に言えば、それはビジネスやアプリケーションの必要性を基にした設計戦略としての選択以上の何物でもなく、どのようにアプリケーションが使用され進化をとげるかを根源的に左右する選択であります。しかしながら、Webサービスの設計パターンの選択よりも大事なのは、Webサービスを実際に提供するかどうかの選択です。どのような形式のサービスを実装しようとしているかに関係なく、そうすることは重要です。

参考文献

  • この記事にて考察されるBloglines へのAPI呼び出しでしたら、http://rpc.bloglines.com/listsubs, http://rpc.bloglines.com/getitems?s={subid}とhttp://rpc.bloglines.com/update?user={email}&ver=1 へどうぞ。Bloglines Web Service APIに関するより詳細にわたる情報でしたら、APIの文書を掲載したサイトをご覧ください。
  • SOAP形式とREST形式のインターフェースの両方を使用するWebサービスの用例でしたら、Amazon.com E-Commerce Services のサイトをご閲覧ください。
  • Webサービス(それのみならず)を含むEmerging Technology のトピックに関するより深い考察をお求めでしたら、著者のdeveloperWorks weblog を閲覧するのも手です。
  • Amazondel.icio.usFlickr、そしてSafari のどれもが、開発者に入手可能な興味深いWebサービスAPIをいくつか掲載しています。
  • IBMからのJavaを基にした最新のソフトウェア開発ツールとミドルウェア(トライアル版)、それとオンラインのチュートリアルと記事、そしてオンラインの技術フォーラムを提供するSpeed-start Web servicesにて、Webサービスに関する知識(情報)、ツール、そしてスキルを取得しましょう。
  • Webサービスに関連する数百ものタイトルを含む技術書物の包括的なリストのあるDeveloper Bookstoreを訪れてみて下さい。
  • 知識欲の袋に底はないのでしょうか?SOA and web services のページは、数百にもわたる情報豊かな記事と、Webサービス・アプリケーションの開発方法についての(初級、中級、そして上級の)チュートリアルを提供します。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=243761
ArticleTitle=リソース指向Webサービスとアクティビティー指向Webサービスを比較する
publish-date=10122004