Diffgram
日記でも書いたけれど現在開発中の.NETのGUIフレームワークは接続先をWindowsServerと限定していない、というか仕事の都合上Javaのアプリケーションサーバを主にしている。その中で現在一番悩ましいと思っているのが.NET上で使用するDataSetやDataTableをどのようにして生成するかだ。Webブラウザの替わりとなるクライアントを開発するのが目的だからもちろんRDB等に直接ADO.NETプロバイダ経由で接続するのは駄目、絶対に駄目。相手が.NETをホスティング環境、そうASP.NET等であれば話は簡単。.NETはXMLスキーマから強く型付けされたDataSetを直接返せるのでシリアライザを選択してやり取りすれば良い。
相手がJavaの場合一番実用的、というか各所で紹介されている方法はAxis等のSOAPサーバをJava側で使用してWebServiceを使って必要なデータを貰い.NET側でDataSetを組み立てる方法。この方法はかなり前に実際に試して成功しているんだけど実際のアプリケーション開発を
想像してみると.NET側でDataSetを作り、それに対応したWebサービスをAxis側に作り、Axis上でプロキシクラスを生成してこれをハンドリングするクラスを呼び出し....これをアプリケーション毎にプログラマに書かせるのはちょっとしんどいなぁ。それに要求されているアプリケーションは必ずしもSOAPやRESTを使用したサービス指向でデータを取得する訳ではなくデータベースにSQLでクエリを発行したい要求もある。(だったらC/Sアーキテクチャで実現すれば? という突っ込みをクライアントにいれたいのは我慢する)
そこで現在考えているのはDiffgramをサーバサイドJava側とやりとりする方法。
元々.NETはDataSetやDataTableのシリアライズにはDiffgramというXMLフォーマットを使用できる。
DiffGram
Diffgramは冗長だがDiffgramをサーバサイドJava側で生成する事ができれば.NET側ではDiffgramで書かれたXMLを直接DataSetやDataTableで読込む事ができるし構造にちょっと手を加えれば使用するSQLクエリをDiffgram中にこっそり仕込む事も割に簡単に出来そうだ。そうすれば.NET側はADO.NETの殆どのクラスをそのまま使えるのでADO.NETのスキルのあるプログラマであれば混乱する事は無いだろう。ただ、.NET側ではADO.NETのクラスとのシームレスな連携の為に独自のADO.NETプロバイダを自分で書かなくちゃならない。
Java側はかなりシンプル。受け取ったRESTパラメタかDiffgramに埋めこまれたSQLクエリを使ってJDBC経由でデータベースへアクセスし結果をDiffgramにシリアライズして返せばOK。既に「俺様DAO」が採用されているのでそれを拡張するだけで対応できそうだ。
と考えを書くだけならすらすら行くんだけどクラス設計と実装は大変そうだな。Diffgramの情報があまりにも少なすぎる。特に
