ratio - rational - irrational

これだけ。bmはinvoke_web_service_requestの処理時間を計ってるBenchmarkオブジェクトだけど。なんで計ってるんだろ。

* プロトコルの特定と解析

さて、これ以上先に進む前に、さっき流してしまったdiscover_web_service_request(request)を見てみる。このメソッドはaction_web_service/protocol/discovery.rbにある。

(self.class.read_inheritable_attribute("web_service_protocols") || []).each do |protocol|
  protocol = protocol.create(self)
  request = protocol.decode_action_pack_request(action_pack_request)
  return request unless request.nil?
end

ここで、read_inheritable_attributeってなんぞ、と一瞬焦ったけれども、舞波さんが解説してくれた。RoR Wikiにも説明がある。本当に名前そのまんま、継承される属性なのね。

クラス変数はその変数を定義しているクラスだけじゃなく、サブクラスからもアクセス可能。だけれども、クラス階層を通じてオブジェクトを共有しているので、サブクラスでその値をいじってしまうと親クラスにまで影響してしまう。

じゃあサブクラスごとに値を持てばいいんでしょ、と思って「Classオブジェクトのインスタンス変数」を使う手も有る。でも、これの問題はそのままではサブクラスから親クラスの属性にアクセスできないこと。サブクラスのClassオブジェクトと親クラスのClassオブジェクトは当然オブジェクトとしては別だから。

まぁ、この問題に対処する方法はいくつかあるけど、その辺をよしなに処理しておいてくれるのが(read|write)_inheritable_attributeだそうな。あー、完全に忘れてたよ。ありがとう舞波たん。

さて、そういうわけで、"web_service_protocols"属性に対してeachを回す。中に入ってるのはActionWebService::Protocol::AbstractProtocolのサブクラスのClassオブジェクトね。デフォルトではSOAPとXMLRPC。

protocol.create(self) で、上手いことインスタンス化する。それで、protocol.decode_action_pack_request(action_pack_request)で、そのプロトコルのメッセージとしてparseしてみる。それで、うまいことparseできたらその結果を返す。

じゃあ、decode_action_pack_requestはどうなってるの?　SOAPは関連ファイルがいっぱいあって、ややこしそう。なのでXMLRPCのほうを見てみる。

* XMLRPCの解析

action_web_service/protocol/xmlrpc_protocol.rbを見る。ActionWebService::Protocol::XmlRpc::XmlRpcProtocolクラスが定義されてる。

まず、さっきprotocol.create(self)として呼んでたやつの実装がある。

def self.create(controller)
  XmlRpcProtocol.new
end

本当にインスタンス化してるだけ。でも、本当はself.newのほうが望ましいけどナー。

で、decode_action_pack_requestのほうは、というと

def decode_action_pack_request(action_pack_request)
  service_name = action_pack_request.parameters['action']
  decode_request(action_pack_request.raw_post, service_name)
end

raw_postで、生のHTTP Request bodyにアクセスしてる。ふーん。次に行こう。

def decode_request(raw_request, service_name)
  method_name, params = XMLRPC::Marshal.load_call(raw_request)
  Request.new(self, method_name, params, service_name)
end

あー、ここでファイルの最初を見ると

require 'xmlrpc/marshal'

XMLRPCメッセージのMarshalには標準添付ライブラリのやつを使ってるのね。

* API呼び出しの実行

というわけで、requestをparseするところまでは読んだので、上に戻って、parseに成功した正常系の場合にどうやって実行されるのかを見てみる。今、parseして作成したリクエストオブジェクトを変数ws_requestに代入しておいて、

ws_response = invoke_web_service_request(ws_request)
しているのであった。

invoke_web_requrestはaction_web_service/dispatcher/abstract.rbにある。

def invoke_web_service_request(protocol_request)
  invocation = web_service_invocation(protocol_request)
  if invocation.is_a?(Array) && protocol_request.protocol.is_a?(Protocol::XmlRpc::XmlRpcProtocol)
    xmlrpc_multicall_invoke(invocation)
  else
    web_service_invoke(invocation)
  end
end

protocol_requestをここで更にinvocationに変換しなければならない理由がよくわからないんだけど、とにかくinvocationというのはこのファイルの下の方で定義されているActionWebService::Dispatcher::InstanceMethods::Invocationのインスタンスだ。

class Invocation # :nodoc:
  attr_accessor :protocol
  attr_accessor :protocol_options
  attr_accessor :service_name
  attr_accessor :api
  attr_accessor :api_method
  attr_accessor :method_ordered_params
  attr_accessor :method_named_params
  attr_accessor :service
end

ようするに、呼び出しに必要な情報を束ねた構造体のようだ。

• protocol: protocol_requestを構築した段階で既にSOAPかXMLRPCかは分かっている。その情話法を格納しておく。ActionWebService::Protocol::AbstractProtocolのインスタンス
• protocol_options: HTTPヘッダなどの、付加情報
• service_name: SOAPならば"SoapAction" HTTPヘッダフィールドから、XMLRPCならばXML中の対応する属性から取得する。
• api: ActionWebService::APIのインスタンス。DSLで定義されたAPI定義を表すオブジェクト。これはdispatching modeによって取得方法が違って、Direct dispatching modeではcontrollerの定義で宣言してあるから、controllerクラスのinheritable attributeから取り出せば良い。dispatching modeがdelegated, layeredの場合は、実際にAPIを実装しているオブジェクトをcontrollerが知っている訳なので、そのオブジェクトに問い合わせればよい。
• api_methodには、呼び出されるAPI実装を表すActionWebService::API::Methodオブジェクトが入る。これ、セッションのときは組み込みのMethodオブジェクトかと思ったら、よく見たら違うのね。API宣言クラスでapi_method :name, :excepcts => [...], :returns => [...] を呼んだときに内部に構築されるオブジェクトで、メソッドの名前と型情報が入ってる。
• method_ordered_paramsは、api_methodが持ってる型情報に応じて変換された引数の列
• method_named_paramsは仮引数名をキーに、実引数を値に持つHash
• service: このAPIの実装を提供しているオブジェクト。direct dispatching modeではコントローラー自身。delegated, layeredの場合は転送先のオブジェクト

