Создание прототипов мобильных приложений с помощью IBM Worklight для IBM Watson

Как команда IBM распространила интерфейс IBM Watson для работников здравоохранения с настольных ПК на мобильные телефоны

Эта статья предназначена для архитекторов и разработчиков, заинтересованных в создании расширенных мобильных приложений – как в целом, так и в контексте работы с IBM Watson. В статье описано проектирование и реализация сложного прототипа мобильного приложения для онкологов, которое взаимодействует с IBM Watson и информационными системами лечебного учреждения. Участник команды IBM, построившей этот прототип, рассказывает, как команда решила технические проблемы, возникшие в ходе проекта, при помощи IBM Worklight, Dojo Mobile и Apache Cordova.

Тонь Нго, архитектор облачных решений, IBM China

Фото автораТонь Нго (Ton Ngo) ― архитектор облачных решений и ведущий разработчик IBM Silicon Valley Lab в Сан-Хосе, штат Калифорния, США. До недавнего времени был архитектором "Высокопроизводительного вычислительного облака" в Наньянском технологическом университете в Сингапуре и занимался тестированием и разработкой облачной системы для канадского Royal Bank. До этого 17 лет работал научным сотрудником в IBM T.J. Watson Research Center и Almaden Research Center и имеет публикации по широкому кругу вопросов.



03.11.2013

Введение

Получите IBM Worklight

Worklight— всеобъемлющая платформа для создания и развертывания нативных, HTML5- и гибридных мобильных приложений. Среда Worklight обеспечивает гибкую разработку, тестирование и поставку мобильных приложений с высоким коэффициентом повторного использования кода на платформах Android, iOS, Blackberry и Windows Metro. Кроме того, за счет применения широко распространенных Web-технологий и стандартов снижается стоимость разработки.

Скачайте IBM Worklight Developer Edition бесплатно.

IBM Watson помогает онкологам в исследовании и лечении раковых опухолей. Например, Watson может предложить варианты лечения с указанием доверительных уровней и ускорить разработку, публикацию и распространение методов лечения. Команда разработчиков решения на базе IBM Watson создала хорошо продуманное браузерное приложение, которое не только представляет онкологам результаты обработки запросов в IBM Watson, но и упрощает консультативную работу с пациентами. В настоящее время группа IBM High Performance On Demand Global Solutions (HiPODS) Enterprise Mobile дополнила это решение полной поддержкой мобильных устройств. С помощью инфраструктуры IBM® Worklight® команда создала прототип мобильного приложения, которое дополняет существующее браузерное приложение.

Модель разработки гибридных приложений в IBM Worklight дала нам множество преимуществ при создании прототипов. Однако при этом возникли определенные проблемы с достижением той же производительности, что и у исходного приложения. В статье описано, как мы решили эти проблемы и создали быстрый интерфейс пользователя для мобильных устройств. Наше мобильное приложение поддерживается планшетами Apple iPad и Android и полностью соответствует требованиям быстрых рабочих процессов, свойственных лечебным учреждениям.

Кроме описания архитектуры, проектирования и реализации мобильного прототипа, в статье описаны основные проблемы, с которыми сталкиваются разработчики мобильных приложений, в особенности предназначенных для применения в области медицины. Внимание акцентируется на том, как мобильные технологии могут повысить эффективность IBM Watson, обеспечив доступ без использования настольного ПК. Подробное описание технологии IBM Watson можно найти в информационном центре IBM Watson (см. раздел Ресурсы).


Архитектура полного решения

Необходимость технических инноваций в онкологии

Онкология, как и многие другие отрасли здравоохранения, «созрела» для технических инноваций. Например, большинство клиницистов до сих пор пользуются совершенно устаревшим методом ручного ведения записей о своих пациентах. Появившиеся недавно технологии позволяют диктовать записи, а затем расшифровывать их вручную или программным способом. Но даже после этого данные остаются в виде неструктурированного текста, что затрудняет полномасштабный доступ к этим данным. Лишь недавно научные сотрудники и младший исследовательский персонал получили возможность получения этих данных в структурированной форме. (И зачастую, учитывая ограниченное время, отводящееся на каждого пациента, онколог не может при следующих визитах пациента даже принять во внимание эти данные).

Мобильный прототип является частью общего решения, которое тесно переплетается с повседневной работой онколога в условиях стационара. Во время этой работы врач просматривает электронные медицинские карты (EMR) пациента в браузере — обычно в комнате медицинских сестер — и только потом приступает к осмотру пациента. После осмотра пациента врач диктует диагноз и назначает лечение и необходимые лабораторные анализы. Затем надиктованная информация преобразуется в текст, и врач проверяет результат. В соответствии с требованиями этого рабочего процесса браузерное приложение позволяет клиницисту просматривать историю болезни за столом перед осмотром пациента.

