IBM Worklight を使用して構築する IBM Watson 用モバイル・アプリケーションのプロトタイプの作成

IBM チームが IBM Watson の医療用ユーザー・インターフェースをデスクトップからモバイルに拡張した方法

この記事では、一般的なコンテキストであるか IBM Watson でのコンテキストであるかに関わらず、先進的なモバイル・アプリケーションの構築に関心があるアーキテクトと開発者を対象に、IBM Watson および病院のバックエンド・システムとのインターフェースを取る、癌専門医用の高度なモバイル・アプリケーションのプロトタイプの設計と実装について説明します。このプロトタイプを構築した IBM チームのメンバーが、チームが IBM Worklight を Dojo Mobile および Apache Cordova とともに使用して、プロジェクトの技術的課題にどのように対処したかを説明します。

Ton Ngo (ton@us.ibm.com), Cloud Architect, IBM

author photo - ton ngoTon Ngo は、カリフォルニア州サンノゼにある IBM Silicon Valley Lab に勤務する IBM ソリューション・アーキテクト兼シニア開発者です。最近では、ベトナムの Mobifone でエンタープライズ・クラウド・モバイル・パイロット・プロジェクトに取り組みました。以前はシンガポールの南洋理工大学のハイパフォーマンス・コンピューティング・クラウド、カナダのロイヤル銀行のテストおよび開発クラウド、そして Vietnam Telecommunication のサービス・クラウドのアーキテクトを務めました。彼は、IBM T.J. Watson Research Center と Almaden Research Center での計 17 年間の研究者としての経歴を持ち、さまざまなテーマの論文を発表しています。LinkedIn で Ton Ngo とつながってください。



2013年 9月 05日

はじめに

IBM Worklight を入手してください

Worklight は、ネイティブ・モバイル・アプリケーション、HTML5 モバイル・アプリケーション、さらにはハイブリッド・モバイル・アプリケーションを作成およびデプロイするための包括的なプラットフォームです。Worklight フレームワークは、Android、iOS、Blackberry、および Windows Metro プラットフォームのすべてで共通して再利用できるコードを増やすことで、モバイル・アプリケーションのアジャイル開発を促進するとともに、モバイル・アプリケーションのテストと配信を容易にします。さらに、広く普及している Web テクノロジーや Web 標準を利用することにより、開発コストも削減します。

無料の IBM Worklight Developer Edition をダウンロードしてください。

現在 IBM Watson は、癌の研究と治療において癌専門医を支援しています。例えば Watson では、確信度で重み付けした治療法の選択肢を提案することや、治療法の特定、公開、配信にかかる時間を短縮することができます。IBM Watson ソリューション・チームが開発した高度なブラウザー・ベースのアプリケーションは、IBM Watson での照会結果を癌専門医に提供するだけでなく、患者の診察ワークフローも容易なものにしました。このソリューションは IBM HiPODS (High Performance On Demand Global Solutions) エンタープライズ・モバイル・チームによって拡張され、現在はモバイル・サポートを完備するようになっています。このチームは、IBM Worklight をサポート・インフラストラクチャーとして使用して、ブラウザー・ベースのアプリケーションを補完する高度なモバイル・アプリケーションのプロトタイプを作成しました。

IBM Worklight のハイブリッド・アプリケーション開発モデルは、プロトタイプの作成において多くの利点をもたらしました。けれどもそれと同時に、このモデルは、モバイル・アプリケーションのパフォーマンスをネイティブ・アプリケーションと同じレベルにするという私たちの取り組みにいくつかの課題を突きつけました。この記事では、これらの問題を私たちがどのように解決して、極めて応答性の良いモバイル UI を実現したのかを説明します。このモバイル・アプリケーションは Apple iPad および Android タブレットでサポートされており、テンポが速い病院環境のワークフローに適しています。

モバイル・プロトタイプのアーキテクチャー、設計、実装について説明することに加え、この記事ではモバイル・アプリケーション開発者にとって重要な問題についても取り上げます。これらの問題は、医療分野とその関連分野でのモバイル・アプリケーション開発に取り組む開発者にはなおさら重要になってきます。この記事で焦点を当てるのは、IBM Watson の有効性をさらに高めるために、モバイル・テクノロジーによってデスクトップの枠を超えたアクセスを実現する方法です。IBM Watson テクノロジーに関する詳細を調べるには、IBM Watson インフォメーション・センター (「参考文献」を参照) にアクセスしてください。


ソリューション全体のアーキテクチャー

腫瘍学における技術革新の必要性

他の多くの医療分野と同じく、腫瘍学にも技術革新が訪れる時期が来ています。例えば、ほとんどの臨床医は、患者に関するメモを書き留めるという何世代も前からの習慣に今でも従っています。最近のテクノロジーを使用すれば、メモする内容を口述しておき、後からソフトウェアや人間によってテキストに書き起こすことができます。けれどもそうしたとしても、データは構造化されていないテキストのままであるため、データが大規模になってくると、医療研究者は簡単にアクセスすることができません。スタッフ・メンバーや臨床研究看護師がこのようなデータを構造化された形で抽出できるのは、極めてまれなことです (さらに、各患者の診察時間が短いことを考えると、通常は、癌専門医でさえ将来の患者の診察に備えてこれらのメモについて考慮する機会は限られています)。

