Extension部分のコーディング

ダイナミック言語が作るレイヤ

   話をMacのIOKitフレームワークの例に戻すと、ノートPCの電源やバッテリ情報にアクセスするCの関数を闇雲に公開するのではなく、必要とな る様々なデータ型をサポートするためだけに、それらをラップするC関数を書くことにしました。この機能だけRuby下のレイヤで実現することで、不必要な 細かいことをRubyコード外に置くことができるのです。

   このRuby/C++ミドルウェア統合では、Rubyで書かれたモジュールをRubyのアプリケーションが利用する多重のレイヤ構造を採用しまし た。このモジュールは、順次Cで書いたモジュールをラッピングし、ミドルウェアシステムに直接アクセスしています。このレイヤ構造のアプローチは、いくつ かの利点があります。

   例えばアプリケーションレイヤはRubyとCの境界ではなく、RubyとRubyの間にあります。これによって、多くをRubyで実装することによってアプリケーションインターフェースの開発を単純化でき、C言語のみの場合よりも容易に開発が行えます。

   またRubyモジュールがRubyとCの境界を包含することで、アプリケーションの直接のアクセスから隠蔽することもできます。アプリケーションイ ンターフェースや既存のアプリケーションに影響を与えることなしに、境界を跨いで機能の配置を変えることができます。

   これによりRubyからCへの境界が隠蔽されるので、Cのコードだけでインピーダンスミスマッチの問題を解決する必要はなくなります。インピーダン スミスマッチの一部をCのレイヤで解決し、一部をRubyモジュールで解消します。必要があれば、Rubyアプリケーションに影響を与えないようなCのレ イヤを作るためにRubyモジュールには、慣用的なプログラミング方法をしないようなコードを作成します。

   このようにSOAの開発において、SOAネットワーク上のアプリケーションが利用できる特定のサービス機能の開発要件は、設計のプロセスと正確に一 致する必要があることが必須です。あるテクノロジーの上でオブジェクトを直接公開するようにサービスを作る方法は、実装のための多くの細かい情報がサービ ス利用者に見えたり影響を与えてしまうために、一般的に良い方法とはいえません。

   SOA開発担当者がサービス設計に注力すべきことは明らかであり、そのためにもエンキャプスレーション（包含関係）をはじめとして、テクノロジー同士の境界線やカップリング（組み合わせ）、結合の方法についての課題を検討する必要があるのです。

   これまで説明してきたように、ミドルウェア統合のためにRubyを拡張することは比較的簡単に行えます。もしかしたら最初は大変だと感じるかもしれ ませんが、書籍やオンラインドキュメント、サンプルコード、「comp.lang.list」のようなRubyコミュニティ、そしてUsenetグループ とRubyのソースコードそのものなどを利用することで、開発のスピードを上げることは容易でしょう。

   Rubyを利用することにより生産性が向上し、結果的に統合プロジェクトを実施する価値も高いものとなるのです。