Прототип мобильного приложения работает на планшете, поэтому врач может просматривать электронную карту пациента и направлять запросы в IBM Watson непосредственно в процессе осмотра. Для единообразия экраны просмотра мобильного приложения аналогичны экранам браузерного приложения по содержанию, внешнему виду и поведению.

В отличие от браузерного приложения, мобильным приложением можно управлять жестами, например, проводя или нажимая пальцем на экран. Кроме того, мобильное приложение поддерживает звуковые функции планшета и встроенную камеру. Врач может добавить информацию в медицинскую карту, надиктовав ее с помощью планшета, или использовать камеру планшета для фотографирования пациента.

В тех больницах, с которыми мы работали, полное решение представлялось в виде интегрированной среды, включающей клиентские компоненты, конвейер IBM Watson и уровень представления. Высокоуровневая архитектура потенциального решения показана на рисунке 1:

Рисунок 1. Высокоуровневая архитектура решения
Diagram of a high-level solution architecture

Давайте рассмотрим архитектуру, показанную на рисунке 1, начиная с левого нижнего угла и двигаясь против часовой стрелки. В левом нижнем углу расположены компоненты Active Directory, EMR (с соответствующей базой данных) и Лечение (с соответствующей базой данных), которые представляют существующие в медицинском учреждении службы. В правом нижнем углу расположены корпус информации и конвейер Watson, которые представляют серверные службы IBM Watson. (Конвейер IBM Watson — на самом деле сложная подсистема, представленная здесь простым «черным ящиком», поскольку ее рассмотрение выходит за рамки этой статьи.) База данных пациентов и атрибутов содержит дополнительные данные, которые собираются врачами в дополнение к результатам IBM Watson. Разработанный командой IBM Watson Solutions обширный REST API-интерфейс выступает в роли связующего звена между приложениями (браузерным и мобильным) и всеми серверными службами. Конвейер и корпус информации Watson взаимодействуют со службами REST через интерфейс на базе Java™.

В правом верхнем углурисунка 1 показано подключение браузерного приложения к серверу приложений IBM® WebSphere® для аутентификации и к службам IBM Watson REST для запроса данных. Мобильное приложение, показанное в левом верхнему углу, подключается к серверу IBM Worklight. Сервер Worklight включает в себя среду исполнения приложений и адаптеры для подключения к тому же серверу директорий и тем же службам IBM Watson REST, которые использует браузерное приложение. Записанные мобильным приложением файлы звука и изображений сохраняются на сервере в хранилище контента Java.

Аутентификация и авторизация

Поскольку браузерное приложение размещено на сервере приложений WebSphere, для него используется стандартная аутентификация и авторизация пользователей WebSphere. Когда пользователь входит в систему, сервер приложений аутентифицирует его с помощью службы каталогов больницы (например, IBM Directory Server или Microsoft Active Directory). Для авторизации сервер управляет ролями пользователя через свою собственную функцию пользователей и групп (что предпочтительней по сравнению с добавлением новых атрибутов в каталог предприятия). Web-приложение проверяет присвоенные пользователям роли и накладывает ограничения на определенные роли. REST API размещается на том же сервере приложений. REST URL защищены шаблоном и ролью URL в файле сервера web.xml. Когда сервер получает URL-запрос, он сопоставляет пользователя, указанного в запросе, с распределением ролей пользователей на сервере и подтверждает, что пользователь имеет право доступа к этому URL.

Для работы мобильного приложения на планшете используется тот же механизм — выполняется аутентификация с помощью службы каталогов для получения сеансового маркера. Если пользователь не имеет записи в каталоге, приложение получает сообщение об ошибке — доступ запрещен. Если аутентификация прошла успешно, полученный маркер используется в REST URL для доступа к серверным службам.

Адаптеры Worklight

Адаптер IBM Worklight представляет собой транспортный уровень, размещенный на сервере IBM Worklight и используемый для подключения к серверным системам. Этот адаптер можно использовать для извлечения информации и выполнения операций с базой данных, службой REST и другими компонентами. Имеются адаптеры трех типов — адаптер SQL, адаптер HTTP и адаптер IBM® Cast Iron®. Адаптер реализован с помощью файла XML, файла JavaScript и при необходимости файла XSL (расширяемый язык стилей). Файл XML содержит информацию о подключении и определяет процедуры, доступные мобильному приложению. Файл JavaScript определяет реализацию процедур. Необязательный файл XSL хранит схему преобразования для обработки исходных данных XML. Адаптер возвращает данные в формате JavaScript Object Notation (JSON). Возвращаемые процедурой данные обрабатываются функцией обратного вызова JavaScript.