このモバイル・プロトタイプは、癌専門医の病院環境での日常的なワークフローとかみ合うように作られた総合的なソリューションの一部です。癌専門医のワークフローでは、医師は患者を診る前に、(一般にはナース・ステーションにある) ブラウザーでその患者の電子医療記録 (EMR) を確認します。患者の診察後には、診断結果、処方した治療法、必要となるすべての臨床検査を口述します。その後、口述した内容がテキストに書き起こされ、医師がその書き起こしの内容を正確なものにするために確認するという流れです。このワークフローに適合するように、ブラウザー・ベースのアプリケーションでは、臨床医が患者を診察する前に症状の詳細をデスクトップで確認できるようにします。

一方、モバイル・アプリケーションのプロトタイプはタブレットで実行されます。そのため、医師は患者の診察中に、タブレットを使用してその患者の EMR を参照したり、IBM Watson に照会したりすることができます。一貫性を保つため、モバイル・アプリケーションのビューは、ブラウザー・ベースのアプリケーションでのコンテキストおよびルック・アンド・フィールと同様になっています。ただし、モバイル・アプリケーションの場合、医師はスワイプやピンチなどのジェスチャーでアプリケーションを操作することもできます。さらに、モバイル・アプリケーションはタブレットのオーディオ機能とカメラ機能をサポートしているため、医師は EMR に情報を追加するために、タブレットに直接口述を録音することも、タブレットのカメラで患者の写真を撮ることも可能です。

私たちが担当した病院の場合、完全なソリューションとして思い描かれたのは、カスタマー・コンポーネント、IBM Watson パイプライン、およびプレゼンテーション層が含まれる統合環境です。図 1 に、このソリューションとして見込まれるアーキテクチャーの概要を示します。

図 1. ソリューションのアーキテクチャー概要
ソリューションのアーキテクチャー概要を示す図

図 1 に示したアーキテクチャーを左下から反時計回りで説明します。まず、左下に示されている「Active Directory」、「EMR」(および関連データベース)、「Treatment (治療法)」(および関連データベース) といったコンポーネントは、顧客サイトの既存のサービスを表します。右下の「Watson corpus (Watson コーパス)」と「Watson pipeline (Watson パイプライン)」は、IBM Watson のバックエンド・サービスを構成するコンポーネントです (IBM Watson パイプラインは、実際には複合サブシステムですが、この記事で焦点を当てるわけではないため、単なるブラック・ボックスとして示されています)。「Cases, Attributes (症例、特質)」データベースは、IBM Watson への照会結果を補うために、医師が収集した追加データを保持します。IBM Watson ソリューション・チームによって開発された拡張 REST API は、各アプリケーション (ブラウザー・ベースおよびモバイル) とバックエンドのすべてのサービスとの間のインターフェースとして機能します。Watson パイプラインと Watson コーパスは、Java インターフェースを介して REST サービスと通信します。

図 1 の右上に画像で示されているブラウザー・ベースのアプリケーションは、「WAS (IBM WebSphere Application Server)」に接続して認証を行い、IBM Watson の「REST services (REST サービス)」に接続してデータを照会します。左上に画像で示されているモバイル・アプリケーションは、「Worklight server (IBM Worklight サーバー)」に接続します。この Worklight サーバーがホストするのは、アプリケーションのランタイムと、ディレクトリー・サーバーおよび IBM Watson の REST サービス (どちらもブラウザー・ベースのアプリケーションが使用するのと同じもの) のそれぞれに接続するための各アダプター (「Authenticate Adapter (認証アダプター)」と「REST Adapter (REST アダプター)」) です。モバイル・アプリケーションに取り込まれた音声ファイルと写真ファイルは、Java Content Repository コンポーネントによってバックエンドに格納されます。

認証と許可

ブラウザー・ベースのアプリケーションは、WebSphere Application Server 上にホストされることから、標準の WebSphere ユーザー認証および許可を使用します。ユーザーのログイン時には、このアプリケーション・サーバーが病院のエンタープライズ・ディレクトリー・サービス (IBM Directory Server または Microsoft Active Directory など) を使用して認証を行います。許可については、このアプリケーション・サーバー固有の「Users and Groups (ユーザーおよびグループ)」機能を使用してユーザー・ロールが管理されます (顧客は病院のエンタープライズ・ディレクトリーに新しい属性を追加するという方法よりも、この機能を使用する方法を選びました)。Web アプリケーションは、割り当て済みのユーザー・ロールをチェックして、特定のロールに制約を設けます。REST API も、この同じアプリケーション・サーバー上にホストされます。REST URL は、アプリケーション・サーバーの web.xml ファイル内の URL パターンとロールによってセキュリティーが保持されます。アプリケーション・サーバーは URL リクエストを受信すると、リクエストのユーザーをサーバーのユーザーとロールとのマッピングに照らし合わせて、そのユーザーがリクエストしている URL にアクセスすることが許可されているかどうかを確認します。

タブレット上で実行されるモバイル・アプリケーションは、ディレクトリー・サービスを使用して認証を行ってセッション・トークンを取得するという方法で、ブラウザー・ベースのアプリケーションと同じメカニズムを使用します。ディレクトリー内に当該ユーザーのレコードがない場合、モバイル・アプリケーションは「アクセス権限がありません」というエラー・メッセージを受け取ります。認証が成功した場合には、トークンを受け取ります。このトークンを REST URL で使用して、バックエンド・サービスにアクセスします。

Worklight のアダプター

