All issues

В статье представлена технология построения систем поддержки принятия врачебных решений (СППВР), основанная на сервис-контейнерах с использованием Docker и веб-интерфейсе, работающем непосредственно в браузере без установки специализированного программного обеспечения на рабочую станцию врача. Предложена модульная архитектура, где для каждого прикладного модуля формируется самостоятельный сервис-контейнер, объединяющий мини-веб-сервер, пользовательский интерфейс и вычислительные компоненты обработки медицинских изображений. Взаимодействие между браузером и серверной частью реализовано через постоянное двунаправленное соединение по веб-сокетам с бинарной сериализацией сообщений в формате MessagePack, что обеспечивает малые задержки и эффективную передачу больших объeмов данных. Для локального хранения изображений и результатов анализа применены средства браузера (IndexedDB) с оболочкой Dexie.js, что ускоряет повторный доступ к данным. Трeхмерная визуализация и базовые операции с DICOM-данными реализованы с использованием библиотек Three.js и AMI.js: такая связка обеспечивает интеграцию интерактивных элементов, возникающих в контексте задачи (аннотации, ориентиры, метки, 3D-модели), в трeхмерные медицинские изображения.

Серверные компоненты и функциональные модули собраны в виде набора взаимодействующих контейнеров, управляемых средствами Docker. Рассмотрены выбор базовых образов, подходы к минимизации контейнеров до уровня исполняемых файлов без внешних зависимостей, организация многоступенчатой сборки, включающей отдельный «сборочный» контейнер. Описан сервис-хаб, выполняющий запуск прикладных контейнеров по обращению пользователя, проксирование запросов, управление сессиями и перевод контейнера из общего режима в монопольный при начале вычислений. Приведены примеры прикладных модулей (оценка фракционного резерва кровотока, расчeт количественного отношения потока, расчет смыкания створок аортального клапана), показана интеграция React-интерфейса и трeхмерной сцены, а также представлены политика версионирования, автоматизированные проверки воспроизводимости результатов и порядок развeртывания на целевой площадке.

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

The article presents a technology for building clinical decision support systems (CDSS) based on service containers using Docker and a web interface that runs directly in the browser without installing specialized software on workstation of a clinician. A modular architecture is proposed in which each application module is packaged as an independent service container combining a lightweight web server, a user interface, and computational components for medical image processing. Communication between the browser and the server side is implemented via a persistent bidirectional WebSocket connection with binary message serialization (MessagePack), which provides low latency and efficient transfer of large data. For local storage of images and analysis of results, browser facilities (IndexedDB with the Dexie.js wrapper) are used to speed up repeated data access. Three-dimensional visualization and basic operations with DICOM data are implemented with Three.js and AMI.js: this toolchain supports the integration of interactive elements arising from the task context (annotations, landmarks, markers, 3D models) into volumetric medical images.

Server components and functional modules are assembled as a set of interacting containers managed by Docker. The paper discusses the choice of base images, approaches to minimizing containers down to runtime-only executables without external utilities, and the organization of multi-stage builds with a dedicated build container. It describes a hub service that launches application containers on user request, performs request proxying, manages sessions, and switches a container from shared to exclusive mode at the start of computations. Examples of application modules are provided (fractional flow reserve estimation, quantitative flow ratio computation, aortic valve closure modeling), along with the integration of a React-based interface with a three-dimensional scene, a versioning policy, automated reproducibility checks, and the deployment procedure on the target platform.

It is demonstrated that containerization ensures portability and reproducibility of the software environment, dependency isolation and scalability, while the browser-based interface provides accessibility, reduced infrastructure requirements, and interactive real-time visualization of medical data. Technical limitations are noted (dependence on versions of visualization libraries and data formats) together with practical mitigation measures.

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

