Apache Wink による RESTful な Web サービス: 第 3 回 Apache Wink と REST

Apache Wink と他のオープンソース JAX-RS 実装を比較する

この記事は 3 回連載の第 3 回として、REST ベースの Web サービスを実装、利用するための新しい Java™ フレームワーク、Apache Wink 1.0 による開発での高度なトピックについて説明します。

Vishnu Vettrivel , Principal Consultant, PunditLabs

Photo of Vishnu VettrivelVishnu Vettrivelは、企業向けコンサルティングおよび技術を専門とする PunditLabs の主任コンサルタントで、10 年以上にわたり、ミッション・クリティカルなエンタープライズ・アプリケーションの構築、設計、開発に携わっています。フォーチュン 50 社に挙げられたさまざまなクライアントに協力し、多くの新しい技術に対する戦略的技術計画を立ててきました。



2010年 4月 06日

3 回連載の第 3 回となるこの記事では、Apache Wink と他の無料のオープンソース JAX-RS 実装 (Project Jersey、JBoss RESTEasy、Restlet Framework など) との比較を行います。そのなかで、各実装フレームワークの概要を説明するとともに、各実装フレームワークに共通した一連の特性をベースに相違点を比較します。そして最後に、皆さんがニーズに合った適切なフレームワークを選択する上で役立つ情報として、これらの JAX-RS 実装の分析、評価を行います。

よく使われる頭字語

  • API: Application Programming Interface
  • CSV: Comma-Separated Values
  • HTML: HyperText Markup Language
  • HTTP: HyperText Transfer Protocol
  • JSON: JavaScript Object Notation
  • MIME: Multipurpose Internet Mail Extensions
  • REST: Representational State Transfer
  • RSS: Really Simple Syndication
  • UI: User Interface
  • URI: Uniform Resource Identifier
  • WebDAV: Web-based Distributed Authoring and Versioning
  • XML: Extensible Markup Language

機能の比較

さて、これらの多様な JAX-RS 実装を比較する上で使われる主な要素は何でしょう。この記事では、5 つの重要な要素に焦点を絞ります。もちろん、JAX-RS の実装の比較に使用できる機能要素は他にも数多くあります。しかし以下に挙げる 5 つの要素は、本番品質で REST ベースのサービスを素早く容易に、そして効率的に開発、テストする上で非常に重要なものです。

  • 組み込みのコンテナー。ほとんどの JAX-RS 実装はサーブレット・コンテナーの中にデプロイされます。しかし場合によると、サーブレット・ベースではない単純な Java アプリケーションの中で、組み込み形式で REST ベースのサービスを実行したい場合があります。組み込みのコンテナーを使用できるのはどの実装なのか、確認する必要があります。
  • クライアント API。JAX-RS にはサーバーをバインドするための高度な仕様が定義されていますが、クライアントのバインドと API の定義は実装フレームワークに任されています。従って、JAX-RS 実装を選択する際にはクライアントのアーキテクチャーとフレームワークが重要な要素となります。
  • インターセプター・フレームワーク。REST ベースの Web サービスの開発では、処理前および処理後に非侵入型の方法で HTTP の呼び出しが必要となることがよくあります。これらの呼び出しは、ロギングやキャッシング、セキュリティー検証などのアクションに使われます。HTTP をインターセプトするために、そのフレームワークがどんなメカニズムを用意しているのかを判断する必要があります。
  • データ・フォーマットのサポート。JAX-RS では、MessageBodyReader プロバイダーと MessageBodyWriter プロバイダーを使って任意のデータ型を容易にサポートできるようになっています。そのフレームワークが一般的なフォーマット (Atom、JSON、MIME マルチパート・データなど) のどれを最初からサポートしているのか、判断する必要があります。
  • コンポーネントの統合。REST ベースのサービスの開発では、他のフレームワークと統合できることが重要です。多くの場合、Spring など他のフレームワークを依存性注入に使用し、また他の MVC (Model-View-Controller) フレームワークを使用して UI を処理します。皆さんが選択した JAX-RS 実装フレームワークがネイティブでどんなサードパーティー・コンポーネントと統合できるのか、判断する必要があります。

Project Jersey

Project Jersey は RESTful な Web サービスを作成するための、オープンソースで二重ライセンス、そして本番品質という、Sun® による JAX-RS リファレンス実装です。Project Jersey は単なるリファレンス実装以上のものを意図しており、カスタマイズや拡張が容易な API を提供しています。Jersey は Sun の GlassFish アプリケーション・サーバー・ダウンロードに同梱されています。