IBM Worklight のアダプターは、バックエンド・システムに接続するために IBM Worklight サーバー内でホストされるトランスポート層です。このアダプターを使用することで、データベース、REST サービス、その他のコンポーネントから情報を取得したり、これらのコンポーネント上でアクションを実行したりすることができます。使用可能なアダプターには、SQL アダプター、HTTP アダプター、IBM Cast Iron アダプターの 3 種類があります。アダプターを実装するために使用するのは、XML ファイル、JavaScript ファイル、そしてオプションの XSL (Extensible Stylesheet Language) ファイルです。XML ファイルで接続情報と、モバイル・アプリケーションに公開するプロシージャーを定義し、JavaScript ファイルでプロシージャーの実装を定義します。オプションの XSL ファイルには、ロー XML データを処理するための変換スキームが格納されます。アダプターからは、JSON (JavaScript Object Notation) フォーマットのデータが返されます。プロシージャーから返されるレスポンスは、JavaScript コールバック関数によって処理されます。

このプロトタイプでは、HTTP アダプターを使用してバックエンドの REST サービスに接続します。アダプターは REST サービスの実装ごとに 1 つのアダプターを定義します。さらに、アダプター・ヘルパーの JavaScript ファイルも定義します。このファイルは、アダプターのプロシージャーを呼び出し、戻りデータとエラー条件を処理するコールバック関数を定義するファイルです。このヘルパー・ファイルが、アダプターとプロシージャーの間の関係をカプセル化するため、モバイル・アプリケーションのビューをサポートする JavaScript ファイルは、どのアダプターが使用されているのかを認識せずに、ヘルパー・ファイル内の関数を呼び出すことができます。


モバイル・アプリケーションの設計

IBM Worklight を使用して構築されるモバイル・アプリケーションならではのユニークな特徴は、実装に使用されるのが HTM5、JavaScript、CSS (Cascading Style Sheets) と、いずれも Web 開発の標準テクノロジーであることです。したがって、Worklight アプリケーションの設計には、Web アプリケーションの設計と同じベスト・プラクティスを適用することができます。このプロトタイプの設計には、現在の Web デザインのトレンドが反映されています。それは、以前の Web 1.0 モデルや Web 1.0 モデルとは対照的に、シングル・ページ・アプリケーション (SPA) モデルによってユーザー・エクスペリエンスを向上させるというトレンドです。IBM Worklight はハイブリッド・モバイル・アプリケーションで HTML5 をサポートしているため、このプロトタイプの設計に SPA を採用することができました。

Web 1.0 モデルの場合、アプリケーションは Web ページの間をナビゲーションするように意図されます。ユーザーがページ要素 (ハイパーリンクやフォームの送信ボタンなど) を操作したことによって、まったく新しいページへのリクエストがブラウザーからサーバーに対して送信されると、アプリケーションには通常、これまでとは別のビューが表示されます。新しいページのデータがサーバーから取得されると、古いページがアンロードされて、新しいページが画面にレンダリングされます。この場合、ネットワーク遅延が原因で、ユーザーは知覚できるほどの中断をページのロード中に体験する可能性があります。さらに、ページがリロードされるときに、ナビゲーション、ツールバー、画像などといった変更されないページ要素が不必要にネットワーク上に再送信されることになります。この設計は、実装するのは簡単なものの、UI が複雑になればなるほど、ユーザーの操作に対するアプリケーションの反応は鈍くなり、その動きもよりぎこちないものになりがちです。

Ajax (asynchronous JavaScript + XML) で実装される Web 2.0 アプリケーションの場合は、ページ全体を更新することなく、Web ページの個々の要素を変更することができます。この設計では、粒度が細かくなることと、非同期のアクティビティーにより、ユーザー・エクスペリエンスは改善されますが、サーバー・サイドとクライアント・サイドの両方に必要な実装作業が増えることになります。

現在、きわめて有能なブラウザーと強力なハードウェアにより、最新の SPA モデルを実現できるようになっています。SPA モデルの場合、Web アプリケーションの処理 (HTML レンダリング、データ処理、およびビジネス・ロジック) の大部分が、クライアント・サイドのブラウザーに任されます。SPA セッションでは、1 回のページ・ロードでアプリケーションのビューとロジックが取得されます。クライアントがサーバーと通信するのは、認証を行う際、またはデータを同期させるときのみです。以降のサーバー・リクエストの送信時には、リクエストがバックグラウンドで処理されます。ユーザー操作、そしてアプリケーションの状態の変更は、すべて単一の Web 文書のコンテキスト内で処理されます。ネットワーク遅延はそれほど感じられなくなり、ユーザー・エクスペリエンスはネイティブ・アプリケーションでのエクスペリエンスと同じように円滑で快適です。このことは、ユーザーがデスクトップ・ブラウザーを使用していようと、スマートフォンのアプリケーションを使用していようと (しかも、速度が不十分な 3G 接続で使用していようとも) 変わりません。

モデル・ビュー・コントローラー

SPA デザインでは、アプリケーションのビューは 1 回のページ・ロードで取得され、データはその後でリクエストによってサーバーから取得されます。したがって、私たちはデータ層をプレゼンテーション層から切り離すために、モデル・ビュー・コントローラー (MVC) アーキテクチャーを使用しています。MVC は、UI をそのベースとなるデータ・モデルに効率的に関連付けるためのアーキテクチャーです。その名前が示唆するように、MVC デザインは次の 3 つのコンポーネントからなります。

  • 「モデル」は、アプリケーション・データとビジネス・ルールで構成されます。
  • 「コントローラー」は、入力の橋渡しとして、入力をモデルまたはビューに対するコマンドに変換します。
  • 「ビュー」は、データをあらゆる出力表現 (グラフや図など) にすることができます。例えば、同じデータを管理者には円グラフで、経理担当者には表形式で表示するなど、複数のビューで表すことができます。

