レベル: 中級 Bruce Sun, Java Architect, National Center for Atmospheric Research
2009年 6月 09日 SOAP ベースのサービスに代わる有望なサービスとして、RESTful な Web サービスが登場しつつあります。これは RESTful な Web サービスが単純で軽量であり、HTTP で直接データを送信できるためです。この記事では REST と RESTful な Web サービスについて、その概念の概要を学び、RESTful な Web サービスを RPC スタイルあるいは SOAP ベースの Web サービスと比較します。また、RESTful な Web サービスを構築するための Java™ フレームワークについて、さらに RESTful な Web サービスの構築にも動的な Web アプリケーションの構築にも共通で使用できるマルチティア・アーキテクチャーについても学びます。
はじめに
最近の Web アプリケーションでは、Ajax (Asynchronous JavaScript and XML) や GWT (Google Web Toolkit) を使ってデスクトップ風のリッチなブラウザー・インターフェースを提供することや、外部のクライアント・アプリケーションに RESTful な Web サービスを提供することが当然のこととなっています。この記事では、2 つのハンドラーを提案します。1 つは外部クライアント・アプリケーションからの呼び出しと Ajax/GWT に対応するためのリソース･リクエスト･ハンドラー (RRH: Resource Request Handler)、もう 1 つはブラウザーからのリクエストを処理し、ブラウザーで表示できるような出力を生成するためのブラウザー・リクエスト・ハンドラー (BRH: Browser Request Handler) です。どちらのハンドラーも共通のビジネス・ロジック・レイヤーを共有しており、このビジネス・ロジック・レイヤーがデータ・アクセス・レイヤーとやり取りします。RRH と BRH を抽出することで設計が単純化されてコードの再利用が促進され、柔軟で拡張性の高いアーキテクチャーを実現することができます。
REST とは何か
REST (REpresentation State Transfer) とは、Web アプリケーションなどのネットワーク化されたシステムのアーキテクチャー・スタイルの 1 つを表す言葉です。REST は 2000年に HTTP 仕様の主要作成者の 1 人である Roy Fielding の博士論文の中で初めて紹介されました。REST はアーキテクチャーに関する制約と原則を集めたものを指します。そうした制約と原則に一致するアプリケーションや設計は RESTful です。
Web アプリケーションに関する REST の原則で最も重要なことの 1 つは、クライアントとサーバーとの間のやり取りが、リクエストとリクエストの間でステートレスであることです。クライアントからサーバーへの各リクエストは、そのリクエストを理解するために必要な情報をすべて含んでいなければなりません。クライアントは、リクエストとリクエストの間のどこかの時点でサーバーが再起動されたかどうか、まったく認識しません。また、ステートレスなリクエストには何の制約もないため、対応可能な任意のサーバーが応答することができますが、これはクラウド・コンピューティングなどの環境にとって好都合です。クライアントはデータをキャッシュすることでパフォーマンスを改善することができます。
サーバー・サイドでは、アプリケーションの状態と機能はリソースに分割されます。リソースというのは関心対象となる項目であり、クライアントに公開される概念的な識別情報です。リソースの例としては、アプリケーションのオブジェクト、データベースのレコード、アルゴリズムなどがありますが、URI (Universal Resource Identifier) を使うことですべてのリソースを一意に指定することができます。すべてのリソースは、クライアントとサーバーとの間で状態の転送を行うための統一されたインターフェースを共有しています。メソッドとしては、標準的な HTTP メソッド (GET、PUT、POST、DELETE など) が使われます。ハイパーメディアはアプリケーションの状態のエンジンであり、またリソース表現はハイパーリンクによって相互接続されます。
REST の原則で、もう 1 つ重要なものがレイヤー構造のシステムです。つまりコンポーネントは、そのコンポーネントが直接やり取りしているレイヤーを超えて何かを見ることはできません。システムに関する情報を 1 つのレイヤーに限定することでシステム全体としての複雑さが制限され、システムを構成する各部分を独立したものにしやすくなります。
REST によるアーキテクチャーの制約が全体として適用されると、生成されるアプリケーションは大量のクライアントに対しても適切にスケーリングできるようになります。またこのアーキテクチャー制約によって、クライアントとサーバーとの間でやり取りする際のレイテンシーも低く抑えることができます。統一的なインターフェースによってシステム全体としてのアーキテクチャーを単純化することができ、またサブシステム間のやり取りが見えやすくなります。REST によって、クライアントの実装もサーバーの実装も単純になります。
RESTful な Web サービスと RPC スタイルの Web サービス
最近まで、SOA (Service-Oriented Architecture) を実装する際には、RPC スタイルのアーキテクチャーで作成された SOAP ベースの Web サービスを使う手法が最も一般的でした。RPC スタイルの Web サービスでは、クライアントはメソッドや引数の情報などのデータが詰まったエンベロープを HTTP でサーバーに送信します。サーバーはそのエンベロープを開き、エンベロープ内で指定されているメソッドを、渡された引数を使って実行します。そのメソッドの結果はエンベロープの中にパックされ、レスポンスとしてクライアントに返送されます。クライアントはそのレスポンスを受信し、そのエンベロープを開きます。すべてのオブジェクトには、そのオブジェクト独自のメソッドがあり、RPC スタイルの Web サービスは 1 つの URI (つまり 1 つのエンドポイント) しか公開しません。この Web サービスでは HTTP の大部分の機能は無視され、POST メソッドのみがサポートされます。
これまでの手法に代わり、RESTful な手法による Web サービスがよく使われるようになってきています。これは RESTful な手法が軽量な上、HTTP で直接データを送信できるためです。クライアントの実装には、Java プログラム、Perl、Ruby、Python、PHP、そして (Ajax を含む) JavaScript など、さまざまな言語を使うことができます。通常、RESTful な Web サービスへのアクセスには、自動化されたクライアントや、ユーザーに代わって動作するアプリケーションが使われます。しかし RESTful な Web サービスは単純であるため、人間が Web ブラウザーで GET URL を作成し、返されるコンテンツを読み取ることで、RESTful な Web サービスと人間とが直接やり取りすることができます。
REST スタイルの Web サービスでは、すべてのリソースにはアドレスがあります。リソース自体がメソッド呼び出しのターゲットであり、またメソッドのリストはすべてのリソースに対して同じです。メソッドは HTTP の GET、POST、PUT、DELETE などの標準的なものであり、場合によると HEADER と OPTIONS が使われることもあります。
RPC スタイルのアーキテクチャーではメソッドに注目しますが、REST スタイルのアーキテクチャーではリソースに注目します。リソースというのは、表現として取得され、標準的なメソッドを使って操作される情報の断片の集まりです。リソース表現同士は、その表現の中のハイパーリンクによって相互接続されます。
Leonard Richardson と Sam Ruby は彼らの著書である『RESTful Web サービス』の中で、「REST-RPC」という混成アーキテクチャーを表す言葉を使っています。メソッドや引数、データをラップするためにエンベロープを使う代わりに、REST-RPC 混成 Web サービスでは HTTP で直接データを送信します。これは REST スタイルと似ています。しかしこの混成 Web サービスでは、標準的な HTTP メソッドを使ってリソースを操作するのではなく、メソッドの情報を HTTP リクエストの URI 部分に含めます。Yahoo の Flickr API や del.icio.us の API など、いくつかの有名な Web サービスでは、この混成アーキテクチャーを使用しています。
RESTful な Web サービスのための Java フレームワーク
RESTful な Web サービスの構築を支援するフレームワークとして、2 つの Java フレームワークが登場しました。そのうちの 1 つ、Jerome Louvel と Dave Pawson による Restlet (「参考文献」を参照) は軽量です。Restlet は、Web サービスをはじめとするあらゆる種類の RESTful なシステムの、リソース、表現、コネクター、メディア・タイプなどの概念を実装しています。Restlet フレームワークでは、クライアントとサーバーの両方がコンポーネントです。コンポーネント同士はコネクターを使って通信を行います。このフレームワークで最も重要なクラスは、Uniform 抽象クラスと、その具象サブクラスである Restlet です。Restlet のサブクラスは、Application、Filter、Finder、Router、Route などの特別なクラスです。これらのサブクラスを組み合わせることで、認証、フィルタリング、セキュリティー、データ変換、そして受信リクエストを対象リソースにルーティングする動作などが行われます。また、Resource クラスはクライアントの表現を生成します。
JSR-311 (「参考文献」を参照) は Sun Microsystems による仕様であり、RESTful な Web サービスを開発するための一連の Java API を定義しています。もう 1 つのフレームワークである Jersey (「参考文献」を参照) は JSR-311 のリファレンス実装です。
JSR-311 には関連するクラスとインターフェースと共に一連のアノテーションが提供されており、それらを使って Java オブジェクトを Web リソースとして公開することができます。JSR-311 の仕様では、ベースとなるネットワーク・プロトコルが HTTP であることを想定しています。JSR-311 では、URI とその URI に対応するリソース・クラスとのマッピング、また HTTP メソッドと Java オブジェクトのメソッドとのマッピングが明確に規定され、そのためにアノテーションが使われます。この API は広範な種類の HTTP エンティティーのコンテンツ・タイプをサポートしています (HTML、XML、JSON、GIF、JPG など)。またこの API には必要なプラグイン機能も提供されており、標準的な方法でアプリケーションがコンテンツ・タイプを追加することができます。
RESTful な Web サービスを構築するためのマルチティア・アーキテクチャー
RESTful な Web サービスと動的な Web アプリケーションは多くの点で似通っています。場合によると、対象とするクライアントの種類は異なっていても、両者が同じ、あるいは非常に似たデータや機能を提供する場合があります。例えば、オンラインの E コマース用のカタログを提供する Web サイトには、ユーザーが商品の検索、閲覧、注文をするためのブラウザー・インターフェースがあります。こうした場合、そのサイトが、企業や、小売店、さらには個人が商品を自動的に注文できる Web サービスも提供していると便利です。関心を分離できるというマルチティア・アーキテクチャー特有の性質は Web サービスにとってメリットがありますが、大部分の動的な Web アプリケーションにとってもほぼ同様のメリットがあります。ビジネスのロジックとデータは、自動化されたクライアントと GUI クライアントの両方で共有することができます。マルチティア・アーキテクチャーにおいて、Web サービスと動的な Web アプリケーションとの間での違いは、クライアントの性質と、中間ティアのプレゼンテーション・レイヤーにあります。またデータ・アクセスとビジネス・ロジックとが分離されると、データベースに依存しないことになり、さまざまなタイプのデータ・ストアに接続できるようになります。
図 1 は自動化されたクライアントを示しています。このクライアントには、Java と、さまざまな言語 (Python、Perl、Ruby、PHP、あるいは curl などのコマンドライン・ツール) によるスクリプトが含まれています。Ajax、Flash、JavaFX、GWT、ブログ、ウィキなど、ブラウザー内部で実行され、RESTful な Web サービスのコンシューマーとして動作するものも、(ユーザーに代わって自動化された形式で動作するので) このグループに属します。自動化された Web サービス・クライアントは HTTP リクエストを Web ティアの RRH (Resource Request Handler) に送信します。クライアントからのステートレスなリクエストには、ヘッダーの中にメソッドの情報 (つまり POST、GET、PUT、DELETE) が含まれており、これらの情報は、RRH での対応するリソース操作にマッピングされます。各リクエストには、RRH がリクエストを処理するためのクレデンシャルなど、必要な情報がすべて含まれています。
図 1. マルチティアの Web アプリケーション環境のブロック図
RRH は Web サービス・クライアントからのリクエストを受信すると、ビジネス・ロジック・レイヤーからサービスを要求します。RRH はシステムが公開する概念的なエンティティーをすべてリソースとして識別し、各リソースに対して一意の URI を割り当てます。しかし概念的な識別情報は、このプレゼンテーション・レイヤーには存在せず、ビジネス・ロジック・レイヤーにあります。RRH の実装には Jersey や他のフレームワーク (Restlet など) を使うことができますが、主に重たい処理をビジネス・ロジック・レイヤーに委任することで RRH を軽量にする必要があります。
Ajax による Web サービスと RESTful な Web サービスは、お互いに自然な形で適合します。どちらも、HTML、JavaScript、ブラウザー・オブジェクト、XML/JSON、HTTP など、非常に一般的な Web 技術と Web 標準を活用しています。Ajax によるフロントエンドと RESTful な Web サービスとの間で効果的なやり取りを実現する上で、他の重要なコンポーネントを購入、インストール、構成する必要はまったくありません。RESTful な Web サービスは Ajax に対して、サーバー上のリソースを操作するための非常に単純な API を提供します。
図 1 の Web ブラウザー・クライアントは GUI フロントエンドとして動作し、プレゼンテーション・レイヤーの BRH (Browser Request Handler) が生成する HTML を使って表示機能を提供します。BRH は MVC モデルを使って実装することができます (JSF、Struts、Spring は Java の例です)。BRH はブラウザーからのリクエストを受け付け、ビジネス・ロジック・レイヤーからサービスを要求し、プレゼンテーションを生成し、そしてブラウザーに応答します。プレゼンテーションは、ブラウザーによってユーザーに表示するためのものです。プレゼンテーションには単にコンテンツが含まれるだけではなく、HTML や CSS など、表示するための属性も含まれています。
ビジネス・ルールはビジネス・ロジック・レイヤーに集められ、ビジネス・ロジック・レイヤーはプレゼンテーション・レイヤーとデータ・アクセス・レイヤーの間でのデータ交換の仲介を行います。データはドメイン・オブジェクトまたは値オブジェクトの形でプレゼンテーション・レイヤーに提供されます。BRH と RRH をビジネス・ロジック・レイヤーから分離することでコードが再利用しやすくなり、またアーキテクチャーの柔軟性や拡張性が高まります。さらに今後新しい REST フレームワークや MVC フレームワークが利用できるようになれば、ビジネス・ロジック・レイヤーを作成し直さなくても、それらのフレームワークを容易に実装することができます。
データ・アクセス・レイヤーはデータ・ストア・ティアとのインターフェースを提供します。データ・アクセス・レイヤーの実装は DAO デザイン・パターン、あるいはオブジェクト・リレーショナル・マッピングによるソリューション (Hibernate、OJB、iBATIS など) を使って行うことができます。あるいはそうする代わりに、ビジネス・レイヤーとデータ・アクセス・レイヤーのコンポーネントを EJB コンポーネントとして実装することもできます (そのためには、コンポーネントのライフサイクルの支援と、パーシスタンス、トランザクション、リソース割り当ての管理を行う EJB コンテナーによるサポートを利用します)。しかしその場合には、Java EE 準拠のアプリケーション・サーバー (JBoss など) が必要であり、Tomcat では動作しません。このレイヤーの強力さは、データ・アクセス・コードをビジネス・ロジックから分離し、まったく異なるデータ・ストア技術を利用できる点にあります。またデータ・アクセス・レイヤーは、例えば他の Web サービスのクライアントとして機能するなど、他のシステムと接続するための統合ポイントとしても機能します。
データ・ストア・ティアには、データベース・システム、LDAP サーバー、ファイルシステム、そしてエンタープライズ情報システム (レガシー・システム、トランザクション処理システム、エンタープライズ・リソース計画システムなど) などがあります。このアーキテクチャーを使用すると、RESTful な Web サービスの強力さがわかり始めるかもしれません。つまり RESTful な Web サービスは、あらゆるエンタープライズ・データ・ストアに対する統一的な API となる柔軟性を備えています。そのため、それまで用途が限定されていたデータを、ユーザー中心の Web アプリケーションや自動化されたバッチ・レポート・スクリプトに公開できるようになります。
まとめ
REST とは、Web アプリケーションなどのネットワーク化されたシステムのアーキテクチャー・スタイルの 1 つを表す言葉です。REST による制約を全体に対して適用すると、単純で、スケーラブルで、効率的で、セキュアで、信頼性が高くて、拡張性のあるアーキテクチャーを構成することができます。RESTful な Web サービスは SOAP ベースのサービスに代わる有望なものとして登場しましたが、それは RESTful な Web サービスの単純さ、軽量な性質、そして HTTP で直接データを送信できる機能によるものです。Web サービスの場合も動的な Web アプリケーションの場合も、マルチティア・アーキテクチャーを採用することによって再利用性、単純さ、拡張性が向上し、また各コンポーネントの役割が明確に分離されます。Ajax と RESTful な Web サービスは、お互いに自然な形で適合します。Ajax と RESTful な Web サービスとを組みあわせて開発を行うことで、リッチなインターフェースを容易に作成することができます。
この記事は、著者によるチュートリアルに先行するものです。そのチュートリアルでは、この記事で説明したマルチティア・アーキテクチャーを使って RESTful な Web サービスと動的な Web アプリケーションを構築する方法を説明します。また、REST Web サービス、Ajax、そして Spring Web Flow を組み合わせることでデスクトップ風のリッチな Web インターフェースを作成する方法の一例も紹介します。そして、Jersey、Spring、MySQL、Tomcat を使用し、Eclipse で構成と実装を行います。
なお、この記事は、University Corporation for Atmospheric Research (米国大気研究大学機構) との協力協定に基づいて National Science Foundation (全米科学財団) が一部をサポートする研究によって実現したものです。National Center for Atmospheric Research は National Science Foundation の後援を受けています。最後に、この記事への助言と編集でご協力いただいた、NCAR の Markus Stobbs 氏に感謝いたします。
参考文献 学ぶために
製品や技術を入手するために
著者について  | 
| | Bruce Sun は Sun Microsystems 認定の Java アーキテクトです。彼は 1998年以来 Java ベースの Web アプリケーション開発を行っています。現在は NCAR (National Center for Atmospheric Research) でシニア・ソフトウェア・エンジニアとして業務を行っています。 |
記事の評価
| 