組み込みのコンテナー

Jersey は通常、サーブレット・コンテナーの中にデプロイされますが、Java プログラムの中で組み込みモードでも動作することができます。組み込みモードで JAX-RS サービスを実行する方法は容易かつ単純であり、必要なコードは数行のみです。また、この組み込み可能コンテナーをユニット・テストの中でも容易に使用することができます。

クライアント API

Jersey のクライアント API は、Java ベースの洗練された API を上位レベルで提供しており、JAX-RS 準拠のサービスだけではなく任意の RESTful な Web サービスを呼び出すことができます。JAX-RS 開発者にとって、Jersey のクライアント API は使いやすく、使い慣れたものに思えるはずです。Jersey のプロジェクトによれば、Jersey のクライアント API には以下の 3 つの重要な目標があります。

  • REST の統一インターフェースの制約 (Uniform Interface Constraint) をクライアント・サイドにカプセル化する。
  • サーバー・サイドの RESTful な Web サービスと相互運用しやすくする。
  • JAX-RS の API の概念と成果物をクライアント・サイドに活用する。

また Jersey のクライアント API を利用すると、(HttpURLConnection や Apache HTTP クライアントのように) プラガブルな HTTP を実装することができます。全般的には、Jersey のクライアント API を利用することで、REST ベースのクライアント・サイド・ソリューションを効率的に実装することができます。

リスト 1 は Jersey クライアントのコードの一例です。このコードではフォーム・パラメーターを使って POST リクエストを送信することができ、またレスポンスを JAXB オブジェクトとして受信することができます。

