碧 - よくある質問 -

フレームワーク全般に関する質問

なぜこのフレームワークを作ったのですか?

複数のRPC形式に対応しているフレームワークはすでに存在したのですが、1つのサービスクラスの実装だけで対応できるものは見当たらなかったからです。

なぜ「碧」という名前なのですか?

次のような理由から名付けました。

会社のコーポレートカラーが緑色だから。
普通の「緑」よりも、「碧」の方が字形がかっこよく、インパクトがあるから。
(「翠」でも良かったのですが、「碧」の方がよりかっこいい気がするから。)
ありふれた洋風な名前よりも純和風な名前の方が、日本人には馴染み深く、外国人には新鮮なイメージを与える気がするから。
ローマ字表記の「midori」という文字が、外国人にも発音しやすい気がするから。
通信方式やプラットフォームを「よりどりみどり」で選べるという意味合いを込めて。

ちなみに、ロゴは「碧」に関連付けられやすい宝石のエメラルドをイメージしています。

ライセンス形態はどうなっていますか?

Apache License 2.0に準拠しています。

障害や要望の問い合わせはどこにすれば良いですか?

下記のメールアドレス宛にお願いします。
midori@fores.jp

Google App Engineで使えますか?

はい、使えます。

publicフィールドは扱えますか?

はい、扱えます。
詳しくはこちらのページを参照して下さい。

ファイルのアップロード・ダウンロード機能はありますか?

残念ながらありません。
midoriはアプリケーションサーバの同一コンテキスト内で他のサーブレットと問題なく共存できますので、アップロード・ダウンロード機能を持つサーブレットを別途作成して下さい。

通信方式・プラグインに関する質問

全ての通信方式のプラグインを設定しておかないと動きませんか?

いいえ、必要な通信方式のプラグインだけを設定しても動きます。
その際、不要な通信方式のプラグインでしか使わないjarファイルは外してもらっても問題ないです。
各プラグインが依存しているライブラリは、こちらのページを参照して下さい。

Javaシリアライズ用のプラグインとはどういう方式ですか?

Javaのjava.io.Serializableの仕組みを使ったmidoriフレームワーク独自規格のバイナリ通信です。
対となるmidoriClientからの使用を想定しています。
このプラグインを使うためには、RPC対象となるメソッドの引数・戻り値ともにjava.io.Serializableインターフェースを実装している必要があります。

XML-RPCプラグインと拡張XML-RPCプラグインの違いは何ですか?

XML-RPCの使用できる型が限られている上にnull値を扱えないという制約を解消すべく作られたのが、拡張XML-RPC(Apache XML-RPC)です。
拡張XML-RPCの方が扱える型が多いというメリットがあるのですが、対応しているクライアントが少ないというデメリットがあります。
サービスクラスのメソッドの引数や戻り値の型や、想定しているクライアントを考慮してどちらのプラグイン(もしくは両方)を使用するか決定して下さい。

JSON-RPCプラグインはJSONPにも対応しているとのことですが、JSONP呼び出しのときのリクエスト・レスポンス形式はどのようになっていますか?

JSON-RPCプラグインでのJSONPは、純粋なJSONPというよりもいわばJSONP方式を介したJSON-RPC(JSON-RPC over JSONP?)というべきものになっています。
リクエストパラメーターに「callback」という名前のデータが設定されている場合、JSONPモードとして動作します。
リクエスト形式は、JSON-RPCに必要なデータ(method, params, id)を、「data」という名前のリクエストパラメーターにJSON形式の文字列にひとまとめにしたものを想定しています。
レスポンス形式は、JSON-RPCと全く同じです。

AMFプラグインを使うときに、クライアント側でgatewayUrl、destinationはどのように指定すれば良いですか?

midoriフレームワークは基本的にURLのパスを元にして呼び出し先のサービスクラスを決定しますが、AMFの場合は少し特殊でリクエストデータに含まれるdestinationの内容に応じて呼び出し先のサービスクラスを決定します。
そのため、gatewayUrlに指定するURLにはサービス名を指定する必要はなく、通信方式がAMFであることを示す「.amf」さえ末尾についていれば何でも良いです。
具体的な例としては、次のようになります。

(例) localhost:8080上のmidoriTutorialの「calcService」を呼び出したい場合
gatewayUrl = http://localhost:8080/midoriTutorial/rpc/xxx.amf (← xxx.amfのxxxの部分は何でも良い)
destination = calcService

Thriftプラグインを使うときに、Thriftのコマンドで自動生成されるソースも必要ですか?

はい、必要です。
サービスクラスを作成する際に、Thriftのコマンドで自動生成されたソースの「Iface」インターフェースを実装することにより、初めてThriftプラグインからの呼び出しが可能になります。
(つまり、ThriftでいうところのHandlerクラスがmidoriのサービスクラスにあたります。)
そのため、サービスクラスにThrift用のインターフェースを実装していない場合は、たとえThriftプラグインが使用可能な場合でも、残念ながらThrift形式のRPC呼び出しは失敗してしまいます。

そのため、Thriftプラグインの使いどころとしては、「他の通信方式に加えてThriftも使えるようにする」といったものではなく、「Thrift用のサーバーなのに他の通信方式でも呼び出せるようにする」と考えて下さい。

Thriftプラグインを使うときに、TServletを継承したクラスを自作する必要がありますか?

いいえ、必要ありません。
midoriフレームワークを使う場合は、全てのRPC呼び出しのリクエストをRPCServletで受け取って適切なプラグイン・サービスクラスに処理を割り振る仕組みになっているので、TServletクラスを継承したクラスを自作する必要はありません。