このアプローチは…

OpenDolphin から OpenOcean に改名したので、今までの仕事をまとめておこうと思い、サイトを新調した。
その際に、ネット上で情報収集をおこなったのだが、けっこう興味深かったのが、

ゼミの飛翔』というブログのこの記事

医療情報系の大学研究室のゼミの公開ブログのようなのだけど、題材として OpenDolphin が取り上げられている。将来的には Dolphin と繋がるオリジナルのスマホアプリをつくりたいらしい。それで、データ構造を把握するためにクライアント-サーバ 間で流れる通信パケットを WireShark でキャプチャして解析したという予備研究。

これはこれで SSL 通信の重要性を示すものとしてまあまあ意味はあると思うけど、目的に対するアプローチの仕方としてはどうなんだろう?

 

というのは…

サーバを走らせた場合、キャプチャしなくても通信内容は同様のものが得られる

というのがその理由の一つ。上記記事を再現してみると「嘔吐・下痢の症状が見られる」という所見を SOA 欄に書き込み、サーバに送信。

ドッカーでは無理だが、普通にサーバを走らせていた場合、Java の(というか Java のライブラリの)ロガーは優秀なので、Win だろうが Mac だろうが Ubuntu だろうが、こんなログを吐き出してくれる(今回は Win10)。

所見の平文対応文字列「PD…(略)…4K」は(当たり前だが)まったくいっしょ。

だから、サーバを走らせれば、キャプチャする意味は(ほぼ)ないのだ。

 

また、トライアンドエラーでサーバの応答をある程度まで求め、それにあわせてクライアントをつくったとしても、

LSC がサーバの仕様を変えてしまえば、そのアプリは使えなくなる

のではないかと思う。

 

そして、これは研究全体の方向性に対することだが、

改変不能なドッカー版サーバを使っている限り、クライアントの仕様はサーバに規定され、クライアントの設計の自由度が落ちるのではないか

という疑問が湧く。

最終的にどういうスマホアプリを目指されているか私程度のものが知る由もないが、個人的には、われわれのように実務家的なちまちまとした工夫を重ねるのではなく、大学には、大学の研究らしくもっと自由で大胆な発想をしてほしいと思う。

 

まあ、私のおすすめは、自由にスマホアプリをつくりたければ、サーバ・クライアントともに Java ソース読んだ方がいいでしょう、ということです。

せっかくソースを公開してくれているのだから。

幸いなことに、Dolphin にしても Ocean にしても、スマホ向けのコードは未実装のところが多いですからね(とヒント出してみる)。

 

(追記)…beanbytes の処理に関しては、元町皮膚科の松村先生のブログ記事にわかりやすい解説があったので、追記しておく。

HealthInsuranceModel,StampModel,ModuleModel には beanBytes というフィールドがあり,bean object を xml 変換して,さらにbyte 配列に変換したものが入って永続化されている。今回,REST化で json を使ったため,object が xml に変換されてさらに byte 配列に変換された beanBytes が json 化でさらに Base64 の文字列に変換されて流されるという,何だかたいそう複雑なことになってしまっていた。

 

引用元『beanBytes の処理:Rest(付録)

 

にほんブログ村 病気ブログ 医者・医師へ

クリックclose

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です