リスト 1. Jersey クライアントのコード
Form form = new Form(); 
f.add(“a”, “dim”); 
f.add(“b”, “sum”);
Client client = Client.create(); 
WebResource resource =   client.resource(“http://localhost:8080/formpost”);
JAXBBean bean = resource.
    type(MediaType.APPLICATION_FORM_URLENCODED_TYPE).
    accept(MediaType.APPLICATION_JSON_TYPE).
    post(JAXBBean.class, form);

重要な注意点として、このコードを HttpURLConnection を使って作成したとすると、フォーム変数をシリアライズしたりレスポンスを JAXB bean にデシリアライズしたりするために、はるかに多くの操作が必要になります。

インターセプター・フレームワーク

Jersey にはフィルター・ベースのインターセプター・フレームワークがあり、このフレームワークに下記の 2 種類のフィルターを登録することができます。

  • コンテナー・フィルター: コンテナー・フィルターはリソース・フィルターよりも前にリクエストをフィルタリングします。
  • リソース・フィルター: リソース・フィルターはコンテナー・フィルターよりも前にレスポンスをフィルタリングします。

データ・フォーマットのサポート

他の JAX-RS 実装と同様、Jersey にも一般的なフォーマット (Atom、JSON、MIME マルチパート・データなど) をサポートするための JAX-RS 拡張モジュールが用意されています。Atom をサポートするためには Apache Abdera と jersey-atom-abdera モジュールが必要です。

コンポーネントの統合

Jersey は現在、Spring Framework と Google Guice フレームワークという 2 つの依存性注入フレームワークを拡張機能によってサポートしています。

  • Spring Framework: Jersey で Spring をサポートするためには jersey-spring モジュールの依存関係が必要です。Spring のサポートを有効にするためには、web.xml ファイルの中で SpringServlet クラスを参照します。
  • Google Guice フレームワーク: Guice をサポートするためには、web.xml ファイルの中で、GuiceFilter という Guice フィルターと、Guice 専用の ServletContextListener を参照します。

Apache Wink

この連載の前回までの記事を読んでいれば、Apache Wink に関して既に多くのことを知っているはずですが、まだ読んでいない人達のために、簡単に概要を説明しましょう。

Apache Wink バージョン 1.0 は JAX-RS 1.0 仕様に完全に準拠した実装として、ゼロの状態から作成されています。Apache Wink は使いやすく、本番環境での使用に対応しており、また JAX-RS のコア仕様を強化する一連の機能を提供しています。その一例を以下に挙げます。

組み込みコンテナー

Apache Wink 1.0 はサーブレット・コンテナーの中で実行するように作られたものであり、現在は組み込みモードの動作をサポートしていません。ただし、JAX-RS 仕様に準拠した軽量サーブレット・コンテナーはすべて Apache Wink のランタイムをサポートすることができるはずです。

クライアント API

Apache Wink には高度なクライアント・フレームワークが組み込まれています。Wink クライアント・フレームワークには、HTTP ベースの RESTful な Web サービスを利用するクライアントを、単純かつ容易に実装できる簡単な Java API が用意されています。また Wink クライアント・フレームワークは REST ベースの独立した Java クライアント・フレームワークとしても有用です。

My developerWorks の Apache Wink グループに参加してください

My developerWorks の Apache Wink グループに参加し、Apache Wink を使った RESTful な Web サービスの開発について他の開発者とさまざまなトピックについて議論をし、リソースを共有してください。

まだ My developerWorks のメンバーになっていない方は、今すぐ登録してください!

インターセプター・フレームワーク

Apache Wink ランタイムはハンドラー・チェーンを使ってリクエストを処理します。具体的には、リクエスト、レスポンス、エラー、という 3 種類のハンドラー・チェーンがあります。ハンドラー・チェーンをカスタマイズするためには、アプリケーションの web.xml ファイルの中で、org.apache.wink.server.handlers.HandlersFactory クラスを継承してメソッドを上書きし、新しいハンドラー・ファクトリー・クラスを指定します。

データ・フォーマットのサポート

Apache Wink 1.0 には業界標準の多様なデータ・フォーマットをサポートする一連のプロバイダーが大量に組み込まれています。サポートされるフォーマットには、XML、Atom、Atom Publishing Protocol (APP)、RSS、JSON、CSV、HTML、OpenSearch、マルチパートなどがあります。

コンポーネントの統合

Apache Wink は、コア・フレームワークに含まれた追加モジュールを利用することで Spring と容易に統合できるようになっています。Apache Wink の Spring 統合モジュールには、以下のようにさまざまな機能があります。

  • リソースやプロバイダーをクラスまたは Spring Bean として登録する
  • リソースやプロバイダーのライフサイクルをカスタマイズする
  • IoC (Inversion of Control) など、Spring の機能を使用することができる
  • Spring のコンテキストの中から、フックを使って容易にカスタマイズが可能

また Apache Wink は拡張モジュールによって WebDAV プロトコルをサポートしています。この拡張モジュールを利用することで、WebDAV レスポンスを容易に作成、処理することができます。リスト 2 の例では、WebDAVResponseBuilder クラスを使用して、WebDAVMethod.PROPFIND アノテーションによって WebDAV の HTTP メソッド PROPFIND と関連付けられた JAX-RS リソースを実装しています。

リスト 2. Apache Wink での WebDAVResponseBuilder の例
@Path("books/{bookid}")
public class BookResource {
  @WebDAVMethod.PROPFIND
  @Consumes("application/xml")
  @Produces(application/xml")
  public Response propfindBook(@PathParam("bookid") String booked) {
    SyndFeed feed = ...
    return WebDAVResponseBuilder.propfind(feed);
  }
}

JBoss RESTEasy

JBoss RESTEasy は JAX-RS 準拠のフレームワークを Red Hat® が実装したものです。JBoss RESTEasy は GNU LGPL (GNU Lesser General Public License) の下でライセンスされており、任意のサーブレット・ベース環境で使用することができます。

組み込みコンテナー

JBoss RESTEasy の実装には TJWS という軽量のサーブレット・コンテナーが組み込まれており、このコンテナーをユニット・テストの中で使用すると、JAX-RS Web サービスをリモートで呼び出すことができます。この組み込みコンテナーを使用することで、サーブレット・コンテナー全体を実行せずにユニット・テストを実行することができます。リスト 3 は RESTEasy の組み込みコンテナーの使い方を示しています。

リスト 3. JBoss RESTEasy の組み込みサーバーの例
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import org.jboss.resteasy.plugins.server.tjws.TJWSEmbeddedJaxrsServer;
import org.jboss.resteasy.spi.ResteasyDeployment;
import org.jboss.resteasy.client.ClientRequest;

public class MainResource {
   @Path("restresource")
   public static class MyRestResource {
   @GET
   @Produces("text/plain")
      public String get() {
         return "Hello World";
      }
   }
public static void main(String[] args) throws Exception {
      TJWSEmbeddedJaxrsServer server = new TJWSEmbeddedJaxrsServer();
      server.setPort(8080);
      server.getDeployment()
            .getRegistry().addPerRequestResource(MyRestResource.class);
      try {
         ClientRequest request =
               new ClientRequet("http://localhost:8080/restresource");
         String message = request.getTarget(String.class);
         System.out.println(message);
      } finally {
         server.stop();
      }
   }
}

クライアント API

RESTEasy には、HTTP リクエストを送信できる一方 JAX-RS にも対応した、プログラミング可能なクライアント API が用意されています。クライアントを呼び出すためには、org.jboss.resteasy.client.ClientRequest クラスのインスタンスを作成する必要があります。RESTEasy クライアント・フレームワークは Apache HttpClient 上で実行されますが、java.net.URLConnection を使うこともできます。また RESTEasy には、少し異なる方法で RESTful な Java クライアントを作成できるクライアント・プロキシー・フレームワークが組み込まれています。このクライアント・プロキシー・フレームワークはクライアント・サイドの JAX-RS アノテーションを再利用することで動作し、アノテーションを使用して、メソッドの呼び出しを、その呼び出しと等価な HTTP リクエストに変換します。

インターセプター・フレームワーク

RESTEasy は JAX-RS 呼び出しをインターセプトして再ルーティングする、インターセプターと呼ばれるリスナー・オブジェクトを使用します。どの段階の呼び出しプロセスをインターセプトするかにより、サーバー・サイドには 4 種類のインターセプターがあります (MessageBodyReader インターセプター、MessageBodyWriter インターセプター、プリプロセス・インターセプター、ポストプロセス・インターセプター)。クライアント・サイドにも、さまざまなタイプのインターセプターがあります。

データ・フォーマット

ここまでに説明した他の JAX-RS 実装と同様、RESTEasy は一般的なデータ・フォーマットの大部分をサポートしています (XML、JSON、Atom、XOP (XML-binary Optimized Packaging)、Fastinfoset、マルチパート、など)。RESTEasy も Jersey フレームワークと同じく Apache Abderaプロジェクトをサポートしています。ただし Abdera プロジェクトでは JAXB コンテンツがサポートされていないため、RESTEasy は JAXB アノテーションの付いた単純なオブジェクト・モデルを用意することで Atom もサポートしています。

コンポーネントの統合

RESTEasy は JBoss ベースの実装であるため、RESTEasy に JBoss Seam を密接に統合できることは驚くに当たりません。ただし RESTEasy は、他の一般的なフレームワークや標準 (例えば、(Java EE (Java Platform, Enterprise Edition) 標準としての) EJB (Enterprise JavaBean) 技術や、Spring、Google Guice など) との統合もサポートしています。


Restlet フレームワーク

Restlet フレームワークは、JAX-RS が標準としての最終仕様が固まるはるか以前から存在していたという点で、これまで見てきた他の JAX-RS 実装とは少し異なります。Restlet フレームワークは軽量で REST ベースの Java フレームワークとして作られており、さまざまな機能がプラガブルな拡張機能として提供されています。上位レベルで見ると、Restlet フレームワークは下記の 3 つの部分で構成されています。

  • Restlet API
  • Restlet API を実装した NRE (Noelios Restlet Engine)
  • オプションとしての Restlet 拡張機能

Restlet フレームワークの一部には JAX-RS 仕様を実装した拡張機能があり、ありとあらゆる JAX-RS 機能を提供しています。

組み込みコンテナー

Restlet フレームワークは、これまでほぼ一貫してプロトコルからは独立してきており、そのため多様なデプロイメント構成の下で実行することができます (例えば、スタンドアロンの JAR ファイル、サーブレット・コンテナー、Spring コンテナー、Google Web Toolkit など)。また Restlet フレームワークは Spring の XML 構成メカニズムを利用できる以外にも、独自に XML ベースの構成もサポートしています。

クライアント API

Restlet には、JAX-RS サービス以外にも HTTP ベースの任意のリモート・サービスを容易に利用できるクライアント API が含まれています。Restlet フレームワークはコネクターとコンポーネントによるアーキテクチャーをベースにしており、コネクターが (通常はネットワーク・プロトコルを実装することで) コンポーネント間の通信を行います。必要なプロトコル専用の org.restlet.Client クラスのオブジェクトをインスタンス化することで、リモートの HTTP サービスを呼び出すことができます。

インターセプター・フレームワーク

Restlet フレームワークは高度なルーター・ベースのメカニズムを利用して、アプリケーションの中で行われる URI 呼び出しをルーティングします。ルーターは Restlet つまりリソースであり、ある 1 つの URI と、その URI に対するすべてのリクエストを処理するリソースとを関連付けます。org.restlet.Filter 抽象クラスを継承して既存のルーターに追加することで、複数のルーターへの呼び出しをインターセプトすることができます。フィルターを使うことで、ターゲット Restlet による呼び出しの前処理または後処理の一部を行うことができます。リスト 4 には、ルーターのデフォルトの使用方法の一例を示しています。この例では 2 つのルーターを宣言しています。1 つのルーターは /books という URI を BooksResource というリソースに関連付け、もう 1 つのルーターは /books/bookNameBookResource というリソースに関連付けています。

リスト 4. Restlet のルーターを作成する
// Create a router Restlet that defines routes.
Router router = new Router(getContext());

// Defines a route for the resource "list of Books"
router.attach("/books", BooksResource.class);
// Defines a route for the resource "book"
router.attach("/books/{bookName}", BookResource.class);

データ・フォーマット

Restlet フレームワークはコア・フレームワークに対する拡張機能を使うことで主なデータ・フォーマットをサポートしています (XML、JSON、Atom など)。Atom 用の Restlet 拡張機能には、フィードとパブリケーションの両方のための包括的な Atom API が用意されています。この API によって Atom 文書や APP XML 文書を構文解析したりフォーマット設定したりすることができます。

コンポーネントの統合

Restlet フレームワークには充実した拡張ライブラリーが用意されており、これらのライブラリーを利用することで多種多様なフレームワークや標準を統合することができます (Spring、Jetty、Grizzly、Simple、JAXB、JAX-RS、JiBX、Velocity、FreeMarker など)。


パフォーマンスの比較

何らかの形でパフォーマンスをテストしない限り、ソフトウェア・フレームワークの比較を終えることはできません。ここでは、さまざまな JAX-RS 実装の相対的なスループットを測定するために極めて非公式な形で行ったパフォーマンス・テストの手法について、簡単に説明しておきます。このテストは決して JAX-RS フレームワークに対する正式なベンチマークを意図したものではなく、相対的なパフォーマンス特性に関する一般的な概念を説明するために行ったものにすぎません。

  • パフォーマンスの基準: ここではテスト・メトリックとしてトランザクションのスループット (通常 1 秒当たりのトランザクション数が測定されます) を使用しました。この場合のトランザクションは、ターゲットの JAX-RS フレームワーク上で実行される RESTful なサービスに対する REST ベースの 1 つの GET リクエストです。
  • テスト・フレームワーク: ここでは、Grinder バージョン 3.3 というオープンソースのパフォーマンス・テスト・フレームワークを使用してクライアントのリクエスト負荷をシミュレートしました。
  • サンプリング・メソッド: サンプリング・メソッドによって実際のテスト・メトリックの収集方法を定義します。ここでは cycle メソッドを使用しました。このメソッドによってテストを一定回数のサイクル、実行します。1 サイクルの定義としては、テスト・スクリプトを完全に 1 回実行すること、としています。このパフォーマンス・テストでは 1500 回の固定サイクルを使用しました。これだけ回数が多ければ統計的に有意な結果を得る上で十分です。
  • テスト対象のサービスとシステム: ここでは JAX-RS フレームワークのパフォーマンス特性をテストするために、おなじみの「HelloWorld」サービスと同程度の簡単な JAX-RS テスト・サービスを選び、このサービスをさまざまな JAX-RS フレームワークに移植しました。ここで使用した JAX-RS リソースのソース・コードについては「ダウンロード」セクションを参照してください。すべての JAX-RS フレームワークは、Jrockit バージョン 1.5 の JVM (Java Virtual Machine: Java 仮想マシン) 上で実行される、まだチューニングを行っていない Apache Tomcat サーバー・バージョン 6.0.13 の中で、Web アプリケーションとして実行されました。リスト 5 はテスト対象として使用したサンプルの RESTful サービスを示しています。
    リスト 5. パフォーマンス・テストに使用した JAX-RS サービス
    …….
    
    // The Java class will be hosted at the URI path "/transactions"
    @Path("/transactions")
    public class TransactionResource {
    
     @GET
     @Path("{pnref}")
     @Produces(MediaType.TEXT_HTML)
     public String doInquiry(@PathParam("pnref") String pnref) {
      try {
    	return getMockTxnStatus(pnref).toString();
      } catch (Exception e) {
    	throw new WebApplicationException(Response.Status.INTERNAL_SERVER_ERROR);
      }
     }
    	
     private JSONObject getMockTxnStatus(String pnref) throws JSONException {        
    
      JSONObject jsonObject = new JSONObject();
      jsonObject = jsonObject
       .put("RESULT","127")
       .put("PNREF",pnref)
       .put("RESPMSG","DummyResponse")
       .put("AUTHCODE","ASSDS")
       .put("CVV2MATCH","true")
       .put("AVSADDR","dummyaddress")
       .put("AVSZIP","dummyzip")
       .put("IAVS","IAVS")
       .put("CARDSECURE","cardsecure");
      JSONObject retObject = new JSONObject();
    	
      for(int i=0;i<100;i++) 
     	retObject.put("jsonbj"+i, jsonObject);
    
      return retObject;
    
     }
        
    }
  • テストの実行: ここではすべての JAX-RS 実装フレームワークに対し、このパフォーマンス・テストを別々に実行しました。サンプルの JAX-RS サービスを各 JAX-RS フレームワークに移植し、各フレームワークで 1500 サイクルを繰り返した後に平均スループットと最大スループットを測定しました。図 1 はパフォーマンス・テストの結果を示しています。
    図 1. パフォーマンス・テストの結果
    JAX-RS 実装フレームワークのパフォーマンス・テストの結果を棒グラフで示してあります。X 軸はパフォーマンス・メトリックを表し、Y 軸は 1 秒当たりのトランザクション数 (TPS) を表します。ピーク TPS (Peak TPS) を示す一連のバーは、平均 TPS (Mean TPS) を示す一連のバーよりも高くなっています。
  • パフォーマンス・テストの分析:図 1 を見るとわかるように、Restlet フレームワークを除き、他の JAX-RS 実装はほとんど同じようなスループット・メトリックを示しています。これらのフレームワーク間の差はわずかなもので、例えばピーク TPS が最も高いのは Apache Wink であり、平均 TPS が最も高いのは Project Jersey です。また平均 TPS での相対順位とピーク TPS での相対順位は、ほとんど同じです。このパフォーマンス・テストの結果から、Apache Wink、JBoss RESTEasy、Project Jersey のパフォーマンス特性は似ていますが、それらよりも Restlet フレームワークは少し劣っていると言うことができます。ただしそれは、このテストが JAX-RS フレームワークの正式なベンチマークではないからであり、負荷やテスト条件が変われば結果が異なる可能性があるということに注意する必要があります。

まとめ

この記事では、Project Jersey、Apache Wink、JBoss RESTEasy、Restlet Framework など、複数の JAX-RS 実装の概要を簡単に調べました。この記事では、組み込みコンテナーのサポート、クライアント API フレームワーク、インターセプター・フレームワーク、データ・フォーマットのサポート、コンポーネントの統合のサポート、という 5 つの主な機能要素を使用して、各フレームワークについて説明しました。上で説明したフレームワークはすべて同じ JAX-RS 仕様を実装していますが、これらのフレームワークの設計やアーキテクチャーは非常に異なっています。

また、この記事で説明したすべての JAX-RS フレームワークに対して、サンプルの RESTful サービスとオープンソースのパフォーマンス・テスト・ツールを利用した非公式なパフォーマンス・テストを実行しました。そのパフォーマンス・テストの結果を分析し、さまざまな実装の実行時の特性を比較しました。

皆さんのニーズがどのようなものかによって、上記のフレームワークの 1 つまたは複数が他のものよりも適していることがわかります。例えばコンポーネントの統合が特に重要な場合には、Restlet Framework または RESTEasy が適切な選択肢です。しかし、広範なデータ・フォーマットをサポートした、高スループット特性の高度なインターセプト・フレームワークを持つことを重要視しているのであれば、Apache Wink がニーズに最適かもしれません。市場にある多様なオープンソースの JAX-RS 実装の違いを理解し、皆さんのニーズに最適な実装を見つける上で、この記事が役に立ったようであれば幸いです。


ダウンロード

内容ファイル名サイズ
Article source codeTransactionResource.zip2KB

参考文献

学ぶために

製品や技術を入手するために

  • Apache Wink: Apache Wink をダウンロードして、最新バージョンのソース・コードとバイナリー、そしてその他のサンプル・プロジェクトを入手してください。
  • Apache Tomcat Web Server バージョン 6.x: Tomcat をダウンロードしてください。
  • Grinder: Grinder をダウンロードしてください。
  • 製品評価用 IBM 試用版ソフトウェア: developerWorks から直接ダウンロードできる試用版ソフトウェアで、次のプロジェクトを構築してください。DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® によるアプリケーション開発ツールおよびミドルウェア製品の試用版が揃っています。

議論するために

コメント

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=Web development
ArticleID=487146
ArticleTitle=Apache Wink による RESTful な Web サービス: 第 3 回 Apache Wink と REST
publish-date=04062010