Модель приложения (Avalanche — application framework for Java)
«Avalanche — application framework for Java» — реализация технологии стирающей различия
между вызовами локального и удаленного кода. Отказоустойчивость, масштабируемость,
модифицируемость, непрерывная доступность идут в комплекте приятными бонусами.
Рассмотренная в этой статье модель приложения родилась на основании собственного опыта реализации и эксплуатации различных интеграционных взаимодействий информационных систем (ИС) и прежде всего была направлена на сокращение использования различных ресурсов (финансовых, трудовых, временных и т.д.) при реализации этих интеграционных решений.
В большинстве предприятий эксплуатируются множество различных систем, автоматизирующих отдельные технологические процессы или работу отдельных структурных подразделений или отделов. В следствии чего возникает потребность организации информационного обмена между этими системами или с информационными системами смежных организаций с целью сокращения эксплуатационных расходов, исключения введения дублируемых данных и рассогласования данных в различных системах (например НСИ), уменьшения влияния человеческого фактора, сокращения временных затрат на обмен информацией.
Потребность интеграции возникает не только в специальном программном обеспечении собственной или заказной разработки, но и в «коробочных» решениях. Стоимость реализации может превосходить ожидаемое сокращение эксплуатационных издержек.
Существующие способы решения вопросов интеграции IT систем:
- Файловый обмен данными
- Обмен сообщениями (является разновидностью файлового обмена)
- Интеграция на уровне модели данных, например, создания специальных объектов базы данных или хранимых процедур
- С использованием RCP (remote call procedure) технологий, например, CORBA, RMI, SOAP, DCOM и т.д.
У всех этих способов реализации интеграционных решений есть одни и те же недостатки: трудоемкость реализации и модификации, низкая повторность использования, необходимость решения вопросов отказоустойчивости, невозможность работы в режиме разноверсионности в процессе установки изменений, трудоемкость эксплуатации и поддержание эксплуатационной документации в актуальном состоянии.
Результатом поиска альтернативы существующим решениям была сформулирована идея преобразования модели MVC (MODEL — VIEW — CONTROLLER) в модель MVFA (MODEL — VIEW — FUNCTION — APPLICATION), разбив CONTROLLER на два программных слоя FUNCTION и APPLICATION между которыми может быть размещена сеть передачи данных (СПД).
Разбиение на функции внутри контролера присутствует в той или иной степени во всех современных IT-системах, особенно, если разработка выполнена с использованием объектно-ориентированных языков программирования. А выделение этих функций в отдельный программный слой решает задачу их повторного использования другими IT-системами.
Выделение в отдельный программный слой объектов «приложение» стандартизирует обращение не только к собственным функциям, но и функциям других систем, что стирает все различия в вызовах «своих» и «чужих» функций.
Для реализации модели MVFA предложена следующая программная модель:
- Функция (Function), любой объект имеющий методы реализации какой либо функциональности ;
- Адаптер (Adapter), декларируемый объект не имеющий реализации. Этот объект обеспечивает связь объектов «приложение» с локальными или удаленными функциями. Для доступа к удаленным функциям используется объект «интерфейс»;
- Коннектор (Connector), обеспечивает доступ к локальным функциям удаленных объектов с помощью объектов «публикация»;
- Публикация (Publish), публикует локальную функцию в коннекторе;
- Интерфейс (Interface), обеспечивает обращение адаптеров к удаленным функциям;
- Приложение (Application), выполняет преобразование данных между представлением и функцией/функциями, также может выступать в роли «функции» для других объектов «приложения».
Пара «интерфейс» — «коннектор» образуют канал передачи данных по какому либо протоколу между различными системами или различными узлами одной системы. Реализованный канал должен иметь способность пропускать требуемые объемы данных.
Существуют специализированные реализации «интерфейсов», не имеющих парных элементов «коннектор», например — интерфейс высокой доступности, который позволяет создавать отказоустойчивые информационные системы. Основное назначение интерфейса высокой доступности — это перенаправление нагрузки на дублирующие узлы при планов или вне плановом отключении одного из узлов системы.
Рассмотренная модель MVFA реализована в программном продукте «Avalanche — application framework for Java», который относится к категории middle ware и предназначен для создания программных кластеров или отказоустойчивых информационных систем высокой доступности.
Конечно, как и у любой технологии, «Avalanche — application framework for Java» имеет некоторые ограничения:
- Любые объекты (типы), декларируемые в адаптерах (входные и возвращаемые параметры), могут быть переданы по сети, а следовательно эти объекты должны реализовывать интерфейс java.lang.Serializable. Локальные объекты вызываются напрямую, без использования операций чтения и записи в поток.
- Не все объекты могут быть переданы по сети. Например, объекты состояние или работоспособность которых зависят от конфигурации узла системы, где они были созданы. К таким объектам можно отнести объекты, реализующие спецификацию javax.sql.DataSource
- Дублирующие узлы системы должны размещаться на разных аппаратных средствах.
- Дублирующие узлы системы не должны выключаться (обслуживаться) одновременно.
Пример простого приложения описан в статье — Первое приложение (Avalanche — application framework for Java)