【Reflex】 ヘテロ環境のインターオペラビリティを考える

　今回の話は、「新規のアプリケーションを作りたいが、ヘテロ環境の基幹システムとどのように連携させればよいか」を整理したもの。あるお客様向けに説明したメモを元にしている。

＜課題＞

　現在様々なプラットフォームの基幹システムが動いており、Microsoft系、Java系、Linux（LL)系のアプリケーションが存在する。これらヘテロな環境のデータを利用する１つのアプリケーションを作成するには、どのようにすればよいか。

＜案＞

１．どれか一つのプラットフォーム（言語）に統一すべく作り替える
　　　＝＞現実的ではないので不採用。

２．新規にアダプターを作成してWebサービス（SOAP）で接続する

　トップダウン的なアプローチであり、大きな政府として振る舞うプロジェクト体制が必要となる。つまり、全体で管理するドメインを定義し、そのスキーマに合わせる形になるように、既存のアプリケーションのデータをアダプターが変換する。そのアダプタを含めてプロジェクトが一元管理しなければならない。これはESB的な発想である。

３．既存の仕組みにRESTfulなI/Fを用意してもらう
　
　ボトムアップ的なアプローチであり小さな政府である。各アプリケーションがスキーマを定義し、RESTでデータを公開する。APIはCRUDのみ。オンラインではREST、バッチではSVNでデータ交換する。課題は各々で作成された互換性のない語彙（シノニム）の扱いをどうするか、またキー項目の定義をどうするか。その解決の役目をマッシュアップサーバが担う。

私は管理面で優れている３．の案がよいのではないかと考えている。

　あらかじめ各アプリに最低限のCRUD APIを実装しておくことができれば、マッシュアップサーバを構築する際に影響を与えずに済む。アプリ開発者はマッシュアップされていることを気にしなくてよいことが最大の利点である。また、２．ではアプリケーションすべてにアダプターを用意する必要があるが、マッシュアップサーバは必要に応じて立てればよい。

　ただし、マッシュアップサーバを立てる者は、アプリのエンドポイントURIを管理する必要がある。同時にアプリがどのような語彙をもっているのかを把握しておかなければならない。単に集めただけで語彙がアンマッチ状態なのかもしれないが、とりあえずこれをURIごとに管理する。まとめたものをシステムのドメインとすればよい。

＜小さな政府案で管理すべき項目＞

１．URI
２．API（CRUD)
３．語彙の集合（ドメイン）

　マッシュアップサーバの主な仕事は、アプリへの接続と語彙の変換である。語彙の変換はI/Oを持たないBlogic(Service)関数で行う。変換後の語彙は、新規のアプリケーションで定義したエンティティと一致するものである。
　
＜マッシュアップサーバで行うこと＞

１．各アプリへの接続
２．語彙の変換(Blogic)

　最後に、このケースが以前紹介したReflexの設計モデルに似ていることを付け加えたい。新規アプリがView(Boundary)、マッシュアップサーバがMashup(Control)、既存アプリがResource(Entity)に位置する。今回のケースでは既存アプリの語彙は決まっているため変換をマッシュアップサーバで行う点だけが異なる。




＜関連＞

　【Groovyコンファレンスデモ】 ZEROからRESTfulアプリを作成
【Groovyコンファレンスデモ】 リソースの実装
【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト
【Reflex】 再発見。実はドメインモデルかもしれないReflex