Comments 25
Рассмотренная в этой статье модель приложения родилась на основании собственного опыта реализации и эксплуатации различных интеграционных взаимодействий информационных систем (ИС) и прежде всего была направлена на сокращение использования различных ресурсов (финансовых, трудовых, временных и т.д.) при реализации этих интеграционных решений.
[...]
Существующие способы решения вопросов интеграции IT систем:
[...]
Результатом поиска альтернативы существующим решениям была сформулирована идея...
Подождите-подождите. Давайте прямо сразу определимся: вы решаете задачу разработки одной системы, или задачу интеграции нескольких различных систем?
Сразу обе. Задачи сходны между собой.
И вас не капли не смущает, что в случае интеграции различных систем у вас намного меньше контроля над платформой, на которой разработаны интегрируемые системы, и даже над протоколом интеграции?
Проще говоря, вам могут поставить задачу на интеграцию с готовой системой, которая умеет только json-over-HTTP. Согласитесь, это гигантское различие по сравнению с "я могу написать свою систему на любой удобной мне платформе и соединить любым удобным мне образом"?
Так подобные вопросы возникают и сейчас, без этого решения, когда возникает вопрос интеграции между системами. Одни разработчики начинают утверждать, что json "пуп земли", другие "мы тут специально создали хранимую процедуру для третьей системы, пользуйтесь ей". В результате, разработчиков приходиться "мирить" заказчику, выбрав один из предложенных вариантов. И этот выбор не всегда оптимальный.
Так подобные вопросы возникают и сейчас, без этого решения
А это не важно. Важно, что задача интеграции нескольких систем сильно отличаются от задачи написания одной системы, поэтому давайте вы определитесь, о какой задаче вы говорите.
Занимаюсь сразу обеими задачами, они одинаковы. Одна задача, является частным случаем другой.
Your words, not mine.
Ну давайте начнем с простого вопроса. Вот надо решить типовую задачу интеграции: есть существующий интернет-магазин, на PHP, он должен отсылать каждый новый заказ в разрабатываемую вами бэк-офис-систему, когда заказ обработан, она должна уведомлять интернет-магазин. Интернет магазин умеет слать уведомления на заданный HTTP-адрес в виде JSON, уведомления от других систем принимает по фиксированному адресу тоже в виде JSON. Схема JSON фиксирована интернет-магазином.
Как ваша модель приложения поможет решить эту задачу, и в чем выигрыш по сравнению с "обычной" реализацией (естественно, под обычной реализацией мы пониманием нормально спроектированную систему, удовлетворяющую DIP)?
Ваш пример не удачный, PHP мало что умеет и "предложить" ему что вне его рамок, думаю дело гиблое. Но и в этом случае, вариантов решений много.
Например, можно написать специализированный коннектор (в терминах Avalanche — application framework for Java).
<connector class="my.package.JSONСonnector" ...
<publish name ... />
</connector> Реализовать класс приложения
<application class="my.package.JSONApplication" service="true" ...
...
</application> Вариантов много
Ваш пример не удачный
Что значит — неудачный? Это реальный случай из жизни, часто встречающаяся задача в интеграции. Я же не зря спросил, какую задачу вы решаете.
Например, можно написать специализированный коннектор
Я и в случае обычного приложения могу написать специализированный интеграционный код. В чем мне польза от вашей модели?
Раз вы решили говорить о проектировании приложения (а не только и исключительно интеграции), то у меня опять-таки есть стартовый вопрос:
Результатом поиска альтернативы существующим решениям была сформулирована идея преобразования модели MVC (MODEL — VIEW — CONTROLLER) в модель MVFA (MODEL — VIEW — FUNCTION — APPLICATION), разбив CONTROLLER на два программных слоя FUNCTION и APPLICATION между которыми может быть размещена сеть передачи данных (СПД).
Пожалуйста, дайте определения используемым вами в вашей модели понятиям Model, View, Function, Application и покажите типичные направления потоков данных и последовательностей вызова.
(ну, знаете, как Фаулер делает в описании MVC… который, кстати, не является моделью построения приложений)
Определения VIEW и MODEL идентичны определениям MVC
FUNCTION — выдает команды манипулирования моделью данных и получает результат этого манипулирования или изменяет состояние элементов системы.
APPLICATION — интерпретирует действия пользователя или по изменениям состояния элементов системы и оповещает функции о необходимости изменения модели или состояния системы.
Элемент APPLICATION может манипулировать множеством элементов FUNCTION.
Элемент APPLICATION может выступать в роли FUNCTION для других элементов FUNCTION, таким образом можно создавать сложную иерархическую структуры объектов.
Определения VIEW и MODEL идентичны определениям MVC
Какого MVC? Лучше приведите используемые вами конкретно определения, это будет намного проще, нежели сначала искать "правильное" сторонее определение.
И сразу еще один вопрос: вы упоминаете некое "состояние элементов системы". Что это такое? Почему оно вынесено отдельно, а не является частью одного из ваших понятий M-V-F-A?
Мне одному кажется что эту проблему уже решили до Вас?
Spring Cloud Data Flow.
Apache Airflow.
Apache Camel.
предложенное решение отличается от перечисленных вами.
Чем?
Прежде всего гибкостью.
Предложенное решение позволяет разрабатывать приложения как "обычные" (эксплуатируемые на одном узле) любого назначения, но которое может быть трансформировано в многоузловую систему без изменения программного кода вашего "обычного" приложения. Для этого достаточно изменить конфигурацию приложения. Добавление в систему избыточных узлов позволяет превратить вашу "обычное" приложение в отказоустойчивую систему опять же без модификации вашего кода, опять же достаточно изменить конфигурацию вашего приложения.
Предложенное решение позволяет горизонтально масштабировать ваше приложение без модификации вашего кода, при этом масштабирование будет практически линейным (если пренебречь потерями на сеть при передаче данных между узлами). Нагрузку между узлами можно разделить практически равномерно — снимаются метрики с каждой функции. Понятно, что нагрузка на ту или иную функциональность системы со временем изменяется и то что поделено на текущих данных статистики 50 на 50 завтра может показать распределение нагрузки, например, 40 на 60.
Предложенное решение позволяет разрабатывать собственные кластерные приложения — опять же любого назначения.
Такой гибкостью не обладают ни одна из перечисленных вами технологий.
Такой гибкостью не обладают ни одна из перечисленных вами технологий
Не соглашусь. Всё что вы перечислили поддерживается Spring Cloud Data Flow. Более того, SCDF is cloud platform agnostic. Выберите clod provider и задеплойте ваше приложение (Flow) куда угодно: kubernetes, cloud foundry, messos, aws даже локально, не изменяя ни строчки кода. Авы так можете?
- "куда угодно" задеплоить не получиться
- задеплоить куда угодно не значит создать распределенное, кластерное или отказоустойчивое приложение.
У SCDF получится задеплоить именно куда угодно именно распределенное кластерное приложение. Ещё и self balanced. Соаетую Вам познакомиться с существующими решениями прежде чем пытаться сделать мир лучше
И все же настаиваю, что куда угодно задеплоить не получиться! Вас в "куда угодно" могут просто не пустить. Предложат Вам передать дистрибутив для самостоятельного деплоя "куда угодно", куда Вы не имеете доступа.
Непременно познакомлюсь. Но из наличие SCDF вовсе не вытекает, что мое решение хуже. Каждое решение разрабатывается под определенные задачи.
Мое направленно на уменьшение кодирования и гибкости при эксплуатации (тут уже описывал, более подробно расписывать не буду).
*
Модель приложения (Avalanche — application framework for Java)