В прототипе мы использовали для подключения к серверным службам REST адаптер HTTP. Для каждой службы REST задается свой адаптер. Кроме того, мы определили файл вспомогательного адаптера JavaScript, который вызывает процедуры адаптера и определяет функции обратного вызова для обработки возвращаемых данных и ошибок. Этот вспомогательный файл инкапсулирует ассоциацию между адаптером и процедурой. Таким образом, файлы JavaScript, поддерживающие отображение мобильного приложения, могут вызывать функции во вспомогательном файле, не имея информации об используемом адаптере.


Разработка мобильного приложения

Уникальная особенность мобильных приложений, созданных с помощью IBM Worklight, заключается в том, что они реализуются на основе HTML5, JavaScript и каскадных таблиц стилей (CSS) — стандартных технологий Web-разработки. В результате при разработке приложение Worklight можно использовать передовые методы разработки Web-приложений. Конструкция прототипа отражает текущие тенденции Web-проектирования: улучшение восприятия пользователем за счет применения модели одностраничного приложения (SPA) по сравнению со старыми моделями Web 1.0 и Web 2.0. Поскольку IBM Worklight поддерживает HTML5 в гибридных мобильных приложениях, при проектировании мы смогли использовать SPA.

В модели Web 1.0 приложения в процессе работы переходят с одной Web-страницы на другую. Обычно приложения переходят к другому виду, когда пользователь воздействует на элементы страницы (такие как гиперссылки и кнопки передачи форм), заставляя браузер отправлять серверу запрос на загрузку совершенно новой страницы. После получения от сервера данных новой страницы эта новая страница отрисовывается на экране. При наличии сетевых задержек пользователь будет наблюдать заметные прерывания во время загрузки страниц. При этом неизменные элементы страницы, такие как элементы управления навигацией, панели инструментов и изображения, передаются по сети повторно. Такая конструкция реализуется очень легко, но, как правило, приводит к усложнению интерфейса пользователя, делая его более медленным и неудобным.

В приложениях Web 2.0, реализованных с помощью Ajax (асинхронного JavaScript + XML), отдельные элементы Web-страницы могут изменяться без обновления всей страницы. Более тонкая гранулярность и асинхронность операций улучшают восприятие пользователями, но эта конструкция более трудоемка в разработке как со стороны сервера, так и со стороны клиента.

Современные продвинутые браузеры и мощное оборудование позволяют использовать передовую модель SPA. Большую часть работа Web-приложения — построение HTML, обработку данных и реализацию бизнес-логики — берет на себя браузер на стороне клиента. В сеансе SPA все представления и вся логика приложения загружаются в результате загрузки одной страницы. Клиент обращается к серверу только для аутентификации или для синхронизации данных. При отправке последующих запросов к серверу обработка этих запросов выполняется в фоновом режиме. Все взаимодействия с пользователем и изменения состояния приложения выполняются в контексте одного Web-документа. Сетевые задержки становятся менее заметными, а работа пользователя становится динамичной и комфортной, напоминающей работу с «родным» приложением, независимо от того, что использует пользователь – браузер на настольном ПК или мобильное приложение (даже в случае неустойчивого 3G-соединения).

Модель-представление-контроллер

При использовании SPA представление приложения получается путем загрузки одной страницы, а данные запрашиваются у сервера позже. Поэтому для отделения уровня данных от уровня представления мы используем архитектуру Модель-представление-контроллер (MVC). Архитектура MVC позволяет эффективно сопоставлять пользовательский интерфейс с нижележащими моделями данных. Как и следует из названия, MVC состоит из трех компонентов:

  • модель содержит данные приложений и бизнес-правила;
  • контроллер принимает входные данные, преобразуя их в команды для модели и представления;
  • представление может быть любым выходным отображением данных, например, графиком или диаграммой. Возможно представление одних и тех же данных разными способами, например, в виде круговой диаграммы для менеджеров и в виде таблицы для бухгалтеров.

Основными концепциями, которые используются в MVC, являются многократное использование кода и разделение ответственности. Взаимосвязь компонентов архитектуры MVC показана на рисунке 2:

Рисунок 2. Структурная схема MVC
Diagram of the interaction among the user, model, view, and controller in an MVC design pattern

Поскольку все представления тесно связаны с моделью данных, MVC хорошо вписывается в архитектуру SPA. Вы можете создавать представления, не заботясь о логике используемой модели данных. На рисунке 3 показано, как мы использовали архитектуру MVC в нашем мобильном приложении и интегрировали ее с адаптерами сервера IBM Worklight:

Рисунок 3. Архитектура MVC в мобильном приложении
Diagram showing implementation of the MVC design in a mobile app using HTML5 and JavaScript

Среда разработки

Мобильное приложение разрабатывалось с помощью IBM Worklight Studio как гибридное приложение с использованием HTML5 и JavaScript с Dojo Toolkit — интегрированной средой JavaScript. Благодаря применению IBM Worklight приложение может работать на разных мобильных платформах (iOS, Android, Microsoft Windows Mobile и Blackberry) без какой-либо адаптации. Кроме того, с помощью HTML5 удалось создать насыщенный визуальный интерфейс, сравнимый с интерфейсом нативного мобильного приложения.

Поскольку HTML5 не имеет доступа к собственным функциям мобильного устройства, таким как GPS, камера, звук и адресная книга, IBM Worklight использует Apache Cordova для добавления поддержки собственных функций. Детальная информация приведена ниже в разделе Поддержка собственных функций устройства..

Набор инструментов Dojo

Архитектура SPA и MVC позволяет создавать динамичные и быстродействующие гибридные мобильные приложения. Для добавления стиля и для поддержки собственных тем мобильного устройств, а также прочих функций, мы использовали интегральную среду Dojo:

  • Dojo MVC предоставляет серверные функции для привязки данных представления к модели (например, контроллер представления) на стороне клиента, что позволило создать информационно насыщенный интерфейс.
  • Dojo Touch предоставляет набор событий, одинаково управляемых как в браузере (например, мышью), так и на сенсорном экране устройств. Разработчик может сосредоточиться на программировании одного набора событий вместо отдельной работы с мышью и сенсорным экраном.
  • Dojo Theme обеспечивает поддержку тем для нескольких мобильных платформ.
  • Виджеты Dojo Mobile предлагают стандартные панели прокрутки и списки, соответствующие собственному стилю мобильного устройства, к которому привыкли пользователи.

Основные компоненты

Архитектура SPA содержит следующие основные компоненты:

  • router.js:
    • Заранее загружает представления
    • Прослушивает загрузку представления и выгружает сообщения
    • Выполняет инициализацию представлений и запускает модули
  • domModifier.js
    • Управляет элементами DOM (объектной модели документа), такими как панель инструментов и меню, и обновляет их
    • Управляет загрузкой экрана и исполняет обратные вызовы после загрузки
  • connector.js
    • Вызывает службы REST
    • Контролирует достоверность данных
    • Упаковывает модели данных для представлений

По своей природе эта конструкция универсальна и может применяться и в других мобильных приложениях.

Специальный виджет для всплывающих панелей

Типовые представления

Обычно врач начинает работу с представления пациента. Это начальное представление содержит данные пациента из EMR, относящиеся к его лечению. Врач может нажать кнопку и посмотреть возможные варианты лечения пациента или открыть соответствующую модель рисков. Для произвольного вывода на экран нескольких представлений используются всплывающие панели. Это отличается от работы со стандартным деревом навигации, в котором пользователь должен открывать представления в иерархическом порядке в соответствии со структурой дерева.

Когда врач просматривает данные пациента в браузерном или мобильном приложении, на экран выводится большой объем информации, полученной из EMR пациента и из результатов IBM Watson, включая симптомы и рекомендации. При работе с браузерным приложением можно использовать большой монитор и древовидную структуру для перемещения по страницам. На маленьком экране планшета вывод такого объема информации более проблематичен. При этом часто пользователь хочет сравнить результаты двух и более панелей, которые могут находиться в разных ветвях дерева.

Для решения этой проблемы мы создали специальный виджет, который может открывать несколько представлений одновременно, что позволяет пользователю легко перемещаться по представлениям.

Виджет строит и загружает любую страницу HTML за одно обращение к API. Он автономен и учитывает размер экрана. Виджет предназначен для работы с мобильными устройствами и обрабатывает все жесты, такие как проведение пальцем для прокрутки и сдвиг пальцев для закрытия окна. При работе учитываются все открытые панели; управление компоновкой и анимацией производится автоматически.

Виджет можно повторно применять в других приложениях, которые требуют отображения большого объема информации.

Структура манипулирования DOM

В архитектуре SPA на работу с элементами DOM на Web-странице оказывают влияние два фактора. Во-первых, поскольку представления постоянно выводятся на экран и убираются с экрана, элементы DOM постоянно обновляются при выводе на экран новых представлений. Во-вторых, в ходе разработки сложных приложений корпоративного класса несколько членов группы могут одновременно разрабатывать разные представления. В связи с этим для управления элементами DOM разработчикам необходимо применять структурированный подход, чтобы два представления не пытались обновить элемент DOM одновременно.

