OpenDolphin から OpenOcean に改名したので、今までの仕事をまとめておこうと思い、サイトを新調した。
『ゼミの飛翔 』というブログのこの記事 。
医療情報系の大学研究室のゼミの公開ブログのようなのだけど、題材として OpenDolphin が取り上げられている。将来的には Dolphin と繋がるオリジナルのスマホアプリをつくりたいらしい。それで、データ構造を把握するためにクライアント-サーバ 間で流れる通信パケットを WireShark でキャプチャして解析したという予備研究。
これはこれで SSL 通信の重要性を示すものとしてまあまあ意味はあると思うけど、目的に対するアプローチの仕方としてはどうなんだろう？
というのは…
・サーバを走らせた場合、キャプチャしなくても通信内容は同様のものが得られる
というのがその理由の一つ。上記記事を再現してみると「嘔吐・下痢の症状が見られる」という所見を SOA 欄に書き込み、サーバに送信。
ドッカーでは無理だが、普通にサーバを走らせていた場合、Java の（というか Java のライブラリの）ロガーは優秀なので、Win だろうが Mac だろうが Ubuntu だろうが、こんなログを吐き出してくれる（今回は Win10）。
所見の平文対応文字列「PD…（略）…4K」は（当たり前だが）まったくいっしょ。
だから、サーバを走らせれば、キャプチャする意味は（ほぼ）ないのだ。
他にも別の unix 系のコマンドを使えば、通信内容の取得は可能です。
また、トライアンドエラーでサーバの応答をある程度まで求め、それにあわせてクライアントをつくったとしても、
・LSC がサーバの仕様を変えてしまえば、そのアプリは使えなくなる
のではないかと思う。
そして、これは研究全体の方向性に対することだが、
・改変不能なドッカー版サーバを使っている限り、クライアントの仕様はサーバに規定され、クライアントの設計の自由度が落ちるのではないか
という疑問が湧く。
最終的にどういうスマホアプリを目指されているか私程度のものが知る由もないが、個人的には、われわれのように実務家的なちまちまとした工夫を重ねるのではなく、大学には、大学の研究らしくもっと自由で大胆な発想をしてほしいと思う。
まあ、私のおすすめは、自由にスマホアプリをつくりたければ、サーバ・クライアントともに Java ソース読んだ方がいいでしょう、ということです。
せっかくソースを公開してくれているのだから。
OpenDolphin で実現されている REST API の仕組みなどはこの分野の基本といってよく、勉強しておいて損のないところだと思います。
（追記）…beanbytes の処理に関しては、元町皮膚科の松村先生のブログ記事にわかりやすい解説があったので、追記しておく。
HealthInsuranceModel，StampModel，ModuleModel には beanBytes というフィールドがあり，bean object を xml 変換して，さらにbyte 配列に変換したものが入って永続化されている。今回，REST化で json を使ったため，object が xml に変換されてさらに byte 配列に変換された beanBytes が json 化でさらに Base64 の文字列に変換されて流されるという，何だかたいそう複雑なことになってしまっていた。
引用元『beanBytes の処理：Rest（付録） 』
（追記２）なお、現在の開発元のメドレーによれば、松村哲理氏は contirbutor として認められていないので、念の為。
いわゆる「契約」問題の話はおいておいても・・・
beanBytes の説明自体は間違ってはいない（ただし、基本設計を考えるとこの通信形式はそんなにおかしくもない）。が、dolphin が画像を保存する際、jpeg に限定されてしまうのだが、ここらへんの不自然さに対する説明は一切なし。
シェーマエディタは、佐藤純三氏のコード の上に後付けで実装されたものなので、この機能を外してしまうと（外しても動作するし、外したバージョンの方が好評。たぶん、一部の診療科以外、この機能は不要なんでしょう）、彼の貢献はほぼなくなってしまう。
・・・といった理由からでしょうか。
そもそも、わざわざ実装した画像エディタの保存形式が（lossless でない） JPEG 限定とか、臨床に従事している医師の感覚ではちょっとあり得ない感じです。
実際、
・公式資料 から、「オープンソース化した時点で、（松村哲理が開発したとされている）シェーマエディタの原型は既に実装されていた」こと
少なくとも 2004 年時点ではスキーマエディタの原型は実装されており、その後にしか関われないはずの医師（松村哲理）が基本設計レベルの開発に関与できるわけがない、公式のアナウンスが資料と矛盾している、などの指摘がなされている。 ・LSC リポジトリに松村哲理のソースコード提供の痕跡はまったく残されていないこと
がわかっており、事後的に（特にメドレー移管以降は）プロジェクトへの貢献の程度を判定するのが難しくなっているという事情があるためでしょう。
あと、増田茂とつるんでこういうツィートするような人なので基本的に信用していません。
（追記３）私の周囲のユーザーさんは「医療画像を情報損失のある JPEG で保存するのは論外だし、その上にのっている機能も不要」という声が多数を占めているので、DolphORCA では、ここら辺は修正予定。
（追記４）いわゆる java17 問題で、画像周りの問題はさらに顕在化。
ライブラリなどの開発元が古い swing コンポーネントの対応をしてくれれば解決はするんですが、現状では実現されていません。
自力運用している施設では java のアップデートに合わせて松村哲理氏、増田茂氏がクライアントアプリに付加した機能を取り外す方向で検討しているところが多いようです。
OpenDolphin-2.7m のリポジトリ見ればわかるけど、コーダーとしてはかなりアヤしい人でもそっくりそのままクレジットしてますけどね。