MVC の背後にある中心的な概念は、コードの再利用性、そして関心の分離です。図 2 に、MVC デザインにおけるコンポーネント間の関係を示します。

図 2. MVC デザイン・パターン
MVC デザイン・パターンでのユーザー、モデル、ビュー、コントローラー間の相互作用を示す図

ビューはデータ・モデルと疎結合であることから、MVC は SPA アーキテクチャーに最適です。MVC を用いれば、データ・モデルのベースにあるロジックを扱うことなく、ビューを作成することができます。図 3 に、私たちがこのモバイル・アプリケーションで MVC デザインを使用して、IBM Worklight サーバーのアダプターを統合した方法を示します。

図 3. モバイル・アプリケーションでの MVC
HTML5 と JavaScript を使用するモバイル・アプリケーションでの MVC デザインの実装を示す図

開発環境

IBM Worklight Studio を使用してハイブリッド・アプリケーションとして開発したこのモバイル・アプリケーションは、HTML5 および JavaScript と併せて、JavaScript フレームワークである Dojo Toolkit を使用します。IBM Worklight では、1 つの開発作業で、アプリケーションのターゲットを複数のモバイル・プラットフォーム (iOS、Android、Microsoft Windows Mobile、Blackberry) へと展開することができます。さらに、HTML5 により、ネイティブ・モバイル・アプリケーションに匹敵するリッチなビジュアル・インターフェースを実現することも可能です。

HTML5 では、GPS、カメラ、オーディオ、連絡先リストといった、モバイル機器にネイティブの機能を利用できないため、IBM Worklight はネイティブ・サポートを追加するために、Apache Cordova を利用します。詳しくは、この記事で後ほど出てくる「ネイティブ・デバイスのサポート」セクションを参照してください。

Dojo Toolkit

SPA と MVC のアーキテクチャーにより、滑らかで応答性の良いハイブリッド・モバイル・アプリケーションを実現することができました。さらにモバイル機器に、タッチ操作やネイティブ・テーマのサポート (およびその他の機能) を追加するために、私たちは以下の Dojo フレームワークを使用しました。

  • Dojo MVC は、クライアント上でのビューとモデルのデータ・バインディングに対して、バックエンド (例えば、ビュー・コントローラー) を提供します。これにより、データを豊富に持つ UI の開発が可能になります。
  • Dojo Touch は、デスクトップ・ブラウザーと、タッチ画面を備えた機器とで同じように動作するように設計された一連のイベント (例えば、ブラウザーでのマウスによるイベント) を提供します。開発者は、マウス・イベントとタッチ・イベントを別々に処理するのではなく、1 つのイベント・セットのコーディングに専念することができます。
  • Dojo Theme は、複数のモバイル・プラットフォームのテーマをサポートします。
  • Dojo Mobile ウィジェットは、ユーザーが使い慣れている機器のネイティブ・デバイスのルック・アンド・フィールに対応する共通スクロール・パネルとリスト・メニューを提供します。

主要なコンポーネント

SPA アーキテクチャーを実装する主要なコンポーネントは以下のとおりです。

  • router.js
    • ビューをプリロードします。
    • ビューのロードをリッスンし、メッセージをアップロードします。
    • ビュー固有の初期化とモジュールの破棄を実行します。
  • domModifier.js
    • ツールバーやメニューなどの共通 DOM (Document Object Model) 要素を処理および更新します。
    • 画面のロードを処理し、ロード後にコールバックを実行します。
  • connector.js
    • REST サービスを呼び出します。
    • データの妥当性を検査します。
    • ビューで使用できるようにデータ・モデルをパッケージ化します。

この設計は一般的な性質のものであるため、他のモバイル・アプリケーションで再利用することができます。

カスタム・ウィジェットのフライイン・パネル

通常のビュー

一般に、臨床医が最初に表示するのは患者のビューです。この初期ビューには、EMR に含まれる患者データの中から、特定の治療法に関係する患者データが抽出されて表示されます。臨床医がボタンをタップすると、治療法として考え得る選択肢や、患者のリスク・モデルが表示されます。するとフライイン・パネルがスライドインして、複数のビューが適宜表示されます。これが、通常のツリー・ナビゲーションとは異なるところです。ツリー・ナビゲーションでは、ユーザーがツリー構造の階層に従ってビューをナビゲーションしなければなりません。

医師が、ブラウザー・ベースのアプリケーションや、モバイル・アプリケーションを使用して、患者データを表示すると、患者の EMR および IBM Watson への照会結果から、助言とエビデンスを含めた大量の情報が取得されて表示されます。ブラウザー・ベースのアプリケーションでは、このような大量のデータを表示するのに大きなモニターを使用することができ、ページのナビゲーションでツリー・ディレクトリー構造を使用することもできます。一方、同じ量の情報をタブレットの小さな画面でナビゲーションするとなると厄介な問題になってきます。多くの場合、ユーザーは複数のパネル間で結果を比較したいと思うはずですが、これらのパネルはそれぞれツリー内の異なるブランチにあるかもしれません。

この問題を解決するために、私たちは複数のビューを同時に開けるカスタム・ウィジェットを設計して、ユーザーがビューを簡単にナビゲーションできるようにしました。この自己完結型のウィジェットは、どの HTML ページでも 1 回の API 呼び出しでレンダリングおよびロードを行い、機器の画面サイズも認識します。また、モバイル機器用に設計されているため、スワイプによるスクロールや、ピンチによるクローズなどのあらゆるジェスチャー制御に対処します。さらに、同時に開かれているすべてのパネルを追跡して、レイアウトとアニメーションを自動的に処理します。