В прототипе мы использовали структуру работы с DOM, основанную на событиях. В роли управляющего компонента выступает контроллер, который отслеживает все представления и является единой точкой входа для манипуляций с DOM.

Каждое представление регистрирует в контроллере заранее определенную функцию запуска и очистки. Контроллер исполняет соответствующие функции запуска или очистки, когда от представления поступает событие загрузки или выгрузки. Все правила работы с DOM определены в функциях запуска и очистки. Такая структура работы с DOM позволяет вести разработку большой командой, повышая эффективность коллективной работы и упрощая отладку.


Поддержка собственных функций устройства

Мобильные устройства имеют ряд функций, недоступных в типичных настольных компьютерах. Чтобы воспользоваться этими функциями и расширить возможности по сравнению с браузерным приложением, в мобильном приложении добавлена поддержка звука и камеры. Врач может продиктовать сообщение в IBM Watson через планшетное приложение и сфотографировать пациента с помощью встроенной в планшет камеры. Сначала мы ввели эти функции в представлении Рейтинг для каждого варианта лечения, но их можно использовать при необходимости и в других представлениях.

В представлении Рейтинг врач может оценить действенность лечения. Когда врач нажимает на звездочку у возможного варианта решения, появляется всплывающее окно Рейтинг, в котором можно выбрать рейтинг и ввести комментарии. Врач может ввести комментарии, нажать на значок микрофона и записать сообщение или нажать на значок камеры и сделать снимок.

Если врач раньше уже вводил текстовые комментарии к лечению пациента, существующие комментарии отображаются и становятся доступны для редактирования. В этом случае вместе с текстовыми комментариями появляются значки воспроизведения и отображения соответствующих голосовых записей и снимков. Врач может стереть эти звуковые файлы и изображения и записать их заново. Для выбранного способа лечения отображаются надиктованные комментарии и снимки всех пользователей, но обновлять разрешается только собственные файлы.

В настоящее время диктовки и снимки можно только воспроизводить (диктовки) или отображать (снимки) с целью просмотра. В будущем мы, вероятно, применим систему преобразования речи в текст или службу ручной транскрипции для преобразования звуковых записей в текст, который затем будет использоваться в качестве входных данных для IBM Watson. В этом сценарии преобразованный текст будет отображаться в виде текста в секции комментариев.

Звук и камера

Для доступа к собственным функциям устройства и для обеспечения переносимости между мобильными платформами мобильное приложение использует Apache Cordova 2.2. Эта библиотека, поставляемая с IBM Worklight Studio, позволяет переносить приложения между устройствами под iOS и Android.

Для записи звука мы использовали медиа-объект Cordova API, который позволяет записывать и воспроизводить звуковые файлы на широком диапазоне мобильных устройств. Аналогичным образом для поддержки камеры на нескольких мобильных платформах мы использовали API Cordova camera.getPicture Этот API используется либо для выполнения снимка камерой планшета, либо для извлечения существующего снимка из фотоальбома. Снимок возвращается в виде строки в кодировке base64 или в виде ссылки на файл изображения.

Хранилище контента

Файлы звуков и изображений сохраняются на локальном накопителе устройства. Для постоянного сохранения этих файлов на сервере мы использовали хранилище контента, основанное на спецификации хранилища контента Java (JCR). Такой подход позволяет приложению работать со всеми программами на основе JCR, такими как Apache Sling или IBM Web Content Management. Мы использовали Apache Sling, который включает продукт Apache Jackrabbit.

Спецификация JCR предлагает следующие функции:

  • абстрактное хранилище данных разного типа: малых и больших, структурированных и неструктурированных, двоичных, метаданных и взаимосвязей;
  • универсальные службы контента: управление доступом, блокировка, управление версиями, транзакции и наблюдения;
  • отделение реального хранилища от взаимодействий приложений;
  • стандартный API.

На рисунке 4 показана модель JCR, включающая следующие элементы:

  • рабочие пространства;
  • иерархию узлов;
  • свойства, относящиеся к узлу.
Рисунок 4. Модель хранилища контента Java
Diagram of the Java Content Repository model

Apache Sling, основанный на спецификации JCR, включает следующие элементы:

  • OSGi - Sling создан с помощью пакета OSGi и использует службы ядра и каталога OSGi.
  • Web API - этот API основан на контенте Web-приложений расширяет API сервлетов Java и добавляет функции для работы с контентом.
  • Обработка запросов – запрос в виде URL преобразуется в ресурс. Затем, только на основе этого ресурса, Sling выбирает сервлет или сценарий для обработки запроса.
  • Ресурсы – ресурсы, адресуемые через запросы URL.
  • Сервлеты и сценарии - сервлеты и сценарии обрабатываются так же, как и сами ресурсы, и доступны посредством resource path.
  • Панель запуска - Sling использует модуль «тонкого» запуска для интеграции с существующим контейнером сервлета, запуска Sling в виде Web-приложения или предоставления класса main для представления автономного приложения Java.

