投稿者: phazor

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 限定とか、臨床に従事している医師の感覚ではちょっとあり得ない感じです。

（追記３）私の周囲のユーザーさんは「医療画像を情報損失のある JPEG で保存するのは論外だし、その上にのっている機能も不要」という声が多数を占めているので、DolphORCA では、ここら辺は修正予定。

（追記４）いわゆる java17 問題で、画像周りの問題はさらに顕在化。
OpenDolphin では、swing GUI コンポーネント上に強引に表示させた画像を hibernate で永続化する、という手法をとっています。
が、これは今となってはかなり無理のある構成なので、公開されている opendolphin のソースコードを少々手直しした程度では、（今のところ）サーバープログラムはアプリケーションサーバにデプロイできません。

ライブラリなどの開発元が古い swing コンポーネントの対応をしてくれれば解決はするんですが、現状では実現されていません。

自力運用している施設では java のアップデートに合わせて松村哲理氏、増田茂氏がクライアントアプリに付加した機能を取り外す方向で検討しているところが多いようです。

 

オープンソース（Open Source Software : しばしば OSS などと略される）の電子カルテ OpenOcean/OpenDolphin は、ビルド・デプロイするだけでも出てくる役者が多いので、整理しておきましょう。

 

Java…Win, Mac, Unix などに仮想的なマシンを設定し、それを動かすための言語。したがって、Java で開発されたソフトは Win/Mac/Unix で動く（はずですが、実際には windows と Mac OSX ではメニューの表示構成などが OS レベルで違うため、この部分は機種依存になります）。JRE は実行環境、SDK は開発用のキットです。ビルドには SDK が必要。

 

Java EE…Java Enterprise Edition の略。通常の Java をクライアント-サーバシステムを開発できるように拡張したもの、というような理解でいいと思います。機能が多彩すぎて私は全貌がまったくつかめてません。Oracle との絡みで先行きは不安のようです。

 

PostgreSQL…データベースソフト。いろんなところでお世話になってます。

 

NetBeans…Java でよく使われるIDE（統合開発環境）。Java 版 VisualStudio といった方がわかりやすいか。Java の IDE は、eclipse が有名ですが、ドルフィンプロジェクトではこちらを使っていたため、私もこちらの方に慣れちゃいました。ただ先行きは不安しかない。

 

Maven…「メイヴェン」と読むのが正しいようです。「マーベン」でも通じると思うけど（内輪だけ？）。Java 用プロジェクト管理ツール、と紹介されることが多い。実用的なソフトを構築する場合、自力で書いたソースの他にライブラリが必要になってくる。OpenDolphin/OpenOcean の pom.xml に

<dependency>
 <groupId>postgresql</groupId>
 <artifactId>postgresql</artifactId>
 <version>8.4-702.jdbc4</version>
</dependency>

などと書かれてあるのは、その指定のためです（この場合は、「postgresql を使いたいので jdbc ドライバをリポジトリから取ってきてね」という意味です。ver が 8.4 と最新ではないのは古い ORCA の postgres に対応するためだと思われます）。他にもビルドの際の細かいルールを指定できる。

 

WildFly…Java EE に準拠したアプリケーションサーバ。Java EE は仕様しか決められていないため、Java で書かれた Web アプリ実運用のためにはサーバ実体が必要。このサーバ実体の一つがWildFly（他には GlassFish や TomEE などがある）。 Redhat が開発し配布している。これの商用版が JBoss。Java EE 同様、機能が多彩すぎて、全体がつかみにくい。実稼働時には（アプリ名）.war をWildFly 内に配置（デプロイ）する。

 

まずは、こんなところでしょうか。

OpenOcean / HorliX 開発チーム