このカスタム・ウィジェットは、大量の情報を表示する必要がある他のアプリケーションでも再利用することができます。

DOM 操作構造

SPA デザインには、Web ページの DOM 要素の操作に影響を及ぼす要因が 2 つあります。1 つは、メイン画面のビューが絶えず入れ替わっているため、新しいビューがメイン画面に表示される際に行われる DOM 要素の更新も、絶えず行われていることです。もう 1 つは、複合エンタープライズ・アプリケーションの開発中には、複数のチーム・メンバーがそれぞれに異なるビューを並行して開発している可能性があることです。これらの理由から、複数の開発者が DOM 要素を操作するには構造化手法が必要になります。この手法により、2 つのビューで同時に 1 つの DOM 要素を更新しようとすることがなくなります。

私たちのプロトタイプでは、DOM 操作にイベント・ベースの構造を使用しました。すべてのビューを追跡する制御コンポーネントとしての役割と、DOM 操作の単一エントリー・ポイントとしての役割を果たすのはコントローラーです。

各ビューは事前に定義された、起動とクリーンアップを行う関数をコントローラーに登録します。コントローラーは、ビューからスワップイン・イベントまたはスワップアウト・イベントが発生すると、そのイベントに応じて起動とクリーンアップを行う関数の起動部分またはクリーンアップの部分を実行します。すべての DOM 操作ルールは、この起動とクリーンアップを行う関数の中で定義されます。この DOM 操作構造により、大規模なチームでのコラボレーションが可能になり、チームでの開発作業が効率化されると同時に、デバッグも容易になります。


ネイティブ・デバイスのサポート

モバイル機器には、一般的なデスクトップ・コンピューターでは使用できない機能がいくつか備わっています。これらの機能を利用してブラウザー・ベースのアプリケーションを補完するために、モバイル・アプリケーションはオーディオとカメラのサポートを追加します。これにより、医師はタブレットのアプリケーションを使用してメッセージを口述し、IBM Watson へ送信することも、タブレットのカメラで治療中の患者の写真を撮ることもできます。最初はこれらの機能を治療法の各選択肢に対して「Rating (評価)」ビューで導入しましたが、適用可能な場合には他のビューで使用することもできます。

Rating (評価)」ビューでは、医師は治療法の妥当性を評価することができます。医師が、治療法として考え得る選択肢の星印アイコンをタップすると、評価を選択してコメントを入力するための「Rating (評価)」ポップアップ・ウィンドウが表示されます。このウィンドウで、医師はコメントを入力したり、マイク・アイコンをタップしてメッセージを録音したり、カメラ・アイコンをタップして写真を撮ったりすることができます。

医師が以前に特定の治療法に関するコメントをテキストで入力した場合、そのコメントが表示されて、編集可能になります。この場合、すでに記録されている口述と写真に対して、それぞれ再生アイコン、表示アイコンがテキスト・コメントの横に表示されます。医師は、これらの音声ファイルや写真ファイルを削除して、取り込み直すことができます。ある特定の治療法に対して、すべてのユーザーからの口述と写真が表示されますが、ユーザーが更新できるのは、そのユーザー自身が記録した口述と写真だけです。

現在のところ、口述および写真は、確認する目的で再生 (口述の場合) または表示 (写真の場合) することしかできません。将来的には、自動音声認識システムや、人間による書き起こしのサービスを使用して音声をテキストに変換し、IBM Watson への入力として使用できるようにすることを検討する可能性があります。そのシナリオでは、音声から書き起こされたテキストが、テキストとしてコメント・セクションに表示されることになります。

オーディオとカメラ

モバイル・アプリケーションでは、ネイティブ・デバイスの機能を利用するため、そしてこれらの機能のサポートをモバイル・プラットフォーム全体で移植可能にするために、Apache Cordova 2.2 を使用しています。これは、IBM Worklight Studio の標準サポートの一部となっており、iOS 機器と Android 機器の間でアプリケーションを移植することを可能にします。

オーディオには、Cordova API メディア・オブジェクトを使用しました。このオブジェクトを使用すれば、さまざまなモバイル機器で音声の録音と、音声ファイルの再生ができるようになります。同様に、さまざまなモバイル・プラットフォーム全体でカメラをサポートできるように、Cordova の camera.getPicture API を使用しました。この API は、タブレットのカメラで写真を撮る場合、またはタブレットの写真アルバムから既存の写真を取得する場合に使用します。画像は、base64 でエンコードされたストリングとして返されるか、画像ファイルの URI として返されます。

コンテンツ・リポジトリー

音声ファイルと写真ファイルは、機器のローカル・ストレージに取り込まれます。これらのファイルを永続的にバックエンドに保管して管理するために、私たちは JCR (Java Content Repository) 仕様に基づくコンテンツ・リポジトリーを使用しました。この手法を使用すれば、アプリケーションを Apache Sling や IBM Web Content Management などの JCR ベースのソフトウェアと連動させることができます。私たちが使用した JCR ベースのソフトウェアは、Apache Jackrabbit 製品が含まれた Apache Sling です。