Интеграция с мобильным приложением

На рисунке 5 показана полная инфраструктура, поддерживающая запись звуков и изображений:

Рисунок 5. Интеграция поддержки звука и камеры в мобильное приложение
Diagram showing the integrating of audio and camera support to mobile app

Сначала файлы звука и изображения сохраняются в памяти устройства. Затем они переносятся в JCR на сервер для постоянного хранения. Мобильное приложение отправляет запрос HTTP POST прямо в сервис JCR REST, передавая в качестве звуки и изображения в качестве содержимого, что повышает производительность, так как исключается лишний проход через адаптер. Данные сохраняются в JCR в виде объектов, доступных через URL. Поскольку JCR API требует аутентификации, приложение использует тот же механизм аутентификации, что и браузерное приложение. Когда JCR возвращает URL, указывающие на новые объекты в хранилище, мобильное приложение вызывает адаптер IBM Worklight для сохранения URL в существующей таблице IBM DB2®. Объекты ассоциируются с пользователем, поэтому этот пользователь может их впоследствии извлекать.

Когда отображается представление Рейтинг, мобильное приложение с помощью адаптера IBM Worklight извлекает из таблицы текстовые комментарии и ссылки URL на файлы звука и изображения. Текст отображается в окне комментариев, а ссылки на файлы звука и изображения отображаются в виде значков для воспроизведения или просмотра. Когда пользователь щелкает на значке воспроизведения или просмотра, приложение отправляет команду HTTP GET в службу JCR REST для извлечения соответствующего файла звука или изображения.

Cordova поддерживает выгрузку файлов из мобильного устройства на файловый сервер и загрузку файлов с файлового сервера в мобильное устройство. Например, фрагмент кода Cordova, приведенный в листинге 1, выгружает файлы звука и изображения на сервер JCR:

Листинг 1. Фрагмент кода Cordova для выгрузки файла
// Установка опций
var options = new FileUploadOptions(); 
options.fileKey = 'audio';  // или 'photo' для изображений
options.fileName = filename;
options.mimeType = "audio/vnd.wave";  // or "image/jpeg" for photos
options.chunkedMode = true;
// Установка заголовка безопасности
var headers = {Authorization:'Basic YWRtaW46YWRtaW4=');
options.headers = headers;
//  Выгрузка файла звука или изображения
var transfer = new FileTransfer(); 
transfer.upload (localFileURI, serverURI, success, failure, options);

Проблемы и соображения

Разрабатывая мобильное приложение для здравоохранения, мы столкнулись с проблемами, поставившими перед нами ряд вопросов, на которые еще предстоит ответить.

Персональная информация о состоянии здоровья

Поскольку сценарии применения в здравоохранении могут включать обработку персональной информации о состоянии здоровья (PHI), критически важную роль играет безопасность. Мобильное устройство дает гибкость, но добавляет потенциальные сложности управления безопасностью. Вот некоторые области, которым нужно уделить особое внимание:

  • Управление доступом к приложению: можно использовать обычный вход пользователя в систему, но в зависимости от политики клиента и действующего законодательства могут потребоваться дополнительные меры безопасности. Например, сервер может проверять идентификатор устройства или идентификатор абонента.
  • Передача PHI через радиоинтерфейс: может потребоваться шифрование (которое должно отвечать стандартам клиента).
  • Сохранение PHI на локальном накопителе мобильного устройства: локально сохраненные данные позволяют использовать приложение в оффлайновом режиме и обновлять информацию на сервере при восстановлении сетевого подключения. Клиент должен выбрать политику безопасности для работы с локальным хранилищем. IBM Worklight поддерживает работу с хранилищем JSON, которое использует шифрование на локальном накопителе устройства.
  • Управление устройствами: организация может потребовать обязательного применения политики безопасности, например, правила назначения паролей или запрещение доступа при потере устройства. Такую поддержку обеспечивает IBM® Tivoli® Endpoint Manager for Mobile.

Текущий прототип использует для управления доступом простой вход в систему. Законченное решение, поддерживающее безопасность PHI, должно учитывать политики клиента и используемые им процедуры для соблюдения действующего законодательства, относящегося к PHI.

Согласованность браузерного и мобильного приложений

