Поиск решений, управляемый данными, требует постоянного взаимодействия с пользователем. База знаний должна поддерживать одновременную работу нескольких пользователей. В статье рассматриваются основные архитектурные подходы к организации доступа к экспертной системе — локально, в локальной сети и через интернет.
Технические аспекты реализации, такие как REST, SPA, WebSocket, long polling и event sourcing, в рамках статьи не обсуждаются.
Сценарии использования и масштабируемость
Вот основные архитектурные варианты доступа к системе поиска решений:
- Локальная работа. База знаний реплицируется, каждый пользователь работает с собственной копией.
- Локальная сеть, толстый клиент. База знаний размещена на сервере, клиенты на рабочих станциях взаимодействуют с ней. Поиск решений выполняется на стороне клиента.
- Локальная сеть, тонкий клиент. Все вычисления и обработка данных происходят на сервере, клиент — минимальный интерфейс.
Первый вариант обеспечивает автономность, но требует постоянной синхронизации базы знаний. Любые изменения должны оперативно распространяться, иначе возникают коллизии. Этот подход удобен при разработке, отладке или для личного использования, когда нет необходимости делиться данными.
Второй вариант устраняет необходимость репликации, но сохраняет риски коллизий при одновременном редактировании информационного наполнения разными пользователями.
Третий вариант менее требователен к ресурсам клиентских устройств, но также подвержен проблемам согласованности при параллельных изменениях.
Через интернет доступ возможен через браузер или веб-клиент. Теоретически все три архитектуры могут быть эмулированы, но с существенными ограничениями.
Наиболее подходящим для веб-доступа является чисто браузерный интерфейс, ориентированный на эксплуатационный режим: поиск и документирование решений. Основная сложность — отсутствие постоянного соединения с обратной связью. Стандартная модель «запрос-ответ» не сохраняет состояние процесса на сервере между запросами. Однако при поиске решений необходимо хранить всё накопленное состояние: данные, флаги, очереди параметров, промежуточные результаты и отчёты.
Асинхронная схема взаимодействия через браузер
Поиск решений выполняется циклически, и новые данные требуются только по завершении очередного цикла. Это позволяет организовать асинхронное взаимодействие по следующей схеме:
- Браузер передаёт данные и запускает серверный процесс.
- Браузер периодически проверяет готовность ответа.
- Сервер выполняет поиск до момента, когда потребуются дополнительные данные или будет найдено решение.
- Если решение найдено, формируется итоговый отчёт.
- Если поиск продолжается, состояние процесса сохраняется: репозитории блоков, очереди параметров, флаги событий, отчёты и другая накопленная информация.
- Серверный процесс завершается, устанавливается флаг ожидания ответа от браузера.
- Браузер обнаруживает готовность данных и забирает их.
- Браузер анализирует данные и управляющие сигналы: завершение процесса или запрос дополнительной информации.
- При необходимости — передаёт новые данные и перезапускает процесс.
- Сервер восстанавливает состояние и продолжает поиск с точки остановки.
- Если процесс продолжается — цикл повторяется с шага 3.
- Если поступила команда остановки — процесс завершается с формированием итоговой информации.
- Браузер завершает сеанс.
Примечание: во время паузы пользователь может запрашивать справочную информацию. В этом случае обмен данными продолжается, но цикл поиска не запускается.
Предотвращение и разрешение коллизий
Коллизии при одновременном изменении данных — распространённая проблема. В системах на основе информационных блоков и терминологического словаря она усложняется. Простое сравнение данных по позициям не работает.
Изменения в словаре легче отслеживать, поскольку его терминологическая часть представляет собой таблицу записей с фиксированным набором атрибутов. Однако словарь включает и сопутствующие данные: оригиналы документов, изображения, связи между статьями и компонентами системы.
Изменения в информационных блоках требуют специальных подходов. Полный запрет на редактирование возможен только при идеальном и статичном наполнении, чего в реальных системах не бывает. Поэтому необходимо вводить правила, минимизирующие дестабилизацию системы.
Правило 1. Запрет одновременного редактирования одного информационного блока с разных мест. На время редактирования доступ для изменений блокируется со всех остальных точек. Альтернативно — изменения не сохраняются, удаляются или сохраняются как конфликтные документы для последующего анализа. Такие механизмы типичны для распределённых систем с репликацией.
Правило 2. Любое изменение в блоке должно инициировать проверку других блоков и восстановление целостности. Например, изменение диапазона допустимых значений параметра в блоке А требует проверки всех блоков, где этот параметр используется для определения одного и того же результата. Необходимо проверять пересечение диапазонов, чтобы избежать неопределённости.
Правило 3. После внесения изменений автоматически запускаются базовые тесты. Если затронуты сохранённые цепочки обработки, они усекаются до точки изменения, чтобы предотвратить использование устаревших или некорректных данных.
Можно предложить и более сложные методы обеспечения целостности, но ключевое преимущество системы из информационных блоков — прозрачность и относительная простота контроля согласованности.
Заключение
Автономная работа с экспертной системой удобна при создании, отладке и тестировании информационного наполнения, а также при индивидуальном использовании без потребности в совместной работе.
Во всех остальных случаях — при коллективной работе или доступе через интернет — предпочтительны клиент-серверные архитектуры.
В следующей статье серии будут рассмотрены перспективы применения технологии накопления и сохранения логически правильных решений.