JCR 仕様は、以下の機能を提供します。

  • 多種多様なデータ・ストレージ (小規模なものと大規模なもの、構造化されているものと構造化されていないもの、バイナリー、メタデータ、リレーションシップ) の抽象化
  • コンテンツ・サービス (アクセス制御、ロック、バージョン管理、トランザクション、観測) の一般化
  • アプリケーションの操作からの実ストレージの分離
  • 標準 API

図 4 に JCR モデルを示します。この図には、以下のものも示されています。

  • ワークスペース
  • ノードの階層
  • ノードに関連付けられたプロパティー
図 4. Java コンテンツ・リポジトリー・モデル
Java コンテンツ・リポジトリー・モデルの図

JCR 仕様に基づく Apache Sling には、以下のものが含まれています。

  • OSGi ― Sling は、OSGi バンドルを使用して作成されており、OSGi コアおよび要約サービスを使用します。
  • Web API ― このコンテンツ・ベースの Web アプリケーション用 API は、Java Servlet API を拡張し、コンテンツを処理するためのさらに多くの機能を提供します。
  • リクエスト処理 ― リクエスト URL はリソースに解決されます。その解決されたリソースのみに基づいて、Sling はリクエストを処理するサーブレットまたはスクリプトを選択します。
  • リソース ― リクエスト URL によってアドレス指定されるリソースを表します。
  • サーブレットとスクリプト ― リソースとして一様に処理されるサーブレットとスクリプトには、リソース・パスによってアクセスすることができます。
  • ランチパッド ― Sling はシン・ランチャーを使用して既存のサーブレット・コンテナーと統合し、Sling を Web アプリケーションとして起動するか、スタンドアロンの Java アプリケーションを表すメイン・クラスを提供します。

モバイル・アプリケーションの統合

図 5 に、音声の録音および写真の撮影をサポートする完全なインフラストラクチャーを示します。

図 5. モバイル・アプリケーションに対するオーディオおよびカメラのサポートの統合
図 5. モバイル・アプリケーションに対するオーディオおよびカメラのサポートの統合を示す図

音声ファイルと画像ファイルは、最初はデバイス・メモリーに保管され、その後でバックエンドの JCR に転送されて永続的に保管されます。モバイル・アプリケーションは、コンテンツとして音声または写真データを含めた HTTP POST を直接 JCR REST サービスに対して開始します。このように、アダプターを介した追加のホップをなくすことで、パフォーマンスを向上させます。JCR にオブジェクトとして保管されたデータには、URL を指定してアクセスすることができます。JCR API には認証が必要なため、モバイル・アプリケーションはブラウザー・ベースのアプリケーションと同じ認証メカニズムを使用します。JCR がリポジトリー内の新規オブジェクトを指す URL を返すと、モバイル・アプリケーションはその URL を既存の IBM DB2 の表に保存するために IBM Worklight アダプターを呼び出します。新規オブジェクトは、ユーザーが後でそのオブジェクトを取得できるようにその特定のユーザーに関連付けられます。

Rating (評価)」ビューが表示される際には、モバイル・アプリケーションが IBM Worklight アダプターを使用して、テキストのコメントと音声および写真の URL を DB2 の表から取得します。テキストはコメント・ボックスに表示され、音声と写真の URL はそれぞれ再生用、プレビュー用のアイコンとして表示されます。ユーザーが再生アイコンまたはプレビュー・アイコンをクリックすると、モバイル・アプリケーションは音声ファイルまたは写真ファイルを取得するために、JCR REST サービスに HTTP GET を送信します。

Cordova は、モバイル機器からファイル・サーバーへのファイルのアップロードも、ファイル・サーバーからモバイル機器へのファイルのダウンロードもサポートします。一例として、音声ファイルと写真ファイルを JCR サーバーにアップロードする Cordova のコード・セグメントをリスト 1 に記載します。

リスト 1. ファイルをアップロードするための Cordova のコード・セグメントのサンプル
// Set options
var options = new FileUploadOptions(); 
options.fileKey = 'audio';  // or 'photo' for photos
options.fileName = filename;
options.mimeType = "audio/vnd.wave";  // or "image/jpeg" for photos
options.chunkedMode = true;
// Set security header
var headers = {Authorization:'Basic YWRtaW46YWRtaW4=');
options.headers = headers;
// Upload photo or audio file
var transfer = new FileTransfer(); 
transfer.upload (localFileURI, serverURI, success, failure, options);

課題と検討事項

医療用のモバイル・アプリケーションを開発する際には、さまざまな課題に直面します。これらの課題にはまだ議論の余地があり、今後の検討事項となっています。

個人の健康情報

医療で使用するケースには個人の健康情報 (PHI) の処理が関わってくる場合があるため、セキュリティーは非常に重要な課題です。モバイル機器は柔軟性をもたらしますが、セキュリティー管理に関して潜在的な複雑さも付加します。焦点となる領域には、以下のものがあります。

  • アプリケーションへのアクセス制御: 通常のユーザー・ログインを使用することができますが、顧客のポリシーおよび政府による規制に応じて、追加のセキュリティー対策が必要になる可能性もあります。その対策は、例えばバックエンドで機器の ID や契約者の ID を検証することなどです。
  • OTA での PHI の送信: 暗号化が必要になることが考えられます (これは、クライアントの標準に適合した暗号化でなければなりません)。
  • モバイル機器のローカル・ストレージでの PHI の保管: ローカルにデータをキャッシュすれば、ユーザーがオフラインでアプリケーションを使用して、機器がオンライン状態になったときにバックエンドを更新することができます。ローカル・ストレージに関するセキュリティー・ポリシーは、顧客が選択する必要があります。IBM Worklight には、機器のストレージ上で暗号化を行う JSON ストアが備わっています。
  • 機器の管理: 場合によっては、企業がパスワード・ルールなどのセキュリティー・ポリシーを施行したり、機器を紛失した場合にアクセスを無効にしたりする必要があるかもしれません。このようなサポートは、IBM Tivoli Endpoint Manager for Mobile が提供しています。