Storage is the essential and expensive part of cloud computation both from the point of view of network requirements and data access organization. So the choice of storage architecture can be crucial for any application. In this article we can look at the types of cloud architectures for data processing and data storage based on the proven technology of enterprise storage. The advantage of cloud computing is the ability to virtualize and share resources among different applications for better server utilization. We are discussing and evaluating distributed data processing, database architectures for cloud computing and database query in the local network and for real time conditions.

Одним из наиболее широко используемых решений для хранения данных в WLCG является Disk Pool Manager (DPM), разрабатываемый и поддерживаемый группой SDC/ID в ЦЕРНе. Недавно старый код DPM был практически переписан с нуля для решения накопившихся проблем с масштабируемостью и расширением функциональности.

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

DMLite имеет модульную архитектуру, при которой основная библиотека обеспечивает только несколько базовых функций. Системы хранения данных, а также протоколы доступа к ним реализованы в виде подключаемых модулей (plug-ins). Конечно, DMLite не смогла бы полностью заменить DPM без поддержки протокола GridFTP, наиболее широко используемого для передачи данных в WLCG.

В DPM поддержка протокола GridFTP была реализована в виде модуля Data Storage Interface (DSI) для GridFTP сервера Globus. В DMLite было решено переписать модуль GridFTP с нуля, чтобы, во-первых, воспользоваться новыми возможностями DMLite, а во-вторых, добавить недостающую функциональность. Наиболее важным отличием по сравнению со старой версией является возможность перенаправления соединений.

При использовании старого интерфейса GridFTP клиенту было необходимо предварительно связаться со службой SRM на головном узле хранилища, чтобы получить Transfer URL (TURL), необходимый для обращения к файлу. С новым интерфейсом GridFTP делать этот промежуточный шаг не требуется: клиент может сразу подключиться к службе GridFTP на головном узле хранилища и выполнять чтение-запись используя логические имена файлов (LFNs). Канал передачи данных при этом будет автоматически перенаправлен на соответствующий дисковый узел.

Такая схема работы делает одну из наиболее часто используемых функций SRM ненужной, упрощает доступ к файлам и повышает производительность. Это также делает DMLite более привлекательным выбором для виртуальных организаций, не относящихся к БАК, поскольку они никогда не были особо заинтересованы в SRM.

Новый интерфейс GridFTP также открывает возможности для хранения данных на множестве альтернативных систем, поддерживаемых DMLite, таких как HDFS, S3 и существующие пулы DPM.

One of the most widely used storage solutions in WLCG is a Disk Pool Manager (DPM) developed and supported by SDC/ID group at CERN. Recently DPM went through a massive overhaul to address scalability and extensibility issues of the old code.

New system was called DMLite. Unlike the old DPM that was based on daemons, DMLite is arranged as a library that can be loaded directly by an application. This approach greatly improves performance and transaction rate by avoiding unnecessary inter-process communication via network as well as threading bottlenecks.

DMLite has a modular architecture with its core library providing only the very basic functionality. Backends (storage engines) and frontends (data access protocols) are implemented as plug-in modules. Doubtlessly DMLite wouldn't be able to completely replace DPM without GridFTP as it is used for most of the data transfers in WLCG.

In DPM GridFTP support was implemented in a Data Storage Interface (DSI) module for Globus’ GridFTP server. In DMLite an effort was made to rewrite a GridFTP module from scratch in order to take advantage of new DMLite features and also implement new functionality. The most important improvement over the old version is a redirection capability.

With old GridFTP frontend a client needed to contact SRM on the head node in order to obtain a transfer URL (TURL) before reading or writing a file. With new GridFTP frontend this is no longer necessary: a client may connect directly to the GridFTP server on the head node and perform file I/O using only logical file names (LFNs). Data channel is then automatically redirected to a proper disk node.

This renders the most often used part of SRM unnecessary, simplifies file access and improves performance. It also makes DMLite a more appealing choice for non-LHC VOs that were never much interested in SRM.

With new GridFTP frontend it's also possible to access data on various DMLite-supported backends like HDFS, S3 and legacy DPM.