Обычно в корпоративных системах уже имеются привычные пользователям браузерные приложения. Создаваемые позже интерфейсы пользователя мобильных приложений должны соответствовать интерфейсам своих браузерных собратьев, чтобы пользователи могли свободно между ними переключаться. Базовой темой (цветовой схемой, графикой и компоновкой) можно управлять через соответствующую CSS в проекте IBM Worklight. Но во многих случаях браузерное и мобильное приложения предполагают разную функциональность. Например, ввод данных может быть проще выполнять в браузерном приложении, а в мобильном приложении возможности ввода могут быть ограничены. Просмотр результатов в мобильном приложении может быть более естественным и управляться жестами.

Повторно используемые ресурсы

Важным аспектом является возможность повторного применения ресурсов проекта в других проектах или обмена ими с другими группами разработчиков. Этот аспект особенно важен, поскольку мы хотим вынести из этого упражнения некоторые уроки, например:

  • Шаблон проектирования MVC: хотя архитектура MVC широко применяется в браузерных приложениях, мы обнаружили, что она в равной степени применима и к мобильным приложениям. MVC помогает разрабатывать и сопровождать сложные мобильные приложения в более контролируемой форме.
  • Хранилище фото и аудио объектов: мы обнаружили, что вместо сохранения этих двоичных объектов в базе данных значительно проще и удобней использовать для этого файловое хранилище JCR. Эту конструкцию и реализацию можно с уверенностью использовать в других проектах.
  • Всплывающие панели: этот новый конструктивный элемент упрощает разработку приложений и предлагает более естественный способ перемещения в сложной структуре представлений.

Как правило, мобильные приложения фокусируются на конкретном сценарии применения, а не повторяют функциональность браузерного приложения. В приложениях этого проекта мы старались использовать единое оформление и единый стиль навигации, чтобы пользователи могли легко находить то, что им нужно. Для оптимизации работы пользователя приложения предлагают различные способы взаимодействия. В мобильном приложении пользователи могут использовать взмах, сдвиг пальцев, нажатие вверх и нажатие вниз. Такой подход опирается на текущую практику применения мобильных устройств, но эта область все еще требует проведения дополнительных экспериментов для выявления наилучших приемов работы.

Работа с открытым исходным кодом

Как показывают современные тенденции, применение открытого исходного кода в приложениях постоянно расширяется. В IBM Worklight хорошим примером использования ПО с открытым исходным кодом является Apache Cordova. Кроме того, в прототипе приложения мы использовали Apache Sling для управления звуковыми записями и фотоснимками. В оптимальной ситуации открытый исходный код повышает продуктивность за счет обмена кодами. Продуманное программное обеспечение с открытым исходным кодом, поддерживаемое большим сообществом, может стать стабильной платформой для промышленного применения. Однако в иных случаях могут возникать проблемы поддержки и безопасности.

На некоторых предприятиях, например, в банках, ИТ-политики могут сильно ограничивать применение ПО с открытым исходным кодом. Кроме того, разработчик ПО с открытым исходным кодом обычно полагается на другие компоненты с открытым исходным кодом, что может порождать непредвиденные зависимости. Один из наших клиентов использовал модуль Cordova с открытым исходным кодом для сканирования QR-кода. Сборка мобильного проекта потерпела неудачу из-за отсутствия библиотек в цепочке зависимостей, и на поиск нужных компонентов с открытым исходным кодом пришлось потратить много усилий. Для управления зависимостями и версиями ПО с открытым исходным кодом нужны эффективные инструменты. В качестве модели можно использовать практический опыт Eclipse и Linux.

Dojo Mobile и jQuery

Одним из первых необходимых решений при разработке мобильного приложения является выбор интерфейса пользователя. IBM Worklight Studio поддерживает разработку как с помощью Dojo Mobile, так и с помощью jQuery. Браузерные и мобильные приложения для IBM Watson создавались с помощью Dojo. Мы считаем это решение оптимальным, но наша команда экспериментировала и с jQuery. Вот что нам удалось выяснить:

  • MVC: Dojo Mobile предлагает лучшую встроенную поддержку реализации шаблона проектирования MVC, тогда как jQuery требует применения дополнительной системы, такой как Backbone. Но, с другой стороны, jQuery можно считать более гибким, поскольку разработчик может выбирать наилучшие компоненты.
  • Внешний вид интерфейса и взаимодействие с пользователем: здесь Dojo Mobile и jQuery предлагают примерно равные возможности.
  • Сопровождение программного обеспечения: многие возможности jQuery зависят от надстроек сторонних изготовителей. С появлением новых версий таких компонентов зависимости между ними могут нарушаться. Dojo Toolkit предлагает более продуманную библиотеку для производственных Web-приложений, менее зависимую от сторонних изготовителей.
  • Поддержка разработки: jQuery имеет большее сообщество пользователей, и поддержку найти достаточно легко. jQuery превосходно подходит для создания Web-страниц и стандартных Web-приложений. Но виджеты Dojo рассчитаны на применение в производственных Web-приложениях, сам Dojo является надежным и гибким строительным блоком для наших приложений, а его функции легко расширяются.