現行のプロトタイプでは、単純なログインを使用してアクセスを制御しています。PHI のセキュリティーに対応した完全なソリューションでは、PHI に関する顧客のポリシーと、PHI に関する政府規制に対処するためのプロシージャーについて考慮する必要があります。

ブラウザー・アプリケーションとモバイル・アプリケーションの一貫性

企業には一般に、長い間使用してきたブラウザー・ベースのアプリケーションがあります。後から導入するモバイル・アプリケーションの UI は、既存のブラウザー・ベースのアプリケーションの UI と一貫していなければなりません。それは、ユーザーが 2 つのタイプのアプリケーションを混乱せずに切り替えられるようにするためです。基本テーマ (カラー・スキーム、グラフィック、レイアウトなど) は、IBM Worklight プロジェクトの該当する CSS で管理することができます。けれども多くの場合、ブラウザー・ベースのアプリケーションとモバイル・アプリケーションが提供する機能は必然的に異なるものです。例えば、ブラウザー・ベースのアプリケーションでは簡単にデータを入力できますが、モバイル・アプリケーションでの入力はそれほど簡単ではありません。一方、結果の表示については、ジェスチャー制御でスクロールやズームを行うモバイル・アプリケーションの方が、より自然な形にすることができます。

再利用可能なアセット

あるプロジェクトのアセットを将来のプロジェクトで再利用できるかどうか、あるいは他のチームと共有するために再利用できるかどうかは、重要な検討事項の 1 つです。この再利用性が特に意味を持ってくる理由は、私たちは実習から学んだ教訓を今後に適用することを目指しているためです。例えば、私たちは以下の教訓を学びました。

  • MVC デザイン・パターン: MVC はブラウザー・ベースのアプリケーションでは一般的ですが、モバイル・アプリケーションにも同じように適用できることがわかりました。MVC によって、複合モバイル・アプリケーションの開発と保守に、より対処しやすくなります。
  • 写真オブジェクトと音声オブジェクトのリポジトリー: これらのバイナリー・オブジェクトをデータベースにではなく、ファイル・ベースの JCR リポジトリーに保管したことで、柔軟性が向上し、管理しやすくなりました。この設計と実装は、他のプロジェクトでもすぐに再利用できるはずです。
  • フライイン・パネル: この新しい設計は、アプリケーション開発を簡素化し、ユーザーが複雑なビュー構造を自然な形でナビゲーションできるようにします。

モバイル・アプリケーションの焦点は、ブラウザー・ベースのアプリケーションに備わっている機能を再現することよりも、特定の使用ケースに置かれがちです。このプロジェクトのアプリケーションでは、私たちはユーザーが必要な機能を簡単に見つけられるように、モバイル・アプリケーションとブラウザー・ベースのアプリケーションでテーマとページ・ナビゲーションが同様となるようにしました。ユーザー・エクスペリエンスを最適化するために、これらのアプリケーションではそれぞれに異なる方法でユーザーが操作できるようになっています。モバイル・アプリケーションでは、ユーザーがスワイプ、ピンチ、プッシュアップ、プッシュダウンの各操作を使用することができます。この手法によって、モバイル機器の最も便利な使い方が促されるように思えますが、ベスト・プラクティスを明らかにするには、さらなる試験が必要です。

オープンソース・コードの使用

最近の傾向から、本番アプリケーションでのオープンソース・コードの採用が増えていることは明らかです。IBM Worklight の Apache Cordova は、オープンソース・ソフトウェアの利用に成功した好例の 1 つです。このプロトタイプ・アプリケーションでは、音声と写真を管理するために Apache Sling も使用しました。最も効果的な場合、オープンソース・コードは、コードの共有という方法によって生産性を向上させます。オープンソース・ソフトウェアが成熟していて、大規模なコミュニティーでサポートされていれば、本番用の安定したプラットフォームになる可能性があります。けれどもそうでなければ、サポートとセキュリティーが問題となる場合もあります。

銀行などの一部の企業では、オープンソース・ソフトウェアの使用を厳しく制限する IT ポリシーを施行している場合があります。さらに、オープンソースの開発者は、概して他のオープンソースのコンポーネントを利用しているため、オープンソース・コードを利用することで予期せぬ依存関係が生まれる可能性があります。ある事例の顧客は、QR コードをスキャンするために Cordova plugin プラグイン (オープンソース・コードとして入手可能) を使用していました。そのモバイル・プロジェクトは、一連の依存関係に必要なライブラリーが不足していることからビルドに失敗し、正しいオープンソース・コンポーネントのすべてを見つけるために、かなりの作業を要する結果となりました。ここで必要となるのは、オープンソースの依存関係の管理とバージョン管理を行う優れたツールです。Eclipse と Linux でのベスト・プラクティスがモデルとなる可能性があります。

Dojo Mobile と jQuery