さて、そんな感じで、invoke_web_service_request(protocol_request)メソッドでは、invocationを構築した訳だ。で、次の行はktkr!

  if invocation.is_a?(Array) && protocol_request.protocol.is_a?(Protocol::XmlRpc::XmlRpcProtocol)

こういうコードがあと何ヶ所かあったんだよね。is_a?で分岐してる類のが。そこはAbstractProtocolのpolymorphismでなんとかしてほしい。そうでないとSOAP, XMLRPC以外のプロトコルを足すのが難しくなってくる。もうね、GoFを100回読めと。せめて、respond_to?で分岐して欲しい。

XMLRPCのmulticallだけ特別扱いしてる模様で、よくわからないけど、とりあえず「普通」のほうを見ることにする。「普通」の場合に呼ばれるのは

ActionWebService::Dispatcher::InstanceMethods#web_service_invoke(invocation)

で、ここでもまたdispatching modeによる場合分けをしていて、directならはweb_service_direct_invokeを、delegatedやlayeredならばweb_service_layered_invokeを呼んでる。

def web_service_invoke(invocation)
  case web_service_dispatching_mode
  when :direct
    return_value = web_service_direct_invoke(invocation)
  when :delegated, :layered
    return_value = web_service_delegated_invoke(invocation)
  end
  web_service_create_response(invocation.protocol, invocation.protocol_options, invocation.api, invocation.api_method, return_value)
end

んー。なんかこれも、dispatching modeはinvocationを構築したときの場合分けで既知なわけだし、これこそ「呼び出しの内容」の実装の詳細だから、invocationのpolymorphismで対処してほしいなぁ。

まぁ、それで、web_service_direct_invokeの場合はちょっとした処理が入るけれども、どちらも最終的にはActionWebService::Dispatcher::InstanceMethods#web_service_filtered_invokeに帰着する。これも、例外処理やコールバックの呼び出しを除けば、invocation.serviceにsendしてるだけ。かくて、呼び出しができたのであった。

そして、最後はweb_service_create_responseを呼ぶ訳だ。これも、こまごまと色々してるけれども、容易に想像がつくように、やりたいのはprotocol実装に返り値をmarshalさせることだけ。このあたりは時間がなかったので少々駆け足でとばしてしまった。

* Include

そういえば、最初に見たようにActionWebServiceの機能はModule#includedを通じてコントローラーに提供されてる。じゃあ、そもそも関連モジュールがIncludeされるのはいつなんだろう。method_missingでも捕まえて、webサービス機能関連の宣言をするとincludeされる仕掛けでもあるんだろうか。

トップレベルのディレクトリにあるaction_web_service.rbを見ると書いてあった。

ActionController::Base.class_eval do
  include ActionWebService::Protocol::Discovery
  include ActionWebService::Protocol::Soap
  include ActionWebService::Protocol::XmlRpc
  include ActionWebService::Container::Direct
  include ActionWebService::Container::Delegated
  include ActionWebService::Container::ActionController
  include ActionWebService::Invocation
  include ActionWebService::Dispatcher
  include ActionWebService::Dispatcher::ActionController
  include ActionWebService::Scaffolding
end

ちょww　無差別wwww

* 他のセッション

ソーシャルブックマークを作る

acts_as_authenticatedを使って認証機能を付けたそうだ。

Capistrano 1.2

なんだっけ?　それはそうと、昨日あたりAWDwR 2nd ed.が更新されて、capistranoについて大幅加筆されてたね。あとで読む。

* 懇親会

ここしばらく同じ店で懇親会やってたので、ちょっと飽きが来はじめるころ。そのへんを考えてか、今回はほかの店にしてくれた。

• もろはしさん、ご結婚おめでとうございます。
• のりおさんのデザイナ向けRails本は遅れ気味
• Rails和レシピ本も遅れ気味
• レビューは喜んでお引き受けしますよ
• ABD: Activity系とEvent系の違いがちょっとだけ分かってきたかも?　マクタガートの時間論に言う2つの時制の違いに近いかも。でも、概念としての違いは分かったのかもしれないけど、それを結合しちゃいけない理由は未だに分からない。
• Rubyの多値代入/多値returnの件って、前にMultiValue < Arrayとかいう案が上がってたけど、もう少し汎用的にTupple < Arrayじゃだめかね。Symbol < Stringが許されるならこれもいいんじゃないか?
• 先日私が触ってみた、NTTデータのマスカット、違う意味で大受けだった。
• なんていうかさ、外部の技術者の自発的な協力を得て発展させて、デファクトスタンダードを目指そうっていうなら、少なくとももっとプロジェクト体制をオープンにしないと受け入れられないよね。
• そもそもが、"みかか"という負のブランドイメージを背負ってるんだから、せめてもう少しオープンさのアピールがないと。
• でも「負のブランドイメージって、内部からはなかなか見えないんだよね」と、もろはしさん評。
• まぁ、ひょっとしたら、現場は分かってるに上の頭が固くてあれがギリギリ頑張った結果という可能性もあるけど。NTTデータにもスーパーハカーがいるのは知ってるしね。
• とにかく、頑張れマスカット。