Заключение

В этой статье мы описали полную разработку и реализацию расширенного прототипа мобильного приложения для IBM Watson. Мы в полной мере использовали возможности среды разработки IBM Worklight Studio и воспользовались системой Dojo Mobile, библиотекой Cordova и другими компонентами с открытым исходным кодом. Созданное нами мобильное приложение дополняет браузерное приложение, предоставляя врачам доступ к решению IBM Watson во время осмотра пациента или за пределами офиса. При создании гибридного мобильного приложения нам пришлось решить ряд проблем, чтобы его скорость реакции не уступала нативному приложению. Кроме того, мобильное приложение позволяет работать с мобильными устройствами, что дает врачам новые средства повышения продуктивности повседневной работы. Мы надеемся, что многократно применяемые ресурсы, решения и уроки, вынесенные из этого проекта, будут полезны другим группам, занятым разработкой мобильных приложений.

Благодарности

Мы хотим выразить благодарность тем, кто помогал нам в реализации этого проекта:

  • Анхелю Диасу (Angel Diaz), Уилли Чиу (Willy Chiu) и Ларри Сюну (Larry Hsiung) из Cloud Labs и группы управления HiPODS
  • Нашим коллегам Рахулу Джайну (Rahul Jain), Крису Кирнану (Chris Kiernan), Чину Хуану (Chin Huang), Раймонду Вону (Raymond Wong) и Теду Хао (Ted Hao) из группы Cloud Labs и HiPODS
  • Робу Хаю (Rob High), Биллу Хьюму (Bill Hume), Джеффу Эйзнеру (Jeff Eisner) и Джаяшри Субрахмония (Jayashree Subrahmonia) из группы управления IBM Watson
  • Мэтью Санчесу (Matthew Sanchez), Эду Сиболту (Ed Seabolt), Эндрю Ортману (Andrew Ortman), Джону Рихтеру (Jon Richter) и Майклу Холмсу (Michael Holmes) из группы решений и группы клиентов IBM Watson

Ресурсы

Научиться

  • Оригинал статьи: Prototype mobile applications built with IBM Worklight for IBM Watson.
  • Getting started with IBM Worklight V6.0 (Начинаем работу с IBM Worklight V6.0): Модули для самостоятельного изучения, упражнения и примеры кода, приведенные на этой странице, помогут вам приступить к созданию, тестированию и внедрению приложений для устройств iOS, Android, Blackberry и Windows Phone.
  • Dojo Toolkit API: познакомьтесь с документацией на Dojo Toolkit API.
  • Developing mobile apps as medical devices (Разработка мобильных приложений как медицинских устройств: требования законодательных актов США) (Эрин Гилмер (Erin Gilmer), developerWorks, апрель 2013): прочтите подробный обзор опубликованных нормативов Управления по контролю за продуктами и лекарствами США, относящихся к применению мобильных медицинских устройств, и узнайте, как они влияют на разработку мобильных приложений.
  • Раздел мобильных приложений на портале developerWorks: опробуйте последние инструменты и технологии для разработчиков мобильных приложений из всеобъемлющей линейки продуктов IBM MobileFirst. Познакомьтесь с нашим бесплатным загружаемым ПО и пробными версиями облачных приложений, образцами кода, советами экспертов, видеороликами, учебными материалами и обсуждениями.
  • Информационный центр IBM Watson: узнайте о возможных способах применения IBM Watson в вашей организации.
  • Демонстрация IBM Watson: диагностика и лечение онкологических заболеваний:: этот видеоролик показывает взаимодействие гипотетического онколога с пациентом и демонстрирует, как они проходят этапы консультации, анализов, выбора способа лечения, предпочтений пациента и предварительной авторизации.
  • Memorial Sloan-Kettering Cancer Center case study (Ситуационное исследование в онкологическом центре имени Слоана-Кеттеринга): прочтите о роли IBM Watson в борьбе с раком и познакомьтесь с основанными на симптомах диагнозами и предложенными методами лечения.
  • Wellpoint, Inc. case study (Ситуационное исследование в Wellpoint, Inc.): узнайте, как решение IBM Watson помогло повысить качество и эффективность принятия решений в Wellpoint.

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Мобильные приложения, Технология Java
ArticleID=955663
ArticleTitle=Создание прототипов мобильных приложений с помощью IBM Worklight для IBM Watson
publish-date=11032013