モバイル・アプリケーションの設計における最初の決定事項の 1 つは、使用する UI フレームワークです。IBM Worklight Studio では、Dojo Mobile を使用した開発と jQuery を使用した開発をどちらもサポートします。IBM Watson 用のブラウザー・ベースのアプリケーションとモバイル・アプリケーションは、どちらも Dojo を使用して構築されています。私たちはこれがベスト・プラクティスであると確信していますが、チームでは jQuery も試してみました。以下の見解は、この 2 つのフレームワークを比較した結果です。

  • MVC: MVC デザイン・パターンの実装に関する組み込みサポートは、Dojo Mobile の方が充実しており、jQuery を使用した場合には Backbone などのフレームワームを追加する必要があります。ただし、見方を変えると、jQuery では開発者が最適なコンポーネントを選択できることから、jQuery のほうがより柔軟であると見なすこともできます。
  • UI の外観とユーザー操作: この分野での Dojo Mobile と jQuery のパフォーマンスは同様です。
  • ソフトウェアの保守: jQuery の多くの機能は、サード・パーティー製のプラグインに依存しています。これらのサード・パーティー・コンポーネントの新しいバージョンが導入されると、コンポーネント間の依存関係が壊れる可能性もあります。Dojo Toolkit は、jQuery に比べ、より包括的なライブラリーをエンタープライズ Web アプリケーションに提供しており、サード・パーティーの依存関係も jQuery より少なくなっています。
  • 開発サポート: jQuery には大規模なコミュニティーがあり、サポートを簡単に見つけることができます。また、jQuery は Web ページや標準的な Web アプリケーションを作成するには最適です。一方、Dojo ウィジェットは、エンタープライズ Web アプリケーションに適応するように作成されています。また、Dojo はアプリケーションにとって、堅固で柔軟なビルディング・ブロックとなることから、機能を簡単に拡張できるようになっています。

まとめ

この記事では、IBM Watson 用の先進的なモバイル・プロトタイプの設計および実装のすべてを紹介しました。私たちは IBM Worklight Studio 開発環境を最大限活用し、Dojo Mobile フレームワーク、Cordova ライブラリー、そしてその他のオープンソース・コンポーネントを利用しました。モバイル・アプリケーションは、医師が患者を診察している間や、オフィスから離れているときでも、IBM Watson ソリューションにアクセスできるようにすることで、ブラウザー・ベースのアプリケーションを補完します。私たちはこのハイブリッド・モバイル・アプリケーションの実装に伴う数々の問題を解決して、ネイティブ・アプリケーションと同じように応答性の良いアプリケーションにしました。モバイル・アプリケーションはまた、モバイル・デバイスのポートを追加して医師に新たなツールを提供し、医師の通常のルーチンにおける生産性を向上させます。これらの再利用可能なアセット、研究成果、そしてこのプロジェクトから学んだ教訓が、他のモバイル・アプリケーション開発チームに役立つことを願います。

謝辞

このプロジェクトに多大な支援を提供してくださった次の方々に感謝の意を表します。

  • Cloud Labs and HiPODS 管理チームの Angel Diaz 氏、Willy Chiu 氏、Larry Hsiung 氏
  • Cloud Labs and HiPODS チームの同僚である Rahul Jain 氏、Chris Kiernan 氏、Chin Huang 氏、Raymond Wong 氏、Ted Hao 氏
  • IBM Watson 管理チームの Rob High 氏、Bill Hume 氏、Jeff Eisner 氏、Jayashree Subrahmonia 氏
  • IBM Watson ソリューション・チームおよびクライアント・チームの Matthew Sanchez 氏、Ed Seabolt 氏、Andrew Ortman 氏、Jon Richter 氏、Michael Holmes 氏

参考文献

学ぶために

  • Getting started with IBM Worklight」: このページに用意されている、自分のペースで学習できるモジュール、演習、サンプル・コードで、iOS、Android、Blackberry、および Windows Phone 機器のアプリケーションをビルド、テスト、デプロイ、管理する方法を学んでください。
  • Dojo Toolkit の API: Dojo Toolkit の API ドキュメントを参照してください。
  • Developing mobile apps as medical devices: Understanding U.S. government regulations」(Erin Gilmer 著、developerWorks、2013年4月): 米国食品医薬品局が発行した、医療用モバイル機器に関するガイドラインの概要を読んで、このガイドラインがモバイル・アプリケーション開発にどのように影響するかを学んでください。
  • developerWorks Mobile development サイトで、包括的な IBM MobileFirst 製品ポートフォリオに揃ったモバイル・アプリケーション開発者向けの最新のツールとテクノロジーを試してみてください。このサイトで、無料のソフトウェア・ダウンロードとクラウドの試用版、サンプル・コード、エキスパートによるハウツー・アドバイス、ビデオ、トレーニング、ディスカッションを詳しく調べてください。
  • IBM Watson インフォメーション・センター: 皆さんの組織が Watson を利用するさまざまな方法を調べてください。
  • IBM Watson Demo: Oncology Diagnosis and Treatment」: このデモのシナリオは、仮説上の癌専門医と患者が、診察から検査、治療法の選択肢、患者の選択、そして事前承認までの過程を進むなかでのやり取りをたどっています。
  • Memorial Sloan-Kettering Cancer Center の事例研究: エビデンスに基づく診断と治療法の推奨案で癌との闘いを支援する IBM Watson の役割について読んでください。
  • Wellpoint, Inc. の事例研究: Wellpoint での医療上の判断における品質と効率性の改善に、IBM Watson がどのように貢献しているかを調べてください。

製品や技術を入手するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Mobile development, Java technology
ArticleID=942794
ArticleTitle=IBM Worklight を使用して構築する IBM Watson 用モバイル・アプリケーションのプロトタイプの作成
publish-date=09052013